Implementing ISO 27001 is often described as a documentation project: define your scope, perform a risk assessment, write some policies, complete an internal audit, and prepare for certification.

That’s technically recognizable. It is also where many implementations go wrong.

ISO 27001 is fundamentally about building an Information Security Management System (ISMS) that can repeatedly identify information security risks, make defensible treatment decisions, operate appropriate controls, evaluate whether those controls and the management system are working, and improve when they’re not.

The documents matter. But the documents are evidence and mechanisms of the management system, not the management system itself.

This guide walks through ISO/IEC 27001:2022 implementation from that perspective.

If you’re responsible for implementing ISO 27001, the practical sequence looks like this:

1. Establish the business case and implementation ownership.
2. Understand the organization’s context and relevant requirements.
3. Define the scope of the ISMS.
4. Establish the information security risk methodology.
5. Perform the risk assessment.
6. Develop the risk treatment plan.
7. Determine necessary controls and compare them with Annex A.
8. Build the Statement of Applicability.
9. Document and implement the ISMS.
10. Operate the controls and collect evidence.
11. Monitor and measure ISMS performance.
12. Conduct the internal audit.
13. Complete management review.
14. Address nonconformities and corrective actions.
15. Prepare for certification.
16. Maintain and continually improve the ISMS.

That looks linear on a page. Real implementations aren’t.

You will discover scope problems while assessing risk. Control implementation may expose unclear ownership. Internal audit may identify processes that exist on paper but aren’t consistently operating. Management review may change priorities.

That’s normal.

A functioning ISMS is a feedback system, not a stack of completed templates.

What Is ISO 27001?

ISO/IEC 27001 is the international standard that specifies requirements for establishing, implementing, maintaining, and continually improving an information security management system.

The current standard is ISO/IEC 27001:2022, published in October 2022. ISO subsequently published Amendment 1:2024 Climate action changes, which applies to the 2022 standard.

An ISMS provides the organizational structure for managing information security risk.

That includes more than cybersecurity technology. Depending on the organization and its risks, an ISMS may encompass:

• Governance
• Risk management
• Policies and procedures
• People
• Suppliers
• Physical security
• Access management
• Cloud services
• Asset management
• Incident management
• Business continuity
• Secure development
• Monitoring
• Internal audit
• Management oversight
• Corrective action
• Continual improvement

ISO 27001 is therefore better understood as a management-system standard than as a security-control checklist.

That distinction becomes important when you reach Annex A.

How ISO 27001 Is Structured

The certifiable requirements of the management system are contained primarily in Clauses 4 through 10.

Clause	Focus	Practical question
4 – Context	Organization, interested parties and ISMS scope	What are we protecting, for whom, and within what boundaries?
5 – Leadership	Commitment, policy, roles and responsibilities	Who is accountable for this system?
6 – Planning	Risks, opportunities, security objectives and risk treatment	What could go wrong, and what are we going to do about it?
7 – Support	Resources, competence, awareness, communication and documentation	What does the ISMS need in order to function?
8 – Operation	Operational risk assessment and treatment	Are we actually executing what we planned?
9 – Performance Evaluation	Monitoring, measurement, internal audit and management review	Is the ISMS working?
10 – Improvement	Nonconformity, corrective action and continual improvement	What needs to change?

ISO guidance makes an important distinction: the requirements in Clauses 4–10 apply to the ISMS, while Annex A is used differently as part of the risk-treatment process.

This gives us a useful implementation principle:

Don’t start by implementing Annex A. Start by building the management system that determines what controls you need.

Phase 1: Establish the ISMS

Step 1: Understand Why the Organization Is Pursuing ISO 27001

Before creating a risk register or writing a policy, establish the business reason for the project.

Common drivers include:

• A major customer requires certification.
• Prospective customers are asking for ISO 27001.
• Certification is needed to enter a market.
• The organization wants to formalize an existing security program.
• Contractual requirements are increasing.
• Leadership wants stronger information security governance.
• Multiple disconnected security activities need to become one managed program.

The reason matters because it influences scope, resources, priorities and timing.

