The Statement of Applicability is the first document auditors ask for, and nobody’s excited to build one. It’s a master list of all the security controls your organization has considered, which ones you’ve implemented, and why you decided to include or exclude each one. Auditors will ask for it. Management needs to understand it. Your security team needs to live by it.
In CISO Assistant, the SoA is built through Applied Controls, which are the concrete security measures your organization actually implements. Not theoretical “we should do this” items, but “we are doing this, here’s how it works” measures. This guide walks you through creating that controls framework, organizing it properly, and connecting it to everything else in your ISMS.
What applied controls actually look like
An applied control is a specific, real security measure. Some examples to set the right level of detail:
- “User and Access Management Procedure” covering onboarding and offboarding processes managed through JumpCloud
- “Encrypted Drives” meaning full-disk encryption on all company laptops via FileVault and BitLocker
- “ESET Endpoint Antivirus” deployed to all workstations via MDM
- “Information Backup” running daily backups of production databases with 30-day retention
Controls can be policies (written rules), processes (documented procedures), technical measures (software, hardware configurations), or physical measures (locks, cameras, fire suppression). Understanding these categories helps you think systematically about what you have and what you’re missing.
| Category | What it covers | Examples |
|---|---|---|
| Policy | Written rules and commitments | Information Security Policy, Acceptable Use Policy, Password Policy |
| Process | Documented procedures people follow | Onboarding/offboarding, access reviews, change management |
| Technical | Technology-based measures | MFA, encryption, firewalls, antivirus, DLP, monitoring |
| Physical | Physical security measures | Office access controls, CCTV, UPS, cabling security |
Build your controls library
Go to Governance > Applied Controls and start creating controls systematically. The temptation is to jump straight to the technical stuff, but starting with organizational controls first gives you the governance foundation that everything else sits on.
Organizational controls (Annex A.5)
Your ISMS governance controls establish who does what and how decisions get made. Create controls for ISMS Roles and Responsibilities (A.5.2), covering who the COO, CISO, and security team members are and what they’re accountable for. Segregation of Duties (A.5.3) documents how you separate responsibilities to prevent conflicts of interest. Contact with Authorities and Interest Groups (A.5.5) covers how you engage with regulators, law enforcement, and security forums.
For information handling, you need Information Classification and Labelling (A.5.12) to define your data sensitivity categories like Public, Internal, Confidential, and Legally Protected. Acceptable Use of Information (A.5.10) sets the rules for how employees handle classified information.
Supplier management requires at least two controls. Information Security in Supplier Relationships (A.5.19) covers how you assess and monitor vendor security - our vendor security management guide walks through this in detail - and Supplier Management Process (A.5.21) handles ongoing monitoring, review, and change management. Add Cloud Security Guidelines (A.5.23) with security recommendations for cloud service usage.
For compliance, create Legal Documents and Compliance Management (A.5.31) to track legal requirements, Software Licensing Compliance (A.5.32) to ensure proper licensing, and an Audit Management Procedure (A.5.35) documenting how you organize and track audits.
People controls (Annex A.6)
These cover the human side of security, and they’re more important than most technical teams want to admit.
| Control Name | Ref ID | Category | What it covers |
|---|---|---|---|
| Employee Screening Process | A.6.1 | Process | Background checks on candidates before hiring |
| Employment Terms - Security Obligations | A.6.2 | Policy | Security responsibilities in employment contracts |
| Security Awareness, Education and Training | A.6.3 | Process | Regular security training for all employees |
| Offboarding Process - Asset Return | A.6.5 | Process | Equipment return, access revocation, exit procedures |
| NDA and Confidentiality Agreements | A.6.6 | Policy | Confidentiality provisions in contracts |
Access management controls
Access management is where we see the most gaps in practice, even when organizations think they have it covered.
| Control Name | Ref ID | Category | What it covers |
|---|---|---|---|
| User and Access Management Procedure | A.5.15 | Process | Onboarding/offboarding rules managed via JumpCloud |
| Privileged Access Management | A.8.2 | Process | How admin and root access is controlled |
| Regular Access Review | A.5.18 | Process | Periodic review of who has access to what |
| Source Code Access Control | A.8.4 | Technical | Repository access based on project and role |
| MFA | A.8.5 | Technical | Multi-factor authentication across critical systems |
| 1Password - Password Manager | A.5.17 | Technical | Enterprise password management for all credentials |
Access reviews are annoying to run. We know. But the alternative is finding out during an incident that a former contractor still has admin access to production. That’s worse.
Physical controls (Annex A.7)
| Control Name | Ref ID | Category | What it covers |
|---|---|---|---|
| Office Security | A.7.1 | Physical | Physical security perimeters and entry controls at each office |
| Secure Areas and Zones | A.7.6 | Physical | Security zone division with video surveillance |
| Clear Desk and Clear Screen Policy | A.7.7 | Policy | Minimizing visible sensitive information |
| UPS and Power Protection | A.7.11 | Physical | Uninterruptible power supplies and electrical protection |
| Cabling Security | A.7.12 | Physical | Network cabling placed to prevent unauthorized access |
| IT Equipment Maintenance | A.7.13 | Process | Regular inspection and maintenance schedule |
| Data Retention and Deletion Procedure | A.7.14 | Process | Secure disposal and reuse of equipment and storage |
Technical controls (Annex A.8)
This is usually the largest section, and for good reason. These are the hands-on measures that directly protect your systems.
For endpoint and device security, you’ll want controls for JumpCloud MDM (A.8.1) handling device management, JumpCloud Storage Media Control (A.7.10) for removable media and device encryption, JumpCloud System Updates (A.8.8) for automated patching, ESET Endpoint Antivirus (A.8.7), ESET Web Filtering (A.8.23) for blocking dangerous sites, and Encrypted Drives (A.8.24) for full-disk encryption.
Network security controls include UTM FortiGate (A.8.20) for unified threat management, FortiGate Web Filtering (A.8.23), Networks Separation with VLANs (A.8.22), and JumpCloud RADIUS (A.8.21) for network authentication.
Data protection covers Encryption of Databases (A.8.24), Google Workspace DLP (A.8.12), Data Masking for Production Data (A.8.11), Information Backup (A.8.13), and Information Deletion (A.8.10).
Monitoring and detection includes Security Monitoring and Alerts (A.8.16), Datadog SIEM (A.8.15), and NTP Clock Synchronization (A.8.17) to keep logs accurate.
For email security, document Gmail’s Antispam, AV Protection, and Sandbox capabilities (A.8.7).
Development security needs Security Recommendations for Projects (A.8.25), ASVS and Secure Coding Guidelines (A.8.28), Dev/Test/Prod Environment Separation (A.8.31), Security Testing Procedure (A.8.29), and Change Management (A.8.32). Change management is the control that developers complain about most, and it’s also the one that saves you from the most incidents.
Business continuity rounds things out with ICT Readiness for Business Continuity (A.5.30), SaaS Redundancy for Critical Services (A.8.14), and Capacity Management for Cloud Resources (A.8.6).
Write descriptions that actually mean something
The description field is where your SoA comes alive. A good description tells the reader exactly what’s happening with enough detail to understand and verify the control.
Bad descriptions look like “We have access control” (what kind? how? where?), or “Compliant with A.5.15” (that’s circular and tells nobody anything), or “See policy document” (forcing the reader to hunt for information).
Good descriptions are specific and concrete. “Onboarding/offboarding processes with rules for user registration, deregistration, and access assignment. Managed via JumpCloud. New employees receive access based on role templates. Departing employees have access revoked within 24 hours of last working day.”
Or “Full-disk encryption enforced on all company macOS and Windows devices via JumpCloud MDM policies. FileVault (macOS) and BitLocker (Windows) are required and cannot be disabled by users.”
Or “Periodic review of user access rights conducted quarterly. All privileged accounts reviewed monthly. Review results documented and non-compliant access removed within 5 business days.”
The pattern is the same: what the control is, how it works, and what the concrete implementation looks like. If an auditor reads your description and has follow-up questions, the description needs more detail.
Connect controls to risk scenarios
Every applied control should mitigate at least one risk scenario. If a control doesn’t connect to any risk, either it’s unnecessary or you’re missing a risk scenario.
The mappings follow a pattern. Unauthorized Data Access is mitigated by MFA, JumpCloud MDM, access reviews, encrypted drives, database encryption, DLP, security monitoring, and supplier security management. Unauthorized Network Access is covered by RADIUS, FortiGate UTM, VLANs, MFA, and monitoring. Malicious Code is fought by antivirus, web filtering on multiple layers, Gmail AV, system updates, DNS protection, monitoring, and network segmentation.
Data Loss is addressed through backup procedures, encryption, data deletion procedures, and DLP. Social Engineering is mitigated by training, MFA, the password manager, email security, web filtering, and monitoring. User Error and Operational Errors are reduced by training, knowledge bases, and change management.
Unavailability is handled by business continuity planning, change management, SaaS redundancy, and capacity management. Fire and flood rely on BCP, backups, and physical security. Theft and loss is covered by MDM, encrypted drives, and MFA.
Keep your SoA current
Your controls framework isn’t something you build once and forget about. When you implement a new control, add it immediately and link it to relevant risk scenarios and compliance requirements. When a control changes, like switching from one firewall to another, update the name and description. When you decommission a control, change its status to “Inactive” rather than deleting it, because you’ll need the historical record for audits.
Before audits, review all controls to make sure descriptions reflect reality. During management review, present the SoA summary showing control counts by category and status.
Your Statement of Applicability is how you prove your organization has thought through what controls it needs and why. Build it well, keep it honest, and it will serve you in every audit, every management review, and every incident response. The organizations that struggle with audits aren’t usually the ones with weak controls. They’re the ones who can’t articulate what they’re doing and why.
Once your SoA is built, the next step is mapping those controls to compliance framework requirements for ISO 27001 and TISAX. Make sure your asset inventory is also connected so auditors can see the full chain from assets through risks to controls. For a broader view of how CISO Assistant handles the entire ISMS process, see why teams choose CISO Assistant.
