1. Purpose

The Credential Compromise Response Procedure defines how the organization identifies, contains, investigates, remediates, and closes incidents involving compromised, exposed, stolen, misused, or potentially compromised authentication credentials.

The procedure is intended to reduce the risk of:

• Unauthorized account access
• Customer-data exposure
• Privilege escalation
• Cloud-resource compromise
• Source-code compromise
• Financial fraud
• Data theft
• Further credential compromise
• Business disruption

Core Principle

Detect → Report → Contain → Revoke → Investigate → Assess → Recover → Verify → Record → Improve

---

2. Scope

This procedure applies to compromise involving:

• Employee credentials
• Contractor credentials
• Third-party credentials
• Privileged accounts
• Administrator accounts
• Cloud credentials
• Passwords
• MFA factors
• API keys
• Access tokens
• Refresh tokens
• OAuth credentials
• SSH keys
• Service-account credentials
• Database credentials
• Certificates/private keys
• CI/CD credentials
• VPN credentials
• Customer-system credentials
• Application secrets

It applies to systems including:

• Identity Provider/SSO
• Email
• SaaS applications
• AWS/Azure/GCP
• Source-code repositories
• CI/CD platforms
• Databases
• VPN
• Security platforms
• Customer environments
• Corporate applications

---

3. What Is Credential Compromise?

Credential compromise occurs when an authentication credential or authentication factor has been:

• Stolen
• Disclosed
• Exposed
• Phished
• Leaked
• Accidentally shared
• Published
• Uploaded to a repository
• Captured by malware
• Used by an unauthorized person
• Suspected of being misused

A credential does not need to be proven stolen before protective action is taken.

Where there is credible evidence that a credential may have been exposed, the organization should treat it as potentially compromised until assessed.

---

4. Examples of Credential Compromise

Examples include:

User Credentials

• Employee enters password into a phishing website.
• Password is accidentally shared.
• Credentials appear in an unauthorized location.
• Suspicious login occurs.

Cloud Credentials

• AWS access key is exposed in GitHub.
• Cloud administrator credentials are stolen.
• An attacker obtains an AWS session token.

Application Credentials

• API key is committed to source code.
• Database password appears in application logs.
• OAuth token is accidentally shared.

Authentication Factors

• MFA device is stolen.
• Security key is lost.
• Recovery codes are exposed.
• Unauthorized MFA factor is added to an account.

---

5. Severity Classification

Credential compromise should be classified according to organizational risk.

Severity	Example
Critical	Production administrator credential compromised or actively misused
High	Privileged credential exposed or customer-data access potentially compromised
Medium	Standard employee credential potentially exposed
Low	Credential exposure with strong controls and no meaningful access identified

Severity should consider:

• Account privilege
• Information accessible
• Customer impact
• Production access
• Cloud access
• Financial impact
• Data sensitivity
• Exposure duration
• Evidence of misuse
• Existing security controls

These categories are organizational examples and should be defined in accordance with the organization’s incident-management methodology.

---

6. Detection Sources

Credential compromise may be identified through:

• User reports
• Phishing reports
• SIEM alerts
• Identity-provider alerts
• EDR alerts
• Cloud security monitoring
• AWS CloudTrail
• Impossible-travel alerts
• Unusual login activity
• Failed authentication attempts
• MFA alerts
• Password-leak notifications
• Secret-scanning tools
• Git repository monitoring
• Vulnerability assessments
• Security testing
• Customer notification
• Supplier notification
• Threat intelligence
• Security incident investigation

---

7. Reporting

Users and personnel must promptly report suspected credential compromise.

Examples:

• “I entered my password on a suspicious website.”
• “My phone containing MFA was stolen.”
• “I accidentally committed an API key to Git.”
• “I received an unexpected MFA approval request.”
• “I believe my AWS credentials were exposed.”

Possible reporting channels include:

• Security team
• IT/help desk
• Incident-response channel
• Security email
• Emergency contact
• Incident-management system

