Security posture
This page sets out the controls Arcla operates to secure customer data, how each one is evidenced, and which controls are not yet in place.
It is generated from a control registry held in our codebase. Controls marked as automatically verified are re-checked against our source code on every build, and a control whose evidence is removed fails that build.
We do not hold a SOC 2 report or ISO 27001 certification. Each control below is mapped to the relevant SOC 2 Trust Services Criteria and NIST Cybersecurity Framework functions so a reviewer can work through their own checklist. The mappings are signposts, not a claim of audited compliance.
Scope
This page covers the Arcla production service: the desktop application, the web dashboard, the call processing service, and the infrastructure and third-party providers that support them. It covers the personal data our customers’ use of that service places in our care. It does not cover our customers’ own systems, their identity providers, or the meeting platforms on which their calls take place.
How each control is evidenced
Controls are not all evidenced the same way, and the evidence class is stated for each:
- Automatically verified — checked against our codebase on every build. If the evidence is removed, the build fails.
- Confirmed by us — asserted by a named owner, with a date. Used where code cannot observe the answer, such as who holds a console credential or whether a review took place. These expire after 180 days and must be re-confirmed.
- Contractual — resting on a signed or published agreement, named in the entry.
- Provider default — provided by an infrastructure provider rather than configured by us. Listed separately because we do not operate it.
Control status
Each control carries one of four statuses:
- Operating — in place and running today.
- Operating with limits — running, with a named limitation stated in the entry.
- Planned — committed and tracked, not yet running.
- Not in place — we do not do this.
Summary: 35 operating, 12 operating with limits, 4 planned, 6 not in place.
Governance
Who is accountable, how the team is shaped, and where we stand on certification.
GOV-01 — Named accountability for security
Security is owned by our Chief Technology Officer, who reviews open security findings, approves remediation, and is the point of escalation for any security question or incident.
GOV-02 — Scale of the engineering organisation
Arcla is a small engineering team. At most two people hold production infrastructure access, and no contractor or third party holds production credentials. Our controls are sized to a team of that size.
GOV-03 — Engineering conventions are written and enforced in CI
Our engineering standards are documented in the repository and enforced automatically on every change rather than left to memory, by a suite of repository-specific checks that run in continuous integration. They cover configuration drift, dependency policy and data-handling declarations, and one of them checks that every other check is actually wired into the build.
GOV-04 — Security awareness training
We do not run a formal, recorded security awareness training programme. The people who hold production access are career software engineers, and security practice is maintained through the weekly security review and direct review of each other’s changes. Recorded training is part of our compliance roadmap.
GOV-05 — Written security policies
A formal written policy set (information security, access control, incident response, change management, acceptable use) is not yet published. The practices those policies would describe are in operation and are recorded as the controls on this page; writing them up as policies is committed work rather than an aspiration.
GOV-06 — SOC 2 and ISO 27001 position
Arcla does not hold a SOC 2 report or ISO 27001 certification. SOC 2 is active work: the readiness preparation is complete, the controls on this page are its output, and we are selecting a compliance provider to engage. No observation window has opened.
GOV-07 — Risk assessment
We maintain a risk register recording the risks to customer data, each rated for likelihood and impact, with an owner, a treatment and a review date. It is held as structured data alongside our control registry, and an automated check requires every control that is not fully operating to be covered by a registered risk, so a gap cannot exist without an owned risk behind it. Risks are reviewed quarterly and whenever a control changes status. The register is internal; we can share it under a non-disclosure agreement.
Limitation: The register was established in September 2026, so a full quarterly review cycle has not yet been completed.
GOV-08 — Background checks
We do not currently run background checks on staff with access to customer data.
Access control
Who can reach customer data, and what keeps one organisation’s data away from another’s.
AC-01 — Authentication through a specialist identity provider
User authentication, session management and multi-factor support are handled by Clerk rather than implemented in-house. Access to the platform is invitation-gated during private beta.
AC-02 — Tenant isolation enforced in the database
Each organisation’s data is separated by an organisation identifier enforced by PostgreSQL row-level security, so isolation is enforced by the database itself rather than by application code alone. Row-level security is enabled across the customer data schema.
AC-03 — Per-call isolation of live transcripts
Each call’s live transcript is held in its own isolated storage instance, so the live read path is separated per call by construction rather than by query filtering.
AC-04 — No standing staff access to customer accounts
Arcla staff hold no standing access to customer organisations. Support access is granted per organisation through an internal surface and can be revoked; the revoke path cannot remove a genuine member of the customer’s own team.
AC-05 — Production infrastructure access is limited and named
Production infrastructure access is normally held by one person: our Chief Technology Officer, who is accountable for security. A single named developer is granted the same access when the CTO is unavailable, and nobody else holds production credentials at any time. Access is granted through each provider’s own identity controls.
AC-06 — Periodic access review
A recorded, scheduled review of who holds access to production systems is not yet in place. The access list is at most two people and is known to both, but we do not yet produce a dated review artefact. Introducing a quarterly recorded review is on our roadmap.
AC-07 — Per-record access logging
We do not maintain a log recording which staff member viewed which customer call. Application activity is logged; a per-record access trail is not.
AC-08 — Secrets management
Secrets and environment configuration are held in Doppler as the single source of truth and synchronised to deployment environments automatically rather than entered by hand. Configuration drift between declared and live secrets is checked weekly.
AC-09 — Physical security
Arcla operates no data centre and no office in which customer data is stored. All customer data is held in facilities operated by the infrastructure providers named in our sub-processor register, and physical security is their responsibility under their own certifications.
AC-10 — Granting and revoking access
Access is granted per person and per provider, and is revoked directly in each provider’s console when someone no longer needs it. We do not yet run this from a written joiner and leaver procedure with a recorded checklist, which is what an auditor would expect to see; at the current size of the team the list of systems is short and held by the Chief Technology Officer.
Limitation: No written joiner and leaver procedure, and no recorded checklist per departure.
AC-13 — Edge protection: firewall, bot challenge and rate limiting
All public traffic reaches us through Cloudflare rather than hitting an origin directly. That edge provides always-on DDoS protection, a managed web application firewall, and bot challenges on the paths that attract automated abuse. Rate limiting on our public API is declared as code in our infrastructure repository and applied to the production zone, so the rule is reviewable rather than remembered.
Limitation: Firewall and bot-management settings are configured in the provider’s dashboard rather than held as code, so they cannot be verified from our repository.
AC-11 — Multi-factor authentication on administrative access
Multi-factor authentication is enforced on every administrative console that holds production access, including our source host, our infrastructure providers, our database provider and our secrets manager. This applies to both people who hold production credentials.
AC-12 — Devices that hold production credentials
The laptops used to administer production run full-disk encryption, lock automatically and require strong authentication to unlock, and credentials are held in a password manager rather than in files or a browser. We do not operate centralised device management, so device policy is applied by the two people concerned rather than enforced and reported centrally.
Limitation: No centralised device management, so device state is not centrally enforced or reported.
Change management
How a change gets from a developer’s machine into production.
CM-01 — All changes go through pull request
Every change reaches production through a pull request. Pushing directly to the main branch is blocked, as are force pushes and branch deletion, and a linear history is enforced.
CM-02 — Automated checks must pass before merge
Three checks must pass before any change can merge: linting, type checking and the automated test suite; linting and type checking also reject unused code. Merges are processed through a queue that re-runs the suite against the merged result, so a change cannot pass by being tested against a stale base.
CM-03 — Review comments must be resolved before merge
Every review comment on a change must be resolved before it can merge. This is enforced by the platform rather than by convention.
CM-04 — Mandatory approving review
We do not currently require an approving review from a second person before a change can merge. On a two-person engineering team a mandatory approval either blocks routine work or becomes a formality. Automated review tooling comments on every change, and the checks above are enforced before a merge. Making this a documented control is on our roadmap.
CM-05 — Production releases are deliberate, not automatic
Releases to production are started by a person rather than triggered by a merge. A release can only be cut from a revision already deployed and validated in staging, is rolled out to zero live traffic until automated smoke tests pass, and is tagged automatically so every production release is identifiable after the fact.
CM-06 — Rollback
Our rollback procedure is to redeploy the previous tagged release. It is documented and supported by automatic release tagging. We have not rehearsed a production rollback.
Limitation: The procedure is documented but has not been rehearsed live.
CM-07 — Emergency changes
An urgent fix follows the same route as every other change: it reaches production through a pull request and must pass the same automated checks. What an emergency release skips is the staging validation step, so the change is deployed without having first run in our staging environment. Emergency releases are started by a person and tagged like any other release, so they are identifiable afterwards.
Vulnerability management
How we find security problems in our own software, and what happens to a finding once we have it.
VM-01 — Dependency scanning
Dependencies and build actions are scanned weekly for known vulnerabilities and out-of-date versions, with updates raised automatically as changes for review.
VM-02 — Static application security testing
Our codebase is scanned daily for security weaknesses, and again whenever a change is queued to merge. Findings are advisory rather than merge-blocking; they are routed into the remediation loop described below rather than left in a dashboard.
VM-03 — Automated remediation of security findings
Every open security finding is mirrored daily into our issue tracker, and one is dispatched automatically each day to a sandboxed worker that attempts the fix. Any resulting change passes the same automated checks and the same merge process as every other change. A finding therefore has an owner, a state, and a trail from detection to deployed fix, rather than sitting in a queue waiting for attention.
VM-04 — Human review of security findings
Open security findings across code scanning, secret scanning and dependency alerts are reviewed by our Chief Technology Officer on a weekly cadence. Each finding is verified against the actual code before a ticket is raised, and false positives are dismissed with a recorded rationale rather than left open. This review is performed by a person on a regular cadence; it is not itself an automated job.
VM-05 — Automated security review of every change
Every proposed change is reviewed automatically by security and code-quality tooling, which comments inline on the change before it merges. These reviews are advisory: they inform the author rather than block the merge.
VM-06 — Database security configuration checks
Our database provider’s security advisors are queried on every change and on every merge to the main branch, surfacing misconfigurations such as a table left without row-level security. This check reports rather than blocks, and hardening it into a required gate is on our roadmap.
Limitation: The check reports rather than blocking a merge, and is skipped if its credentials are unavailable.
VM-07 — Secret scanning
Our source host scans for committed credentials and alerts on them. Alerts are triaged by a person, and a confirmed exposure takes a rotate-first path: the credential is rotated before the repository history is addressed. This scanning runs on the hosting platform rather than in our own build pipeline.
VM-08 — Coordinated vulnerability disclosure
We publish a vulnerability disclosure policy with a dedicated security contact, a commitment to acknowledge a report within two business days and update within seven, and a 90-day coordinated disclosure window.
VM-09 — Independent penetration test
We have not yet commissioned an independent penetration test. Commissioning one is part of our compliance roadmap, and we will publish the vendor and date when it is done.
Data protection
What happens to customer data at rest, in transit, and at the end of its life.
DP-01 — Encryption in transit
All traffic to and within the platform is served over HTTPS, with HTTP Strict Transport Security enforced on the domains we operate. The minimum accepted protocol version is TLS 1.2; earlier versions are refused at the edge.
DP-02 — Encryption at rest
Databases and object storage are encrypted at rest by our infrastructure providers using their platform defaults. We do not currently operate customer-managed encryption keys.
DP-03 — Data residency
Our system of record is hosted in the United Kingdom. Live call processing runs on United States infrastructure, deliberately co-located with our inference providers because transatlantic round-trips would make real-time coaching unusable. We do not currently offer region locking.
Limitation: Region locking is not offered; EU call processing is on the roadmap.
Basis: Data Processing Agreement §5; sub-processor register
DP-04 — No model training on customer data
We do not train artificial intelligence models on customer call data, and we operate no models of our own. All speech recognition and language models are operated by the third-party providers named in our sub-processor register, and none is engaged to train on customer data.
Basis: Data Processing Agreement §3
DP-05 — Declared inventory of stored data
Every store holding call-scoped data is declared in a machine-checked inventory, and a new data store cannot be added without declaring how that data is deleted. This is enforced automatically rather than maintained by hand.
DP-06 — Deletion and erasure
Deleting a call removes it from the customer’s workspace immediately, and removal from underlying storage follows within 30 days. Automated erasure across every store is in active development; until it completes, erasure is carried out as a managed process on request.
Limitation: Automated purge across all stores is in development; erasure is currently a managed process.
Basis: Privacy Policy §9; Data Processing Agreement §8
DP-07 — Retention schedule
We do not yet offer configurable retention periods. Call recordings and transcripts are kept until deleted or the account is closed. A defined retention schedule with automated expiry is in development.
DP-08 — Backup and recovery
Our system of record has point-in-time recovery enabled in production, with a seven-day recovery window. Recovery positions for the remaining stores are being established and documented, and we will state the recovery window for each when that work completes.
Limitation: Point-in-time recovery is confirmed for the primary database; positions for other stores are being established.
Monitoring and response
How we notice something is wrong, and what we do about it.
MON-01 — Alerting on system behaviour
Our alerting rules are held in version control and deployed as code rather than configured by hand, covering error rates, latency and service-specific failure conditions. Alerts are routed to a staffed channel.
MON-02 — The monitoring is itself monitored
Deployed alerting rules are compared weekly against their versioned definitions, so an alert deleted or altered outside version control is surfaced. Separately, a watchdog reports any scheduled job that fails or stops running, so a check that stops without failing is still surfaced. Both guard against silent failure of our own monitoring.
MON-03 — Proactive anomaly detection
An automated sweep examines our production event stream every hour for anomalies, and raises a de-duplicated ticket with an investigation automatically attached when it finds one. This looks for problems rather than waiting for a threshold to be crossed.
MON-04 — Configuration drift detection
Several classes of configuration are compared weekly against their declared state, including secret visibility, the environment variable manifest and repository health. An undeclared change to production configuration is surfaced rather than discovered later.
MON-05 — Incident response
We maintain a written incident playbook with a severity gate, a rollback decision tree and a dependency matrix. Incidents are run against a ticket that serves as the log, and a person approves each consequential step.
MON-06 — Formal on-call rotation
We do not operate a paging on-call rotation. Alerts are routed to a staffed channel monitored during working hours, and the team is small enough that escalation is direct. A formal rotation and a public status page are on our roadmap.
MON-07 — Breach notification
We commit contractually to notifying an affected customer without undue delay and within 72 hours of becoming aware of a personal data breach, including the nature of the breach, the categories and approximate numbers affected, the likely consequences and the measures taken.
Basis: Data Processing Agreement §7
MON-08 — Business continuity and disaster recovery
We maintain a business continuity and disaster recovery plan setting a recovery time and recovery point objective for each system that holds customer data, the recovery path for each, and the roles and decision rights during an incident. It sits above our production incident playbook, which carries the operational detail. The plan states for each system whether that recovery has actually been performed, and today none has been rehearsed, so the objectives are commitments rather than measurements. It also records that we have not established a recovery position for per-call storage. The plan is internal; we can share it under a non-disclosure agreement.
Limitation: No recovery has been rehearsed, and no recovery position is established for per-call storage.
Vendor management
The third parties in the path, and the terms we hold them to.
VEN-01 — Published sub-processor register
We publish a dated register of every third party that processes customer data, naming what each one does, the categories of data it handles, where the company is based and the region in which it actually processes. The register distinguishes those two, because they frequently differ.
VEN-02 — Notice before adding a sub-processor
We commit to at least 30 days’ notice before adding a new sub-processor that handles customer call data, with a right to object on reasonable data protection grounds and to terminate without penalty if an objection cannot be resolved.
Basis: Data Processing Agreement §4
VEN-03 — Processing terms with sub-processors
We rely on data processing terms with each sub-processor that limit them to processing on our instructions. For most this is the provider’s published standard agreement. For a minority that documentation is still being completed, and our sub-processor register marks which.
Limitation: Transfer and processing documentation is not yet complete for every provider.
Basis: Data Processing Agreement §4; sub-processor register
VEN-04 — Assessment before a provider is added
Before a provider is added to the processing path we review its published security documentation, its data processing terms and its certifications, and we record what it processes and where in our sub-processor register. We do not run a scored vendor risk assessment or request a security questionnaire from each provider, which is what an auditor would expect at a larger scale.
Limitation: No scored vendor risk assessment and no per-provider security questionnaire.
Controls not in place
The following controls are planned or not operated today. They are listed here as well as in their own sections.
- Security awareness training (GOV-04) — Not in place.
- Written security policies (GOV-05) — Planned.
- SOC 2 and ISO 27001 position (GOV-06) — Planned.
- Background checks (GOV-08) — Not in place.
- Periodic access review (AC-06) — Planned.
- Per-record access logging (AC-07) — Not in place.
- Mandatory approving review (CM-04) — Not in place.
- Independent penetration test (VM-09) — Not in place.
- Retention schedule (DP-07) — Planned.
- Formal on-call rotation (MON-06) — Not in place.
SOC 2 Trust Services Criteria index
| Criterion | Controls | |
|---|---|---|
| A1 | Availability | CM-05, CM-06, DP-08, MON-01, MON-05, MON-06, MON-08 |
| C1 | Confidentiality | AC-02, AC-03, DP-01, DP-02, DP-03, DP-04, DP-05, DP-06, DP-07 |
| CC1 | Control environment | GOV-01, GOV-02, GOV-03, GOV-04, GOV-05, GOV-06, GOV-08 |
| CC2 | Communication and information | GOV-05, VM-08 |
| CC3 | Risk assessment | GOV-07, DP-05, VEN-04 |
| CC4 | Monitoring of controls | VM-04, VM-09, MON-01, MON-02, MON-03, MON-04 |
| CC5 | Control activities | GOV-03 |
| CC6 | Logical and physical access | AC-01, AC-02, AC-03, AC-04, AC-05, AC-06, AC-07, AC-08, AC-09, AC-10, AC-13, AC-11, AC-12, VM-06, VM-07, DP-01, DP-02 |
| CC7 | System operations | AC-07, AC-13, CM-06, VM-01, VM-02, VM-03, VM-04, VM-05, VM-06, VM-07, VM-08, VM-09, MON-01, MON-03, MON-05, MON-06, MON-07, MON-08 |
| CC8 | Change management | CM-01, CM-02, CM-03, CM-04, CM-05, CM-07, VM-05, MON-04 |
| CC9 | Risk mitigation | VM-01, VM-03, VEN-01, VEN-02, VEN-03, VEN-04 |
| P1 | Privacy | DP-03, DP-04, DP-05, DP-06, DP-07, MON-07, VEN-01, VEN-02, VEN-03 |
NIST Cybersecurity Framework index
| Function | Controls | |
|---|---|---|
| GV | Govern | GOV-01, GOV-02, GOV-03, GOV-04, GOV-05, GOV-06, GOV-07, GOV-08, AC-06, AC-10, CM-01, CM-04, CM-05, VM-08, DP-03, DP-04, DP-05, DP-06, DP-07, MON-02, MON-08, VEN-01, VEN-02, VEN-03, VEN-04 |
| ID | Identify | GOV-02, GOV-07, AC-05, VM-01, VM-02, VM-03, VM-04, VM-05, VM-06, VM-09, DP-05, VEN-01, VEN-03, VEN-04 |
| PR | Protect | GOV-04, GOV-08, AC-01, AC-02, AC-03, AC-04, AC-05, AC-06, AC-07, AC-08, AC-09, AC-10, AC-13, AC-11, AC-12, CM-01, CM-02, CM-03, CM-04, CM-05, CM-07, VM-01, VM-05, VM-06, DP-01, DP-02, DP-03, DP-04, DP-06, DP-07, MON-04 |
| DE | Detect | AC-07, AC-13, VM-02, VM-07, MON-01, MON-02, MON-03, MON-04 |
| RC | Recover | CM-06, DP-08, MON-05, MON-08 |
| RS | Respond | CM-07, VM-03, VM-04, VM-07, VM-08, MON-05, MON-06, MON-07 |
Questions
Security questions, questionnaires and requests for further detail: security@arcla.com.
Our Data Processing Agreement, Privacy Policy, sub-processor register and vulnerability disclosure policy carry the contractual and legal detail behind these controls.