ISO 27001

ISMS Implementation

The deliverable is not a folder of ISO documents. It is a management system in which owners know what they must do, management knows what decisions are pending, and evidence exists to demonstrate that controls operate. Documents are the residue of that, not the objective — and an ISMS built the other way round passes its first audit and decays before the second.

Methodology

01
Discover
Business interviews, ISMS scope, interested parties, locations, processes, information assets and existing governance. Primary output: scope baseline + stakeholder map.
02
Assess
Gap assessment, risk context, current controls, evidence review and maturity observations. Primary output: gap register + risk inputs.
03
Design
ISMS architecture, governance, risk methodology, control applicability and documentation plan. Primary output: isms blueprint + soa approach.
04
Build
Draft and tailor policies, procedures, registers, records and control implementation artefacts with owners. Primary output: controlled isms document set.
05
Operate
Run selected processes: risk treatment, access reviews, incidents, supplier reviews, awareness and control evidence. Primary output: operational records + evidence.
06
Assure
Internal audit, management review, CAPA and certification-readiness assessment. Primary output: audit report + capa + readiness view.
07
Improve
Close actions, refresh risk, improve controls and establish annual maintenance cadence. Primary output: continual improvement plan.

Approach to testing

Controls are owned by the business, not by the ISMS. A control whose owner is 'the security team' for a process the security team does not run will not operate, and the auditor will find that.
The sequence compresses or expands with organisational size, existing controls, the certification deadline and — most often the binding constraint — the availability of process owners.
Documents are tailored, not templated. A generic policy set is recognisable to any auditor and signals that the management system was bought rather than built.
Every applicable control must answer five questions: why does it matter, who owns it, what happens, what evidence exists, and how do we know it works. A control that cannot answer all five is not implemented.
Evidence is designed at the same time as the control. Retrofitting evidence before an audit is the single most common cause of a late, expensive certification push.

Types of assessment

Greenfield implementation (default)

No existing ISMS. The full lifecycle from Discover through to certification readiness.

Remediation implementation

An ISMS exists but does not work — documents without operation, or a failed audit. Entry at Assess or Design.

Scope extension

An existing certified ISMS extended to new entities, locations or services.

Accelerated implementation

A compressed sequence against a fixed customer or contractual deadline, with the trade-offs stated explicitly rather than discovered later.

Frameworks and standards

ISO/IEC 27001:2022: The requirements standard the ISMS is built to satisfy.
ISO/IEC 27002:2022: Control implementation guidance, organised as organisational, people, physical and technological controls.
ISO/IEC 27005: Risk management guidance underpinning the risk methodology.
CSS GRC lifecycle: Discover, Assess, Design, Build, Operate, Assure, Improve.
CSS ISO 27001 toolkit: CSS maintains a toolkit across governance, risk and assurance; only the components relevant to the engagement are deployed.

Tools used

Tooling is where testing starts, not where it ends. Every automated result is reproduced by hand before it reaches a report.

CSS ISO 27001 toolkit

Governance, risk and assurance components tailored to scope rather than deployed as a document dump.

PlyoGRC workspace

Where engaged: policies, risks, controls, actions and evidence held as controlled records with requirement → risk → control → evidence → finding → action traceability.

Risk assessment methodology

Defined with the client so it is repeatable by their own people after CSS leaves.

Evidence map

Associating records with the controls they demonstrate, built during implementation rather than before the audit.

Action and CAPA tracker

So findings and decisions do not disappear into email threads.

Checklist approach

The checklist is the floor, not the ceiling. It guarantees coverage so nothing standard is missed; the findings that matter usually come from what a tester does after it is complete.

Foundation

ISMS scope and boundaries
Information security policy
Objectives and governance structure
Roles and responsibilities, assigned to named people
Interested-party and context records
Governance charter and meeting records

Risk

Risk assessment methodology, documented and repeatable
Asset and information inventory
Risk register with owners
Risk treatment plan
Statement of Applicability with justification
Residual risk acceptance records

Operational controls

Access control
Acceptable use
Incident management
Supplier security
Business continuity and DR alignment
Change, asset and vulnerability governance as applicable

Assurance

Internal audit procedure and programme
Audit report and findings
Nonconformity and CAPA tracker
Management review agenda and minutes
KPI/KRI dashboard

Certification readiness

Evidence index
Control-to-evidence mapping
Interview preparation for process owners
Open-item tracker
Pre-assessment checklist and closure plan

Free toolkit

ISO 27001 Toolkit

A complete ISO/IEC 27001:2022 documentation set, arranged the way the standard is: clauses 4 to 10 for the management system, then the four Annex A control families — organizational, people, physical and technological. Includes the implementation resources, policies, procedures and records an ISMS needs to reach certification.

310 documents · ZIP · 40.8 MB

Download the toolkit

Deliverables

Controlled ISMS document set: policies, procedures, registers and records
Risk assessment methodology, risk register and risk treatment plan
Statement of Applicability
Internal audit procedure and first audit programme
Management review pack and governance cadence
Evidence index and control-to-evidence map
Certification readiness pack and open-item tracker
Knowledge transfer so the client's own team can operate the system

Frequency

