Statement of Applicability

Document Control

Field	Detail
Document Owner	Reuben Firmin, CISO
Approval Authority	Reuben Firmin (CISO) and François Huet (Head of Platform)
Review Cycle	Annual (or upon significant change to scope, risk assessment, or controls)
Classification	Confidential
Related Document	ISMS Manual

Version History

Version	Date	Author	Changes
1.0	2026-02-24	Reuben Firmin	Initial SoA for ISO 27001:2022 certification
1.1	2026-05-28	Reuben Firmin	A.5.5 and A.5.6 moved from Partially Implemented to Implemented (BCP Appendices D and E added)
1.2	2026-07-01	Bomee Jung	Corrected Approval Authority to reflect CISO as accountable authority; removed CEO and “Lead Engineer” (not a role at Cadence OneFive) from approval authority

Introduction

This Statement of Applicability (SoA) is required by ISO 27001:2022 clause 6.1.3(d). It lists all controls from Annex A of ISO/IEC 27001:2022 and documents, for each control:

• Whether the control is applicable to Cadence OneFive’s ISMS scope
• Justification for inclusion or exclusion
• Implementation status (Implemented, Partially Implemented, or Planned)
• The implementing document(s) — links to existing policies or notation of documents to be created
• Implementation notes — what is in place and what gaps remain

The ISMS scope is defined in the ISMS Manual, section 4.3. Controls are selected based on the risk assessment process described in the ISMS Manual, section 6.1.

Implementation Status Definitions

Status	Definition
Implemented	Control is fully operational and documented
Partially Implemented	Control exists but has gaps in documentation, scope, or consistency
Planned	Control is recognized as needed and scheduled for implementation

Theme 5: Organizational Controls