Suppose a SaaS company needs certification because enterprise prospects require it for the cloud platform they purchase.

That’s different from an organization whose objective is to establish an enterprise-wide ISMS across several business units and countries.

Both may pursue ISO 27001.

They are not necessarily implementing the same ISMS.

Practitioner checkpoint

Before moving forward, you should be able to answer:

Why are we doing this?

What business outcome are we trying to achieve?

Who is accountable for achieving it?

If those answers aren’t clear, don’t compensate by producing more documentation.

Step 2: Establish Leadership and Ownership

An ISO 27001 implementation can be coordinated by one person.

It cannot realistically be operated by one person.

Information security responsibilities are typically distributed across functions such as:

• Information security
• IT
• Engineering
• Human resources
• Legal and privacy
• Procurement
• Facilities
• Business operations
• Risk and compliance
• Internal audit
• Executive management

Establish ownership early.

At minimum, clarify:

• Who sponsors the ISMS?
• Who coordinates implementation?
• Who owns information security risks?
• Who can accept risk?
• Who owns individual controls?
• Who operates those controls?
• Who approves policies?
• Who monitors performance?
• Who performs internal audits?
• Who owns corrective actions?
• Who participates in management review?

Your original implementation material included an ISMS RASCI Chart for exactly this purpose. That’s worth retaining in the GRCPod approach because unclear accountability tends to surface repeatedly later in the implementation.

The practical test

For every important ISMS activity, ask:

If this doesn’t happen, whose problem is it?

If the answer is “the ISO team,” responsibility probably isn’t mature enough yet.

Phase 2: Establish Context and Scope

Step 3: Understand the Organization’s Context

Clause 4 starts before scope.

The organization needs to understand the internal and external issues relevant to its purpose that can affect its ability to achieve the intended outcomes of the ISMS.

Think practically.

Relevant issues might include:

• Business strategy
• Organizational structure
• Technology architecture
• Remote or hybrid operations
• Outsourcing
• Cloud dependence
• Threat environment
• Regulatory environment
• Customer expectations
• Acquisition activity
• Rapid growth
• Resource constraints
• Reliance on critical suppliers

You are trying to understand the environment in which the ISMS has to succeed.

Don’t turn context into compliance theater

A context document containing generic statements such as “cyber threats are increasing” adds little value.

The useful question is:

What characteristics of this organization materially affect how we need to manage information security?

That’s what should inform the ISMS.

Step 4: Identify Relevant Interested Parties and Requirements

Interested parties may include:

• Customers
• Employees
• Regulators
• Suppliers
• Business partners
• Owners
• Insurers
• Contractual counterparties

But don’t create a ceremonial stakeholder inventory.

Determine which interested parties have requirements relevant to the ISMS and understand those requirements.

For example, a customer contract may impose security obligations beyond what your risk assessment alone would have produced.

That matters when determining controls.

Don’t overlook the 2024 amendment

ISO/IEC 27001:2022 was amended in February 2024 as part of ISO’s climate-action changes. The amendment added a requirement to Clause 4.1 to determine whether climate change is a relevant issue and added a note under Clause 4.2 that relevant interested parties can have climate-related requirements.

This does not mean every ISMS suddenly requires environmental controls.

It means the organization needs to consider whether climate change is relevant in its context rather than automatically ignoring it.

That is a small change, but a current ISO 27001 implementation should account for it.

Step 5: Define the Scope of the ISMS

Scope is one of the highest-leverage decisions in the entire project.

Make it unnecessarily broad and you’ve expanded the implementation and certification burden.

Make it artificially narrow and you may exclude dependencies necessary to operate or secure what you claim is in scope.

Consider:

• Products and services
• Business processes
• Legal entities
• Organizational functions
• Employees and contractors
• Physical locations
• Cloud environments
• Infrastructure
• Applications
• Information repositories
• Supporting corporate systems
• Outsourced functions
• Critical suppliers
• Interfaces with out-of-scope environments

Your original RiskComply material correctly emphasized business operations, locations, technology and information assets, suppliers, and regulatory considerations when determining scope.

But there is an important practitioner distinction:

A boundary doesn’t automatically eliminate a dependency.

