Skip to content

Statement of Applicability (SoA)

Purpose. The SoA is the central control document of the ISMS (ISO/IEC 27001:2022 clause 6.1.3 d). It lists all 93 Annex A controls, states for each whether it is applicable to Soon, gives the justification for inclusion or exclusion, and points to how/where it is implemented. The auditor uses this document as the map for the entire Stage 2 audit.

Status: DRAFT (v0.2). Applicability decisions are unchanged from v0.1 (approved 2026-09-01). This version brings the "Implementation" column up to date with the documents written since. An implementing document that is not yet approved is marked (draft); where no document implements a control yet, the cell says what covers it today and marks the gap TODO(owner). Approval status per document is in REGISTER.md.

How applicability was decided

  • Driven by the Context & Scope, the Risk Assessment and Treatment Process (ISMS-DOC-06-2), the Risk Assessment Report (ISMS-DOC-06-3) and the Risk Treatment Plan (ISMS-DOC-06-4, draft).
  • Soon is a fully-remote, cloud-native SaaS on AWS (eu-west-1) — with one production service still on GCP europe-west4 pending migration (S-365) — with no offices and no data centres. Physical/environmental controls are therefore largely inherited from AWS (independently certified to ISO/IEC 27001, SOC 1/2, PCI DSS) or not applicable, with justification per control.
  • Development is performed in-house; there is no outsourced development.

Summary

Count
Total Annex A controls 93
Applicable 84
Not applicable (excluded) 9

Excluded controls: A.7.1, A.7.2, A.7.3, A.7.4, A.7.5, A.7.6, A.7.11, A.7.12 (physical/environmental — no Soon premises, inherited from AWS) and A.8.30 (no outsourced development). Justifications in the tables below.

Legend — Applicable: ✅ Yes · ➖ No (excluded). Implementation: links to the implementing document(s), with the relevant section where the control is covered by part of a broader document. (draft) marks a document not yet approved. TODO(owner) marks a gap that no document closes yet.

A.5 — Organizational controls (37)

