The implementation lesson behind the certificate
ISO 27001 projects often begin with a spreadsheet of clauses and controls. That is useful, but it can create checklist theatre: documents are produced because an auditor might ask for them, while the organisation never establishes a repeatable way to identify, treat and monitor information-security risk.
In a Help Net Security interview, ISO 27001 practitioner Robin Long reduces the standard to two practical questions: what information-security risks does the organisation face, and how should it manage them? That framing matters because certification is not the finish line. A functioning Information Security Management System (ISMS) must keep answering those questions as technology, suppliers, people and threats change.
1. Put the audit date on the roadmap early
Long recommends building a detailed implementation plan and engaging a certification body early. A tentative audit date creates a real deadline, exposes dependencies and gives leadership a clearer cost picture.
For most organisations, the plan should show more than policy-writing dates. It should include:
- ISMS scope and interested-party decisions
- Asset, process and supplier discovery
- Risk assessment and treatment workshops
- Statement of Applicability approval
- Control implementation and evidence collection
- Awareness and role-based training
- Internal audit and management review
- Corrective actions before Stage 1 and Stage 2
The key improvement is to assign an owner and evidence outcome to every workstream. “Implement access reviews” is vague. “System owners review privileged access quarterly; signed review exports are retained for 12 months” can be tested.
2. Build a cross-functional ISMS team
Information security cannot be delegated entirely to IT. Long recommends a small team with access to senior management and representation from functions such as technology, business operations and data protection.
That structure prevents predictable gaps. HR understands joiner, mover and leaver evidence. Procurement understands supplier onboarding. Product teams know where customer data flows. Legal interprets contractual requirements. The security team connects those activities to risk and controls.
| Role | Decision it should own | Evidence to retain |
|---|---|---|
| Executive sponsor | Risk appetite, priorities and resources | Approved objectives and management review minutes |
| ISMS lead | Roadmap, scope and control coordination | Programme plan, issue log and status reports |
| Risk owner | Accept, avoid, transfer or treat risk | Risk-treatment approval and residual-risk acceptance |
| Control owner | Operate and improve the control | Logs, reviews, tickets and exceptions |
| Internal auditor | Independently test the system | Audit programme, samples, findings and follow-up |
3. Make the Statement of Applicability explain your choices
Long correctly highlights that organisations do not need to claim every Annex A control is applicable. Applicability should follow the risk assessment, legal and contractual requirements, and the organisation’s operating context.
A defensible Statement of Applicability should record whether each control applies, why it applies or does not, how it is implemented and who owns it. “Not relevant” is rarely enough. A remote-first company may still depend on home-working safeguards, cloud physical-security assurance and device handling even when it has no corporate office.
4. Translate controls into your actual environment
Generic policies create weak evidence. The control language must be translated into the organisation’s cloud services, SaaS platforms, remote-working patterns and software-delivery practices.
For example, access control is not complete because a policy says access is reviewed. The organisation needs defined populations, reviewers, frequency, evidence of completion, exception handling and proof that removals occurred. The same principle applies to backups, vulnerability management, supplier assurance and incident exercises.
5. Prepare evidence as the process operates
Do not wait for the internal audit to start collecting screenshots. Evidence should be a natural output of the process. Tickets should show approvals. Review records should identify the population and reviewer. Exceptions should have owners and target dates.
Use three tests before accepting an evidence item:
- Relevance: Does it prove the stated control operated?
- Reliability: Is it system-generated or independently verifiable?
- Coverage: Does the sample represent the full review period and population?
A practical 90-day reset
Days 1–30: decide
- Confirm scope, interested parties and the certification objective.
- Form the ISMS team and assign risk and control owners.
- Complete a current-state risk assessment and draft the Statement of Applicability.
Days 31–60: operate
- Prioritise controls that need an operating history.
- Define evidence standards and retention locations.
- Train owners on what good evidence looks like.
Days 61–90: challenge
- Run an independent internal audit using representative samples.
- Hold management review with decisions, not status slides alone.
- Close systemic causes before polishing documents.
ICyberWave perspective
The practical lesson from Long’s guidance is that a good implementation is managed as a risk programme, not a documentation project. ICyberWave supports scope definition, risk assessment, control implementation, internal audit and certification readiness. Use our ISO 27001 audit checklist to test your evidence, or talk to us about an implementation roadmap.