Imagine a SaaS provider scopes its customer platform but excludes corporate IT.

That may sound reasonable.

Now suppose corporate identity services authenticate the engineers administering production.

Corporate IT is suddenly relevant to the security of the scoped service.

The correct response isn’t necessarily “put all corporate IT in scope.” It is to understand and appropriately address the dependency.

Scope test

Someone unfamiliar with your company should be able to read your scope and reasonably understand:

What is covered?

What is not?

What organizational and technical boundaries exist?

What significant dependencies cross those boundaries?

If they can’t, keep working.

Phase 3: Build the Risk Management System

Step 6: Establish the Risk Assessment Methodology

Don’t start filling out a risk register until you’ve decided how risk will be assessed.

Your methodology should establish a repeatable process for identifying, analyzing and evaluating information security risk.

That commonly means defining:

• Risk identification approach
• Likelihood criteria
• Impact criteria
• Risk evaluation criteria
• Risk levels
• Risk acceptance criteria
• Risk ownership
• Treatment options
• Approval authority
• Review frequency
• Reassessment triggers

The methodology does not need to be mathematically sophisticated.

It needs to be consistent enough to support decisions.

A five-level likelihood scale with clear criteria can be more useful than a complicated formula nobody can explain.

A better way to write risks

Weak:

Risk: Ransomware.

That identifies a threat, not a useful risk scenario.

Better:

Because externally accessible systems may contain exploitable vulnerabilities, a threat actor could compromise production infrastructure and deploy ransomware, resulting in service disruption, data loss, recovery costs and contractual impacts.

Now you can evaluate:

Cause → event → impact

and ask what controls actually modify that risk.

Step 7: Perform the Information Security Risk Assessment

Apply the methodology across the ISMS scope.

Look at the organization you actually have, not the risk library you found online.

Useful inputs include:

• Critical business processes
• Information
• Systems and applications
• Infrastructure
• People
• Suppliers
• Physical locations
• Previous incidents
• Vulnerability information
• Audit findings
• Contractual requirements
• Regulatory obligations
• Technology changes
• Business changes

A practical risk register might include:

Field	Why it matters
Risk ID	Traceability
Risk scenario	What could actually happen
Affected process/asset	What is exposed
Cause/threat	Why it could happen
Impact	Business consequence
Existing controls	What already modifies the risk
Likelihood	Probability/frequency assessment
Impact rating	Severity assessment
Risk rating	Prioritization
Owner	Decision accountability
Treatment decision	What will be done
Treatment actions	Specific remediation
Target date	Accountability
Residual risk	Exposure expected to remain
Status	Current position

Your exact fields should follow your methodology rather than somebody else’s spreadsheet.

Step 8: Treat the Risks

Once risks have been evaluated, determine what to do about them.

Treatment can involve:

• Modifying the risk through controls
• Avoiding the activity creating the risk
• Sharing aspects of the risk
• Retaining the risk through authorized acceptance

The important part is connecting the treatment to the actual risk.

Weak treatment:

Implement stronger security.

Better:

Require phishing-resistant MFA for privileged production access and migrate existing administrative accounts by June 30.

The second statement has an ownerable activity, scope and completion condition.

This is where the ISMS begins turning risk analysis into actual security decisions.

Phase 4: Determine and Implement Controls

Step 9: Determine Necessary Controls, Then Compare Them With Annex A

This is one of the most misunderstood parts of ISO 27001.

ISO’s own auditing guidance describes the process this way: determine the controls necessary to treat information security risks, then compare those controls against Annex A to verify that necessary controls haven’t been omitted.

That’s materially different from:

“Go through all 93 Annex A controls and choose the ones you like.”

Annex A is a reference set of controls.

The 2022 edition contains 93 controls organized into four themes:

Theme	Number of controls
Organizational	37
People	8
Physical	14
Technological	34
Total	93

ISO SC 27 confirms the 93 controls and four-group structure.

But your necessary controls don’t have to come exclusively from Annex A.

ISO guidance explicitly recognizes that organizations can determine their own controls or use controls from other sources. Annex A acts as a comparison point to help identify omissions.