Control Title Applic. Justification & implementation
A.5.1 Policies for information security ✅ Required. Information Security Policy (ISMS-DOC-05-4) + topic-specific policies in this repo.
A.5.2 Information security roles and responsibilities ✅ Roles, Responsibilities & Authorities (ISMS-DOC-05-2) and Organisation Chart & Reporting Lines (ISMS-DOC-05-5). ISM = Olaf Jacobson; Technical / Infrastructure Security Lead = Thomas Picauly (A.8 controls, production access); independent internal audit by Andrea Cardinali (CyberSquad). Melvin Jacobson is a co-founder and shareholder with no operating role (ISMS-DOC-05-2 v0.3, 2026-09-08).
A.5.3 Segregation of duties ✅ Applicable but constrained by small team; compensating controls are detective. The limitation and its controls are recorded in the Risk Assessment Report (ISMS-DOC-06-3, "Fraud risk" section, risk R-24): every production release approved by a second founder (Change Management Process §3.2), tamper-evident organisation-wide CloudTrail, quarterly access review. Approver/grantor separation in the Access Control Policy §2.1.
A.5.4 Management responsibilities ✅ Leadership mandates compliance. Information Security Policy §2.1 (commitment); HR Security Policy (ISMS-DOC-A05-1-2); Policy Acknowledgement Form (ISMS-FORM-A06-3-1); Executive Support Letter (ISMS-DOC-05-3, draft); Management Review Procedure (ISMS-DOC-09-4).
A.5.5 Contact with authorities ✅ Need to reach DPAs/CERT. Breach-notification routes are documented: as processor, Soon notifies the controller, who notifies its supervisory authority; Soon notifies the Autoriteit Persoonsgegevens only where it is itself the controller (Data Breach playbook, ISMS-DOC-A05-24-3, "Notification"; Personal Data Breach Notification Procedure, ISMS-DOC-A05-34-2, draft). TODO(owner): no list of authority contacts exists (planned ISMS-DOC-A05-5-1) — record the supervisory authority, CSIRT and police contacts, and who makes contact.
A.5.6 Contact with special interest groups ✅ Security community/threat sources. TODO(owner): no record of special interest group membership or contacts exists (planned ISMS-DOC-A05-6-1). The advisory sources in the Technical Vulnerability & Threat Management Policy §2.3 serve A.5.7, not this control — decide which groups Soon takes part in and record them.
A.5.7 Threat intelligence ✅ Technical Vulnerability & Threat Management Policy (ISMS-DOC-A08-8-1) §2.3: Dependabot and Aikido alerts, AWS security bulletins, vendor notifications. The former Threat Intelligence Policy (ISMS-DOC-A05-7-1) is superseded and merged into it.
A.5.8 Information security in project management ✅ Security considered in product/projects. Product work: Secure Development Policy (ISMS-DOC-A08-25-1) §2.1 (security at requirements and design) and release review of security-relevant changes (Change Management Process §3.2). New services: Cloud Services Policy §2.1 (draft). TODO(owner): nothing covers non-development projects such as infrastructure migrations — decide whether the planned guideline (ISMS-DOC-A05-8-1) is still needed.
A.5.9 Inventory of information and other associated assets ✅ Asset Management Policy (ISMS-DOC-A05-9-1) + Information Asset Inventory (ISMS-DOC-A05-9-2, draft); third parties in the Vendor & Sub-processor Register (ISMS-FORM-A05-19-1).
A.5.10 Acceptable use of information and associated assets ✅ Acceptable Use Policy (ISMS-DOC-A05-10-1), which absorbed the former Electronic Messaging and Online Collaboration policies (§2.7, §2.8); Asset Management Policy §2.3.
A.5.11 Return of assets ✅ On leaver/change events. Asset Management Policy §2.4; Termination & Change Checklist (ISMS-FORM-A06-5-1, draft). Soon issues no company devices (Device Management Policy §2.2), so return covers data, credentials and tokens.
A.5.12 Classification of information ✅ Classification scheme in use (Public/Internal/Confidential/Restricted), defined with handling rules in the Information Classification Procedure (ISMS-DOC-A05-12-1).
A.5.13 Labelling of information ✅ Information Classification Procedure (ISMS-DOC-A05-12-1) §4: classification field in document front matter (checked by tools/isms.py check), classification per asset in the asset inventory; Confidential/Restricted Drive documents kept in restricted folders rather than marked individually.
A.5.14 Information transfer ✅ Encrypted transfer. Acceptable Use Policy §2.7 (email and Slack) and §2.8 (video calls and screen sharing); Cryptographic Policy §2.1 (TLS 1.2+); handling rules in the Information Classification Procedure §3; sharing ISMS material outside Soon per External Access to the ISMS (ISMS-DOC-07-8).
A.5.15 Access control ✅ Access Control Policy (ISMS-DOC-A05-15-1); production database access per Operating Procedure — Production Database Access (ISMS-DOC-A05-37-1).
A.5.16 Identity management ✅ Unique named accounts and SSO: Access Control Policy §2.1 and §2.5 (Google Workspace is the staff identity provider; WorkOS serves customer SSO only); User Access Management Process (ISMS-DOC-A05-18-1, draft).
A.5.17 Authentication information ✅ Access Control Policy §2.5: MFA required for AWS and GitHub, Google Workspace enforces MFA for staff sign-in, Enpass for every credential, 12-character minimum. GitHub organisation-wide 2FA enforced 2026-09-08 (System Description v0.3); AWS access through IAM Identity Center with MFA. Secrets per the Cryptographic Policy and User Access Management Process §7 (draft). TODO(owner): confirm whether MFA on the product /admin interface (S-419) is enforced.
A.5.18 Access rights ✅ Joiner/mover/leaver and reviews: Access Control Policy §2.2 and §2.4 (privileged access quarterly, all access annually); User Access Management Process (ISMS-DOC-A05-18-1, draft) §2–§6; Termination & Change Checklist (ISMS-FORM-A06-5-1, draft).
A.5.19 Information security in supplier relationships ✅ Supplier Relationships Security Policy (ISMS-DOC-A05-19-1) + Vendor & Sub-processor Register (ISMS-FORM-A05-19-1).
A.5.20 Addressing information security within supplier agreements ✅ DPAs/agreements with AWS, Stripe, Intercom, etc. Required terms in the Supplier Relationships Security Policy §2.2; agreement and DPA status per vendor in the Vendor & Sub-processor Register (ISMS-FORM-A05-19-1); signed agreements listed in the Schedule of Confidentiality Agreements (ISMS-DOC-A06-6-1, draft). Bespoke agreement for the one service supplier with ISMS access: Consultancy Agreement — CyberSquad (ISMS-DOC-A05-20-1).
A.5.21 Managing information security in the ICT supply chain ✅ Due diligence before onboarding: Supplier Relationships Security Policy §2.1 and Vendor & Sub-processor Register §8 (SOC 2 Type 2 or ISO 27001 assurance for core sub-processors). Software supply chain: Dependabot and Aikido dependency scanning (Technical Vulnerability & Threat Management Policy §2.1); open-source licences per the IP and Copyright Compliance Policy §2.1.
A.5.22 Monitoring, review and change management of supplier services ✅ Supplier Relationships Security Policy §2.4 (annual or on renewal; critical suppliers on material change); Vendor & Sub-processor Register §8 (annual review; customers notified 30 days before a new sub-processor); upstream provider changes per the Change Management Process §3.7.
A.5.23 Information security for use of cloud services ✅ Cloud Services Policy (ISMS-DOC-A05-23-1, draft) + Cloud & Infrastructure Security Policy (ISMS-DOC-A08-20-1); providers in the Vendor & Sub-processor Register. Core control (AWS; soon-connect on GCP pending migration, S-365).
A.5.24 Information security incident management planning and preparation ✅ Incident Response Procedure (ISMS-DOC-A05-26-1) with playbooks for ransomware (ISMS-DOC-A05-24-1), denial of service (ISMS-DOC-A05-24-2) and data breach (ISMS-DOC-A05-24-3). Annual exercise pack: ISMS-FORM-A05-30-2 (draft); not yet held as at 13 October 2026 (Control Self-Assessment, row 59).
A.5.25 Assessment and decision on information security events ✅ Incident Response Procedure §3 (severity P1–P4) and §4 step 2 (the ISM assesses, triages and assigns severity); events arrive through the Event Reporting Procedure (ISMS-DOC-A06-8-1).
A.5.26 Response to information security incidents ✅ Incident Response Procedure (ISMS-DOC-A05-26-1) §4–§5 and the playbooks under A.5.24; Personal Data Breach Notification Procedure (ISMS-DOC-A05-34-2, draft); incidents recorded in the Security Incident Register (ISMS-FORM-10-2).
A.5.27 Learning from information security incidents ✅ Incident Response Procedure §4 step 8 (post-incident review within 10 working days for P1/P2; actions into the Nonconformity & Corrective Action Procedure); root cause and lesson recorded per incident in the Security Incident Register (ISMS-FORM-10-2). TODO(owner): the Lessons Learned record (ISMS-FORM-A05-27-1) named in §4 step 8 does not exist — create it or point the procedure at the register.
A.5.28 Collection of evidence ✅ Incident Response Procedure §4 step 3 (preserve evidence before destructive actions) and §6 (incident record and evidence held in Linear, in a controlled location outside this repo); tamper-evident organisation CloudTrail in a separate account (Logging & Monitoring Policy §2.1).
A.5.29 Information security during disruption ✅ Continuity arrangements; AWS multi-AZ. Business Continuity & Disaster Recovery Plan (ISMS-DOC-A05-30-1) §3 (scenarios), §6 (systems needed to run a recovery) and §7 (people and deputies). The DR tabletop has not yet been held (Control Self-Assessment, row 66).
A.5.30 ICT readiness for business continuity ✅ Backups, RTO/RPO, AWS redundancy. Business Continuity & Disaster Recovery Plan (ISMS-DOC-A05-30-1) §2 (RTO 8 hours, RPO 24 hours) and §8 (testing); Backup Policy; Availability Management Policy. The first restore test (S-412) has not yet been run, so recovery times are design estimates (Control Self-Assessment row 60).
A.5.31 Legal, statutory, regulatory and contractual requirements ✅ Legal & Regulatory Requirements Procedure; GDPR/NIS2.
A.5.32 Intellectual property rights ✅ IP and Copyright Compliance Policy.
A.5.33 Protection of records ✅ Records Retention and Protection Policy.
A.5.34 Privacy and protection of PII ✅ GDPR processor. Privacy and Personal Data Protection Policy (ISMS-DOC-A05-34-1, draft); Record of Processing Activities (ISMS-FORM-A05-34-1, draft); Personal Data Breach Notification Procedure (ISMS-DOC-A05-34-2, draft).
A.5.35 Independent review of information security ✅ Internal audit + external certification audit. Procedure for Internal Audits (ISMS-DOC-09-2), performed by the external consultant; independence terms in the Consultancy Agreement — CyberSquad (ISMS-DOC-A05-20-1) §4. Annual independent penetration test per the Penetration Testing Procedure (ISMS-DOC-A08-8-2).
A.5.36 Compliance with policies, rules and standards ✅ Management review and the quarterly security review (Management Review Procedure, ISMS-DOC-09-4, §2.1), internal audit, the quarterly Control Self-Assessment (ISMS-FORM-09-9), and this SoA.
A.5.37 Documented operating procedures ✅ Operating Procedure — Production Database Access (ISMS-DOC-A05-37-1); database recovery procedure in the Business Continuity & Disaster Recovery Plan §4; change, deploy and rollback path in the Change Management Process §3. TODO(owner): decide which other routine operations need a written runbook.