One-time: An implementation programme runs once. Typically three to nine months depending on scope, existing controls and process-owner availability.
Annual maintenance: After implementation, the system needs periodic risk review, internal audit and management review — delivered as Annual Maintenance rather than as repeat implementation.
On scope change: Triggered — a new entity, location, product or jurisdiction entering the ISMS scope.
Before recertification: A refresh ahead of the three-yearly cycle, particularly where the organisation has changed materially.

Resource deployment

Implementation needs significant on-site time. Control design happens in conversation with process owners across IT, HR, Legal, Privacy, Procurement, Facilities and Engineering, and a workshop in a room produces decisions that a sequence of calls does not. Operate and Assure stages also benefit from presence, because that is when people discover the control is harder than the design assumed. A typical programme places a consultant on site two to four days a month across the engagement, with drafting and review remote.

How CSS tests

A unified swarm of agents, for blind spot detection

AI agents drive several testing tracks against the same target at once, then cross-check each other. A single tester works one hypothesis at a time; parallel agents cover the space a sequential pass leaves behind.

Control-to-evidence mapping across 93 Annex A controls and a large record set is systematic association; gaps in it are what surface during a certification audit as 'can you show me'.
Consistency checking across a tailored document set finds the policy that still references the template's example scope, which auditors notice immediately.
Dependency analysis across the implementation plan keeps the critical path honest as dates move.
Cross-referencing the Statement of Applicability against the risk register and the treatment plan catches controls marked applicable with no corresponding risk, and risks with no treating control.

Agents check consistency and completeness. Every control design decision, every applicability judgement and every risk treatment is made with the client's own owners, because a management system nobody in the business decided anything about is one nobody will operate.

Why this differs

What CSS does that most vendors do not

Every one of these is checkable. Ask any vendor for the same and compare the answers.

A working system, not a document set

CSS's own stated position. The measure of success is that owners know what they must do and evidence exists — not that a folder is complete.

Business owns the controls

Ownership is assigned to the people who run the process. A security team nominally owning HR screening is a control that will fail at audit and, more importantly, in practice.

Evidence designed in

Evidence is built at the same time as the control rather than assembled in the weeks before an audit, which is where most certification programmes lose their margin.

It outlasts the certificate

A governance cadence, an audit programme and an improvement plan are part of the delivery, so the system still operates at surveillance and recertification.

What you receive

A working management system, not a folder of documents

The target state is that owners know what they must do, management knows what decisions are pending, and evidence exists to demonstrate that controls operate. Outputs are grouped by who uses them.

Executive layer

Scope, risk posture, roadmap, management decisions, KPI/KRI, readiness summary

GRC layer

Risk register, Statement of Applicability, policies, procedures, ownership, evidence map, action tracker

Assurance layer

Internal audit, findings, CAPA, management review, certification-readiness assessment

Operational layer

Control records, recurring reviews, awareness, supplier / access / incident / continuity evidence as applicable

Governance cadence established

Monthly: Risk / action review, evidence status, control exceptions, material incidents
Quarterly: Risk trend, supplier / control reviews, KPI/KRI, management action tracking
Annual: Internal audit programme, management review, ISMS objectives, risk refresh, improvement plan

For this engagement specifically

Controlled ISMS document set, tailored to the agreed scope
Statement of Applicability with per-control justification
Risk register, methodology and treatment plan
Control-to-evidence mapping
Certification readiness position and remaining open items
Decisions requiring management sign-off, with their risk implications

Case studies

What this finds in practice

Representative engagement patterns. Sector and scale only — no client is named, and no detail is included that could identify one.

Large BFSI organisation — published in CyberSmithSECURE's own capability statement as a representative case.

Finding: A compliance mandate for ISO 27001, third parties entrusted with financial information, intellectual property and employee data, and a requirement to align security with business strategy.
Recommendation: Information gathering through OSINT, network mapping, vulnerability identification and prioritisation, with ethical-hacking-led assurance forming part of the broader security programme.
Outcome: ISO 27001 compliance achieved with stronger alignment between security practice and business strategy. CSS's stated lesson: certification is most valuable when risk, control implementation and business objectives reinforce one another.

A SaaS business of around 180 staff, certifying to unblock enterprise sales.

Finding: The initial scope proposed covered the whole company. Assessment showed the enterprise customers driving the requirement only cared about the production platform and the people who touch it — roughly a third of the organisation.
Recommendation: Narrow the scope to the platform and its supporting functions, with clearly documented boundaries and interfaces, and extend later if customers ask.
Outcome: Certification achieved in five months rather than the projected eleven. Representative pattern; details illustrative and not attributable to a named client.

A manufacturer that had failed a certification audit under a previous provider.

Finding: A complete, well-written document set with almost no operating evidence. The risk register had not been reviewed since creation, no internal audit had been run, and management review existed as a single undated slide.
Recommendation: Stop producing documents. Run the processes for one full quarter — risk review, access review, incident handling, supplier review — and let the evidence accumulate naturally before rebooking the audit.
Outcome: Certified at the second attempt. The organisation's own conclusion was that the first programme had optimised for the wrong deliverable. Representative pattern; details illustrative.

Scope this assessment

Most scopes are settled in one call. Tell us what the application does and who uses it, and we will tell you what testing it properly involves.

Start a conversation All ISO 27001 capabilities