ISO 27001 Implementation: Your First 90 Days From Zero to Audit-Ready Documentation

ISO 27001 certification requires documented evidence that your organization has established, implemented, maintained, and continually improved an Information Security Management System (ISMS). The auditor evaluates your documentation, interviews your staff, and samples your evidence to determine whether what you have written matches what you actually do.

Most organizations that fail their first audit fail on documentation — not on technical controls. They have MFA deployed but no access control policy. They run backups but have no business continuity plan. They patch systems but have no vulnerability management standard. The controls exist informally; the evidence that they exist, are maintained, and are reviewed does not.

This guide provides a week-by-week implementation roadmap that takes an organization from no formal ISMS to audit-ready documentation in 90 days. It is written for the person leading the implementation — typically a security manager, IT director, or CISO at an organization with 50-500 employees.

What the Auditor Actually Evaluates

Before building anything, understand what the auditor looks for. ISO 27001:2022 certification audits evaluate three categories:

1. Mandatory clauses (4-10) — These are non-negotiable. Every certified organization must have documented evidence for each clause: context of the organization, leadership commitment, risk assessment process, objectives, operational planning, performance evaluation, and continual improvement.

2. Annex A controls (93 controls across 4 domains) — Organizational, People, Physical, and Technological. You do not need to implement all 93 — but you must document in your Statement of Applicability which controls you have implemented, which you have excluded, and why.

3. Operational evidence — Proof that the documented processes are actually running. Meeting minutes, risk review records, audit logs, training records, incident logs, access reviews. This is where most organizations fail — they write the policy but do not produce the evidence that they follow it.

The auditor will randomly select controls from your Statement of Applicability and ask for the policy, the procedure, and the evidence that the procedure has been executed within the review period. If any link in the chain is missing (no policy, policy exists but no procedure, procedure exists but no evidence), it is a nonconformity.

The 90-Day Roadmap

Weeks 1-2: Scope, Context, and Governance

Define ISMS scope. What is in scope for certification? Define the boundaries: which locations, which business functions, which information systems, which third parties. A common mistake is scoping too broadly — certifying the entire organization when only the SaaS product team and its supporting infrastructure need to be covered.

The scope statement must be specific enough that an auditor can determine what is included and what is excluded. “Ridgeline Cyber Defence’s development, delivery, and support of cybersecurity documentation products and implementation services” is a defensible scope. “Information security” is not.

Document context of the organization (Clause 4). Identify internal and external issues that affect the ISMS: regulatory requirements (GDPR, sector-specific regulation), contractual obligations (customer security requirements, insurance conditions), organizational structure, technology landscape. This feeds the risk assessment.

Establish governance (Clause 5). Document leadership commitment, information security policy (the top-level policy signed by the CEO/MD that commits the organization to information security), and roles and responsibilities. The ISMS needs a named owner — someone with the authority to make decisions and allocate resources.

Deliverables by end of Week 2:

• ISMS scope statement
• Context of the organization document (interested parties, issues, requirements)
• Information security policy (top-level, signed by leadership)
• Roles and responsibilities matrix (ISMS owner, risk owners, control owners)

Weeks 3-4: Risk Assessment

Define risk methodology (Clause 6.1.2). Document how you identify, assess, and treat risks. The methodology must include: the scoring criteria (likelihood and impact scales with calibrated definitions), risk appetite (what level of risk is acceptable), and the process for risk treatment (accept, mitigate, transfer, avoid).

Conduct the risk assessment. Identify risks to information assets within your ISMS scope. Score each risk using your defined methodology. Document risk owners for each identified risk.

The practical approach: run a risk workshop with key stakeholders (IT, operations, HR, finance, legal). Walk through common risk categories: credential compromise, data loss, ransomware, insider threat, vendor compromise, regulatory non-compliance, physical access, business continuity. Score each risk. Assign owners.

Document the Statement of Applicability (SoA). This is the most important single document in the ISMS. It lists all 93 Annex A controls with, for each one: whether it is applicable, the justification for inclusion or exclusion, the implementation status, and the responsible party.

The SoA is not optional. ISO 27001:2022 Clause 6.1.3(d) explicitly requires it. The auditor will use it as their roadmap for the entire audit — they will select controls from the SoA and evaluate the supporting policy, procedure, and evidence for each.

Risk treatment plan. For each risk above your appetite threshold, document the treatment: what control or action will reduce the risk, who is responsible, what is the timeline, and what is the target residual risk score.

Deliverables by end of Week 4:

• Risk assessment methodology document
• Risk register (all identified risks, scored, with owners)
• Statement of Applicability (93 controls, justified)
• Risk treatment plan (actions for above-appetite risks)

Weeks 5-8: Policy and Procedure Documentation

This is the bulk of the work. Each applicable Annex A control needs a policy (what the organization requires), a procedure (how the requirement is met), and evidence that the procedure is followed.

