ISO/IEC 27001 certifies an information security management system, or ISMS, not a product. A VP of engineering shapes three things: the scope statement, the technical risk treatment, and the evidence that controls operate. A certification body audits the system, and the certificate names the scope it covers.
What is being certified?
A management system: defined scope, leadership commitment, risk assessment, a statement of which controls apply, operation of those controls, internal audit and management review, repeated over time. The text of the standard is sold by ISO, so this post does not quote it. Confirm clause and control detail from the purchased standard or your certification body.
What matters for planning is that the certificate is tied to a stated scope. A customer reading it should check what the scope includes. If your product is outside it, the certificate says little about that product.
What does the VP decide?
Scope. Which products, locations and teams. Narrow scopes cost less and cover less. A scope that excludes the production platform your customers use may not satisfy them. Ask what customers actually need before drawing it.
Risk treatment. The ISMS rests on a risk assessment, and technical risks are yours to judge: supply chain, secrets, access, availability, change. For each, decide to reduce, accept, transfer or avoid, and record who accepted what.
Applicability. You choose which controls apply and justify exclusions. Auditors test the reasoning, so do not exclude controls because they are inconvenient.
Evidence. Controls must operate over time. Pull requests, access reviews, backup tests and incident records are the evidence, and they should come from systems you already use.
Where do engineers get surprised?
Three places. Internal audit must be independent of the work it examines, which surprises teams who assume the security lead can audit their own controls. Management review means leadership, including you, must be recorded as reviewing the ISMS. And nonconformities need corrective action with a record, not a quiet fix.
A constructed example
A company's scope statement covers its SaaS platform and the team that runs it. During the audit, the auditor asks about the build system, which sits in a separate cloud account run by a platform group not named in the scope. The company has two choices: bring the build system and its team into scope with evidence, or argue it does not affect the service. The first is honest and straightforward, because a compromised build system obviously affects the service.
What to do
- List what customers expect the certificate to cover, and draw scope from that.
- Include every system that can affect the in-scope service, such as build, identity and cloud accounts.
- Own the technical risk register entries, with treatments and accepted risks signed by a named person.
- Draft the statement of applicability and the reasons for every exclusion.
- Pull evidence from existing tools: version control, ticketing, access systems, backup logs.
- Arrange an internal audit by someone independent of the work.
- Put management review on the calendar and record it.
- Pick an accredited certification body and ask what scope wording will appear on the certificate.
Safeguard offers compliance automation and dependency evidence that can feed technical controls. The certificate comes only from a certification body.
Quick check
Does an ISO 27001 certificate cover the whole company?
Only what the stated scope covers. Read the scope wording on any certificate.
Can the security lead audit their own controls?
Internal audit should be independent of the activity audited, so use someone else.
Sources
Last reviewed: 18 October 2026.
