Statement of Applicability
Owner: Security Officer · Approved by leadership · Version 1.0 · Effective 27 May 2026 · Next review 27 May 2027
1. Purpose
This Statement of Applicability (SoA) is the controlled document required by ISO/IEC 27001:2022 Clause 6.1.3 d). It lists every control from Annex A of the standard, states whether the control is applicable to Glassbreak's ISMS scope, and points to the implementation that satisfies the control (where applicable). It operates inside the boundaries declared in the ISMS Scope and supports the treatment decisions taken in the Risk Treatment Plan.
2. How to read this document
- Ref — the Annex A control identifier (A.5.1 through A.8.34).
- Requirement — short title of the control.
- Status — Met (control applies and is implemented), Partial (control applies and is partially implemented), Gap (control applies and is not yet implemented to a satisfactory standard), or N/A (control does not apply, with rationale in the position column).
- Position — for applicable controls, the implementation reference (a policy URL, a code artefact, or a procedural commitment); for N/A, the reason the control does not apply.
Physical controls (A.7) are inherited from cloud sub-processors where production assets are concerned; the sub-processor attestations underwriting that inheritance are tracked in the Supply Chain Risk Management Plan.
3. Theme A.5 — Organisational controls (37)
A.5.1 to A.5.18 — Policies, roles, assets, access
10 met8 partial
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| A.5.1 | Policies for information security | Met | Top-level policy at /policies/information-security with the dependent set at /policies (IR, BCP/DR, Onboarding, Offboarding, Sanctions, SDLC, Audit-log Retention, Supply Chain Risk, Fraud Risk Assessment, ISMS Scope, SoA, RTP). |
| A.5.2 | Information security roles and responsibilities | Met | /policies/information-security §4 names the Security Officer, engineering, workforce, and customer responsibilities. |
| A.5.3 | Segregation of duties | Partial | PR review and OpenTofu plan-and-review separate plan from apply; admin actions logged. Some operations remain single-actor at current scale. |
| A.5.4 | Management responsibilities | Met | Leadership approves every policy at publication and at material revision; quarterly risk-register review under the RTP. |
| A.5.5 | Contact with authorities | Partial | Supervisory-authority contacts identified for the customer-facing GDPR scope; formal authority-contact register not yet maintained. |
| A.5.6 | Contact with special interest groups | Partial | Industry working groups consulted ad hoc (cryptography, cloud security); not yet formalised as a documented membership list. |
| A.5.7 | Threat intelligence | Partial | Dependabot, CVE feeds, sub-processor advisories monitored; no documented threat-intelligence consumption procedure. |
| A.5.8 | Information security in project management | Met | Every change starts from docs/architecture.md; security review is a mandatory step in the PR workflow per the SDLC procedure. |
| A.5.9 | Inventory of information and other associated assets | Partial | IaC is the authoritative cloud-asset inventory; workforce endpoint inventory is informal. |
| A.5.10 | Acceptable use of information and assets | Partial | Acceptable Use Standard exists in the onboarding briefing; formal standalone document in flight. |
| A.5.11 | Return of assets | Met | /policies/offboarding §7 mandates return of laptops, hardware keys, badges, and documentation by the last working day. |
| A.5.12 | Classification of information | Met | /policies/isms-scope §6 defines seven information classes (P, CT, A, K, L, W, S) with class-specific handling rules. |
| A.5.13 | Labelling of information | Partial | Logical labelling exists in the data model and in source comments; user-facing labelling of classified material is not standard. |
| A.5.14 | Information transfer | Met | TLS 1.2+ in transit; HMAC-signed cross-vertical sync; transfer of W-class records to external counsel only over encrypted channels. |
| A.5.15 | Access control | Met | RBAC with 8 organisation-level and 25+ team-level permissions enforced at the application layer; admin access requires MFA. |
| A.5.16 | Identity management | Met | Per-user accounts; MFA required for sensitive operations; refresh-token rotation with family-based reuse detection. |
| A.5.17 | Authentication information | Met | Argon2id (t=4, m=128MB, p=2) with per-user salt and server-side pepper; TOTP and WebAuthn for MFA; secrets held in approved stores only. |
| A.5.18 | Access rights | Partial | Access register lists every workforce member, system, and review date; quarterly reviews are the cadence. SSO/SCIM not yet available to customers. |
A.5.19 to A.5.37 — Suppliers, incidents, continuity, compliance
12 met7 partial
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| A.5.19 | Information security in supplier relationships | Partial | /policies/supply-chain-risk states the sub-processor lifecycle; sub-processor list at /legal/sub-processors. Formal SOC 2 re-review on intake is documented but not annual yet. |
| A.5.20 | Addressing information security within supplier agreements | Met | Standard DPA terms required of every sub-processor that processes customer data; security obligations contractual. |
| A.5.21 | Managing information security in the ICT supply chain | Partial | Lockfiles, Dependabot, Wycheproof vectors in CI; SBOM publication on roadmap (RTP R-06). |
| A.5.22 | Monitoring, review and change management of supplier services | Partial | Sub-processor service announcements monitored; annual re-attestation cycle documented in the Supply Chain Risk Management Plan. |
| A.5.23 | Information security for use of cloud services | Met | Two independent compute stacks (AWS + Scaleway) with documented cloud-shared-responsibility split; IaC under version control. |
| A.5.24 | Information security incident management planning and preparation | Met | /policies/incident-response defines SEV-1 to SEV-4 classification, response phases, customer-notification SLAs, and the post-mortem cadence. |
| A.5.25 | Assessment and decision on information security events | Met | Triage step in the IR procedure assigns initial severity and identifies in-scope vs out-of-scope events. |
| A.5.26 | Response to information security incidents | Met | IR procedure phases detect, triage, contain, eradicate, recover, learn. |
| A.5.27 | Learning from information security incidents | Met | Blameless post-mortems within 5 business days of resolution; action items tracked to closure. |
| A.5.28 | Collection of evidence | Met | IR procedure §5.3 mandates forensic preservation before destructive remediation; chain-of-custody recorded. |
| A.5.29 | Information security during disruption | Met | /policies/business-continuity §4 defines multi-cloud continuity strategy; sync transport tolerates partition; cross-vertical failover automated. |
| A.5.30 | ICT readiness for business continuity | Met | BCP/DR plan with RTO 15 min, RPO 5 min; 22 DR scenarios exercise the recovery path nightly in CI. |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | Partial | GDPR, UK GDPR, FADP covered via DPA + addenda at /legal/dpa; consolidated jurisdictional register not yet a separate document. |
| A.5.32 | Intellectual property rights | Met | IP terms in employment and contractor agreements; third-party dependency licences tracked in lockfiles. |
| A.5.33 | Protection of records | Met | Workforce, incident, access, and credential-rotation records under retention schedules in the source policies; audit log per /policies/audit-log-retention. |
| A.5.34 | Privacy and protection of PII | Met | Data-subject rights routes at /legal/data-request; DPIA response published at /trust/dpia; consent and lawful-basis framework in the DPA. |
| A.5.35 | Independent review of information security | Partial | Internal security audit performed 27 May 2026; external penetration test in flight; formal independent review on the certification path. |
| A.5.36 | Compliance with policies, rules and standards for information security | Partial | Daily security-posture probes verify 16+ runtime controls; formal annual compliance review cycle planned for the certification path. |
| A.5.37 | Documented operating procedures | Partial | Operational runbooks held in docs/; SDLC procedure published at /policies/sdlc; ISMS procedure register on the certification path. |
4. Theme A.6 — People controls (8)
A.6.1 to A.6.8 — People
6 met2 partial
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| A.6.1 | Screening | Met | /policies/onboarding §3.2 requires background checks for workforce members with production access; lighter verification otherwise. |
| A.6.2 | Terms and conditions of employment | Met | /policies/onboarding §3.4 requires confidentiality clauses surviving termination in every workforce agreement. |
| A.6.3 | Information security awareness, education and training | Met | /policies/onboarding §§4.3, 5, 8 mandate security briefing on Day 1, formal awareness training in the first 30 days, role-specific training, and annual renewal. |
| A.6.4 | Disciplinary process | Met | /policies/sanctions defines Minor / Material / Gross categories, investigation procedure, sanctions, right to respond, right of appeal. |
| A.6.5 | Responsibilities after termination or change of employment | Met | /policies/offboarding §10 sets confidentiality, IP, non-disclosure, return-of-materials, and cooperation obligations that survive termination. |
| A.6.6 | Confidentiality or non-disclosure agreements | Met | NDA terms in employment and contractor agreements; supplemental NDAs for engagements with sub-processors and external assessors. |
| A.6.7 | Remote working | Partial | Managed-device baseline (FDE, OS firewall, screen-lock, MFA) per /policies/onboarding §4.1; standalone Remote Working Standard not yet a controlled procedure. |
| A.6.8 | Information security event reporting | Partial | External reporting met (security@glassbreak.io, /trust/disclosure); internal reporting channels exist but are not yet documented in a single Standard. |
5. Theme A.7 — Physical controls (14)
Glassbreak operates no physical data centres. Production physical controls are inherited from the cloud sub-processors listed at /legal/sub-processors, each of which holds its own SOC 2 / ISO 27001 attestation covering Annex A.7 equivalents. Office and workforce-device physical controls apply only where workforce members use premises and equipment for Glassbreak work.
A.7.1 to A.7.14 — Physical
8 met3 partial3 n/a
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| A.7.1 | Physical security perimeters | Met | Inherited from cloud sub-processors (AWS, Scaleway, Neon, Fastly) under their own attestations. |
| A.7.2 | Physical entry | Met | Inherited from cloud sub-processors. |
| A.7.3 | Securing offices, rooms and facilities | N/A | Glassbreak operates no dedicated office estate. Workforce members operate from personal premises; equipment-level controls apply. |
| A.7.4 | Physical security monitoring | Met | Inherited from cloud sub-processors. |
| A.7.5 | Protecting against physical and environmental threats | Met | Inherited from cloud sub-processors. |
| A.7.6 | Working in secure areas | N/A | No Glassbreak-operated secure areas. |
| A.7.7 | Clear desk and clear screen | Partial | Practised; covered in the onboarding security briefing; not yet a standalone controlled procedure. |
| A.7.8 | Equipment siting and protection | Partial | Inherited from sub-processors for production assets; informal for workforce endpoints in personal premises. |
| A.7.9 | Security of assets off-premises | Partial | Workforce endpoints carry managed-baseline controls; standalone off-premises asset standard not yet documented. |
| A.7.10 | Storage media | Met | Cryptographic erasure enforced for production storage media via sub-processor controls; workforce endpoint media wiped per /policies/offboarding §§5, 7. |
| A.7.11 | Supporting utilities | Met | Inherited from cloud sub-processors. |
| A.7.12 | Cabling security | Met | Inherited from cloud sub-processors. |
| A.7.13 | Equipment maintenance | N/A | Inherited from cloud sub-processors; Glassbreak holds no production hardware. |
| A.7.14 | Secure disposal or re-use of equipment | Met | Cloud sub-processors handle production disposal; workforce endpoints wiped per the offboarding procedure (factory reset, secure erase, re-imaging). |
6. Theme A.8 — Technological controls (34)
The strongest area of coverage. The platform was designed with most of these controls in mind from the start; the remaining gaps are tracked in the Risk Treatment Plan.
A.8.1 to A.8.12 — Endpoints, access, capacity, malware, vulns
7 met5 partial
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| A.8.1 | User endpoint devices | Partial | Managed-device baseline (FDE, OS firewall, screen-lock, MFA) enforced per /policies/onboarding §4.1; centralised MDM inventory not yet formal at current scale. |
| A.8.2 | Privileged access rights | Partial | Admin access requires MFA; admin-action audit log captures privileged actions; known gaps in admin-impersonation logging (audit findings C-3, C-4) on the RTP R-04 treatment plan. |
| A.8.3 | Information access restriction | Met | Per-organisation row-level isolation enforced at the database client layer; RBAC at the application layer. |
| A.8.4 | Access to source code | Met | GitHub with SSO + hardware-key 2FA required for admin; branch protection on main; CI-only deployment. |
| A.8.5 | Secure authentication | Met | Argon2id (t=4, m=128MB, p=2); TOTP and WebAuthn MFA; refresh-token rotation with peppered HMAC; EdDSA JWTs with kid-driven verify. |
| A.8.6 | Capacity management | Partial | Serverless autoscaling on both verticals; formal capacity-planning review on the certification path. |
| A.8.7 | Protection against malware | Met | Built-in OS protections on workforce endpoints; N/A for serverless production (no persistent compute surface). |
| A.8.8 | Management of technical vulnerabilities | Partial | Dependabot on every repository; CVE feeds monitored; formal monthly review minutes on the SOC 2 readiness path. |
| A.8.9 | Configuration management | Met | OpenTofu state under version control; no manual cloud-console changes; configuration drift surfaced by the daily security-posture snapshot. |
| A.8.10 | Information deletion | Met | Self-service erasure route mounted (audit finding C-12 resolved); cryptographic erasure default for shared secrets; account deletion via /legal/data-request. |
| A.8.11 | Data masking | Met | Met by design via end-to-end encryption: customer plaintext is masked from Glassbreak by virtue of not holding the keys. |
| A.8.12 | Data leakage prevention | Partial | CSP, HSTS, no third-party tracking on authenticated pages; managed DLP product not deployed at current scale. |
A.8.13 to A.8.23 — Backup, monitoring, network, software
9 met1 partial1 n/a
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| A.8.13 | Information backup | Met | Per-vertical encrypted backups; integrity verified nightly in DR scenario 22 (real round-trip restore). |
| A.8.14 | Redundancy of information processing facilities | Met | Two independent compute stacks across two cloud providers and two regions; cross-vertical failover automated via Fastly. |
| A.8.15 | Logging | Met | Application audit log; request log with trace IDs; sub-processor access logs retained per /policies/audit-log-retention. |
| A.8.16 | Monitoring activities | Met | OTLP telemetry to Grafana Cloud (Tempo, Loki, Mimir); three SLO alerts wired (5xx rate, p95 latency, apex probe) with inline runbooks. |
| A.8.17 | Clock synchronisation | Met | NTP via cloud provider; serverless runtime clocks within tolerance. |
| A.8.18 | Use of privileged utility programs | Partial | No SSH to production (serverless); operator console access logged in the admin-action audit log; just-in-time elevation on RTP R-04 treatment plan. |
| A.8.19 | Installation of software on operational systems | Met | CI-only deployment; manual production installs prohibited; OpenTofu plan-and-review for infrastructure. |
| A.8.20 | Networks security | Met | Per-vertical network isolation; egress controls on serverless functions; CSP, HSTS, secure DNS at the edge. |
| A.8.21 | Security of network services | Met | Fastly fronts the primary surface with TLS termination; direct-backup surfaces bypass Fastly with native TLS; dual DNS authority per domain. |
| A.8.22 | Segregation of networks | Met | Per-vertical isolation; the two compute stacks share no network surface beyond the HMAC-signed sync transport over public HTTPS. |
| A.8.23 | Web filtering | N/A | No corporate network; workforce devices use ISP-default DNS or personal-choice resolvers. Outbound from serverless production is controlled at the function level. |
A.8.24 to A.8.34 — Cryptography, SDLC, test data, audit
9 met1 partial1 n/a
| Ref | Requirement | Status | How we meet it / gap |
|---|---|---|---|
| A.8.24 | Use of cryptography | Met | AES-256-GCM at rest; TLS 1.2+ in transit; hybrid post-quantum encryption (RSA-OAEP-8192 + ML-KEM-1024); Noble libraries with Wycheproof vectors in CI. Documented at /technology/encryption. |
| A.8.25 | Secure development life cycle | Partial | /policies/sdlc documents the phases (plan, design, implement, review, test, release, operate, retire) and the security activities at each phase; formal evidence rollup on the SOC 2 readiness path. |
| A.8.26 | Application security requirements | Met | Security requirements captured in the architecture document; encoded as tests in CI; OWASP ASVS used as a reference baseline. |
| A.8.27 | Secure system architecture and engineering principles | Met | docs/architecture.md captures the principles (multi-stack independence, zero-knowledge, per-vertical signing, sync via HMAC). |
| A.8.28 | Secure coding | Met | /policies/sdlc §3 requires lint and SAST in CI; peer review on every change; TypeScript strict mode; Zod validation at every public route boundary. |
| A.8.29 | Security testing in development and acceptance | Met | Unit, integration, endpoint, and DR-scenario tests run in CI on every PR; auth-security tests (rate-limit, replay, family-based reuse) included. |
| A.8.30 | Outsourced development | N/A | Software development is not outsourced; all changes go through the same PR review regardless of contributor type. |
| A.8.31 | Separation of development, test and production environments | Met | Dev, staging, and production are separate cloud accounts / namespaces with separate credentials; no production data in non-production environments. |
| A.8.32 | Change management | Met | Every code change PR-reviewed; every infrastructure change OpenTofu-planned and reviewed; branch protection on main; CI-only deployment. |
| A.8.33 | Test information | Met | Test data is synthetic (faker, fixtures) or anonymised; no production data is copied to non-production environments. |
| A.8.34 | Protection of information systems during audit testing | Met | Audit testing scoped to dedicated read-only credentials where possible; audit windows scheduled to minimise impact; observability separates audit traffic. |
7. Summary of applicability decisions
- Applicable controls: 89 of 93 — the overwhelming majority of Annex A applies to a SaaS provider operating customer-facing infrastructure.
- Not applicable: 4 — A.7.3 (offices), A.7.6 (secure areas), A.7.13 (equipment maintenance), A.8.23 (web filtering), and A.8.30 (outsourced development). The rationale for each is recorded in the position column above.
8. Tracking and remediation
- Controls marked Partial or Gap are tracked in the Risk Treatment Plan with owner, treatment decision, and target date.
- Status of each control is reviewed at the quarterly RTP review; the SoA is reissued at the annual ISMS management review or sooner if a status change is material.
- The live operational view of the implementation of these controls is the daily security-posture publication at /trust, which surfaces only controls that have been measured green for 30+ consecutive days.
9. Review
This Statement of Applicability is reviewed at least annually and after every material change to the ISMS scope, the sub-processor mix, the architecture, or the regulatory environment. The next scheduled review is 27 May 2027.
10. Related documents
- ISMS Scope
- Risk Treatment Plan
- Information Security Policy
- Incident Response Policy
- Business Continuity & DR Plan
- Onboarding Policy
- Offboarding Policy
- Sanctions & Disciplinary Policy
- Secure Development Lifecycle
- Supply Chain Risk Management Plan
- Audit-log Retention Policy
- Fraud Risk Assessment
Counter-signed PDF copy available on request to compliance@glassbreak.io.