A.6 — People controls (8)

Control Title Applic. Justification & implementation
A.6.1 Screening ✅ HR Security Policy (ISMS-DOC-A05-1-2) §2.1 (proportionate screening; founders not screened, by design), Employee Screening Checklist (ISMS-FORM-A06-1-1) and Screening Records (ISMS-FORM-A06-1-2), where legally permissible. The former Employee Screening Procedure (ISMS-DOC-A06-1-1) is superseded and merged into the HR Security Policy.
A.6.2 Terms and conditions of employment ✅ Guidelines for Inclusion in Employment Contracts (ISMS-DOC-A06-2-1, draft); HR Security Policy §2.2; Founder Confidentiality & Security Undertaking (ISMS-DOC-A06-6-3).
A.6.3 Information security awareness, education and training ✅ Competence, Awareness and Training Procedure (ISMS-DOC-07-1): induction and annual refresher via /isms:onboard; completions recorded in the Training & Awareness Log (ISMS-DOC-07-5, draft); signed Policy Acknowledgement Form (ISMS-FORM-A06-3-1).
A.6.4 Disciplinary process ✅ HR Security Policy (ISMS-DOC-A05-1-2) §2.3. The former Employee Disciplinary Process (ISMS-DOC-A06-4-1) is superseded and merged into it.
A.6.5 Responsibilities after termination or change of employment ✅ Termination & Change Checklist (ISMS-FORM-A06-5-1, draft); HR Security Policy §2.5.
A.6.6 Confidentiality or non-disclosure agreements ✅ NDA (ISMS-DOC-A06-6-2) + Schedule of Confidentiality Agreements (ISMS-DOC-A06-6-1, draft); Founder Confidentiality & Security Undertaking (ISMS-DOC-A06-6-3); Consultancy Agreement — CyberSquad §3.
A.6.7 Remote working ✅ Core control for Soon. Remote Working Policy (ISMS-DOC-A06-7-1); Device Security Standard (ISMS-DOC-A08-1-3, draft).
A.6.8 Information security event reporting ✅ Event Reporting Procedure (ISMS-DOC-A06-8-1): Slack #Security and security@soon.works; Incident Response Procedure §4 step 1.

