ISO 27001:2022 Clause 6.3 Planning Of Changes for Tech Startups

ISO 27001 Clause 6.3 is a security control that mandates the Planning of Changes to the Information Security Management System (ISMS). For tech startups, this requirement ensures that updates to technology or governance are assessed for risk before implementation, providing the Business Benefit of operational stability and reduced downtime during rapid scaling.

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.

The Business Case: Why This Actually Matters

If you think this clause is just paperwork, you are missing the point. Clause 6.3 is the only thing standing between you and a catastrophic “bad deploy” that takes down your service for 24 hours.

• Sales Angle: Enterprise clients will ask: “Do you have a Change Management process?” If you say “we just push to prod,” you look like a liability. Clause 6.3 gives you the grown-up answer: “Yes, we follow a risk-based change control process.”
• Risk Angle: The “config drift” nightmare. A dev opens an AWS security group for testing and forgets to close it. Without a planned change process, that port stays open until a hacker finds it. Clause 6.3 forces a review that catches this error.

The “No-BS” Translation: Decoding the Requirement

The Auditor’s View: “When the organisation determines the need for changes to the information security management system, the changes shall be carried out in a planned manner.”

The Startup’s View: Don’t just YOLO your infrastructure changes. Think about what might break before you hit enter.

For a DevOps engineer, this translates to:

• The Plan: The Jira ticket describing the feature.
• The Impact Assessment: The comment on the PR saying “This migration might lock the database for 5 seconds.”
• The Approval: The senior dev clicking “Approve” on GitHub.
• The Rollback: The “Revert” button in your CI/CD tool.

DORA, NIS2, and AI Laws

Clause 6.3 is your safety net for regulatory change.

• DORA (Fintech): Requires “Change Management” to prevent ICT incidents. Clause 6.3 provides the exact framework DORA auditors look for to prove you aren’t introducing instability.
• NIS2: Mandates “Security in network and information systems acquisition, development and maintenance.” Clause 6.3 is the “maintenance” part. It proves you manage patches and upgrades securely.
• AI Act: When you update your AI model, that is a “significant change.” Clause 6.3 requires you to assess if the new model introduces bias or safety risks before you release it.

Why the ISO 27001 Toolkit Trumps SaaS Platforms

SaaS platforms try to force you into their rigid “Change Request” forms. Startups don’t work like that.

Feature	ISO 27001 Toolkit (High Table)	Online SaaS GRC Platform
Ownership	You integrate the process into your existing tools (Jira/Linear).	You have to log into a separate portal to file a “Change Request.”
Friction	Zero. The “form” is just a template in your ticketing system.	High. Developers hate logging into compliance tools.
Cost	One-off fee.	Monthly subscription. Why pay rent to fill out a form?
Agility	You define what needs approval.	Often forces a “one size fits all” workflow that slows down dev teams.

Top 3 Non-Conformities When Using SaaS Platforms

1. The “Double Documentation” Error: Developers do the work in Jira, but the SaaS platform requires a separate “Change Record.” Nobody fills out the SaaS form. Result: The auditor sees zero changes recorded for the year, which is impossible. Fail.
2. The “Rubber Stamp” Trap: The SaaS tool has an “Auto-Approve” feature that gets abused. Every change is marked “Low Risk” to bypass the workflow. The auditor spots a major DB migration marked as “Low Risk” and issues a finding for lack of due diligence.
3. The “Scope Gap”: The SaaS tool tracks code changes (via GitHub integration) but misses infrastructure changes (like changing an AWS IAM policy manually). Because you relied on the tool, you didn’t document the manual change.

What is ISO 27001 Clause 6.3 Planning of Changes?

Clause 6.3 mandates that when an organisation determines the need for changes to the ISMS, those changes must be carried out in a planned manner.

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.”

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.

1. Establish Process: Document a simple “Change Management Policy.” Keep it to one page.
2. Assess Impact: Add a “Risk” field to your Jira tickets. Low/Medium/High.
3. Plan: Who is doing it? When? How long will it take?
4. Authorise: Get a “Thumbs up” from the lead dev or CTO.
5. Implement: Do the work.
6. Test: Run the unit tests or check the staging environment.
7. Communicate: Tell the team “We are deploying now” in Slack.
8. Review: If it breaks, do a post-mortem.
9. Document: The closed Jira ticket IS the documentation.
10. Emergency: Have a “Break Glass” protocol for P0 incidents.

The Evidence Locker: What the Auditor Needs to See

To pass the audit for Clause 6.3, you need these artifacts:

• Change Management Policy: A PDF describing your process (Standard vs. Emergency).
• Sample Change Tickets: Export 3 Jira/Linear tickets showing:
  • Description of change.
  • Risk assessment (e.g., “Low Risk”).
  • Approval (e.g., “Approved by @cto”).
  • Test evidence (e.g., “Passed CI pipeline”).
• Pull Request History: Screenshots of your GitHub/GitLab merge rules (e.g., “Require 1 reviewer”).
• Incident Post-Mortem: Evidence that you reviewed a failed change (if any occurred).

Common Pitfalls and Auditor Traps

• The “Retrospective Ticket”: Creating the ticket after the work is done. Auditors check the timestamps. If “Created” is after “Deployed,” you fail.
• The “Verbal Approval”: “Steve said it was okay.” If it’s not written down (Slack, Email, Jira), it didn’t happen.
• The “Test Evidence” Gap: Marking a ticket “Tested” but having no screenshots or logs to prove it.

Handling Exceptions: The Break Glass Protocol

Sometimes you need to fix a bug NOW.

• The Emergency: Production is down.
• The Action: Dev pushes code directly to prod (if allowed) or bypasses standard approval.
• The Paper Trail: Create an “Emergency Change” ticket after the incident is resolved. Link it to the Incident Report.
• Review: The CTO must review all emergency changes within 24 hours.

The Process Layer: Standard Operating Procedure (SOP)

Tools: Linear/Jira, GitHub.

1. Request: Dev creates a ticket. Selects type: “Standard” or “Major.”
2. Assessment: Dev answers “Will this cause downtime?” (Yes/No).
3. Approval:
   • Standard: Peer review (PR) is sufficient.
   • Major: Requires CTO approval on the ticket.
4. Deployment: CI/CD pipeline deploys the code.
5. Verification: Automated tests run. Dev marks ticket “Done.”

Frequently Asked Questions (FAQ)

About the author