Users should not attempt to investigate the compromise themselves if doing so could destroy evidence or increase risk.

---

8. Initial Response

Upon receiving a suspected credential-compromise report:

1. Create or update an incident record.
2. Identify the affected identity/credential.
3. Determine the credential type.
4. Determine the affected system.
5. Determine whether the credential is still active.
6. Determine the privilege level.
7. Assess whether active misuse is occurring.
8. Initiate containment.
9. Preserve relevant evidence.

For high-risk credentials, containment should begin immediately.

---

9. Immediate Containment

Containment should be proportionate to the risk.

Possible actions include:

• Disable the account.
• Revoke the credential.
• Reset the password.
• Revoke active sessions.
• Revoke refresh tokens.
• Revoke OAuth grants.
• Disable API keys.
• Rotate secrets.
• Remove SSH keys.
• Disable compromised MFA factors.
• Restrict cloud access.
• Temporarily block suspicious activity.
• Disable compromised service accounts.
• Restrict network access.

Important

If active compromise is suspected, do not wait for a complete investigation before taking reasonable containment action.

---

10. Credential Revocation

The compromised credential should be revoked or invalidated where technically possible.

Examples:

Credential	Response
Password	Reset
AWS Access Key	Disable/revoke
API Key	Revoke and replace
OAuth Token	Revoke
Refresh Token	Revoke
SSH Key	Remove/revoke
MFA Factor	Disable/re-enroll
Session	Terminate
Certificate	Revoke/replace where required
Database Credential	Rotate
CI/CD Secret	Revoke/rotate

The organization should confirm that the old credential is no longer usable where technically feasible.

---

11. Password Compromise

If a password is suspected to be compromised:

1. Treat the password as exposed.
2. Reset the password.
3. Revoke active sessions where appropriate.
4. Review MFA status.
5. Review recent authentication activity.
6. Check for unauthorized account changes.
7. Determine whether the password was reused elsewhere.
8. Assess other affected systems.
9. Record the response.

Users should never disclose their previous password to IT or Security.

---

12. MFA Compromise

MFA compromise may involve:

• Stolen security key
• Lost authenticator device
• MFA fatigue attack
• Unauthorized MFA factor
• Exposed recovery codes
• SIM-related compromise
• Compromised authenticator application

Response may include:

• Disable compromised factor.
• Revoke sessions.
• Re-register MFA.
• Review account activity.
• Check for unauthorized factor additions.
• Assess whether the primary password is also compromised.
• Escalate if suspicious activity is identified.

---

13. MFA Fatigue

If a user receives unexpected MFA requests:

Do Not Approve → Reject → Report → Investigate

Repeated unexpected MFA prompts may indicate an attacker already possesses a valid username/password combination or is attempting to manipulate the user into approving access.

---

14. Phishing Credential Compromise

If credentials were entered into a suspected phishing site:

1. Report immediately.
2. Treat credentials as compromised.
3. Reset the password.
4. Revoke active sessions.
5. Verify MFA.
6. Review recent login activity.
7. Review account changes.
8. Check connected applications/tokens.
9. Assess other systems where the same credential may have been used.
10. Create an incident record.
11. Provide security awareness follow-up.

---

15. AWS Credential Compromise

For AWS credential compromise:

Immediate Actions

• Identify affected IAM identity/credential.
• Disable compromised access keys where applicable.
• Revoke or restrict access.
• Terminate/revoke sessions where appropriate.
• Review IAM changes.
• Review CloudTrail activity.
• Review creation/modification of resources.
• Review security-group/network changes.
• Review S3 access.
• Review database access.
• Review unusual API activity.
• Assess whether customer data was accessed.

Response Flow

Detect

→ Disable/Revoke

→ Review CloudTrail

→ Identify Actions

→ Assess Impact

→ Remediate

→ Replace Credential if Required

→ Verify

→ Close