A useful mental model

Think:

Risk and requirements → necessary controls → Annex A comparison

not:

Annex A → controls → invent a reason for them

That one distinction can improve the logic of your entire ISMS.

Step 10: Build the Statement of Applicability

The Statement of Applicability, or SoA, creates traceability around your control decisions.

ISO guidance says the SoA should contain the necessary controls, justification for their inclusion, implementation status, and justification for excluding Annex A reference controls.

A useful SoA might therefore include:

Control	Applicable/Necessary	Justification	Implementation Status	Related Risk/Requirement
Example control	Yes	Addresses privileged-access risk	Implemented	R-014
Example control	No	Control type not necessary within scoped environment	N/A	N/A

The standard doesn’t prescribe one mandatory SoA layout. ISO SC 27 specifically notes that organizations can structure it in different ways.

Don’t write meaningless justifications

Weak:

Applicable because ISO requires it.

That doesn’t explain your decision.

Better:

Necessary to reduce the risk of unauthorized administrative access to production infrastructure.

Now the control has a reason to exist.

Step 11: Design Controls That Can Actually Be Operated

A control is not effective merely because it appears in a policy.

A well-designed control should make clear:

• Objective
• Scope
• Owner
• Activity
• Frequency or trigger
• Expected result
• Exception handling
• Evidence

Consider privileged-access reviews.

Weak control:

Privileged access will be reviewed regularly.

Questions immediately appear.

By whom?

For which systems?

How often?

Against what criteria?

What happens when inappropriate access is found?

What record proves the review occurred?

A stronger design might establish that the system owner reviews the complete privileged-account population quarterly, validates continued business need, documents exceptions, removes inappropriate access within a defined period, and retains the review record.

Now the control can be operated.

And tested.

Phase 5: Document and Operate the ISMS

Step 12: Create the Documentation You Actually Need

Your original toolkit material contains a substantial documentation library: ISMS scope, information security policy, risk methodology, risk register, Statement of Applicability, operational policies, audit records, corrective-action tracking, awareness records and implementation resources.

Those resources can save considerable blank-page work.

But don’t make the mistake of assuming:

More documents = more compliant.

Some documented information is explicitly required. Additional policies, procedures and records will be necessary based on your organization, controls, risks and operational needs.

Common ISMS documentation includes:

• ISMS scope
• Information security policy
• Risk assessment methodology
• Risk assessment results
• Risk treatment plan
• Statement of Applicability
• Information security objectives
• Evidence of competence where appropriate
• Monitoring and measurement results
• Internal audit program/results
• Management review records
• Nonconformity and corrective-action records

You will likely need additional operational documentation to support your controls.

The correct documentation set is the one that helps you define, operate, demonstrate and improve your ISMS.

Step 13: Customize Templates Before Approving Them

Templates are useful because they eliminate blank-page work.

They are dangerous when organizations approve them without understanding what they promise.

Your original toolkit was designed around customizable policy and procedure templates. That remains valuable—but customization isn’t cosmetic.

For every requirement in a template, ask:

Does this apply to us?

Is this how we actually operate?

Does the named owner exist?

Can we meet this frequency?

Do the referenced systems match our environment?

How would we prove this occurred?

That last question is particularly powerful.

Suppose a policy says:

Privileged access is reviewed quarterly.

If an auditor asks you to demonstrate the last three quarterly reviews, what will you provide?

If the answer is “the policy,” you have confused control design with operating evidence.

A policy can establish an expectation.

It doesn’t prove the activity occurred.

Step 14: Put the ISMS Into Operation

Eventually, the implementation project has to stop producing documents and start producing evidence.

Controls need to operate.

Examples might include:

• Access reviews
• Supplier assessments
• Risk reviews
• Security training
• Vulnerability remediation
• Backup testing
• Incident exercises
• Policy reviews
• Change approvals
• Security monitoring
• Business continuity testing

This creates an important distinction:

Design: Is the control reasonably capable of achieving its objective?

Implementation: Has the control actually been put in place?

Operation: Did it function as intended during the relevant period?

A screenshot of today’s administrator list might help demonstrate current configuration.

