Credential Breach Response: ISO 27001 Incident Guide

When credentials are compromised — whether through a phishing attack, an infostealer infection, or a database leak — Annex A.16 of ISO 27001:2022 requires a documented, tested, and measurable incident response process. Password-related incidents account for the majority of reported security breaches: the 2026 Verizon DBIR found that 74% of all breaches involved credential theft or misuse.

This guide covers the full ISO 27001 incident management lifecycle for credential breaches, from detection through containment, eradication, recovery, and post-incident review. Based on our work with UK enterprises managing ISO 27001-certified credential systems, these are the specific procedures that auditors expect to see.

Control 6.8: Information Security Incident Reporting

While part of Annex A.6 (Organisational Controls), Control 6.8 is the trigger mechanism for A.16. Every employee must know how to report a suspected credential compromise. The key requirements are:

• Clear reporting channels — email, phone hotline, and (for larger organisations) a dedicated incident management platform. The process must be documented in the Information Security Policy and accessible to all staff.
• Reporting timelines — employees must report suspected credential compromise within a defined timeframe (typically 1 hour for critical systems, 4 hours for standard systems)
• Non-punitive culture — employees must not fear reprisal for reporting incidents. This is critical because delayed reporting is the leading cause of credential breach escalation (IBM's 2026 Cost of a Breach study found that breaches contained within 24 hours cost an average of 52% less than those taking a week to contain).
• Training and awareness — Control 6.3 (Information Security Awareness) requires annual training covering credential compromise recognition and reporting procedures

A.16.1.2: Incident Response Planning for Credential Breaches

Annex A.16.1.2 requires a documented incident response plan specifically covering credential security events. The plan must address:

• Definition of a credential incident: What constitutes a reportable event? Examples include: confirmed credential leak on a paste site, brute-force attack detected, lost hardware token, or evidence of credential harvesting malware.
• Severity classification: A simple tiered system (Low / Medium / High / Critical) based on: number of affected users, sensitivity of systems accessed, and evidence of data exfiltration.
• Escalation paths: Who is notified at each severity level? Critical incidents (C-suite credentials, database admin passwords) must have documented escalation to senior management and legal counsel within 30 minutes.
• Containment strategies: Pre-defined playbooks for each severity level — immediate password rotation, account suspension, network isolation, forensic imaging.

A.16.1.5: Response to Credential Incidents

Control A.16.1.5 is the operational response requirement. When a credential incident is confirmed, your organisation must execute the following steps:

1. Immediate containment (first 60 minutes): Disable compromised accounts. Revoke active sessions and tokens. Place affected systems in maintenance mode if they are externally accessible. Document the exact time of detection and containment.
2. Forensic preservation: Capture system logs, authentication logs, network traffic captures, and affected credential databases. Preserve in write-once media or cloud storage with immutability enabled. This evidence must be retained for the duration of any regulatory investigation (typically 12+ months).
3. Credential remediation: Force password rotation for ALL affected accounts, not just the directly compromised ones. If the breach involved an identity provider, rotate the IdP master credentials and all application-specific secrets.
4. User notification: Notify affected users within the timeframe defined in your incident response plan (typically 24-48 hours for High severity, 72 hours under GDPR Article 33 for personal data breaches).
5. Root cause analysis: Determine how the compromise occurred. Common root causes include: phishing, weak password reuse, unpatched vulnerability, or insider threat. Each root cause must map to a corrective action.

The CREST framework for incident response recommends documenting each of these steps with timestamps to demonstrate a measurable response timeline. Your ISO auditor will look for evidence of time-to-contain (TTC) and time-to-eradicate (TTE) metrics.

A.16.1.6: Learning from Credential Incidents

Control A.16.1.6 is arguably the most valuable requirement — it turns incidents into improvement opportunities. After resolving a credential breach, your organisation must:

• Document lessons learned: A formal report covering what went well, what went wrong, and what must change. The report should be shared with the security team and relevant management.
• Update risk assessment: The incident must inform your organisation's risk register. If the breach exploited a gap in multi-factor authentication, the risk assessment for authentication controls must be updated.
• Update policies and procedures: If the incident revealed a gap in the credential management policy (e.g., no procedure for rotating service account passwords), the policy must be amended within 30 days.
• Train staff: If the incident involved user error (e.g., falling for a phishing campaign), additional awareness training must be delivered to the affected team within 2 weeks.

The ISO 27001 auditor will expect to see evidence that lessons learned from previous incidents have been actioned. This is often the most scrutinised part of an Annex A.16 audit — a pattern of repeated incidents with no documented corrective action is a major non-conformity.

A.16.1.7: Collection of Evidence for Credential Incidents

Control A.16.1.7 requires organisations to define and document procedures for handling evidence during a credential breach investigation. The key requirements are:

• Chain of custody: Every piece of evidence (log files, database exports, network captures) must have a documented chain of custody showing who collected it, when, and where it is stored.
• Admissible evidence handling: If the incident may lead to legal action or regulatory investigation, evidence must be collected in a manner that preserves its integrity. This typically means write-blocked forensic copies, hash-verified collections, and tamper-evident storage.
• Data protection compliance: Evidence collection must comply with UK GDPR and DPA 2018. Personal data in credential databases must be handled according to your organisation's data protection policy, even during an active breach investigation.

Integrating with Other ISO 27001 Controls

Annex A.16 does not operate in isolation. Effective credential breach response depends on integration with:

• A.12.4 (Logging and Monitoring): Without adequate logging, you cannot detect a credential breach. Your SIEM must capture authentication events, password changes, and privileged account usage.
• A.9 (Access Control): Post-breach, compromised access rights must be promptly revoked and re-certified. This is where a Privileged Access Management (PAM) system becomes essential.
• A.10 (Cryptography): A credential breach often reveals weaknesses in cryptographic controls. If password hashes were stored using a weak algorithm, this must feed back into the A.10 cryptographic policy review.
• A.18 (Compliance): If the breach involves personal data, GDPR Article 33 notification requirements apply. Your incident response plan must include the DPO contact and ICO notification procedure.

For a deeper understanding of how ISO 27001 controls interconnect for credential security, read our NIST vs ISO 27001 comparison and our SOC 2 Password Requirements guide for the broader audit perspective.