Human users should preferably use centralized identity/SSO mechanisms and temporary role-based access rather than long-lived access keys.

---

16. Cloud Administrator Credential Compromise

If a cloud administrator credential is compromised:

• Treat the event as high risk.
• Immediately contain the identity.
• Review active sessions.
• Review privileged changes.
• Review IAM changes.
• Review newly created users/roles/keys.
• Review security-control changes.
• Review network changes.
• Review data access.
• Review persistence mechanisms.
• Assess whether additional credentials were created.
• Escalate to incident response/security leadership.

---

17. API Key Compromise

If an API key is exposed:

Detect → Identify Usage → Disable/Revoke → Generate Replacement → Update Application → Test → Verify Old Key Disabled → Record

Examples of exposure:

• Git repository
• Public website
• Error message
• Log file
• Ticket
• Chat message
• Email
• Developer workstation

Secret-scanning tools should be used where appropriate.

---

18. Secrets in Source Code

If a secret is committed to a source repository:

1. Treat the secret as compromised.
2. Revoke/rotate it immediately.
3. Identify systems using the secret.
4. Update applications securely.
5. Remove the secret from active source code.
6. Assess repository exposure and history.
7. Review access/logs where appropriate.
8. Verify the old secret is unusable.
9. Record the incident.

Simply deleting the secret from the latest source-code version does not necessarily eliminate historical exposure.

---

19. SSH Key Compromise

If an SSH private key is compromised:

• Remove the associated public key from authorized systems.
• Revoke access.
• Generate a new key pair.
• Protect the new private key.
• Review authentication logs.
• Check for unauthorized activity.
• Update affected systems.
• Verify access.
• Record the incident.

---

20. Service Account Compromise

Service-account compromise requires consideration of application dependencies.

Process:

1. Identify the service account.
2. Identify systems using it.
3. Determine privileges.
4. Assess business impact.
5. Disable or rotate credentials.
6. Update dependent applications.
7. Test services.
8. Review logs.
9. Search for unauthorized activity.
10. Verify the old credential is invalid.
11. Record the response.

Where practical, use short-lived credentials or workload identities instead of static credentials.

---

21. Privileged Credential Compromise

Privileged credentials require immediate escalation.

Examples:

• AWS Administrator
• Identity Provider Administrator
• Database Administrator
• Security Administrator
• CI/CD Administrator
• Network Administrator

Response may include:

• Immediate credential revocation
• Session termination
• MFA review
• Privileged activity investigation
• IAM review
• Creation of replacement credentials
• Review of changes made by the account
• Review of other privileged accounts
• Threat hunting
• Incident escalation

---

22. Investigation

After containment, investigate:

Identity

• Who owns the credential?
• What account was affected?
• What role does it have?
• What systems can it access?

Credential

• What type of credential was compromised?
• How was it exposed?
• When was it exposed?
• How long could it have been used?

Activity

• Were unauthorized logins detected?
• Were permissions changed?
• Were new accounts created?
• Were tokens created?
• Were files accessed?
• Was data downloaded?
• Were cloud resources changed?

Impact

• Customer data
• Personal data
• Financial information
• Source code
• Security information
• Production systems
• Intellectual property
• Business operations

---

23. Evidence Preservation

Relevant evidence may include:

• Authentication logs
• SSO logs
• Cloud logs
• AWS CloudTrail
• Application logs
• VPN logs
• EDR alerts
• SIEM events
• Git audit logs
• API logs
• Email security records
• MFA events
• Access changes
• IAM changes
• Incident communications
• Threat-intelligence information

Evidence should be preserved according to the organization’s incident-response and evidence-handling requirements.

---

24. Account Activity Review

For potentially compromised accounts, review appropriate activity for the relevant period.

Look for:

• Unusual login locations
• Unusual devices
• Unusual times
• Failed login attempts
• Successful suspicious logins
• MFA changes
• Password changes
• Privilege changes
• New API keys
• New OAuth applications
• New SSH keys
• Data downloads
• Cloud-resource changes
• Security-control changes