Control #	Control Name	Applicable?	Justification	Status	Implementing Document	Implementation Notes
A.5.1	Policies for information security	Yes	Required governance foundation	Implemented	Information Security Policy, ISMS Manual	—
A.5.2	Information security roles and responsibilities	Yes	All personnel must understand security responsibilities	Implemented	ISMS Manual §5.3, Information Security Policy	—
A.5.3	Segregation of duties	Yes	Prevents unauthorized or unintentional modification	Implemented	GitHub Access Policy, Configuration Management Policy	Enforced through mandatory PR review, branch protection, and team-based access controls. Small team size provides inherent visibility across all changes.
A.5.4	Management responsibilities	Yes	Management must enforce security compliance	Implemented	ISMS Manual §5.1, Information Security Policy	—
A.5.5	Contact with authorities	Yes	Must be able to contact relevant authorities during incidents	Implemented	BCP Appendix E — Cyber Incident Notification Register	Register covers contractual notifications (NYC Cyber Command, NYSERDA ISO), statutory notifications (NYS AG, DOS Consumer Protection, NYS Police under ISBNA), and voluntary federal information sharing (CISA, FBI IC3).
A.5.6	Contact with special interest groups	Yes	Stay current with threat landscape and best practices	Implemented	BCP Appendix D — Information-Sharing Subscriptions	CISO subscribes to CISA Emergency Communications, Incident Response, Cybersecurity Advisories, and Vulnerability Bulletins. Advisories triaged into incidents or vulnerability-remediation tasks.
A.5.7	Threat intelligence	Yes	Cloud-hosted SaaS platform faces evolving threats	Partially Implemented	Vulnerability Management Policy; supplemented by vendor advisories and dependency scanning	Dependency scanning (Dependabot) and vendor advisories provide threat signals. Gap: no formal threat intelligence process or feeds documented.
A.5.8	Information security in project management	Yes	Security must be considered in development projects	Implemented	Configuration Management Policy (PR-based changes)	—
A.5.9	Inventory of information and other associated assets	Yes	Must track information assets to protect them	Implemented	How Our Systems Are Set Up, Backup Policy, Asset Inventory spreadsheet	Asset inventory maintained as a spreadsheet with owners and classification. Vendor census tracks third-party systems.
A.5.10	Acceptable use of information and other associated assets	Yes	Personnel must understand acceptable use of company assets	Implemented	Acceptable Use Policy, Remote Access Policy, BYOD Policy	—
A.5.11	Return of assets	Yes	Assets must be returned when employment ends	Implemented	On & Off Boarding Procedures, BYOD Policy	—
A.5.12	Classification of information	Yes	Data must be classified to determine protection level	Implemented	Data Classification Policy	—
A.5.13	Labelling of information	Yes	Classified information should be labelled accordingly	Partially Implemented	Data Classification Policy	Classification scheme is defined. Gap: labelling conventions (how to mark documents, repos, data stores with their classification) not yet formalized.
A.5.14	Information transfer	Yes	Secure transfer of information is required	Implemented	Data Security Policy	—
A.5.15	Access control	Yes	Least-privilege access is required	Implemented	GitHub Access Policy, Data Security Policy	—
A.5.16	Identity management	Yes	Unique identification of all users is required	Implemented	GitHub Access Policy, On & Off Boarding Procedures, Google Workspace identity management	—
A.5.17	Authentication information	Yes	Strong authentication protects system access	Partially Implemented	Remote Access Policy (MFA required), BYOD Policy	MFA is required for all system access. Gap: dedicated password/authentication standards (complexity, rotation, manager credentials) to be created.
A.5.18	Access rights	Yes	Access rights must be provisioned, reviewed, and revoked	Implemented	GitHub Access Policy, On & Off Boarding Procedures, Data Security Policy	—
A.5.19	Information security in supplier relationships	Yes	Vendors process/access company data	Implemented	Vendor Management Policy	—
A.5.20	Addressing information security within supplier agreements	Yes	Contracts must include security requirements	Implemented	Vendor Management Policy	—
A.5.21	Managing information security in the ICT supply chain	Yes	Cloud-dependent infrastructure requires supply chain oversight	Partially Implemented	Vendor Management Policy	Annual SOC 2 report review for key vendors in place. Gap: supply chain-specific risk assessment (sub-processors, fourth-party dependencies) to be formalized.
A.5.22	Monitoring, review, and change management of supplier services	Yes	Vendor performance and compliance must be monitored	Implemented	Vendor Management Policy (annual SOC 2 report review)	—
A.5.23	Information security for use of cloud services	Yes	Core infrastructure is cloud-hosted (Fly.io, AWS, Google)	Partially Implemented	Vendor Management Policy, How Our Systems Are Set Up	Shared responsibility understood operationally; vendor SOC 2 reports reviewed. Gap: formal cloud security policy documenting shared responsibility boundaries per provider to be created.
A.5.24	Information security incident management planning and preparation	Yes	Organization must be prepared to respond to incidents	Implemented	Business Continuity and Disaster Recovery	—
A.5.25	Assessment and decision on information security events	Yes	Security events must be assessed and classified	Partially Implemented	Business Continuity and Disaster Recovery	Incident declaration process exists with Incident Commander role. Gap: formal event classification criteria (severity levels, escalation thresholds) to be documented.
A.5.26	Response to information security incidents	Yes	Incidents require defined response procedures	Implemented	Business Continuity and Disaster Recovery	—
A.5.27	Learning from information security incidents	Yes	Incidents must drive improvement	Implemented	Business Continuity and Disaster Recovery (post-incident review), ISMS Manual §10.2	—
A.5.28	Collection of evidence	Yes	Evidence may be needed for incident investigation or legal proceedings	Partially Implemented	Log Management Policy (chain of custody, log preservation)	Logs preserved in HyperDX with access controls and retention. Gap: formal evidence collection and chain of custody procedures to be documented.
A.5.29	Information security during disruption	Yes	Security controls must be maintained during disruptions	Implemented	Business Continuity and Disaster Recovery	—
A.5.30	ICT readiness for business continuity	Yes	Technology must support business continuity objectives	Implemented	Business Continuity and Disaster Recovery, Backup Policy	—
A.5.31	Legal, statutory, regulatory, and contractual requirements	Yes	Must identify and comply with applicable requirements	Partially Implemented	Data Disposal Policy (GDPR, CCPA references)	Data disposal policy references key regulations. Gap: formal legal/regulatory requirements register to be created.
A.5.32	Intellectual property rights	Yes	Source code and product IP must be protected	Implemented	Employment/contractor agreements (PICAA); GitHub Access Policy (access control)	—
A.5.33	Protection of records	Yes	Records must be protected from loss or unauthorized access	Implemented	ISMS Manual §7.5, Data Security Policy	—
A.5.34	Privacy and protection of PII	Yes	Customer and employee PII requires protection	Partially Implemented	Data Classification Policy, Data Security Policy	PII classified as Confidential and protected by encryption and access controls. Gap: dedicated privacy policy mapping PII flows and legal bases to be formalized for ISO alignment.
A.5.35	Independent review of information security	Yes	ISMS effectiveness must be independently assessed	Implemented	SOC 2 Type 2 annual audit; ISMS Manual §9.2 (internal audit program)	—
A.5.36	Compliance with policies, rules, and standards for information security	Yes	Compliance must be regularly reviewed	Implemented	ISMS Manual §9.2, SOC 2 Type 2 audit	—
A.5.37	Documented operating procedures	Yes	Critical operations require documented procedures	Partially Implemented	Policies exist across the suite	Core policies documented. Gap: some operational procedures (incident classification, evidence collection, capacity planning) still to be documented.

