1. Purpose
The Supply Chain Security Incident Response Procedure defines how the organization identifies, assesses, contains, investigates, responds to, recovers from, and learns from security incidents involving suppliers, third-party services, software components, technology providers, subprocessors, and other external dependencies.
The procedure is intended to reduce the impact of incidents such as:
- Supplier data breaches
- Compromise of a third-party service
- Compromise of supplier accounts
- Malicious or compromised software components
- Vulnerable third-party dependencies
- Supply-chain malware
- Compromised software updates
- Supplier credential compromise
- Unauthorized supplier access
- Third-party cloud outages with security implications
- Subprocessor incidents
- Third-party API compromise
- Compromise of CI/CD or software-delivery dependencies
- Supplier-related ransomware or cyberattacks
The objective is to ensure that a supply-chain incident is handled as an organizational security incident, rather than simply being treated as a supplier-management issue.
2. Core Incident Response Principle
The response lifecycle should follow:
Detect → Validate → Classify → Notify → Contain → Investigate → Eradicate → Recover → Verify → Communicate → Learn → Improve
For supply-chain incidents, an additional dependency chain should be considered:
Supplier → Service → Technology → Information → Access → Dependency → Incident → Impact → Response → Recovery
3. Scope
This procedure applies to incidents involving:
- Cloud providers
- SaaS providers
- IaaS/PaaS providers
- Software suppliers
- Open-source components
- Third-party libraries
- Container images
- Managed service providers
- Security service providers
- Contractors
- Consultants
- Data processors
- Subprocessors
- Payment providers
- Network providers
- Backup providers
- Development partners
- CI/CD providers
- Source-code repositories
- External APIs
- Technology platforms
- Other critical third parties
The procedure applies whether the incident is:
- Detected internally
- Reported by the supplier
- Reported by a customer
- Identified through security monitoring
- Discovered through vulnerability intelligence
- Reported by a regulator or law-enforcement authority
- Discovered through security testing
4. What Constitutes a Supply Chain Security Incident?
Examples include:
Supplier Breach
A supplier confirms unauthorized access to information belonging to the organization or its customers.
Supplier Account Compromise
A supplier administrator account used to access organizational systems is compromised.
Third-Party Software Compromise
A software component used by the organization is found to contain malicious code or has been compromised.
Malicious Update
A trusted software update is discovered to contain malicious or unauthorized functionality.
Vulnerable Dependency
A critical vulnerability is discovered in a third-party component used by production systems.
Supplier Infrastructure Compromise
A supplier’s infrastructure is compromised and could affect organizational systems or information.
Subprocessor Incident
A supplier’s downstream service provider experiences a security incident affecting the organization’s information or service.
Third-Party Availability Incident
A critical supplier outage causes a significant security, operational, or business continuity impact.
5. Incident Sources
Supply-chain incidents may be identified through:
- Supplier notification
- Security monitoring
- SIEM alerts
- EDR alerts
- Cloud security monitoring
- Vulnerability scanning
- SCA tools
- SBOM analysis
- Threat intelligence
- Customer reports
- Employee reports
- Security researchers
- Penetration testing
- Internal audit
- Supplier security review
- External security advisories
- Regulatory notification
- Law-enforcement communication
6. Roles and Responsibilities
Incident Response Lead
- Coordinates the response
- Establishes incident severity
- Assigns actions
- Coordinates internal teams
- Maintains incident records
- Escalates significant incidents
Information Security
- Performs technical assessment
- Investigates security impact
- Coordinates containment
- Reviews evidence
- Supports eradication and recovery
Supplier Owner
- Contacts the supplier
- Obtains supplier incident information
- Coordinates supplier actions
- Tracks supplier commitments
Technology/Application Owner
- Identifies affected systems
- Supports containment
- Validates recovery
- Confirms technical remediation
Legal/Privacy
Where applicable:
- Assesses contractual requirements
- Reviews notification obligations
- Assesses privacy implications
- Coordinates legal/regulatory response
Communications/Customer Support
Where required:
- Coordinates customer communication
- Maintains approved messaging
- Prevents unauthorized disclosure
Executive Management
For significant incidents:
- Provides strategic direction
- Approves major business decisions
- Supports customer/regulatory escalation
7. Incident Severity
The organization should classify incidents according to its established incident-management methodology.
A practical model is:
| Severity | Example |
|---|---|
| Critical | Confirmed supplier compromise affecting critical production systems, sensitive customer information, or major business services |
| High | Significant supplier incident with credible impact to important systems, information, or customers |
| Medium | Limited security impact requiring investigation and corrective action |
| Low | Minor event with limited or no material security impact |
Severity should consider:
- Confidentiality
- Integrity
- Availability
- Customer impact
- Information sensitivity
- Regulatory impact
- Number of affected systems
- Supplier criticality
- Privileged access
- Exploitability
- Business impact
8. Initial Detection and Reporting
Any employee or system identifying a potential supply-chain security incident should report it promptly through the organization’s established incident-reporting channel.
The initial report should capture:
- Date/time detected
- Reporter
- Supplier
- Service
- Technology/component
- Description
- Initial evidence
- Potentially affected systems
- Potentially affected information
- Known supplier notification
- Initial business impact
Do not delay reporting while attempting to determine whether the event is definitely an incident.
9. Initial Triage
The Incident Response Lead should determine:
- Is the event genuine?
- Is a third party involved?
- Which supplier/service is involved?
- Which systems are potentially affected?
- What information may be affected?
- Is production affected?
- Is privileged access involved?
- Is customer data involved?
- Is exploitation ongoing?
- Is immediate containment required?
10. Supply Chain Dependency Mapping
For significant incidents, identify the dependency chain:
Supplier
→ Service
→ Technology
→ Application/System
→ Information
→ Users/Customers
→ Business Process
Example:
Software supplier → Authentication SDK → Customer SaaS application → Customer login → Customer accounts → Customer access
This helps determine the actual scope of the incident.
11. Immediate Containment
Containment should be based on the nature and severity of the incident.
Possible actions include:
- Disable supplier access
- Disable compromised accounts
- Revoke supplier credentials
- Revoke API keys
- Rotate affected credentials
- Block malicious domains/IP addresses
- Isolate affected systems
- Disable vulnerable software components
- Stop deployment pipelines
- Block compromised packages
- Remove compromised container images
- Suspend integrations
- Restrict network access
- Disable affected functionality
- Increase security monitoring
Containment decisions should consider the risk of disrupting critical business services.
12. Supplier Access Containment
If supplier access is suspected to be compromised:
- Identify affected supplier accounts.
- Review authentication logs.
- Disable or suspend accounts where appropriate.
- Revoke sessions/tokens.
- Rotate credentials or secrets where required.
- Review privileged access.
- Review recent supplier activity.
- Preserve relevant evidence.
- Confirm whether access remains necessary.
- Restore access only after appropriate validation.
13. Software Supply Chain Containment
Where a third-party component may be compromised:
- Identify affected versions
- Identify applications using the component
- Identify production deployments
- Compare against SBOM
- Stop further deployments
- Prevent affected version from entering CI/CD
- Remove or isolate the component
- Roll back where appropriate
- Upgrade to a trusted version
- Validate package provenance/integrity
- Review build and deployment logs
For suspected malicious packages, preserve evidence before removal where practical.
14. Investigation
The investigation should establish:
What happened?
Describe the event.
When did it happen?
Establish the relevant timeline.
Which supplier was involved?
Identify the supplier and service.
What was affected?
Identify systems, applications, components, information, and users.
How did it happen?
Identify the suspected attack path or failure mechanism.
Was exploitation successful?
Determine whether unauthorized access or malicious activity occurred.
What information was affected?
Determine whether information was accessed, modified, disclosed, or destroyed.
Is the incident ongoing?
Determine whether containment is sufficient.
15. Evidence Collection
Relevant evidence may include:
- Supplier incident report
- Supplier forensic report
- Contracts
- Security addendum
- Supplier notifications
- Authentication logs
- Cloud logs
- SIEM records
- Application logs
- API logs
- EDR alerts
- Network logs
- Vulnerability reports
- SCA results
- SBOM
- CI/CD logs
- Package metadata
- Deployment records
- Access reviews
- Screenshots
- Emails/communications
- Incident tickets
Evidence should be handled according to the organization’s evidence-retention and investigation requirements.
16. Supplier Coordination
The Supplier Owner should obtain appropriate information from the affected supplier.
Depending on the incident, request:
- Incident summary
- Incident timeline
- Affected service
- Affected systems
- Affected data
- Root cause
- Indicators of compromise
- Containment actions
- Remediation actions
- Customer impact
- Subprocessor involvement
- Security recommendations
- Recovery status
- Independent investigation results where available
Do not assume that the supplier’s initial statement represents the final scope.
The organization should continue validating the impact to its own environment.
17. Contractual and Notification Requirements
Review the applicable:
- Supplier agreement
- Security addendum
- DPA
- SLA
- Incident-notification requirements
- Regulatory requirements
- Customer commitments
- Insurance requirements
Determine:
- Required notification period
- Required notification recipient
- Required incident information
- Evidence requirements
- Cooperation obligations
- Audit/assessment rights
Legal or privacy teams should determine applicable legal notification obligations.
18. Data Breach Assessment
Where personal, customer, confidential, or regulated information may be involved, assess:
- What data was involved?
- Whose data was involved?
- Was data accessed?
- Was data disclosed?
- Was data modified?
- Was data deleted?
- Was encryption applied?
- Were credentials or authentication information involved?
- How many records may be affected?
- Which jurisdictions are involved?
- What contractual or legal obligations apply?
The assessment should distinguish between:
Potential exposure → Confirmed exposure → Unknown
Avoid assuming that a supplier compromise automatically means organizational data was compromised.
19. Customer Impact Assessment
Determine:
- Which customers are affected?
- Which services are affected?
- Is customer data involved?
- Is customer access affected?
- Are contractual SLAs affected?
- Is customer notification required?
- What customer support actions are needed?
Customer communications should be factual and coordinated through authorized personnel.
20. Eradication and Remediation
After containment, eliminate the underlying cause where possible.
Examples:
- Remove compromised software
- Upgrade vulnerable components
- Rebuild affected systems
- Rotate credentials
- Remove unauthorized accounts
- Revoke compromised certificates
- Reconfigure access
- Patch systems
- Remove malicious packages
- Update CI/CD controls
- Change supplier access permissions
- Replace affected supplier
- Apply additional monitoring
21. Recovery
Recovery should include:
- Restore affected services.
- Validate system integrity.
- Confirm security controls are functioning.
- Validate authentication and authorization.
- Verify logging and monitoring.
- Confirm affected dependencies are safe.
- Perform security testing where appropriate.
- Monitor closely after restoration.
Critical services should be restored according to approved business continuity and disaster recovery requirements.
22. Software Component Recovery Example
If a third-party package is found to be compromised:
Identify affected version
↓
Stop deployment
↓
Identify applications using it
↓
Review SBOM
↓
Isolate/remove package
↓
Install trusted version
↓
Rebuild application
↓
Run security testing
↓
Deploy
↓
Verify package integrity
↓
Monitor
23. Cloud Supplier Incident Example
Consider a SaaS company using AWS.
A potential compromise of a privileged cloud account is detected.
Immediate Actions
- Disable/suspend affected credentials
- Revoke active sessions where appropriate
- Review CloudTrail
- Identify affected resources
- Rotate potentially exposed credentials
- Review IAM changes
- Review security-group/network changes
- Review S3/RDS access
- Preserve logs
- Increase monitoring
Investigation
Determine:
- Who accessed the account?
- From where?
- What actions occurred?
- Which resources were accessed?
- Was customer data accessed?
- Were new credentials created?
- Were logging controls modified?
- Was persistence established?
Recovery
- Remove unauthorized access
- Restore secure configurations
- Rotate affected secrets
- Validate infrastructure
- Verify monitoring
- Perform post-incident review
24. Third-Party Vulnerability Incident
Not every vulnerability is a security incident.
For example:
A critical vulnerability is announced in a library, but the organization has confirmed that the affected version is not deployed.
This may be handled through the vulnerability-management process.
However, escalation to incident response may be appropriate if:
- Exploitation is detected
- Compromise is suspected
- Malicious activity is identified
- Unauthorized access occurred
- Security controls were bypassed
- Customer information may be affected
25. Incident Communications
Communication should be:
- Accurate
- Timely
- Authorized
- Evidence-based
- Consistent
- Appropriate to the audience
Potential audiences include:
- Internal management
- Security teams
- Supplier
- Customers
- Regulators
- Contractual partners
- Law enforcement
- Insurers
Do not disclose unverified technical details as confirmed facts.
26. Incident Timeline
Maintain a chronological record.
| Date/Time | Event | Action | Owner | Evidence |
|---|---|---|---|---|
| Incident detected | ||||
| Supplier notified | ||||
| Access disabled | ||||
| Investigation started | ||||
| Containment completed | ||||
| Remediation completed | ||||
| Recovery completed | ||||
| Incident closed |
A reliable timeline is particularly important for significant incidents.
27. Root Cause Analysis
After containment, determine the root cause where reasonably possible.
Possible causes:
- Supplier control failure
- Compromised credentials
- Vulnerable component
- Malicious software update
- Weak access control
- Poor supplier monitoring
- Inadequate segmentation
- Configuration error
- Inadequate change management
- Subprocessor failure
- Insufficient vulnerability management
- Human error
The root cause should distinguish between:
Immediate Cause → Contributing Factors → Control Weakness → Root Cause
28. Corrective and Preventive Actions
Create actions addressing both the incident and the underlying weakness.
| Action | Type | Owner | Target Date | Status |
|---|---|---|---|---|
| Rotate supplier credentials | Corrective | |||
| Upgrade vulnerable component | Corrective | |||
| Improve supplier monitoring | Preventive | |||
| Update contract requirements | Preventive | |||
| Improve access review | Preventive | |||
| Update incident procedure | Preventive |
Actions should be tracked until completion.
29. Supplier Performance Review
After a significant incident, reassess the supplier.
Review:
- Security controls
- Incident handling
- Communication
- Response time
- Root cause
- Corrective actions
- Contract compliance
- Assurance evidence
- Subprocessors
- Residual risk
- Continued business dependency
Possible outcomes include:
- Continue with additional controls
- Increase monitoring
- Require remediation
- Conduct enhanced assessment
- Restrict supplier access
- Change contractual requirements
- Develop alternative supplier
- Exit the supplier relationship
Any decision should follow the organization’s risk-management and supplier-governance processes.
30. Post-Incident Review
After the incident is stabilized, conduct a formal review.
Ask:
- What happened?
- What worked?
- What did not work?
- How quickly was the incident detected?
- How quickly was the supplier contacted?
- Was the supplier cooperative?
- Was the dependency correctly identified?
- Were logs available?
- Were backups/recovery mechanisms effective?
- Were contractual requirements sufficient?
- Were customer notification processes effective?
- Could the incident have been detected earlier?
- What controls need improvement?
31. Lessons Learned
Document:
- Incident cause
- Detection gap
- Response gap
- Supplier-management gap
- Technology gap
- Process gap
- Documentation gap
- Training gap
- Control improvement
- Required policy/procedure changes
Lessons learned should feed into continual improvement.
32. Risk Register Update
Where the incident identifies a material risk:
Incident → Root Cause → Risk → Risk Treatment → Owner → Target Date → Residual Risk
Update relevant:
- Enterprise Risk Register
- Supplier Risk Assessment
- ICT Dependency Register
- Critical Supplier Register
- Vulnerability Register
- Software Dependency Inventory
- Security Exception Register
33. Incident Closure Criteria
A supply-chain incident may be closed when:
- Immediate threat is contained
- Affected systems are secure
- Required remediation is completed or formally tracked
- Customer/regulatory notifications are completed where required
- Evidence has been preserved
- Root cause is documented
- Corrective actions are assigned
- Residual risks are addressed
- Supplier actions are tracked
- Management review is completed where required
Open long-term corrective actions do not necessarily prevent incident closure if they are formally tracked and owned.
34. Evidence Retention
Maintain appropriate evidence such as:
- Incident ticket
- Timeline
- Supplier notifications
- Supplier reports
- Logs
- Screenshots
- Forensic evidence
- Vulnerability reports
- SBOM
- Access records
- Communication records
- Risk assessments
- Customer/regulatory notifications
- Corrective-action records
- Closure approval
Retention should follow the organization’s evidence-retention and legal requirements.
35. Startup-Friendly Response Model
A startup does not need a large incident-response team to implement this process.
A practical model is:
Level 1 — Security/Technology Team
Detect, validate, contain, investigate.
Level 2 — Supplier Owner
Coordinate with the supplier and track supplier actions.
Level 3 — Management
Make significant business decisions and approve escalation.
Level 4 — Legal/Privacy
Engage when contractual, privacy, regulatory, or legal obligations may apply.
External Support
Use specialist forensic, legal, cybersecurity, or communications support when the incident exceeds internal capability.
36. Quick Incident Checklist
| Action | Completed |
|---|---|
| Incident identified | ☐ |
| Supplier identified | ☐ |
| Service identified | ☐ |
| Affected technology identified | ☐ |
| Incident severity assigned | ☐ |
| Incident owner assigned | ☐ |
| Supplier notified/contacted | ☐ |
| Affected systems identified | ☐ |
| Affected information identified | ☐ |
| Supplier access reviewed | ☐ |
| Immediate containment completed | ☐ |
| Credentials/tokens reviewed | ☐ |
| Logs/evidence preserved | ☐ |
| Vulnerability/exploitability assessed | ☐ |
| Customer impact assessed | ☐ |
| Privacy/legal impact assessed | ☐ |
| Required notifications completed | ☐ |
| Root cause identified | ☐ |
| Remediation completed | ☐ |
| Recovery validated | ☐ |
| Supplier reassessment completed | ☐ |
| Risk register updated | ☐ |
| Corrective actions assigned | ☐ |
| Lessons learned completed | ☐ |
| Incident formally closed | ☐ |
37. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Incident Management Procedure | Provides the overall incident-management framework |
| Supplier Risk Assessment | Provides supplier-specific risk information |
| Supply Chain Risk Assessment | Provides broader supply-chain risk context |
| Critical Supplier Register | Identifies critical suppliers |
| ICT Dependency Register | Identifies technology dependencies |
| Critical Technology Dependency Assessment | Assesses critical technology dependencies |
| Supplier Security Requirements | Defines supplier security expectations |
| Supplier Security Agreement | Establishes contractual security obligations |
| Supplier Security Review | Provides periodic supplier assessment |
| Vulnerability Management Procedure | Manages vulnerabilities |
| Third-Party Component Vulnerability Procedure | Handles component-specific vulnerabilities |
| SBOM | Identifies software components |
| Business Continuity Plan | Supports business continuity |
| Disaster Recovery Plan | Supports technical recovery |
| Risk Register | Tracks significant risks |
| Corrective Action Register | Tracks improvement actions |
38. ISO 27001 Connection
Supply-chain incidents should be incorporated into the organization’s broader information-security incident-management and supplier-management processes.
The organization should ensure that:
- Relevant supplier security requirements are established
- Supplier-related incidents can be reported and escalated
- Security events are assessed for incident significance
- Incidents are responded to consistently
- Evidence is retained
- Lessons learned are captured
- Corrective actions are tracked
- Supplier risks are reassessed after significant incidents
- Applicable legal, regulatory, and contractual requirements are addressed
The exact procedure and level of documentation should be proportionate to the organization’s size, risk, technology environment, supplier dependency, and applicable obligations.
39. Final Audit Trail
A strong audit trail should demonstrate:
Incident Detected
↓
Supplier & Dependency Identified
↓
Incident Validated & Classified
↓
Affected Information/Systems Assessed
↓
Supplier Contacted
↓
Containment Performed
↓
Evidence Preserved
↓
Investigation Completed
↓
Root Cause Identified
↓
Remediation Performed
↓
Recovery Validated
↓
Notifications Completed Where Required
↓
Supplier Risk Reassessed
↓
Corrective Actions Assigned
↓
Lessons Learned Captured
↓
Incident Closed & ISMS Improved
Final Principle
A supply-chain security incident should not end when the supplier says “the issue has been resolved.”
The organization should establish:
What happened → What was affected → What the supplier did → What the organization did → Whether the environment is secure → What risk remains → What must change
This ensures that a third-party incident becomes an input to risk management, supplier governance, incident response, and continual improvement, rather than simply becoming a closed supplier ticket.