It does not, by itself, demonstrate that quarterly privileged-access reviews occurred throughout the year.

Evidence should support the assertion you’re making.

That mindset will help considerably when internal and certification audits begin.

Phase 6: Evaluate the ISMS

Step 15: Monitor and Measure Performance

An ISMS should give management meaningful information about whether it is working.

Potential measures include:

• Information security objective performance
• Open risk treatments
• Security incidents
• Vulnerability remediation
• Access-review completion
• Security awareness completion
• Supplier review status
• Internal audit findings
• Corrective-action aging
• Recovery testing
• Policy-review status

Don’t measure something simply because your security platform can graph it.

Ask:

What information would help us determine whether the ISMS and its controls are achieving the intended outcomes?

The answer should drive measurement.

Step 16: Conduct the Internal Audit

Internal audit is one of your best opportunities to find weaknesses before the certification body does.

Don’t waste it by turning it into a checkbox exercise.

A useful internal audit evaluates whether the ISMS conforms to applicable requirements and whether it is effectively implemented and maintained.

That means looking beyond documentation.

Instead of asking only:

Do we have an access control policy?

ask:

What control is actually operating?

Who owns it?

What population does it cover?

What evidence demonstrates performance?

Were exceptions identified?

What happened to them?

Internal audit should surface uncertainty.

That’s a feature, not a failure.

Your original Toolkit includes internal-audit planning/reporting and readiness resources intended to support this stage.

Step 17: Complete Management Review

Management review is not supposed to be a meeting held because Clause 9 says you need one.

It is where leadership evaluates the management system.

The review should provide management with enough information to make meaningful decisions about the continuing suitability, adequacy and effectiveness of the ISMS.

That includes relevant information about areas such as:

• Previous actions
• Changes affecting the ISMS
• Performance
• Security objectives
• Monitoring and measurement
• Audit results
• Nonconformities
• Corrective actions
• Interested-party feedback
• Risk assessment and treatment
• Opportunities for improvement

The output should capture decisions.

If leadership decides that a risk requires more resources, record it.

If an objective needs to change, record it.

If the organization accepts an exposure, use the appropriate risk-governance process.

The purpose isn’t to prove a meeting occurred.

It’s to demonstrate management of the system.

Phase 7: Improve and Prepare for Certification

Step 18: Address Nonconformities and Corrective Actions

By now, you should have found problems.

That’s healthy.

Typical implementation issues include:

• Scope inconsistencies
• Missing ownership
• Risk-rating inconsistencies
• Weak risk-treatment traceability
• SoA errors
• Policies that don’t match actual practice
• Missing operating evidence
• Controls that haven’t operated consistently
• Incomplete internal audit coverage
• Weak management review
• Unresolved exceptions

Don’t simply patch the document that exposed the issue.

Ask why the problem occurred.

If three access reviews were missed because nobody knew who owned them, updating the access-control policy may not solve the root cause.

Corrective action should address the cause sufficiently to reduce the likelihood of recurrence.

Step 19: Determine Whether You’re Actually Ready for Certification

“Project plan complete” and “certification ready” are not the same thing.

Before engaging the certification process, challenge the ISMS.

Can you demonstrate:

• Defined context and interested parties?
• A defensible scope?
• Leadership involvement?
• A repeatable risk methodology?
• Completed risk assessment?
• Risk treatment decisions?
• Necessary controls?
• Annex A comparison?
• A coherent Statement of Applicability?
• Implemented controls?
• Operating evidence?
• Monitoring and measurement?
• Completed internal audit?
• Completed management review?
• Managed nonconformities?
• Corrective actions?

And perhaps most importantly:

Can the people responsible for the ISMS explain how it works without reading from the policy?

That’s a much better readiness indicator than the number of documents in your compliance folder.

Phase 8: Certification and Beyond

Step 20: Prepare for Stage 1 and Stage 2

Third-party ISO 27001 certification generally involves an initial certification process with Stage 1 and Stage 2 assessments.

Broadly:

Stage 1 evaluates the organization’s readiness and management-system preparation for the fuller assessment.