Theme 6: People Controls

Control #	Control Name	Applicable?	Justification	Status	Implementing Document	Implementation Notes
A.6.1	Screening	Yes	Personnel with access to sensitive data require screening	Partially Implemented	On & Off Boarding Procedures	Background checks managed through Justworks PEO for employees. Gap: formal screening requirements for contractors and consultants to be documented.
A.6.2	Terms and conditions of employment	Yes	Security obligations must be established contractually	Implemented	Employment agreements and PICAA (Proprietary Information, Confidentiality, and Assignment Agreement); On & Off Boarding Procedures	—
A.6.3	Information security awareness, education, and training	Yes	All personnel must understand security responsibilities	Implemented	Information Security Policy (annual training requirement), ISMS Manual §7.3	—
A.6.4	Disciplinary process	Yes	Policy violations require a consistent response	Implemented	Remote Access Policy, BYOD Policy, Vulnerability Management Policy (each includes enforcement clauses)	—
A.6.5	Responsibilities after termination or change of employment	Yes	Access must be revoked and assets returned on departure	Implemented	On & Off Boarding Procedures, GitHub Access Policy, BYOD Policy	—
A.6.6	Confidentiality or non-disclosure agreements	Yes	Proprietary information must be contractually protected	Implemented	PICAA signed by all personnel; NDAs with third parties as required	—
A.6.7	Remote working	Yes	Fully remote organization — all work is remote	Implemented	Remote Access Policy, BYOD Policy	—
A.6.8	Information security event reporting	Yes	Timely reporting enables rapid response	Implemented	Information Security Policy (report to Head of Platform), Business Continuity and Disaster Recovery, Discord #tech_security channel	—

Theme 7: Physical Controls

Control #	Control Name	Applicable?	Justification	Status	Implementing Document	Implementation Notes
A.7.1	Physical security perimeters	No	Fully remote organization with no offices, data centers, or physical premises. All infrastructure is cloud-hosted with physical security managed by cloud providers (Fly.io, AWS).	N/A	N/A	N/A
A.7.2	Physical entry	No	No physical premises to control entry to. Cloud provider facilities have their own physical access controls.	N/A	N/A	N/A
A.7.3	Securing offices, rooms, and facilities	No	No offices, rooms, or facilities. Fully remote since founding.	N/A	N/A	N/A
A.7.4	Physical security monitoring	No	No physical premises to monitor. Cloud providers monitor their own facilities.	N/A	N/A	N/A
A.7.5	Protecting against physical and environmental threats	No	No physical premises. Cloud providers manage environmental controls (fire, flood, power) for hosted infrastructure.	N/A	N/A	N/A
A.7.6	Working in secure areas	No	No secure areas — fully remote organization.	N/A	N/A	N/A
A.7.7	Clear desk and clear screen	Yes	Remote workers must protect visible information on screens	Partially Implemented	BYOD Policy (auto-lock after 5 minutes), Data Classification Policy (clean desk reference)	Auto-lock enforced via BYOD policy. Gap: clear screen/desk guidance specific to remote home offices not explicitly documented.
A.7.8	Equipment siting and protection	No	No company-owned facilities for equipment siting. Employee devices covered under BYOD.	N/A	N/A	N/A
A.7.9	Security of assets off-premises	Yes	All company assets (laptops, devices) are off-premises by definition	Implemented	BYOD Policy, Remote Access Policy	—
A.7.10	Storage media	Yes	Employee devices may contain cached or temporary company data	Implemented	BYOD Policy (encryption, data protection), Data Disposal Policy	—
A.7.11	Supporting utilities	No	No physical infrastructure. Cloud providers manage power, cooling, and connectivity for hosted services.	N/A	N/A	N/A
A.7.12	Cabling security	No	No physical network cabling. All connectivity is via internet and cloud services.	N/A	N/A	N/A
A.7.13	Equipment maintenance	Yes	Employee devices require maintenance to remain secure	Partially Implemented	BYOD Policy (OS updates, antivirus)	Weekly OS updates and antivirus required. Gap: no formal maintenance schedule or compliance verification mechanism for employee devices.
A.7.14	Secure disposal or re-use of equipment	Yes	Company data must be removed from devices at end of life or employment	Implemented	BYOD Policy (retirement/replacement and separation procedures), Data Disposal Policy	—

Theme 8: Technological Controls

