1. Purpose
The ISMS Improvement Log is a central register used to identify, record, prioritize, implement, and verify opportunities to improve the organization’s Information Security Management System (ISMS).
The log helps ensure that improvement opportunities identified through day-to-day security operations are converted into measurable actions.
Improvements may originate from:
- Security incidents
- Post-Incident Reviews
- Root Cause Analysis
- Lessons Learned
- Security events
- Internal audits
- External audits
- Risk assessments
- Risk treatment
- Vulnerability assessments
- Penetration testing
- Supplier reviews
- Cloud security reviews
- Access reviews
- Security testing
- Tabletop exercises
- Business continuity exercises
- Management reviews
- Security metrics
- Customer feedback
- Regulatory changes
- Changes in technology
- Changes in business context
- Changes in threats
The objective is:
Identify → Prioritize → Improve → Verify → Standardize → Continue Improving
2. What Is an ISMS Improvement?
An ISMS improvement is a change that strengthens the organization’s ability to:
- Protect information
- Manage security risks
- Operate security controls
- Detect and respond to incidents
- Meet security objectives
- Support business requirements
- Improve compliance
- Improve resilience
- Reduce recurring weaknesses
- Adapt to changes in technology and threats
An improvement does not necessarily mean implementing new technology.
Examples include:
- Clarifying control ownership
- Improving an existing procedure
- Automating an access review
- Improving monitoring
- Updating a risk assessment
- Improving incident escalation
- Removing unnecessary documentation
- Training employees
- Improving supplier oversight
3. Improvement Sources
| Source | Example |
|---|---|
| Incident | Control failed during security incident |
| RCA | Root cause identified |
| Lessons Learned | Improvement identified after incident |
| Audit | Nonconformity or observation |
| Risk Assessment | New risk treatment |
| Vulnerability Assessment | Repeated technical weakness |
| Penetration Test | Security control improvement |
| Supplier Review | Third-party security gap |
| Management Review | Strategic improvement |
| Exercise | Response capability gap |
| Metrics | Negative trend |
| Customer Feedback | Security requirement |
| Business Change | New technology or service |
| Threat Change | Emerging threat |
| Regulatory Change | New obligation |
4. ISMS Improvement Register
| Improvement ID | Date | Source | Source ID | Improvement Opportunity | Area | Priority | Owner | Target Date | Status | Evidence | Effectiveness |
|---|---|---|---|---|---|---|---|---|---|---|---|
| IMP-2026-001 | Incident | IAM | High | Open | |||||||
| IMP-2026-002 | Audit | Incident Response | Medium | In Progress | |||||||
| IMP-2026-003 | Management Review | Risk Management | Medium | Planned |
Recommended ID
Use:
IMP-YYYY-0001
Example:
IMP-2026-0001
5. Improvement Record
Improvement Information
Improvement ID:
IMP-YYYY-0001
Date Identified:
Source:
Incident / Audit / Risk / Exercise / Management Review / Security Testing / Other
Source Record ID:
Identified By:
ISMS Area:
Business Area:
Owner:
Priority:
Critical / High / Medium / Low
Status:
6. Improvement Opportunity
Describe what could be improved.
The description should explain the opportunity without immediately assuming the solution.
Example
Privileged cloud access reviews currently require manual consolidation of IAM information from multiple AWS accounts.
7. Why Is Improvement Required?
Describe the reason for the improvement.
Consider:
- Security risk
- Incident
- Recurring weakness
- Audit finding
- Inefficient process
- Technology change
- Business growth
- Customer requirement
- Regulatory requirement
- Threat change
- Control effectiveness
- Management decision
Reason
8. Current State
Describe the current situation.
Current Process
Current Control
Current Technology
Current Risk
9. Desired Future State
Describe what the organization wants to achieve.
The future state should be measurable where practical.
Example
All production privileged identities are reviewed quarterly, have documented owners, follow least privilege, and generate alerts for defined high-risk activities.
10. Improvement Gap
Describe the difference between the current and desired state.
| Area | Current State | Desired State | Gap |
|---|---|---|---|
| Process | |||
| People | |||
| Technology | |||
| Control | |||
| Governance |
11. Improvement Objective
Define the objective.
A good objective should answer:
What will be better after this improvement is implemented?
Example:
Improve privileged-access governance so that production access is reviewed consistently and unnecessary permissions are identified and removed.
12. Improvement Type
Classify the improvement.
- Process Improvement
- Control Improvement
- Technology Improvement
- People / Training
- Policy Improvement
- Procedure Improvement
- Risk Management
- Incident Management
- Supplier Management
- Cloud Security
- Application Security
- Data Security
- Business Continuity
- Governance
- Monitoring and Measurement
- Automation
- Documentation Simplification
- Other
13. Risk Assessment
Determine whether the improvement addresses a security risk.
| Risk Factor | Assessment |
|---|---|
| Threat | |
| Vulnerability | |
| Likelihood | |
| Impact | |
| Existing Controls | |
| Current Risk | |
| Expected Residual Risk |
Risk ID:
If the improvement originates from a risk assessment, link it to the relevant Risk Register entry.
14. Improvement Priority
Critical
Improvement addresses:
- Significant security exposure
- Major control failure
- Critical business/security risk
- Major incident
- Significant customer or regulatory exposure
High
Improvement addresses:
- Significant control weakness
- High-risk finding
- Important recurring issue
- Significant incident lesson
Medium
Meaningful improvement with manageable risk.
Low
Minor optimization or efficiency improvement.
| Priority | Typical Treatment |
|---|---|
| Critical | Immediate management attention |
| High | Prioritized |
| Medium | Planned |
| Low | Scheduled improvement |
15. Improvement Plan
| Step | Activity | Owner | Target Date | Status | Evidence |
|---|---|---|---|---|---|
| 1 | |||||
| 2 | |||||
| 3 | |||||
| 4 |
16. Resources Required
Identify required resources.
People
Technology
Budget
External Support
Management Support
17. Dependencies
Identify dependencies that could affect implementation.
| Dependency | Impact | Owner | Resolution | Status |
|---|---|---|---|---|
Examples:
- Product release
- Cloud migration
- Supplier dependency
- Legal review
- Budget
- Engineering capacity
- Customer requirement
- Technology integration
18. Implementation Evidence
Record evidence that demonstrates implementation.
| Evidence ID | Evidence | Date | Location | Verified By |
|---|---|---|---|---|
Examples:
- Updated policy
- Updated procedure
- Configuration
- Access review
- Security test
- Training record
- Dashboard
- Monitoring alert
- Change record
- Risk assessment
- Audit evidence
- Tabletop exercise
- Technical test results
Never store passwords, API keys, access tokens, private keys, or recovery codes in the improvement log.
19. Implementation Status
Use standardized statuses:
- Identified
- Under Assessment
- Approved
- Planned
- In Progress
- Blocked
- Awaiting Approval
- Implemented
- Awaiting Verification
- Effectiveness Review
- Completed
- Closed
- Deferred
- Risk Accepted
- Reopened
20. Effectiveness Verification
An improvement should not be considered successful merely because the planned activity was completed.
Evaluate:
Did the improvement produce the intended security outcome?
Verification Questions
- Was the improvement implemented?
- Is the improved process operating?
- Is the control functioning as intended?
- Has the original gap been addressed?
- Has risk reduced?
- Has performance improved?
- Is the improvement sustainable?
- Has the change introduced any new risk?
Verification Result
Verified By:
Verification Date:
21. Effectiveness Measurement
Define measurable indicators where practical.
| Measure | Before Improvement | Target | After Improvement | Result |
|---|---|---|---|---|
Examples:
- Access review completion rate
- Incident detection time
- Incident response time
- Vulnerability remediation time
- Backup recovery success
- Security-training completion
- Supplier review completion
- Corrective-action closure rate
- Security alert response time
22. AWS SaaS Example
A SaaS startup identifies through an incident review that privileged AWS access is difficult to review consistently.
Current State
- Multiple AWS accounts
- Several production IAM roles
- Role ownership not consistently documented
- Manual access reviews
- Limited privileged activity monitoring
Improvement Objective
Establish consistent production privileged-access governance across AWS environments.
Improvement Plan
- Inventory production IAM roles.
- Assign an owner to each role.
- Review permissions against business need.
- Remove unnecessary privileges.
- Establish quarterly access review.
- Implement high-risk privileged activity alerts.
- Document approval and evidence.
- Test the process.
- Measure review completion and exceptions.
Success Measures
- 100% of production privileged roles have documented owners.
- Quarterly review completed within defined timeframe.
- Unnecessary permissions removed.
- High-risk privileged activity generates alerts.
- Review evidence retained.
23. Policy and Procedure Changes
Determine whether the improvement requires documentation changes.
| Document | Change Required | Description | Owner | Status |
|---|---|---|---|---|
| Information Security Policy | ||||
| Access Control Procedure | ||||
| Incident Response Procedure | ||||
| Cloud Security Policy | ||||
| Risk Management Procedure | ||||
| Supplier Security Procedure |
24. Risk Register Update
Determine whether the improvement changes the organization’s risk profile.
Risk Updated?
Yes / No
Risk ID:
Previous Risk:
Current Risk:
Residual Risk:
Risk Owner:
25. Statement of Applicability / Control Review
Where relevant, determine whether the improvement affects information-security controls.
| Control Area | Existing Control | Change Required | Reason |
|---|---|---|---|
The organization should consider whether:
- An existing control needs strengthening
- A control is no longer appropriate
- A new control is required
- Control implementation has changed
- Control ownership needs clarification
- Evidence requirements need improvement
The decision should remain risk-based, rather than treating Annex A as a checklist.
26. Incident and Lessons Learned Link
For improvements originating from incidents:
Incident ID:
RCA ID:
Post-Incident Review ID:
Lesson ID:
Corrective Action ID:
This creates traceability:
Incident → RCA → Lesson → Corrective Action → Improvement → Verification
27. Audit and Finding Link
For improvements originating from audits:
Audit ID:
Finding ID:
Finding Severity:
Corrective Action ID:
Evidence of Closure:
28. Improvement From Management Review
Management may identify improvements relating to:
- ISMS performance
- Security objectives
- Risk treatment
- Resources
- Security controls
- Business changes
- Customer requirements
- Technology
- Security metrics
- Supplier management
Management Improvement
Management Decision:
Action Owner:
Target Date:
29. Continual Improvement Review
Periodically review the improvement register for:
- Open improvements
- Overdue improvements
- Repeated improvement themes
- Improvements that failed
- Improvements that generated new risks
- High-risk unresolved gaps
- Improvements requiring management decisions
- Improvements that should be standardized
- Improvements that can be automated
Review Findings
30. Recurring Improvement Themes
Analyze improvement opportunities by theme.
| Theme | Number | Examples | Priority |
|---|---|---|---|
| IAM | |||
| Cloud Security | |||
| Incident Management | |||
| Vulnerability Management | |||
| Supplier Security | |||
| Data Protection | |||
| Security Awareness | |||
| Business Continuity | |||
| Application Security | |||
| Governance |
Recurring themes may indicate a broader ISMS improvement opportunity.
31. Management Dashboard
| Metric | Result |
|---|---|
| Total Improvements | |
| Open Improvements | |
| Critical Improvements | |
| High-Priority Improvements | |
| Overdue Improvements | |
| Blocked Improvements | |
| Implemented Improvements | |
| Awaiting Verification | |
| Verified Effective | |
| Failed Effectiveness Reviews | |
| Reopened Improvements | |
| Risk-Accepted Improvements |
32. Suggested ISMS Improvement KPIs
Improvement Completion Rate
Closed Improvements ÷ Total Improvements
On-Time Completion Rate
Improvements Completed by Target Date ÷ Improvements Completed
Effectiveness Rate
Improvements Verified Effective ÷ Improvements Tested
Recurrence Rate
Repeated Issues After Improvement ÷ Issues Previously Improved
Overdue Rate
Overdue Improvements ÷ Open Improvements
These metrics should be interpreted alongside the risk and significance of the improvements, not treated as standalone performance scores.
33. Improvement Review Frequency
A practical approach:
| Improvement | Suggested Review |
|---|---|
| Critical | Weekly / As required |
| High | Monthly |
| Medium | Monthly / Quarterly |
| Low | Quarterly |
The actual frequency should be based on organizational risk.
34. Closure Criteria
An ISMS improvement may be closed when:
- Improvement objective is defined
- Required approval is obtained
- Implementation is completed
- Evidence is available
- Relevant stakeholders have been informed
- Control/process operates as intended
- Effectiveness has been assessed where appropriate
- Risk has been reassessed
- Related policies/procedures are updated
- Security objectives or metrics are updated where necessary
- Residual risk is acceptable or formally accepted
- Management review is completed where required
35. Evidence Supporting ISMS Improvement
Maintain appropriate evidence such as:
- Risk assessments
- Incident reports
- RCA reports
- Lessons Learned
- Corrective Action Tracker
- Audit findings
- Security testing
- Vulnerability reports
- Policies
- Procedures
- Access reviews
- Security configurations
- Training records
- Monitoring results
- Tabletop exercise results
- Management review records
- Performance metrics
- Control-testing records
36. Startup-Friendly Implementation
A startup does not need a separate improvement document for every small change.
A simple spreadsheet can contain:
Improvement ID → Source → Opportunity → Current State → Desired State → Risk → Action → Owner → Due Date → Evidence → Effectiveness → Status
For significant improvements, link the record to:
- Incident
- RCA
- Lesson Learned
- Corrective Action
- Risk
- Audit Finding
- Management Review
This avoids duplicate documentation while maintaining a clear audit trail.
37. Difference Between Corrective Action and ISMS Improvement
These records are related but not identical.
| Corrective Action | ISMS Improvement |
|---|---|
| Usually addresses an identified problem or failure | Can address a broader improvement opportunity |
| Often linked to a finding or incident | Can originate from strategy, metrics, risk, or business change |
| Focuses on correcting a weakness | Focuses on strengthening the ISMS |
| Often specific and targeted | Can be systemic or strategic |
| Example: Fix excessive IAM permissions | Example: Establish automated privileged-access governance |
A corrective action can therefore become an ISMS improvement when the organization decides to embed the learning into a broader, sustainable improvement.
38. ISO 27001 Alignment
The ISMS Improvement Log supports the organization’s approach to continual improvement by maintaining evidence that improvement opportunities are identified, evaluated, implemented, and reviewed.
It can support:
- Information-security risk management
- Corrective action
- Control improvement
- Management review
- Monitoring and measurement
- Security objectives
- Incident learning
- Organizational change
- Continual improvement
The specific log format is an organizational implementation choice. ISO/IEC 27001 does not prescribe a particular “ISMS Improvement Log.”
The organization should determine the appropriate level of documentation based on:
- Risk
- Business context
- ISMS scope
- Organizational size
- Complexity
- Customer requirements
- Regulatory obligations
- Security objectives
39. Final ISMS Improvement Audit Trail
Improvement Opportunity Identified → Source Recorded → Current State Assessed → Desired State Defined → Risk Assessed → Improvement Prioritized → Owner Assigned → Action Planned → Improvement Implemented → Evidence Collected → Control/Process Verified → Effectiveness Measured → Risk Reassessed → Management Review → Improvement Standardized → ISMS Updated → Improvement Closed
Final Principle
Continual Improvement Means Turning Experience Into Better Security.
Identify the Opportunity + Understand the Gap + Assess the Risk + Define the Desired State + Assign Ownership + Implement the Improvement + Collect Evidence + Measure Effectiveness + Reassess Risk + Embed the Change + Keep Improving.