ISO 27001
Internal Audit
Incident Response
Certification Readiness
ISO 27001 Internal Audit After a Cyber Incident: What Must Be Retested Before Certification?
Learn how to run an ISO 27001 post incident internal audit, retest failed controls, verify corrective actions, and prepare stronger evidence before certification.
A Cyber Incident Does Not Automatically End Certification Readiness
Your ISO 27001 certification audit is approaching.
Then a cybersecurity incident happens.
Maybe an account was compromised.
Perhaps customer data was exposed.
A phishing attack may have succeeded.
A cloud configuration may have failed.
Or an attacker exploited an unpatched vulnerability.
First, the organization must contain the incident and recover.
However, another question soon appears:
Is the ISMS still ready for certification?
An incident does not automatically mean the organization is unprepared.
What matters is how the organization responds, learns, corrects, and verifies.
That is why an ISO 27001 post incident internal audit should go beyond the incident report.
It should retest the controls that failed.
Quick Answer
What Should Be Tested After a Cyber Incident?
An ISO 27001 internal audit should determine:
- What happened.
- Why it happened.
- Which controls failed or were bypassed.
- Whether the root cause was identified.
- Whether corrective actions were completed.
- Whether affected controls were retested.
- Whether logs can prove what happened.
- Whether access has been corrected.
- Whether risks were reassessed.
- Whether lessons learned changed the ISMS.
- Whether management reviewed the remaining risk.
Clause 9.2 addresses internal audit.
Clause 10.2 addresses nonconformity and corrective action.
Before certification, prove that the weakness was corrected and retested.
Why an Incident Changes the Internal Audit
Before an incident, an auditor may test whether a control appears effective.
After an incident, the organization has new evidence.
Something did not work as expected.
Therefore, the internal audit scope should respond to the incident.
1. Start With the Incident Timeline
First, reconstruct what happened.
Do not begin with the corrective-action spreadsheet.
Begin with the event.
Internal Audit Should Establish
- When the incident started.
- When it was detected.
- Who detected it.
- How it was classified.
- Who was notified.
- Which systems were affected.
- Which information was affected.
- How containment occurred.
- When recovery occurred.
- When normal operations resumed.
Then compare the actual response with the documented process.
Evidence to Request
- Incident ticket.
- Incident timeline.
- SIEM alerts.
- Email notifications.
- Security logs.
- Response records.
- Escalation evidence.
- Communication records.
- Recovery records.
The goal is to determine whether the ISMS operated as expected.
2. Verify the Root-Cause Analysis
“An employee clicked a phishing link” is usually not enough.
Ask why that click could create the incident.
For example:
- MFA was missing.
- Legacy authentication was enabled.
- Privileges were excessive.
- Endpoint protection failed.
- Conditional Access was incomplete.
- Security awareness was ineffective.
- Monitoring failed to detect unusual activity.
A useful root-cause analysis looks deeper than the final user action.
3. Retest Access Control
If compromised credentials were involved, access control needs immediate attention.
Do not only verify that one attacker account was disabled.
Test the wider environment.
- User access.
- Administrative roles.
- Service accounts.
- Shared accounts.
- MFA.
- Conditional Access.
- Privileged access.
- Dormant accounts.
- Authentication methods.
- Access-review processes.
- Session revocation.
For example, a password reset may not be enough.
4. Retest Logging and Detection
Next, ask:
Review whether logs captured enough evidence.
- Authentication logs.
- Administrative activity.
- Endpoint events.
- Cloud logs.
- Application logs.
- Firewall activity.
- Data-access events.
- Security alerts.
Then test detection.
Did security detect the incident?
If yes, how quickly?
If not, why not?
Malicious Activity
↓
Log Generated
↓
Alert Triggered
↓
Security Investigation
↓
Containment
↓
New Detection Implemented
↓
Detection Tested
5. Verify That Remediation Actually Works
A corrective action is not complete because its status says “Closed.”
Internal audit should test effectiveness.
Attackers accessed an exposed administrative portal.
Access was restricted behind VPN and MFA.
Attempt access from an unauthorized external network.
Access is denied.
Did the Incident Expose a Bigger ISMS Weakness?
Canadian Cyber can independently retest affected controls, review corrective actions, assess evidence, and identify unresolved risks before your certification audit.
The goal is not simply to close the incident. It is to prove that the control environment improved.
6. Retest Vulnerability and Patch Management
If a vulnerability caused the incident, look beyond one CVE.
Ask:
- Was the vulnerability known?
- When was it detected?
- Was a patch available?
- Who owned remediation?
- Was the SLA exceeded?
- Was risk accepted?
- Were similar systems exposed?
- Could the same vulnerability exist elsewhere?
Then sample the wider vulnerability-management process.
The root cause may not be:
Instead, it may be:
7. Retest Security Configuration
Incidents often expose configuration weaknesses.
Examples include:
- Public storage.
- Excessive firewall rules.
- Weak tenant settings.
- Open administrative interfaces.
- Missing security headers.
- Insecure cloud permissions.
- Disabled logging.
- Default credentials.
Internal audit should verify both the affected setting and the process that manages it.
Evidence May Include
- Secure configuration baseline.
- Updated configuration.
- Cloud policy.
- Configuration scan.
- Change record.
- Retest results.
8. Retest Backup and Recovery
If the incident affected availability or data integrity, test recovery.
Do not settle for:
Verify that:
- Backups existed.
- The correct information was backed up.
- Backups were protected.
- Restoration succeeded.
- Restored information was accurate.
- Recovery time was acceptable.
- Compromised weaknesses were not restored.
Successful restoration is much stronger evidence than a backup configuration screenshot.
9. Review Incident Lessons Learned
ISO 27001 Annex A Control 5.27 addresses learning from information security incidents.
Useful Questions
- What worked?
- What failed?
- What took too long?
- What information was missing?
- Were responsibilities clear?
- Did escalation work?
- Were suppliers responsive?
- Did communications work?
- What should change?
Evidence May Include
- Post-incident review.
- Lessons-learned meeting.
- Updated procedures.
- New security controls.
- Updated training.
- Revised playbooks.
- New monitoring rules.
- Management actions.
The strongest evidence is proof that lessons changed the system.
10. Confirm Incident Evidence Was Preserved
Evidence handling matters when legal, contractual, insurance, or regulatory issues may follow.
Annex A Control 5.28 addresses evidence identification, collection, acquisition, and preservation.
Internal audit should check whether evidence was:
- Identified.
- Preserved.
- Protected from alteration.
- Access controlled.
- Retained appropriately.
- Traceable where required.
Potential evidence includes:
11. Update the Risk Assessment
A real incident provides new risk information.
Therefore, the risk assessment should be reconsidered.
For example, a risk previously rated as unlikely may have actually occurred.
Review whether the incident changed:
- The risk register.
- The risk treatment plan.
- Control selection.
- The Statement of Applicability where relevant.
- Security objectives.
- Monitoring requirements.
12. Review Supplier Controls if a Third Party Was Involved
Many incidents involve third parties.
- Cloud providers.
- SaaS platforms.
- Managed service providers.
- Software vendors.
- Contractors.
- Supply-chain dependencies.
If a supplier played a role, test:
- Supplier responsibilities.
- Incident notification.
- Contract requirements.
- Communication.
- Evidence supplied.
- Remediation commitments.
- Follow-up monitoring.
Vendor risk is still organizational risk.
13. Retest Security Awareness if People Were Involved
Phishing, social engineering, or procedural error may require training review.
However, avoid the easy response:
Ask broader questions.
- Was the training adequate?
- Was it relevant?
- Was the procedure clear?
- Could a technical control have prevented the error?
- Did similar employees understand the risk?
A strong corrective action improves the system instead of blaming one person.
14. Check Whether the Incident Changed Documentation
An incident may reveal outdated procedures.
Review whether the organization updated:
- Incident response plan.
- Access-control procedure.
- Backup procedure.
- Vulnerability management process.
- Security monitoring.
- Supplier procedures.
- Business continuity plans.
- Risk assessments.
- Playbooks.
Then verify that affected employees know about the changes.
A revised document nobody follows is weak evidence.
15. Verify Corrective Actions Before Certification
Certification readiness improves when corrective actions have a clear evidence trail.
| Step | Evidence |
|---|---|
| Incident | Incident record |
| Root Cause | Root-cause analysis |
| Control Failure | Audit finding |
| Corrective Action | Action plan |
| Owner | Assigned responsibility |
| Due Date | Target completion |
| Implementation | Technical or process evidence |
| Retest | Internal audit evidence |
| Effectiveness | Successful test result |
| Closure | Approved closure |
What Should Be Retested Before Certification?
The exact scope should follow the incident.
| Area | Retest Question |
|---|---|
| Incident Response | Did the response process work as documented? |
| Root Cause | Was the underlying cause identified? |
| Access Control | Can unauthorized access still occur? |
| Identity Management | Were compromised or excessive identities corrected? |
| Logging | Can important security events now be reconstructed? |
| Monitoring | Would similar activity now trigger an alert? |
| Vulnerability Management | Could the same vulnerability remain elsewhere? |
| Configuration | Are insecure settings corrected across the environment? |
| Backups | Can clean information and systems be restored? |
| Supplier Management | Were third-party weaknesses addressed? |
| Awareness | Were people-related causes addressed effectively? |
| Risk Assessment | Did the incident change the risk picture? |
| Corrective Action | Has remediation effectiveness been verified? |
| Documentation | Do procedures reflect what was learned? |
ISO 27001 Areas to Consider
| ISO 27001 Area | Post-Incident Audit Focus |
|---|---|
| Clause 6.1 | Risks and treatment decisions |
| Clause 8.2 | Updated information security risk assessment |
| Clause 8.3 | Updated risk treatment |
| Clause 9.1 | Monitoring and measurement |
| Clause 9.2 | Internal audit |
| Clause 9.3 | Management review |
| Clause 10.1 | Continual improvement |
| Clause 10.2 | Nonconformity and corrective action |
| A.5.15–A.5.18 | Access and identity controls |
| A.5.24 | Incident management preparation |
| A.5.25 | Assessment of security events |
| A.5.26 | Incident response |
| A.5.27 | Learning from incidents |
| A.5.28 | Collection of evidence |
| A.8.15 | Logging |
| A.8.16 | Monitoring |
| A.8.8 | Technical vulnerability management |
| A.8.13 | Backup |
| A.8.32 | Change management |
Post-Incident Audit Evidence Pack
Before certification, consider preparing:
- Incident report.
- Incident timeline.
- Root-cause analysis.
- Lessons-learned report.
- Corrective-action register.
- Updated risk assessment.
- Updated risk treatment plan.
- Relevant log evidence.
- Access review results.
- Vulnerability scan results.
- Configuration evidence.
- Patch evidence.
- Backup and restoration test results.
- Supplier correspondence.
- Updated procedures.
- Training evidence.
- Retest evidence.
- Internal audit findings.
- Closure evidence.
- Management review records.
Evidence should show that the ISMS actually improved.
Common Post-Incident Audit Mistakes
Recovery is treated as corrective action.
Similar systems remain exposed.
The report explains what happened but not why.
Changes are implemented but never verified.
System and process weaknesses remain untested.
The incident does not change the ISMS risk picture.
The organization cannot reconstruct the attack.
Actions are closed based only on implementation.
Known issues remain unresolved until the external audit.
A Simple Certification-Readiness Test
Before the external audit, ask five questions.
There should be a reliable timeline and incident record.
There should be credible root-cause analysis.
There should be implementation evidence.
There should be retest evidence.
Risks, controls, processes, or monitoring should reflect the lessons.
If all five answers have evidence, the incident can demonstrate ISMS maturity.
Frequently Asked Questions
Can you still achieve ISO 27001 certification after a cyber incident?
Yes.
A cyber incident does not automatically prevent certification. The key issue is how the ISMS responded and improved.
Does ISO 27001 require an internal audit after every incident?
Not necessarily.
However, a significant incident may justify targeted follow-up testing or a change in audit scope.
What is the most important evidence after an incident?
There is no single document.
A strong trail connects Incident → Root Cause → Corrective Action → Retest → Effectiveness.
Should the risk register be updated after an incident?
Review it.
Update relevant risk information when the incident changes likelihood, impact, vulnerabilities, threats, controls, or treatment decisions.
What does an auditor want to see from corrective actions?
Evidence should show both implementation and effectiveness.
Should management review the incident before certification?
Significant incidents, risks, corrective actions, and internal-audit results may be relevant management-review inputs.
What if corrective actions are still open?
Assess their risk, status, temporary controls, ownership, deadlines, and impact on ISMS effectiveness.
The Takeaway
A cyber incident before certification creates a problem.
However, it also creates a test of the ISMS.
The organization now has an opportunity to prove that it can:
The internal audit should follow the same path.
Retest the controls.
Verify the root cause.
Review the logs.
Challenge access.
Test remediation.
Update the risks.
Confirm lessons learned.
Then confirm that corrective actions actually worked.
Certification readiness is about proving that the ISMS responded effectively when something went wrong.
Preparing for Certification After a Cyber Incident?
Canadian Cyber can independently review your ISMS after a cybersecurity incident.
Our ISO 27001 internal audit approach can test whether affected controls, corrective actions, and supporting evidence are ready for external certification review.
- Incident-response effectiveness.
- Root-cause evidence.
- Access controls.
- Logging and monitoring.
- Vulnerability remediation.
- Corrective actions.
- Risk-register updates.
- Control effectiveness.
- Certification readiness.
Stay Connected With Canadian Cyber
Follow Canadian Cyber for practical guidance on ISO 27001 internal audits, incident response, corrective actions, risk management, and certification readiness.
