ISO 27001 Documentation Requirements
Documentation is a fundamental aspect of ISO 27001. Understanding what documentation is required—and why—helps you build an effective ISMS without over-engineering or under-preparing.
Key Takeaways
| Point | Summary |
|---|---|
| Mandatory documents | ISO 27001 explicitly requires certain documented information |
| Total documentation | Typically 30-35 documents for a complete ISMS |
| Purpose | Ensures consistency, enables improvement, provides audit evidence |
| Balance needed | Sufficient for compliance without bureaucratic overhead |
| Maintenance | Documents must be controlled, reviewed, and kept current |
Quick Answer: ISO 27001 requires documented information including your ISMS scope, information security policy, risk assessment methodology and results, Statement of Applicability, and evidence that controls are operating. Most organizations create 30-35 documents, but the exact number depends on your context and how you choose to organize your documentation.
Understanding Documentation Requirements
What "Documented Information" Means
ISO 27001:2022 uses the term "documented information" to cover:
- Documents: Policies, procedures, guidelines (how things should be done)
- Records: Evidence that activities have been performed (proof things were done)
Both are important for certification:
- Documents define your ISMS
- Records prove it's operating
Why Documentation Matters
| Purpose | Benefit |
|---|---|
| Consistency | Ensures practices are repeatable |
| Communication | Makes expectations clear to staff |
| Training | Provides reference material |
| Audit evidence | Demonstrates compliance |
| Continuity | Knowledge preserved if people leave |
| Improvement | Baseline for measuring progress |
Mandatory Documentation
Explicitly Required by ISO 27001
The standard explicitly requires the following documented information:
| Document | Clause Reference | Purpose |
|---|---|---|
| ISMS scope | 4.3 | Defines boundaries of your ISMS |
| Information security policy | 5.2 | Top-level security commitment |
| Risk assessment methodology | 6.1.2 | How you identify and assess risks |
| Risk assessment results | 6.1.2 | Output of your risk assessment |
| Risk treatment plan | 6.1.3 | How you're addressing identified risks |
| Statement of Applicability | 6.1.3 d) | Which Annex A controls apply and why |
| Information security objectives | 6.2 | Measurable security goals |
| Competence evidence | 7.2 | Proof of personnel competence |
| Operational planning and control | 8.1 | How operations are managed |
| Risk assessment records | 8.2 | Documentation of risk assessment activities |
| Risk treatment records | 8.3 | Evidence of risk treatment implementation |
| Monitoring and measurement results | 9.1 | Performance metrics |
| Internal audit program and results | 9.2 | Internal audit documentation |
| Management review results | 9.3 | Management review meeting records |
| Nonconformity and corrective action | 10.1 | Evidence of improvement activities |
Control-Specific Documentation
Many Annex A controls also require documented information, such as:
| Control Area | Documentation Needed |
|---|---|
| Access control | Access control policy, user access records |
| Asset management | Asset inventory, acceptable use policy |
| Operations security | Operating procedures, change records |
| Incident management | Incident response procedure, incident records |
| Business continuity | Business continuity plans, test results |
| Supplier relationships | Supplier policy, supplier assessments |
Typical ISMS Documentation Set
Common Structure
Most organizations organize their ISMS documentation in layers:
Tier 1: Policy Documents
High-level statements of intent and direction
Tier 2: Procedures
How policies are implemented in practice
Tier 3: Work Instructions/Guidelines
Detailed steps for specific tasks
Tier 4: Records/Evidence
Proof that activities occurred
Representative Document List
A typical ISMS includes documents such as:
| Category | Documents |
|---|---|
| Core ISMS | ISMS scope, Security policy, Risk methodology, Statement of Applicability |
| Organizational | Security roles, Asset management, Information classification |
| People | Acceptable use, Remote working, Security awareness, Screening |
| Operations | Change management, Incident response, Business continuity, Backup |
| Access Control | Access control policy, User provisioning, Privileged access |
| Technical | Encryption, Network security, Secure development, Vulnerability management |
| Third Party | Supplier security, Cloud security |
| Records | Risk register, Internal audit, Management review |
Document Count Guidance
| Organization Size | Typical Document Count |
|---|---|
| Small startup | 25-30 documents |
| Medium company | 30-40 documents |
| Larger organization | 40-50+ documents |
The goal isn't to minimize or maximize—it's to have appropriate documentation for your context.
Creating Effective Documentation
Policy Writing Principles
Effective policies are:
| Principle | Application |
|---|---|
| Clear | Unambiguous language, no jargon |
| Concise | Long enough to be complete, short enough to be read |
| Actionable | Specific enough to guide behavior |
| Appropriate | Suited to your organization's size and culture |
| Maintained | Reviewed and updated regularly |
Common Documentation Mistakes
| Mistake | Better Approach |
|---|---|
| Copying generic templates | Tailor to your actual environment |
| Over-documenting | Document what's necessary, not everything |
| Under-documenting | Ensure mandatory items are covered |
| Set and forget | Regular review and update cycle |
| Too theoretical | Reflect actual practices |
| No version control | Track changes and approvals |
Document Control Requirements
ISO 27001 requires that documented information is controlled:
| Requirement | Implementation |
|---|---|
| Identification | Clear titles, version numbers |
| Format | Consistent templates and structure |
| Review and approval | Defined approval process |
| Distribution | Ensure current versions available |
| Storage and protection | Secure, accessible storage |
| Change control | Track and approve modifications |
| Retention | Defined retention periods |
| Disposition | Secure disposal when no longer needed |
Key Documents in Detail
1. ISMS Scope
Purpose: Defines the boundaries of your information security management system.
Should include:
- Products/services covered
- Business functions in scope
- Physical locations included
- Systems and data covered
- Organizational units
- Boundaries and exclusions (with justification)
Example:
"The ISMS covers the development, delivery, and support of [Product Name], including customer data processing, cloud infrastructure (AWS), corporate IT systems, and all personnel involved in these activities."
2. Information Security Policy
Purpose: Top-level statement of management's commitment and security direction.
Should include:
- Management commitment to security
- Security objectives or framework
- Compliance with requirements
- Continual improvement commitment
- Policy applicability
- Review frequency
Length: Typically 2-4 pages
3. Risk Assessment Methodology
Purpose: Defines how your organization identifies, analyzes, and evaluates risks.
Should include:
- Risk identification approach
- Risk analysis criteria (likelihood, impact scales)
- Risk evaluation criteria (risk levels, acceptance thresholds)
- Risk treatment options
- Review frequency
4. Statement of Applicability (SoA)
Purpose: Documents which Annex A controls apply to your organization and why.
Should include for each of 93 controls:
- Control reference and title
- Applicable (Yes/No)
- Justification for inclusion or exclusion
- Implementation status
- Brief description of implementation (optional)
5. Risk Register
Purpose: Documents identified risks and their treatment.
Should include:
- Risk identifier
- Risk description
- Asset/process affected
- Threat and vulnerability
- Likelihood and impact ratings
- Risk level (calculated)
- Treatment decision
- Controls applied
- Residual risk
- Risk owner
- Status
Evidence and Records
What Evidence to Collect
| Control Area | Example Evidence |
|---|---|
| Access control | User lists, access review records, MFA configuration |
| Change management | Change tickets, approval records, test results |
| Security awareness | Training records, completion certificates, materials |
| Incident response | Incident tickets, response timelines, lessons learned |
| Vulnerability management | Scan reports, remediation records, patching status |
| Backup | Backup logs, restoration test records |
| Supplier management | Assessments, contracts, monitoring records |
Evidence Freshness
Different types of evidence have different freshness requirements:
| Evidence Type | Freshness Expectation |
|---|---|
| Security awareness training | Annual completion |
| Access reviews | Quarterly |
| Vulnerability scans | Monthly or continuous |
| Backup tests | Regular intervals (quarterly typical) |
| Incident records | Period since last audit |
| Policy reviews | Annual |
Organizing Evidence
Effective evidence organization:
| Approach | Benefits |
|---|---|
| Centralized platform | Single source of truth |
| Automated collection | Reduces manual effort |
| Consistent naming | Easy to locate |
| Version control | Clear audit trail |
| Access control | Appropriate permissions |
Maintaining Documentation
Review Cycle
| Document Type | Review Frequency |
|---|---|
| Policies | Annual minimum |
| Procedures | Annual or on change |
| Risk assessment | Annual + on significant change |
| SoA | Annual + on control changes |
| Records | As generated |
Triggers for Updates
Update documentation when:
- Annual review cycle
- Significant organizational changes
- New systems or processes
- Incident findings
- Audit findings
- Regulatory changes
- Feedback or improvements identified
Version Control
Essential version control elements:
| Element | Purpose |
|---|---|
| Version number | Track document evolution |
| Date | When approved/published |
| Author | Who wrote/updated |
| Approver | Who authorized |
| Change summary | What changed |
| Next review date | When to review again |
Working with Templates
Pros of Templates
| Benefit | Consideration |
|---|---|
| Faster development | Don't start from scratch |
| Completeness | Cover required elements |
| Consistency | Uniform formatting |
| Experience-based | Learn from what works |
Template Pitfalls
| Risk | Mitigation |
|---|---|
| Generic content | Customize to your context |
| Over-complexity | Simplify for your size |
| Outdated standards | Ensure ISO 27001:2022 alignment |
| Cut-and-paste errors | Careful review before use |
Best Practice
Templates are a starting point, not an end point. Every document should reflect your actual organization, processes, and controls.
Common Questions
How many pages should policies be?
There's no requirement. Policies should be long enough to be complete and short enough to be read. For smaller organizations, a 2-3 page policy is often sufficient. Avoid unnecessary complexity.
Can we combine documents?
Yes. You can organize documentation however works for your organization. What matters is that required content exists and is controlled, not how it's packaged.
What format should documents use?
No required format. Most organizations use Word documents, Google Docs, or purpose-built compliance platforms. Choose what's maintainable for your team.
How detailed should procedures be?
Detailed enough that someone could follow them, concise enough that they will be read. The right level depends on your team's expertise and the complexity of the process.
The Bastion Approach
We help organizations develop appropriate documentation:
| Challenge | Our Approach |
|---|---|
| Starting from scratch | Pre-built templates tailored to your context |
| Document development | Expert drafting with your review and approval |
| Consistency | Uniform formatting and organization |
| Completeness | Coverage of all mandatory requirements |
| Maintenance | Ongoing support for reviews and updates |
Ready to develop your ISMS documentation? Talk to our team
Sources
- ISO/IEC 27001:2022 - Information security management systems requirements
- ISO/IEC 27002:2022 - Information security controls guidance