Control #	Control Name	Applicable?	Justification	Status	Implementing Document	Implementation Notes
A.8.1	User endpoint devices	Yes	Remote workers use personal and company-issued devices	Implemented	BYOD Policy, Remote Access Policy	—
A.8.2	Privileged access rights	Yes	Administrative access to systems must be controlled	Implemented	GitHub Access Policy (team structure, least privilege), Configuration Management Policy (branch restrictions)	—
A.8.3	Information access restriction	Yes	Access to information must be based on need-to-know	Implemented	GitHub Access Policy, Data Security Policy, Data Classification Policy	—
A.8.4	Access to source code	Yes	Source code is a critical intellectual property asset	Implemented	GitHub Access Policy (team-based access, branch protection)	—
A.8.5	Secure authentication	Yes	Strong authentication prevents unauthorized access	Partially Implemented	Remote Access Policy (MFA required), BYOD Policy	MFA enforced across all systems via Google Workspace and GitHub. Gap: dedicated password/authentication standards (complexity rules, service account credentials) to be created.
A.8.6	Capacity management	Yes	Platform must handle expected load	Partially Implemented	Business Continuity and Disaster Recovery	Fly.io provides on-demand scaling. Gap: formal capacity planning and monitoring thresholds to be documented.
A.8.7	Protection against malware	Yes	Endpoints and servers require malware protection	Implemented	Vulnerability Management Policy (endpoint protection), VM Hardening Policy (ClamAV on servers), BYOD Policy (antivirus required)	—
A.8.8	Management of technical vulnerabilities	Yes	Vulnerabilities in systems and software must be managed	Implemented	Vulnerability Management Policy (scanning, patching, penetration testing)	—
A.8.9	Configuration management	Yes	System configurations must be controlled and documented	Implemented	Configuration Management Policy, VM Hardening Policy	—
A.8.10	Information deletion	Yes	Data must be deleted when no longer needed	Implemented	Data Disposal Policy	—
A.8.11	Data masking	Yes	Sensitive data may need masking in non-production environments	Implemented	Configuration Management Policy (separate staging environment)	Customer data is masked in staging. Staging uses separate data from production.
A.8.12	Data leakage prevention	Yes	Prevents unauthorized disclosure of sensitive data	Partially Implemented	Data Security Policy (encryption, access control), Remote Access Policy (VPN, data protection)	Encryption in transit/at rest, VPN for customer data access, no local storage of customer data. Gap: formal DLP controls (e.g., endpoint DLP, email DLP) to be evaluated.
A.8.13	Information backup	Yes	Critical data requires backup for availability and recovery	Implemented	Backup Policy	—
A.8.14	Redundancy of information processing facilities	Yes	Service availability requires redundant processing	Partially Implemented	Fly.io; Business Continuity and Disaster Recovery	Fly.io provides multi-region capability. Gap: formal redundancy architecture and failover procedures to be documented.
A.8.15	Logging	Yes	System activity must be logged for security monitoring	Implemented	Log Management Policy	—
A.8.16	Monitoring activities	Yes	Logs and events must be actively monitored	Implemented	Log Management Policy (Sentry), Vulnerability Management Policy	—
A.8.17	Clock synchronization	Yes	Accurate timestamps required for log correlation and forensics	Implemented	Vulnerability Management Policy (single reference time source), cloud provider NTP services	—
A.8.18	Use of privileged utility programs	Yes	Utility programs with elevated access must be controlled	Partially Implemented	Configuration Management Policy (Fly CLI changes logged)	Fly CLI usage logged in #tech_change-control. Gap: formal inventory and access controls for privileged utilities to be documented.
A.8.19	Installation of software on operational systems	Yes	Software installation on production must be controlled	Implemented	Configuration Management Policy (PR-based deployment, Docker containers), VM Hardening Policy (package management)	—
A.8.20	Networks security	Yes	Network connectivity must be secured	Implemented	VM Hardening Policy (firewall, network access controls), Remote Access Policy (VPN, WPA2/WPA3), Cloudflare proxy and Zero Trust	—
A.8.21	Security of network services	Yes	Network services from vendors must be managed	Implemented	Vendor Management Policy, Cloudflare (DNS, proxy), Fly.io (networking)	—
A.8.22	Segregation of networks	Yes	Production, staging, and development must be separated	Implemented	Configuration Management Policy (three separate environments in Fly and Doppler)	—
A.8.23	Web filtering	Yes	Access to malicious websites should be controlled	Implemented	Vulnerability Management Policy (controls for malicious websites), Cloudflare Zero Trust	Cloudflare Zero Trust provides web filtering for traffic routed through the corporate network. BYOD devices accessing company resources via VPN are covered.
A.8.24	Use of cryptography	Yes	Encryption protects data in transit and at rest	Implemented	Encryption Key Management Policy, Data Security Policy (TLS 1.2+, encryption at rest)	—
A.8.25	Secure development life cycle	Yes	Application development must follow secure practices	Partially Implemented	Configuration Management Policy (PR review, CI, staging)	PR review, CI checks, and staging environment enforce secure practices. Gap: dedicated secure development policy documenting the full SDLC to be created.
A.8.26	Application security requirements	Yes	Security requirements must be defined for applications	Partially Implemented	Biweekly architecture meetings and PR reviews	Security considered in architecture discussions. Gap: formal security requirements documentation per feature/project to be created.
A.8.27	Secure system architecture and engineering principles	Yes	Systems must be designed with security in mind	Partially Implemented	Configuration Management Policy (architecture meetings), VM Hardening Policy	Defense-in-depth applied in practice (network segmentation, least privilege, encryption). Gap: secure architecture principles to be formally documented.
A.8.28	Secure coding	Yes	Code must be developed securely to prevent vulnerabilities	Partially Implemented	Configuration Management Policy (code review, CI)	Mandatory code review and CI checks catch common issues. Gap: secure coding standards (OWASP top 10 checklist, language-specific guidelines) to be created.
A.8.29	Security testing in development and acceptance	Yes	Security must be tested before deployment	Partially Implemented	Vulnerability Management Policy (penetration testing), Configuration Management Policy (CI, staging)	Annual penetration testing and CI-based testing in place. Gap: formal security testing requirements within the SDLC (e.g., SAST, DAST per release) to be documented.
A.8.30	Outsourced development	Yes	May engage external developers/contractors	Partially Implemented	Vendor Management Policy, PICAA for contractors	Contractors sign PICAA and follow same PR review process. Gap: outsourced development security requirements to be formalized in a dedicated policy.
A.8.31	Separation of development, test, and production environments	Yes	Environments must be separated to protect production	Implemented	Configuration Management Policy (development, staging, production in Fly and Doppler)	—
A.8.32	Change management	Yes	Changes to systems must be controlled	Implemented	Configuration Management Policy	—
A.8.33	Test information	Yes	Test data must be protected and controlled	Partially Implemented	Configuration Management Policy	Staging uses separate data from production. Gap: formal test data management procedures (sanitization, access controls for test data) to be documented.
A.8.34	Protection of information systems during audit testing	Yes	Audit testing should not disrupt production systems	Partially Implemented	GitHub Access Policy (Auditors team)	SOC 2 audit uses read-only evidence; auditor GitHub access is time-limited. Gap: formal audit testing controls (scope restrictions, rollback procedures) to be documented.