Stage 2 evaluates implementation and conformity more deeply using objective evidence.

The exact certification process and audit program depend on the certification body and your organization, so confirm the details with the certification body you select.

Where accredited certification matters to customers or other interested parties, verify that the certification body has appropriate accreditation for the certification you’re seeking.

Step 21: Maintain the ISMS After Certification

Certification doesn’t freeze your environment.

Employees leave.

Systems change.

Suppliers change.

New products launch.

Threats evolve.

Risks change.

Controls fail.

Business priorities shift.

An ISMS has to respond.

Ongoing activities include:

• Risk reassessment
• Risk-treatment tracking
• Control monitoring
• Internal audit
• Management review
• Corrective action
• Security awareness
• Supplier oversight
• Incident management
• Policy review
• Objective monitoring
• Continual improvement

The healthiest operating model is not:

We need to get ready because the auditor is coming.

It’s:

The ISMS operates throughout the year, so an audit should not require us to manufacture a compliance program for the occasion.

The ISO 27001 Implementation Roadmap

Here is the complete process condensed into one working view:

Phase	What you’re doing	Primary outputs
1. Establish	Business case, context, leadership, ownership	ISMS governance
2. Scope	Determine boundaries and dependencies	ISMS scope
3. Assess Risk	Establish methodology and evaluate risks	Risk methodology + risk register
4. Treat Risk	Decide how unacceptable risks will be addressed	Risk treatment plan
5. Determine Controls	Determine necessary controls and compare with Annex A	Control set
6. Establish Applicability	Document control decisions	Statement of Applicability
7. Document	Define policies, processes and supporting information	ISMS documentation
8. Implement	Put controls and processes into operation	Operating controls
9. Evidence	Demonstrate operation	Records and evidence
10. Evaluate	Monitor, measure and internally audit	Metrics + audit results
11. Review	Leadership evaluates the ISMS	Management review
12. Improve	Address nonconformities and causes	Corrective actions
13. Certify	Complete external certification assessment	Certification decision
14. Maintain	Repeat, reassess and improve	Sustainable ISMS

Seven ISO 27001 Implementation Mistakes to Avoid

1. Starting With the 93 Annex A Controls

Start with the organization, its scope, risks and requirements.

Determine necessary controls.

Then use Annex A as the required comparison set to help identify controls you may have overlooked.

2. Treating ISO 27001 as a Policy-Writing Project

Policies establish expectations.

They don’t make the expected activities happen.

Implementation needs ownership, processes, controls and evidence.

3. Copying Someone Else’s Risk Register

Generic risks create generic treatment.

Your risks should reflect your environment.

4. Approving Templates Without Customizing Them

Every mandatory statement you adopt can become something you need to explain and demonstrate.

Don’t promise what you don’t actually do.

5. Confusing a Control With Evidence of the Control

A quarterly-review requirement isn’t proof that quarterly reviews occurred.

Design, implementation and operation are different assertions.

6. Conducting Internal Audit at the Last Minute

Give internal audit enough time to find problems.

Then give the organization enough time to understand and correct them.

7. Treating Certification as the Finish Line

A certificate is an outcome.

The real asset is the functioning management system underneath it.

How Long Does ISO 27001 Implementation Take?

There is no responsible universal answer.

Implementation time depends on:

• Scope
• Organization size
• Complexity
• Existing security maturity
• Existing documentation
• Number of gaps
• Leadership involvement
• Available resources
• Internal expertise
• Technology changes required
• Supplier dependencies
• Remediation effort
• Certification-body scheduling

A relatively mature organization with a narrow scope may spend much of its effort formalizing, aligning, evidencing and auditing processes that already exist.

An immature organization may need to build significant governance and security capabilities.

Those are completely different projects.

Instead of asking:

What’s the fastest we can get certified?

ask:

What has to be true before we can credibly demonstrate that this ISMS operates?

Then build the timeline around that.

Do You Need an ISO 27001 Consultant?

Not necessarily.

ISO itself publishes implementation guidance aimed specifically at SMEs, reinforcing that the standard is applicable across organization sizes.

Whether you should use outside help depends on your internal capability.