A.7 — Physical controls (14)

Soon has no offices and no data centres. Infrastructure physical security is inherited from AWS (certified), and from Google Cloud for the one production service still hosted there (soon-connect, pending migration S-365). Controls relevant to home working and endpoints remain applicable.

Control Title Applic. Justification & implementation
A.7.1 Physical security perimeters ➖ No Soon premises; data-centre perimeters inherited from AWS.
A.7.2 Physical entry ➖ No Soon premises; AWS data-centre entry controls inherited.
A.7.3 Securing offices, rooms and facilities ➖ Soon operates no offices/facilities.
A.7.4 Physical security monitoring ➖ Inherited from AWS (data-centre CCTV/monitoring).
A.7.5 Protecting against physical and environmental threats ➖ Inherited from AWS (fire/flood/power protections in data centres).
A.7.6 Working in secure areas ➖ No Soon secure areas exist.
A.7.7 Clear desk and clear screen ✅ Applies to home working. Clear Desk and Clear Screen Policy.
A.7.8 Equipment siting and protection ✅ Endpoint siting at home covered by the Remote Working Policy §2.4 and §2.6; infra inherited from AWS.
A.7.9 Security of assets off-premises ✅ All assets are off-premises by design. Remote Working Policy; Device Management Policy (ISMS-DOC-A08-1-1, which absorbed the former BYOD Policy); Device Security Standard (ISMS-DOC-A08-1-3, draft).
A.7.10 Storage media ✅ Cloud-only; Soon issues no storage media. Company data is kept only in approved services (Acceptable Use Policy §2.3); no customer personal data stored locally, and external drives that held Soon data are erased or destroyed (Device Security Standard §2 item 7 and §3.1, draft). TODO(owner): v0.1 said removable media are prohibited by the Acceptable Use Policy, but its text does not say so — confirm the rule and write it into the AUP or the Device Security Standard.
A.7.11 Supporting utilities ➖ Power/cooling/UPS inherited from AWS; no Soon facilities.
A.7.12 Cabling security ➖ No Soon premises/cabling; inherited from AWS.
A.7.13 Equipment maintenance ✅ Endpoint patching: Device Management Policy §2.1, Endpoint Protection Policy §2.3, and security updates within 14 days (Device Security Standard §2 item 3, draft), verified in the quarterly attestation; infra maintained by AWS.
A.7.14 Secure disposal or re-use of equipment ✅ Device Security Standard (ISMS-DOC-A08-1-3, draft) §3.1 "Disposal or re-use of a device": sign-out and data removal if the owner keeps the device, full erase before it leaves the owner's hands; confirmed on the Termination & Change Checklist item 6. Cloud media handled by AWS.