The review period should be based on the circumstances and available evidence.

---

25. Persistence Check

For higher-risk compromises, assess whether an attacker may have established continued access.

Examples:

• New user accounts
• New administrator roles
• New access keys
• New SSH keys
• OAuth applications
• API tokens
• Scheduled jobs
• CI/CD credentials
• Backdoor accounts
• Modified security rules

This is particularly important for privileged and cloud compromises.

---

26. Impact Assessment

The organization should determine:

• What systems were accessible?
• What information was accessible?
• Was customer data involved?
• Was personal data involved?
• Was restricted information involved?
• Was production infrastructure involved?
• Was unauthorized activity confirmed?
• Was data accessed or exfiltrated?
• Was business operation affected?

The result should be documented in the incident record.

---

27. Data Breach Assessment

Credential compromise does not automatically mean that a data breach occurred.

The organization should determine whether:

• Unauthorized access actually occurred.
• Data was accessed.
• Data was downloaded or disclosed.
• Personal data was involved.
• Customer information was involved.
• Contractual obligations were triggered.
• Regulatory notification requirements apply.

Where legal, privacy, contractual, or regulatory requirements may apply, the appropriate Legal/Privacy/Compliance function should be involved.

---

28. Customer Impact Assessment

If customer systems or customer information may have been affected:

• Identify affected customers.
• Determine information involved.
• Determine whether access occurred.
• Review contractual notification requirements.
• Coordinate with Legal/Privacy/Account Management.
• Preserve evidence.
• Document communications and decisions.

Customer notification should follow applicable contractual and legal requirements.

---

29. Regulatory Assessment

Depending on the organization’s activities and jurisdiction, credential compromise may trigger regulatory or contractual considerations.

The organization should assess:

• Applicable laws
• Regulatory requirements
• Customer contracts
• Data-processing agreements
• Security commitments
• Notification timelines
• Evidence requirements

Not every credential compromise requires regulatory notification.

---

30. Credential Replacement

After containment and investigation:

• Generate replacement credentials securely.
• Apply least privilege.
• Enable appropriate MFA.
• Store secrets in approved systems.
• Update applications securely.
• Test the replacement.
• Confirm old credentials are invalid.
• Update relevant records.

---

31. Recovery

Recovery may include:

• Restoring legitimate user access.
• Re-enabling an account.
• Re-establishing MFA.
• Replacing credentials.
• Restoring application functionality.
• Reconfiguring cloud permissions.
• Restoring security settings.
• Removing unauthorized changes.
• Revalidating access controls.

Recovery should not restore compromised configurations or credentials.

---

32. Verification

Before closing the response:

• Confirm compromised credentials are revoked.
• Confirm replacement credentials work.
• Confirm MFA is properly configured.
• Confirm unauthorized accounts/factors are removed.
• Confirm suspicious sessions are terminated.
• Confirm unauthorized changes are reversed.
• Confirm affected applications operate correctly.
• Confirm required security controls remain active.
• Confirm monitoring is functioning.

---

33. Risk Register Update

Credential compromise may identify a broader information-security risk.

Examples:

• Weak authentication
• Excessive privileges
• Insufficient MFA
• Inadequate secret management
• Weak phishing resistance
• Excessive long-lived credentials
• Poor access monitoring
• Inadequate employee awareness

Where appropriate, update the:

• Risk Register
• Risk Treatment Plan
• Security controls
• Authentication requirements
• Awareness program
• Access-control processes

---

34. Lessons Learned

After significant credential compromises, conduct a post-incident review.

Questions may include:

• How was the credential compromised?
• Why was it possible?
• Was detection timely?
• Was containment effective?
• Were credentials properly protected?
• Was MFA effective?
• Was privilege excessive?
• Could automation have reduced response time?
• Were users adequately trained?
• Were logging and monitoring sufficient?
• What should change?

---