Consider whether you have:

• Someone who understands ISO 27001
• Sufficient project capacity
• Risk-management capability
• Control-design knowledge
• Internal audit competence
• Leadership support
• Time to create and maintain documentation
• Confidence preparing for certification

External expertise can reduce uncertainty and accelerate parts of the project.

But it cannot own the ISMS forever.

Your organization still has to operate the system after the implementation project ends.

Where an ISO 27001 Toolkit Fits

Templates and implementation tools are most valuable when they remove blank-page work without replacing organizational judgment.

Your original toolkit was built around that problem. It includes resources spanning ISMS core documentation, risk management, policies and procedures, internal audit, certification readiness, project planning and continual improvement.

A toolkit can give you a structured starting point for:

• Defining scope
• Establishing roles and responsibilities
• Conducting risk assessments
• Maintaining a risk register
• Developing the risk treatment plan
• Building the Statement of Applicability
• Creating policies and procedures
• Planning internal audits
• Tracking corrective actions
• Preparing for certification

But a template can’t determine your scope.

It can’t identify your risks for you.

It can’t decide whether a control is necessary.

It can’t operate the control.

And it can’t create valid evidence for an activity that never occurred.

That’s the right relationship between an implementation toolkit and an ISMS:

Use the toolkit to accelerate the structure. Use organizational judgment to build the system.

Don’t want to build every ISO 27001 document from scratch?

The GRCPod ISO 27001 Implementation Toolkit provides customizable templates and implementation resources for building, documenting, auditing and maintaining an ISMS.

[Explore the ISO 27001 Implementation Toolkit →]

ISO 27001 Implementation FAQ

What is the first step in ISO 27001 implementation?

Understand why the organization is pursuing ISO 27001, establish leadership and ownership, evaluate organizational context and define a defensible ISMS scope. Don’t begin by blindly implementing Annex A controls.

Are all 93 Annex A controls mandatory?

Not in the sense that every organization must implement all 93. ISO SC 27 guidance explains that organizations determine necessary controls through risk treatment and compare those controls with Annex A to ensure necessary controls haven’t been omitted. Annex A controls left over require the organization to determine that controls of that type are unnecessary and reflect the appropriate justification in the SoA.

How many Annex A controls are in ISO 27001:2022?

There are 93, organized into four groups: 37 organizational, 8 people, 14 physical and 34 technological controls.

What is an ISMS?

An Information Security Management System is the system an organization uses to establish, operate, evaluate, maintain and improve its approach to managing information security risk.

What is the Statement of Applicability?

The Statement of Applicability documents the organization’s necessary controls and relevant justification and implementation information, while also accounting for Annex A controls determined to be unnecessary. ISO does not mandate one specific SoA table format.

Do I need a policy for every Annex A control?

No. Controls may be implemented through policies, standards, procedures, technical configurations, contractual mechanisms, physical measures, workflows, training or combinations of these. Documentation should support the operation and evidence needs of your ISMS rather than create unnecessary paperwork.

Can a small company implement ISO 27001?

Yes. ISO describes ISO/IEC 27001 as applicable to organizations of all sizes and publishes dedicated implementation guidance for SMEs.

Is ISO 27001 certification proof that an organization is completely secure?

No. Certification provides third-party conformity assessment of the ISMS within its defined scope. It doesn’t guarantee that security incidents, control failures or vulnerabilities can never occur.

Build an ISMS You Can Defend and Operate

A strong ISO 27001 implementation creates a chain of reasoning:

Business context → information security risk → treatment decisions → necessary controls → accountable owners → operation → evidence → evaluation → management decisions → improvement.

Break that chain and compliance starts becoming paperwork.

Keep it intact and the documents begin serving their actual purpose: supporting a management system that helps the organization understand and manage information security risk.

So if you’re beginning ISO 27001 implementation, don’t start by asking how many policies you need.

Start with the foundation:

Understand the organization. Define the scope. Assess the risks. Determine what needs to be controlled and why. Build controls that can actually operate. Collect evidence that proves what you claim. Test the system. Fix what you find.

Then let certification validate the management system you’ve built.