Summary

Applicability Overview

Theme	Total Controls	Applicable	Not Applicable
Theme 5: Organizational	37	37	0
Theme 6: People	8	8	0
Theme 7: Physical	14	5	9
Theme 8: Technological	34	34	0
Total	93	84	9

Implementation Status Overview

Status	Count
Implemented	56
Partially Implemented	28
Planned	0
Not Applicable	9
Total Applicable	84

Exclusion Summary

All 9 excluded controls are in Theme 7 (Physical Controls) and relate to physical premises, facilities, or infrastructure that Cadence OneFive does not maintain as a fully remote, cloud-native organization:

• A.7.1 Physical security perimeters
• A.7.2 Physical entry
• A.7.3 Securing offices, rooms, and facilities
• A.7.4 Physical security monitoring
• A.7.5 Protecting against physical and environmental threats
• A.7.6 Working in secure areas
• A.7.8 Equipment siting and protection
• A.7.11 Supporting utilities
• A.7.12 Cabling security

Physical security of cloud infrastructure is managed by the respective cloud providers (Fly.io, AWS) under the shared responsibility model, validated through their SOC 2 reports as part of the Vendor Management Policy.

Key Gaps for Remediation

The following documents or formalizations are identified as needed to move from “Partially Implemented” to “Implemented”:

1. Secure Development Policy — Covering secure SDLC, coding standards, and security testing (A.8.25–A.8.31)
2. Password/Authentication Standards — Formal requirements for authentication mechanisms (A.5.17, A.8.5)
3. Incident Classification Criteria — Formal event assessment and classification procedure (A.5.25)
4. Evidence Collection Procedures — Chain of custody and forensic evidence handling (A.5.28)

Policy Review

• This Statement of Applicability will be reviewed annually and updated as necessary to reflect changes in the risk assessment, control implementations, or organizational context.
• Last reviewed/updated: 2026-08-25