The certificate is the result—not the operating system
A customer asks whether the company is ISO 27001 certified. The sales team needs an answer. Leadership chooses a deadline. Someone buys templates, opens a compliance platform and begins assigning policies across the company.
The project appears to be moving. But the central question remains unanswered: does the company have a functioning information security management system?
ISO/IEC 27001 defines requirements for establishing, implementing, maintaining and continually improving an information security management system, or ISMS. Certification provides independent assurance that the management system conforms to those requirements within a defined scope. It is not a one-time checklist and it is not a claim that no security incident can occur.
The work is to build a system that repeatedly identifies risk, makes treatment decisions, operates controls, evaluates performance and improves. The certification audit tests whether that system is real.
What this looks like inside a growing company
The need often arrives through a commercial trigger:
- A strategic customer makes ISO 27001 a procurement requirement.
- The company is expanding into a market where the standard is widely expected.
- A partner wants independent assurance covering the service and its operations.
- Leadership wants one security-management system across multiple teams or jurisdictions.
- Due diligence exposes inconsistent policies, controls or risk decisions.
Growing companies rarely begin from zero. They may already use single sign-on, access reviews, backups, secure development practices, vendor reviews and incident processes. The problem is that these activities developed independently. Scope is unclear. Ownership is informal. Evidence is inconsistent. Risks and controls are not connected. Leadership cannot see whether the overall system works.
Certification readiness turns those separate activities into one governed system.
The common misdiagnosis: “We need the documents”
Documents matter. ISO 27001 requires defined information and evidence. But policies copied from templates do not establish that controls operate or that leadership manages the program.
A paper program usually has familiar symptoms:
- Policies describe practices the team does not follow.
- Control owners do not know they own controls.
- The risk register was created for the audit and is not used for decisions.
- The Statement of Applicability has no clear connection to the risk treatment plan.
- Evidence is collected retrospectively and cannot show consistent operation.
- Internal audit is treated as a proofreading exercise.
- Management review is a meeting held only to satisfy a requirement.
The better question is not “Which documents do we need?” It is “What management system must operate, and what evidence will demonstrate that it does?”
The blind spots experienced operators recognize
Scope silently expands
The ISMS scope determines what the company is asking the certification body to examine. If it is vague, systems, locations, teams and third parties can enter the project without a conscious decision. If it is artificially narrow, the scope may not satisfy the customer requirement or may exclude dependencies that cannot credibly be separated.
Certification and implementation ownership are confused
The company builds and operates the ISMS. An independent certification body audits it. A GRC platform can organize work, and outside specialists can advise, but neither replaces the internal owner accountable for decisions and execution.
Annex A becomes a universal checklist
Controls must follow the company’s risk-assessment and risk-treatment process. The organization should determine which controls are necessary, compare them with Annex A and explain inclusion or exclusion in its Statement of Applicability. Selecting every possible control without context can create work the company cannot sustain.
Business processes are left outside security
An ISMS reaches beyond technical safeguards. People processes, supplier relationships, legal commitments, physical environments, incident response, continuity, change and leadership oversight may all affect information security. Engineering cannot complete the program alone.
The audit date drives unsafe shortcuts
A deadline can create momentum, but it cannot manufacture operating history or repair major gaps overnight. If the company commits externally before understanding scope and readiness, the team may overpromise, implement temporary controls or enter the audit with evidence it cannot defend.
A practical ISO 27001 readiness framework
1. Confirm the business requirement
Identify who is asking for certification, why it matters and what they expect the scope to cover. Confirm whether certification is actually required or whether another form of assurance would satisfy the near-term need.
Clarify:
- The target customers, markets or contracts
- The expected certification timeline
- The services, legal entities and locations involved
- Dependencies on cloud providers, vendors and shared corporate systems
- Budget, internal capacity and executive sponsorship
This prevents the program from becoming a detached compliance project.
2. Define the ISMS scope and context
Describe the organizational boundaries and applicability of the management system. Document the relevant internal and external issues, interested parties and their requirements. Map the products, processes, information, people, technology and third parties that support the scoped service.
The scope should be commercially useful, technically defensible and operationally manageable.
3. Establish governance and decision rights
Name an accountable program owner and executive sponsor. Define who owns individual controls, who accepts risk, who approves exceptions and which issues reach leadership.
Set a working cadence for:
- Program decisions
- Risk review
- Remediation tracking
- Control-owner follow-up
- Metrics and leadership reporting
- Audit preparation
Without this layer, the ISMS becomes a set of tasks with no durable owner.
4. Build the risk-assessment and treatment process
Create a repeatable method for identifying information-security risks, assessing their likelihood and impact, assigning owners and choosing treatment. The method must fit the company; it should be consistent enough to produce comparable decisions without becoming too elaborate to use.
The risk treatment plan should show what the company will do, who owns it and when it will happen. The Statement of Applicability should explain which controls apply and why.
5. Run a real gap assessment
Compare the current operating state with the requirements of ISO/IEC 27001 and the controls the organization has determined are necessary. Examine implementation and evidence—not only whether a policy exists.
For each gap, record:
- The requirement or control involved
- The current state
- The risk created by the gap
- The remediation action
- The accountable owner
- The target date
- The evidence that will show completion
Prioritize foundational gaps and high business risk before cosmetic documentation work.
6. Implement controls inside existing workflows
Good controls become part of how work happens. Joiner, mover and leaver controls belong in people and IT workflows. Supplier review belongs in procurement. Secure development controls belong in the engineering lifecycle. Incident management belongs in operating procedures and exercises.
Avoid building a parallel “audit version” of the company. A control that exists only for evidence week is not sustainable.
7. Make documentation describe reality
Write policies and procedures after understanding the current and intended process. Keep them specific enough to direct behavior, but proportionate to the company’s size and risk.
At minimum, the document system needs clear ownership, approval, version control, review and accessibility. Employees should be able to find the rules that affect their work.
8. Build evidence as the system operates
Evidence should emerge from normal operation: access-review records, tickets, approvals, training completion, risk decisions, incident exercises, supplier reviews, logs and leadership minutes.
Create an evidence map connecting each requirement or control to:
- The owner
- The operating frequency
- The source system
- The expected artifact
- The review or approval step
This makes readiness visible before the auditor requests a sample.
9. Test the management system
Internal audit should objectively test whether the ISMS conforms to the organization’s requirements and the standard, and whether it is effectively implemented and maintained. Management review should give leadership a structured view of performance, changes, risks, audit results, objectives and improvement needs.
Treat findings as useful information. Correct them, investigate root causes where appropriate and retain evidence of the response.
10. Select and coordinate the certification body
ISO develops the standard but does not certify organizations. Certification is performed by an external certification body. Evaluate the body’s competence, accreditation, industry familiarity, geographic coverage, schedule and commercial terms.
Coordinate the audit only when scope, system operation, internal audit, management review and major remediation are sufficiently mature. The operator preparing the company should not imply that they can issue the certificate.
What needs to be built or changed
A certification-readiness mandate commonly produces:
- A confirmed business requirement and target scope
- ISMS context and interested-party requirements
- Governance, roles and decision rights
- An information-security risk methodology and current risk register
- A risk treatment plan
- A Statement of Applicability
- A mapped control environment with accountable owners
- Policies and procedures that match actual practice
- Security objectives, measures and reporting
- A structured evidence repository
- Internal-audit results and corrective actions
- Management-review records
- A certification-body selection and audit plan
- A post-certification cadence for surveillance and continual improvement
The exact artifact set depends on scope, business model and existing maturity. The deliverable is not the folder. It is the management system those artifacts represent.
Which operator should own it?
GRC Lead
A GRC Lead is often the best fit when the primary mandate is framework implementation, control design, evidence, audit coordination and cross-functional readiness. They should be able to translate requirements into practical work rather than operate as a document administrator.
Security Program Lead
A Security Program Lead fits when significant remediation and implementation must move across engineering, IT, people operations, procurement and leadership. They bring program structure and execution discipline to a complex readiness effort.
Fractional CISO
A fractional CISO may be needed when the company lacks senior security direction, has material risk decisions to make or needs executive credibility with customers, auditors and the board. The vCISO can own the security strategy and risk position while a GRC or program lead drives detailed readiness.
The right configuration depends on what is actually missing: assurance ownership, technical remediation, executive risk leadership—or all three.
What fractional ownership looks like
ISO 27001 readiness is well suited to fractional ownership when the deadline is consequential, the work crosses functions and the company does not yet need a permanent security executive.
The operator should enter with a defined outcome and enough authority to coordinate the people who operate controls. They assess the current state, build the workback plan, lead remediation, prepare internal governance and coordinate with the external certification body. Company employees still own the processes that must continue after the engagement.
Fractional does not mean advisory-only. The operator should make the program move.
Expected milestones and measures
First 30 days: define and diagnose
- Business requirement and scope are confirmed.
- Governance and owners are established.
- The existing environment and dependencies are mapped.
- The readiness assessment identifies prioritized gaps.
- The certification plan reflects real capacity and risk.
Days 31–60: implement and operationalize
- Risk assessment and treatment are active.
- High-priority controls and remediation are moving.
- Policies reflect real processes.
- Evidence collection is integrated into workflows.
- Leadership receives a clear program view.
Days 61–90: test and prepare
- Control operation is sampled.
- Internal audit and management review are completed or scheduled on a credible basis.
- Findings have owners and corrective actions.
- Certification-body coordination is active.
- The team understands what must continue after certification.
Measures should include remediation status, overdue control activities, evidence completeness, internal-audit findings, corrective-action closure, security objectives and unresolved risks. Passing the audit matters. Sustaining the ISMS matters more.
Related questions
Is ISO 27001 certification mandatory?
Not generally for every organization. It may become a contractual, market or sector expectation. Confirm the buyer or regulatory requirement before committing to the program.
Can a compliance platform make us ISO 27001 certified?
No. Software can organize controls, tasks and evidence. The company must implement and operate the ISMS, and an independent certification body conducts the certification audit.
Is ISO 27002 certifiable?
No. ISO/IEC 27002 provides information-security control guidance. Organizations are certified against ISO/IEC 27001 requirements.
Do we need a full-time CISO?
Not necessarily. A growing company may use a GRC Lead, Security Program Lead or fractional CISO depending on the risk, scope and leadership gap. The mandate should determine the role.
Does certification mean the company is completely secure?
No. Certification provides assurance about the scoped management system’s conformity to the standard. Security risk still requires ongoing management and continual improvement.
Example mandate: prepare for ISO 27001 certification
Outcome: Establish a functioning ISMS, close material readiness gaps and prepare the scoped organization for an independent ISO 27001 certification audit.
Initial work: Confirm the business requirement and scope; assess context, risks, controls, documentation, evidence and ownership; then define the readiness workback plan.
Execution: Build governance, lead risk assessment and treatment, coordinate control implementation, align policies with practice, organize evidence, oversee internal audit and management review, resolve findings and coordinate certification-body readiness.
Success measures: Scope is approved; the ISMS operates with clear ownership; material gaps have been remediated or formally treated; evidence is current and defensible; internal audit and management review are complete; and the company enters the certification process with a credible, sustainable system.
Certification should leave the company more capable
The strongest ISO 27001 programs do more than satisfy procurement. They give leadership a clearer view of risk, make responsibilities explicit, improve how controls operate and create evidence the company can trust.
That is the real value of the mandate: a security-management system that supports the business before, during and after the audit.