ISO 27001 & ISMS Implementation
What ISO 27001 Actually Is
ISO 27001 is the international standard for information security management. Unlike SOC 2, which is an attestation (an auditor writes an opinion), ISO 27001 is a certification. You either pass or you do not. An accredited certification body audits your ISMS against the standard and issues a certificate valid for three years.
Enterprise buyers outside of North America care about ISO 27001 more than SOC 2. European companies often require it. Government contracts in many countries list it as a prerequisite. If you sell globally, you will probably need both.
The standard follows a Plan-Do-Check-Act (PDCA) cycle. You define your security objectives and controls (Plan), implement them (Do), monitor and measure their effectiveness (Check), and improve based on findings (Act). The auditor verifies that this cycle is running continuously, not just at audit time.
The Statement of Applicability
The Statement of Applicability (SoA) is the most important document in your ISMS. It lists every Annex A control, states whether it applies to your organization, and explains why or why not.
The 2022 revision has 93 controls organized into four themes:
| Theme | Controls | Examples |
|---|---|---|
| Organizational | 37 | Information security policies, roles, threat intelligence, cloud service security |
| People | 8 | Screening, awareness training, responsibilities after termination |
| Physical | 14 | Secure areas, equipment maintenance, clear desk policy |
| Technological | 34 | Access rights, cryptography, secure development, logging, data masking |
You are expected to exclude controls that genuinely do not apply. If you do not handle physical media, exclude the media handling control and document the justification. Auditors respect well-reasoned exclusions. They get suspicious when an organization claims every single control applies, because that usually means nobody thought about it carefully.
Risk Assessment
The risk assessment drives everything. ISO 27001 does not prescribe a specific methodology, but it requires that you:
- Identify assets - Not just servers. Information assets include databases, source code, customer data, API keys, and the knowledge in people's heads.
- Identify threats and vulnerabilities - What could go wrong? Unauthorized access, data loss, service outages, insider threats, supply chain compromise.
- Evaluate likelihood and impact - Use whatever scale works for you (3x3, 5x5). The standard does not mandate a specific matrix.
- Decide on treatment - For each risk: mitigate (apply a control), accept (the risk is within appetite), transfer (insurance, outsourcing), or avoid (stop the activity).
The risk register is a living document. Update it when your infrastructure changes, when new threats emerge, or when incidents reveal gaps. Auditors will ask to see the history.
Controls That Engineers Own
Many Annex A controls map directly to engineering work:
Access control (A.8.3-A.8.5) - Least privilege, unique credentials, MFA enforcement, access provisioning and de-provisioning. If you can pull a report showing who has access to what, and that access reviews happen quarterly, you are in good shape.
Cryptography (A.8.24) - Encryption at rest and in transit. Key management procedures. Certificate lifecycle management. Document your encryption standards and make sure they are actually enforced, not just recommended.
Secure development (A.8.25-A.8.31) - Secure coding guidelines, code review requirements, separation of dev/test/prod environments, change management procedures. If you already do pull request reviews and have CI/CD pipelines with automated testing, you are most of the way there.
Logging and monitoring (A.8.15-A.8.16) - Centralized logging, log protection (logs should be immutable), monitoring for security events, and defined response procedures when anomalies are detected.
Vulnerability management (A.8.8) - Regular vulnerability scanning, patch management timelines, and a process for handling zero-days. Define SLAs: critical vulnerabilities patched within X days, high within Y days.
The Certification Process
Stage 1 (documentation review) - The auditor reviews your ISMS documentation: scope, risk assessment, SoA, policies, and procedures. They check completeness, not effectiveness. Typical outcome: a list of gaps you need to close before Stage 2. Budget 1-2 days for the audit, 2-3 months for remediation.
Stage 2 (implementation audit) - The auditor interviews staff, inspects systems, and samples evidence to verify that your controls are working as documented. They will talk to engineers, check access logs, review incident records, and test whether people follow the processes they claim to follow. Budget 3-5 days depending on scope.
Surveillance audits - After certification, the certification body conducts an annual surveillance audit covering a subset of controls. These keep you honest between full assessments.
Recertification - Every three years, a full audit cycle repeats. The expectation is that your ISMS has matured, not just survived.
ISO 27001 vs. SOC 2
These two frameworks overlap significantly but serve different buyers:
| ISO 27001 | SOC 2 | |
|---|---|---|
| Type | Certification (pass/fail) | Attestation (auditor opinion) |
| Geography | Global, especially strong in EU and APAC | Primarily North America |
| Scope | Entire ISMS | Specific system or service |
| Controls | 93 Annex A controls | 5 Trust Service Criteria (flexible) |
| Audit cycle | 3-year cert + annual surveillance | Annual Type II report |
| Cost | $30K-$100K for initial cert | $20K-$80K for Type II report |
If you need both, run them in parallel. About 60-70% of the evidence overlaps. Use the same access review process, the same logging infrastructure, the same incident response records. The main additional work for ISO 27001 is the formal risk assessment methodology and the Statement of Applicability, which SOC 2 does not require.
Key Points
- •ISO 27001 is a certification, not an attestation like SOC 2. An accredited auditor verifies your Information Security Management System (ISMS) against a defined standard
- •The 2022 revision reorganized Annex A from 114 controls in 14 domains down to 93 controls in 4 themes: Organizational, People, Physical, and Technological
- •You do not implement all 93 controls. The Statement of Applicability documents which controls apply to your organization and why any are excluded
- •Certification requires two audit stages: Stage 1 reviews your documentation, Stage 2 tests whether you actually do what the docs say
- •Surveillance audits happen annually; full recertification every three years. This is not a one-and-done effort
Common Mistakes
- ✗Writing an ISMS that describes how you want to operate rather than how you actually operate. Auditors test reality, not aspirations
- ✗Trying to implement all 93 Annex A controls regardless of relevance. The standard explicitly expects you to exclude controls that do not apply
- ✗Treating the risk assessment as a paperwork exercise rather than using it to drive actual security investment decisions
- ✗Underestimating the time between Stage 1 and Stage 2. Most organizations need 2-3 months to close gaps identified in the documentation review