Prioritise by audit risk. Not all 93 controls receive equal auditor attention. The controls that auditors almost always sample:

• A.5.1 Policies for information security — the auditor checks that the policy framework exists and is approved
• A.5.15 Access control — the auditor checks that access is based on business need and reviewed periodically
• A.5.23 Information security for cloud services — increasingly common focus area
• A.5.24 Incident management planning — the auditor checks for a plan, roles, and evidence of testing
• A.5.29 Information security during disruption — business continuity and DR documentation
• A.8.1 User endpoint devices — device management, encryption, patching
• A.8.5 Secure authentication — MFA, password policy, session management
• A.8.8 Management of technical vulnerabilities — patching and vulnerability scanning evidence

Write the policies and procedures for these controls first. Then work through the remaining applicable controls systematically.

Policy structure that survives audits. Every policy document needs: purpose, scope, policy statements with specific measurable requirements, roles and responsibilities, exceptions process, review cycle, document control (version, owner, approval date, next review date).

Specific requirements are critical. “Passwords must be strong” fails an audit. “Passwords must be a minimum of 12 characters, include uppercase, lowercase, numeric, and special characters, and must not be reused within 24 generations” passes. The auditor tests whether your requirements are specific enough to be audited — if a requirement cannot be objectively verified, it is a weakness.

Deliverables by end of Week 8:

• Information security policy suite (policies covering all applicable Annex A domains)
• Access control policy and procedure
• Incident response plan with classification and roles
• Business continuity and disaster recovery plan
• Change management policy and procedure
• Supplier/vendor management policy
• Data classification policy and handling procedures
• Acceptable use policy
• Supporting procedures for each policy

Weeks 9-10: Control Implementation and Evidence

Policies describe requirements. This phase ensures the technical and operational controls are actually implemented and producing evidence.

Access reviews. Run a formal access review for all systems in scope. Document who has access, whether the access is appropriate for their role, and any access that was revoked. This produces evidence for A.5.15 and A.5.18.

Vulnerability scan. Run a vulnerability scan against all in-scope systems. Document the results, the remediation plan, and the timeline. This produces evidence for A.8.8.

Backup verification. Verify that backup jobs are completing successfully and test a restore. Document the test results. This produces evidence for A.8.13.

Security awareness training. Deliver training to all in-scope personnel. Document attendance and assessment results. This produces evidence for A.6.3.

Incident response test. Run a tabletop exercise using the IR plan you wrote in Week 6. Document the scenario, participants, decisions made, and lessons learned. This produces evidence for A.5.24 and A.5.25.

The theme: every control needs evidence that it has been executed at least once within the review period. An auditor sampling A.8.8 (vulnerability management) will ask for your policy, your scanning procedure, the most recent scan report, and the remediation tracking. If any piece is missing, it is a nonconformity.

Weeks 11-12: Internal Audit and Management Review

ISO 27001 Clause 9.2 requires an internal audit of the ISMS before the certification audit. Clause 9.3 requires a management review.

Internal audit. Audit your own ISMS against the standard. Check that every mandatory clause has documented evidence. Sample 15-20 Annex A controls from your SoA and verify the policy-procedure-evidence chain for each. Document findings as conformities, observations, or nonconformities.

The internal audit does not need to be performed by an external party — but the auditor must be independent of the processes being audited. If you wrote the policies, someone else should audit them.

Management review. Present the ISMS status to leadership. Cover: scope, risk assessment results, internal audit findings, incident metrics, performance against objectives, resource requirements, and improvement opportunities. Document the meeting minutes including decisions made and actions assigned.

These two activities produce the evidence for Clauses 9.2 and 9.3 — and they demonstrate to the certification auditor that the ISMS is being actively managed, not just documented.

Deliverables by end of Week 12:

• Internal audit report with findings
• Management review meeting minutes with decisions
• Corrective action plan for any nonconformities identified
• Updated risk register reflecting any new risks identified during audit

After the 90 Days: Maintaining Certification

Certification is not the end — it is the beginning of continuous operation. The surveillance audit (12 months after initial certification) will check that the ISMS is still running: policies have been reviewed, risk assessments updated, incidents managed, access reviewed, vulnerabilities scanned, and management reviews conducted.

Build a rolling calendar of ISMS activities: monthly (security metrics review, incident log review), quarterly (access reviews, vulnerability scanning, policy spot-checks), annually (full risk reassessment, internal audit, management review, policy review cycle).

The Documentation Stack

A complete ISMS requires approximately 60-100 documents depending on your scope and the number of applicable controls. Building this from scratch — with the specificity that auditors require — takes 200-400 hours of skilled labor.

The Information Security Policy Suite provides the complete set: 100 documents covering all mandatory clauses and Annex A domains, a compliance assessment tool for all 93 controls, policy acknowledgment tracking, evidence management, and board reporting — structured specifically for ISO 27001:2022 certification.