A.8 — Technological controls (34)

Control Title Applic. Justification & implementation
A.8.1 User endpoint devices ✅ Device Management Policy (ISMS-DOC-A08-1-1, which absorbed the former BYOD Policy) + Device Security Standard (ISMS-DOC-A08-1-3, draft): baseline and quarterly attestation (§2, §4); no MDM, by documented decision (§1.1).
A.8.2 Privileged access rights ✅ Least-privilege. Access Control Policy §2.3–§2.4 (named admin accounts, quarterly privileged-access review); User Access Management Process §5 (draft); database access only through SSM Session Manager (ISMS-DOC-A05-37-1). MFA on AWS (IAM Identity Center), GitHub (organisation-wide 2FA enforced 2026-09-08) and Google Workspace. Privileged utilities: see A.8.18.
A.8.3 Information access restriction ✅ Access Control Policy §2.1, §2.6 (role-based IAM; attribute-based restrictions where finer control is needed) and §2.7, which absorbed the former Dynamic Access Control Policy (ISMS-DOC-A08-3-1); tenant isolation per the Cloud & Infrastructure Security Policy §2.2.
A.8.4 Access to source code ✅ Private GitHub repositories (Access Control Policy §2.7); branch protection and PR review (Secure Development Policy §2.2); second-founder release approval enforced by rulesets on soon-server, frontend and soon-terraform (Change Management Process §3.2). Rulesets on the other three repositories not yet confirmed (System Description §9).
A.8.5 Secure authentication ✅ Access Control Policy §2.5: risk-tiered MFA, Google Workspace as the staff identity provider (see A.5.17). SSO/SAML offered to customer tenants via WorkOS, plus social login. Native MFA for customer email/password accounts is a known gap (risk R-22; pentest finding #4 accepted with a roadmap, ISMS-FORM-A08-8-3).
A.8.6 Capacity management ✅ AWS autoscaling/monitoring. Availability Management Policy §2 ("Capacity": utilisation reviewed, scaling through change management); production API auto-scales 2–4 ECS tasks (System Description §3.1). TODO(owner): no capacity review is recorded — decide whether the planned Capacity Plan (ISMS-DOC-A08-6-1) is needed or where the review is evidenced.
A.8.7 Protection against malware ✅ Endpoint Protection Policy (ISMS-DOC-A08-7-1): macOS XProtect/Gatekeeper, verified in the quarterly device attestation (Device Security Standard §4, draft); no EDR, by documented decision. Ransomware playbook (ISMS-DOC-A05-24-1).
A.8.8 Management of technical vulnerabilities ✅ Technical Vulnerability & Threat Management Policy (ISMS-DOC-A08-8-1): Dependabot and Aikido scanning, remediation within 7/30/90 days for Critical/High/Medium. Annual pentest per the Penetration Testing Procedure (ISMS-DOC-A08-8-2); 2026 results and treatment in ISMS-FORM-A08-8-3.
A.8.9 Configuration management ✅ Configuration Management Policy; IaC (OpenTofu, soon-terraform). AWS Config is not enabled, so drift surfaces only at the next plan.
A.8.10 Information deletion ✅ Data Handling & Deletion Policy (ISMS-DOC-A08-10-1) §2.1; GDPR erasure — customer data deleted 90 days after contract end, matching the published DPA.
A.8.11 Data masking ✅ Data Handling & Deletion Policy (ISMS-DOC-A08-10-1) §2.2, which absorbed the former Data Masking Policy (ISMS-DOC-A08-11-1). That staging holds no production data rests on the owner's confirmation until S-493 verifies it.
A.8.12 Data leakage prevention ✅ Data Handling & Deletion Policy (ISMS-DOC-A08-10-1) §2.3, which absorbed the former Data Leakage Prevention Policy (ISMS-DOC-A08-12-1); no customer personal data stored on endpoints (Device Security Standard §2 item 7, draft).
A.8.13 Information backup ✅ Backup Policy (ISMS-DOC-A08-13-1); AWS RDS automated encrypted backups, 30-day retention with point-in-time recovery. Restore not yet tested (S-412) and backups not yet isolated off-account (System Description §9).
A.8.14 Redundancy of information processing facilities ✅ Availability Management Policy; AWS multi-AZ (production RDS Multi-AZ); scenarios in the Business Continuity & Disaster Recovery Plan §3.
A.8.15 Logging ✅ Logging and Monitoring Policy (ISMS-DOC-A08-15-1) §2.1–§2.3; organisation-wide CloudTrail soon-org-trail with log-file validation in the separate log-archive account; CloudWatch, Sentry.
A.8.16 Monitoring activities ✅ Logging and Monitoring Policy §2.4, which absorbed the former Monitoring Policy (ISMS-DOC-A08-16-1); GuardDuty findings and CloudWatch alarms to security@soon.works; alert sample reviewed at the quarterly security review (ISMS-DOC-09-4 §2.1).
A.8.17 Clock synchronization ✅ Logging and Monitoring Policy §2.5: cloud-provider time synchronisation (AWS/managed platform NTP); no separate time infrastructure.
A.8.18 Use of privileged utility programs ✅ Restricted/logged. Database sessions only through SSM Session Manager under a dedicated permission set, every session logged (ISMS-DOC-A05-37-1); AWS console and API actions recorded by CloudTrail. TODO(owner): the Privileged Utility Program Register (ISMS-DOC-A08-18-1), referenced in ISMS-DOC-A05-18-1 §5, does not exist — create it or remove the reference.
A.8.19 Installation of software on operational systems ✅ Software Policy; controlled deployments through CI/CD only (Change Management Process §3.1).
A.8.20 Networks security ✅ Cloud & Infrastructure Security Policy (ISMS-DOC-A08-20-1); Network Architecture & Segmentation (ISMS-DOC-A08-22-1, draft); VPC, security groups, TLS.
A.8.21 Security of network services ✅ Cloud & Infrastructure Security Policy §2.3; Cloudflare edge (DNS, CDN, WAF, Cloudflare Pages) for the web application and the AWS load balancer for the API (ISMS-DOC-A08-22-1 §2, draft). Known gap: the API is not behind Cloudflare and AWS WAF on the load balancer is not verified (S-426).
A.8.22 Segregation of networks ✅ Network Architecture & Segmentation (ISMS-DOC-A08-22-1, draft) §2–§3: public and private subnets, database private; development in its own VPC with no peering to production; staging on Azure, outside the AWS production account. Cloud & Infrastructure Security Policy §2.1.
A.8.23 Web filtering ✅ Endpoint Protection Policy (ISMS-DOC-A08-7-1) §2.4, which absorbed the former Web Filtering Policy (ISMS-DOC-A08-23-1): browser malicious-site protection kept on; no DNS-level filtering, accepted at current size.
A.8.24 Use of cryptography ✅ Cryptographic Policy; TLS 1.2+ (production ALB listener policy ELBSecurityPolicy-TLS13-1-2-2021-06, applied and verified 2026-09-02 — S-503), AES-256 at rest. Legacy CBC suites still offered on the Cloudflare Pages hostnames (pentest finding #1) are accepted as a platform limitation (ISMS-FORM-A08-8-3 §3).
A.8.25 Secure development life cycle ✅ Secure Development Policy.
A.8.26 Application security requirements ✅ OWASP-aligned requirements. Secure Development Policy (ISMS-DOC-A08-25-1) §2.1 ("Requirements": tenant isolation, access control, GDPR obligations) and §2.3 (OWASP Top 10 as the review baseline). TODO(owner): the planned Requirements Specification (ISMS-FORM-A08-26-1) has not been written — confirm the policy is sufficient or create it.
A.8.27 Secure system architecture and engineering principles ✅ Secure Development Policy (ISMS-DOC-A08-25-1) §2.1 ("Design") and §2.3; Cloud & Infrastructure Security Policy §2.1–§2.2; architecture in ISMS-DOC-A08-22-1 (draft).
A.8.28 Secure coding ✅ Secure Development Policy (ISMS-DOC-A08-25-1) §2.3, which absorbed the former Secure Coding Policy (ISMS-DOC-A08-28-1); peer review.
A.8.29 Security testing in development and acceptance ✅ CI tests before merge (Secure Development Policy §2.1–§2.2); release acceptance by a second founder (Change Management Process §3.2); annual pentest (ISMS-DOC-A08-8-2; 2026 results in ISMS-FORM-A08-8-3).
A.8.30 Outsourced development ➖ Excluded — development is performed in-house; no development is outsourced.
A.8.31 Separation of development, test and production environments ✅ Secure Development Policy §2.4; development in its own VPC, staging on Azure (ISMS-DOC-A08-22-1 §3, draft). Staging holds no production data per the owner (2026-09-09), pending verification (S-493).
A.8.32 Change management ✅ Change Management Process; PR review, CI/CD.
A.8.33 Test information ✅ Masked or anonymised data only outside production: Data Handling & Deletion Policy §2.2 and Secure Development Policy §2.4. Not yet verified that staging holds no production data (S-493).
A.8.34 Protection of information systems during audit testing ✅ Penetration Testing Procedure (ISMS-DOC-A08-8-2) §2 (snapshot before testing production), §3 (scope and window agreed in writing) and §5 (no destructive testing, no exfiltration); auditors get named, time-boxed, read-only access to the ISMS site (External Access to the ISMS §3).

Change log

Version Date Author Comments
0.1 2026-06-25 Andrea Cardinali / ISMS First draft — all 93 Annex A:2022 controls listed with applicability decisions and justifications; implementation references mapped to the repo. Pending completion of the risk assessment and tailoring of referenced documents.
0.2 2026-10-17 ISMS Implementation references brought up to date: 31 controls that said "to create" now point to the documents written since; stale facts corrected; remaining gaps marked TODO(owner).