If you’re running a tech startup, the phrase ‘ISO 27001 compliance’ probably conjures images of slow-moving bureaucracy, the exact opposite of your agile operations. In your world, change is the engine of growth. However, the ISO 27001:2022 update introduced a requirement that actually aligns perfectly with the startup ethos: Clause 6.3 Planning of changes.
This isn’t about slowing you down. It is about ensuring that as you pivot, scale, and deploy, you do so in a way that is secure and resilient. This guide breaks down ISO 27001 Clause 6.3 into actionable steps specifically for tech startups, helping you turn compliance into a competitive advantage.
Table of contents
- What is ISO 27001 Clause 6.3 Planning of Changes?
- Why Clause 6.3 Matters for Tech Startups
- The 10-Step Implementation Roadmap for Startups
- Step 1: Establish a Formal Change Management Process
- Step 2: Assess the Impact of Changes
- Step 3: Plan Changes in a Controlled Manner
- Step 4: Authorise Changes
- Step 5: Implement Changes as Planned
- Step 6: Test Changes
- Step 7: Communicate Changes
- Step 8: Review Changes
- Step 9: Document Changes
- Step 10: Manage Emergency Changes
- Audit Checklist: What Auditors Look For in Clause 6.3
- Conclusion: Change as a Superpower
- About the Author
What is ISO 27001 Clause 6.3 Planning of Changes?
Before writing policies, you need to understand the requirement. Clause 6.3 is a straightforward addition to the ISO 27001:2022 standard. It mandates that when an organisation determines the need for changes to the Information Security Management System (ISMS), those changes must be carried out in a planned manner.
For a resource-constrained startup, the good news is that you don’t need to invent new administrative hurdles. Most tech companies already have evidence of this. Your incident response post-mortems, Git pull request reviews, internal audit findings, or Jira backlogs for infrastructure improvements are all valid forms of “planning for change.”
The Official Definition
The standard defines it concisely:
“When the organisation determines the need for changes to the information security management system, the changes shall be carried out in a planned manner.”
Why Clause 6.3 Matters for Tech Startups
Viewing Clause 6.3 strictly as a compliance box-ticking exercise is a mistake. For a high-growth tech company, a structured approach to change management is a strategic enabler.
- Reduced Risk and Improved Stability: Startups often operate with a “move fast and break things” mindset. However, downtime can be catastrophic. A formal process forces you to assess the impact before you push code or change policy, preventing unexpected disruptions.
- Enhanced Control as You Scale: When you are five people in a room, communication is organic. When you are 50 people remote, you need structure. Formal procedures ensure that changes to key policies or system configurations are managed consistently, regardless of who leads the project.
- Clearer Communication: A planned change includes a communication plan. This prevents the confusion that slows down fast-moving teams. When engineering, sales, and support all understand what is changing and why, the whole company moves faster.
The 10-Step Implementation Roadmap for Startups
We have translated the ISO requirements into a practical checklist. Follow these steps to build a process that satisfies auditors without killing your velocity.
Step 1: Establish a Formal Change Management Process
Action: Document your official process for managing changes to the ISMS.
The Startup Challenge: Resistance to “corporate” procedures.
The Pragmatic Solution: Keep it simple. A one-page policy in Confluence or Notion is perfect. Startups don’t fail audits for simple processes; they fail for having no process. Ensure it is documented and accessible.
Step 2: Assess the Impact of Changes
Action: Before implementation, assess potential impacts on information security.
The Startup Challenge: Overlooking downstream consequences.
The Pragmatic Solution: Add a simple risk field to your Jira tickets or change request templates. Ask: “What is the worst that could happen if this goes wrong?” and document the answer.
Step 3: Plan Changes in a Controlled Manner
Action: Plan the execution, considering resources, timelines, and testing.
The Startup Challenge: Under-planning due to speed.
The Pragmatic Solution: Use your existing project management tools. A checklist on a Linear or Trello card covering “Who, What, When, and How” is often sufficient evidence of planning.
Step 4: Authorise Changes
Action: Obtain authorisation from the appropriate level of management.
The Startup Challenge: Informal approvals (“Yeah, go ahead”) that leave no trail.
The Pragmatic Solution: Create an audit trail. Use a dedicated Slack channel with emoji reactions (e.g., :approved:) for minor changes, and a formal workflow for major ones.
Step 5: Implement Changes as Planned
Action: Execute the change according to the plan.
The Startup Challenge: Deviating from the plan to solve unexpected issues on the fly.
The Pragmatic Solution: Have a rollback plan ready. Whether it is reverting a deployment or using version control for policy documents (e.g., ‘Policy v1.1’), show the auditor you can move forward or backward safely.
Step 6: Test Changes
Action: Verify changes work as expected and introduce no new vulnerabilities.
The Startup Challenge: Rushed testing.
The Pragmatic Solution: Include testing in your “Definition of Done.” Document test results—even if it is just a screenshot or a comment on a ticket—to demonstrate diligence.
Step 7: Communicate Changes
Action: Inform relevant stakeholders.
The Startup Challenge: Assuming everyone already knows.
The Pragmatic Solution: Create a communication checklist. Who needs to know? Use existing channels like team meetings or Slack announcements and keep a record of it.
Step 8: Review Changes
Action: Post-implementation review to assess effectiveness.
The Startup Challenge: Moving instantly to the next project.
The Pragmatic Solution: Schedule a 15-minute “retro” for significant changes. Ask: “Did we achieve the goal?” and “What could we do better?” Document this in the change record.
Step 9: Document Changes
Action: Maintain accurate records.
The Startup Challenge: Scattered records.
The Pragmatic Solution: Use a central change log. A simple spreadsheet linked to your ticketing system is perfectly acceptable. Don’t over-engineer it.
Step 10: Manage Emergency Changes
Action: Have an expedited process for critical fixes.
The Startup Challenge: Panic-induced process abandonment.
The Pragmatic Solution: Define what constitutes an emergency. Allow verbal approval but require retrospective documentation. You must prove that even in a crisis, you are in control.
Audit Checklist: What Auditors Look For in Clause 6.3
When the auditor arrives, they are looking for verification that your system works as described. Here is what you need to have ready.
| Auditor’s Focus Area | How Your Startup Can Prepare |
|---|---|
| Formal Process | Have your policy ready in your wiki/knowledge base. Be prepared to walk through it. |
| Impact Assessment | Show examples of Jira tickets or change logs where risk was considered before action. |
| Controlled Planning | Present implementation plans or checklists showing resources and schedules. |
| Authorisation | Show the “digital paper trail” of approvals (Slack logs, ticket transitions, email approvals). |
| Implementation Evidence | Provide system logs or diffs showing the change matches the plan. |
| Testing Evidence | Have test cases and success results available for review. |
| Communication | Show slack announcements, emails, or meeting minutes regarding the change. |
| Post-Implementation Review | Show notes on lessons learned. This is crucial evidence of “Continual Improvement.” |
| Emergency Procedures | Explain your “break glass” procedure and show a retrospective record of a past emergency change. |
Pro Tip: Leverage your existing records. Show the auditor how your incident management reviews or agile retrospectives serve as evidence of planned changes. Auditors appreciate efficiency.
Conclusion: Change as a Superpower
ISO 27001 Clause 6.3 is not a restrictive rule designed to stifle agility. It is a framework for harnessing the power of change safely. By implementing a planned approach, you reduce risk, improve stability, and signal operational maturity to investors and enterprise clients.
Embrace planned change. You are not just aiming for a certificate; you are building a scalable, resilient business.
About the Author
Stuart Barker is a veteran practitioner with over 30 years of experience in systems security and risk management. Holding an MSc in Software and Systems Security, Stuart combines academic rigor with extensive operational experience. His background includes over a decade leading Data Governance for General Electric (GE) across Europe, as well as founding and exiting a successful cyber security consultancy.
As a qualified ISO 27001 Lead Auditor and Lead Implementer, Stuart possesses distinct insight into the specific evidence standards required by certification bodies. He has successfully guided hundreds of organizations—from high-growth technology startups to enterprise financial institutions—through the audit lifecycle.