35. Corrective Actions

Corrective actions may include:

• Enable MFA
• Strengthen authentication
• Remove excessive access
• Implement SSO
• Reduce long-lived credentials
• Implement secret scanning
• Improve password-manager adoption
• Improve phishing awareness
• Improve logging
• Improve alerting
• Rotate credentials
• Implement privileged-access controls
• Improve cloud monitoring
• Update procedures
• Conduct targeted training

Each action should have:

• Action
• Owner
• Priority
• Due date
• Status
• Verification evidence

---

36. Credential Compromise Incident Record

The incident record may include:

Field	Description
Incident ID	Unique reference
Date/Time Detected	Detection
Reported By	Reporter
Affected User/Account	Identity
Credential Type	Password/API key/etc.
System	Affected system
Privilege Level	Standard/Privileged
Detection Source	User/log/alert/etc.
Exposure Method	Phishing/leak/etc.
Initial Severity	Risk classification
Containment Action	Action taken
Credential Revoked	Yes/No
Sessions Revoked	Yes/No
MFA Reconfigured	Yes/No
Investigation	Summary
Unauthorized Activity	Yes/No/Unknown
Data Impact	Summary
Customer Impact	Summary
Regulatory Assessment	Status
Root Cause	Summary
Corrective Actions	Actions
Risk Register	Related risk
Evidence	References
Closure Date	Date
Approved By	Reviewer

Actual passwords, tokens, API keys, private keys, recovery codes, or other secrets must never be stored in the incident record.

---

37. Communication

Communication should be controlled according to the severity and circumstances.

Potential stakeholders include:

• User
• IT
• Security
• ISMS Manager
• Management
• System Owner
• Data Owner
• Legal/Privacy
• Customer Account Manager
• Customer
• Supplier
• Regulator
• Law enforcement where appropriate

Only authorized personnel should communicate externally about security incidents.

---

38. Third-Party Credential Compromise

If a third-party credential is compromised:

1. Notify the internal sponsor.
2. Identify affected systems.
3. Revoke or disable access.
4. Assess third-party activity.
5. Review logs.
6. Determine customer/data impact.
7. Review contractual requirements.
8. Coordinate with the supplier.
9. Replace credentials where necessary.
10. Verify access removal.
11. Record the incident.

---

39. Credential Compromise Testing

The organization may periodically test its ability to respond to credential compromise.

Examples:

• Phishing simulations
• Tabletop exercises
• Credential-leak simulations
• Secret-scanning exercises
• Cloud credential exposure drills
• Incident-response exercises

Testing should focus on:

Detection → Containment → Revocation → Investigation → Recovery → Verification

---

40. Roles and Responsibilities

Role	Responsibility
User	Immediately report suspected compromise
IT/Help Desk	Perform initial account containment/reset
Security Team	Lead investigation and response
IAM Administrator	Revoke/reset identities and authentication
Cloud Team	Contain cloud credentials and investigate cloud activity
System Owner	Support system-level investigation
Data Owner	Assess information impact
Legal/Privacy	Assess legal/privacy obligations
Management	Provide escalation and business decisions
ISMS Manager	Ensure process, records, risk, and corrective actions
Internal Audit	Independently assess effectiveness

---

41. Evidence

Potential evidence includes:

• Incident report
• User notification
• Authentication logs
• SSO logs
• MFA logs
• AWS CloudTrail
• IAM records
• API logs
• Git audit logs
• EDR/SIEM alerts
• Credential revocation records
• Password reset records
• Token/session revocation
• Secret rotation records
• Investigation notes
• Data-impact assessment
• Customer communications
• Regulatory assessment
• Corrective-action records
• Risk-register updates
• Lessons-learned report
• Closure approval

---

42. Metrics

The organization may monitor:

• Number of credential-compromise incidents
• Time to detect
• Time to contain
• Time to revoke credentials
• Time to recover
• Number of privileged credential incidents
• Number of exposed API keys
• Number of secrets detected in repositories
• MFA-related incidents
• Phishing-related credential compromises
• Repeat incidents
• Percentage of incidents with completed lessons learned

---

43. Startup-Friendly Credential Compromise Model

A startup can implement the following minimum response:

Standard User Credential

Report → Verify → Reset → Revoke Sessions → Check MFA → Review Activity → Record

Phishing

Report → Reset → Revoke Sessions → MFA Check → Investigate → Record

AWS/API Credential

Detect → Disable/Revoke → Investigate Logs → Replace → Test → Verify → Record

Privileged Credential

Immediate Containment → Revoke → Investigate → Review Privileged Activity → Replace → Verify → Escalate

Confirmed Data Impact

Contain → Investigate → Assess Data Impact → Legal/Privacy Review → Notify Where Required → Remediate → Document

---

44. Quick Audit Checklist

Detection & Reporting

• Compromise identified
• Incident recorded
• Affected identity identified
• Credential type identified
• Severity assessed

Containment

• Credential revoked/reset
• Sessions terminated where required
• Tokens revoked
• MFA reviewed
• Privileged access contained
• Cloud access reviewed

Investigation

• Authentication logs reviewed
• Relevant system activity reviewed
• Unauthorized activity assessed
• Persistence checked where appropriate
• Data access assessed
• Customer impact assessed

Recovery

• Replacement credential created
• Old credential invalidated
• MFA verified
• Access verified
• Security controls restored

Closure

• Corrective actions identified
• Risk register reviewed
• Lessons learned completed
• Evidence retained
• Incident formally closed

---

45. Relationship with Other ISMS Documents

This procedure connects with:

• Authentication & Password Policy
• Credential Reset Procedure
• Identity Management Policy
• User Account Management Procedure
• User Onboarding & Authentication Procedure
• Joiner-Mover-Leaver Procedure
• Identity Register
• Identity Review Checklist
• Access Control Policy
• Access Revocation Checklist
• Privileged Identity Management Procedure
• Privileged Access Register
• Secrets Management Procedure
• PKI & Key Management Procedure
• Incident Response Plan
• Security Incident Management Procedure
• Data Breach Response Procedure
• Threat Intelligence Procedure
• Threat Intelligence Register
• Risk Assessment Procedure
• Corrective Action Process
• Security Awareness Training

Control Chain

Credential

→ Exposure/Compromise

→ Detection

→ Containment

→ Revocation

→ Investigation

→ Impact Assessment

→ Recovery

→ Verification

→ Risk/Control Improvement

→ Evidence

---

46. ISO 27001 Connection

This procedure supports applicable ISO/IEC 27001 requirements and controls relating to:

• Identity management
• Authentication information
• Access rights
• Secure authentication
• Privileged access
• Access control
• Logging and monitoring
• Incident management
• Information security event handling
• Information security incident response
• Continual improvement

The exact controls applicable to the organization should be determined through its risk assessment and Statement of Applicability (SoA).

---

47. Final Audit Trail

For every significant credential compromise, the organization should be able to demonstrate:

How was the compromise detected?

→ Who reported it?

→ Which identity or credential was affected?

→ What systems could it access?

→ What was the privilege level?

→ How was the credential contained?

→ Was the credential revoked or rotated?

→ Were sessions, tokens, MFA factors, or keys addressed?

→ Was suspicious activity investigated?

→ Was unauthorized access confirmed?

→ Was customer or personal data potentially affected?

→ Were legal, regulatory, or contractual requirements assessed?

→ Was the credential securely replaced?

→ Was access verified?

→ Were risks and corrective actions identified?

→ Was the incident formally closed with evidence?

Final Principle

A compromised credential should never be treated as simply a password-reset request. The organization must assume potential unauthorized access, contain the credential, investigate relevant activity, assess business and data impact, securely recover access, verify that the threat has been removed, and use the lessons learned to strengthen authentication and access controls.