Incident Management & Response
239 records. Direct records match this topic; context records explain their connections.
Read the first JSON page · Data retrieval guide
Mappings may provide partial coverage. Read mapping properties, residual requirements and source notes before relying on a connection.
control · Context
A004 — Protect IP & trade secrets
Protect IP & trade secrets
control · Context
A005 — Prevent cross-customer data exposure
Prevent cross-customer data exposure
control · Context
A006 — Prevent PII leakage
Prevent PII leakage
control · Context
B008 — Protect AI system deployment environment
Protect AI system deployment environment
control · Context
E009 — Monitor third-party access
Monitor third-party access
control · Context
CCPA-1798.150 — Reasonable security procedures; private right of action for breaches
Reasonable security procedures; private right of action for breaches
control · Context
BAI03 — Managed Solutions Identification and Build
Managed Solutions Identification and Build
control · Context
DSS02 — Managed Service Requests and Incidents
Managed Service Requests and Incidents
control · Context
DSS03 — Managed Problems
Managed Problems
control · Context
DSS05 — Managed Security Services
Managed Security Services
control · Context
P17 — The organization evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate.
The organization evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate.
control · Context
DORA-Art17-23 — ICT-related incident management, classification and reporting
ICT-related incident management, classification and reporting
control · Context
AIA-Art15 — Accuracy, robustness and cybersecurity (high-risk)
Accuracy, robustness and cybersecurity (high-risk)
control · Context
GDPR-Art33 — Notification of a personal data breach to the supervisory authority
Notification of a personal data breach to the supervisory authority
control · Context
GDPR-Art34 — Communication of a breach to the data subject
Communication of a breach to the data subject
control · Context
GDPR-Art44-49 — International transfers of personal data
International transfers of personal data
control · Context
GDPR-Art9 — Processing of special categories of data
Processing of special categories of data
control · Context
HIPAA-164.312(b) — Audit controls recording activity in systems with ePHI
Audit controls recording activity in systems with ePHI
control · Context
HIPAA-164.312(c) — Integrity controls protecting ePHI from improper alteration or destruction
Integrity controls protecting ePHI from improper alteration or destruction
control · Context
HIPAA-164.400-414 — Breach notification to individuals, media, and HHS (incl. business-associate duties)
Breach notification to individuals, media, and HHS (incl. business-associate duties)
control · Context
HIPAA-164.514 — De-identification of PHI and limited data sets
De-identification of PHI and limited data sets
control · Context
A.5.24 — Information security incident management planning and preparation
Information security incident management planning and preparation
control · Context
A.5.25 — Assessment and decision on information security events
Assessment and decision on information security events
control · Context
A.5.26 — Response to information security incidents
Response to information security incidents
control · Context
A.5.27 — Learning from information security incidents
Learning from information security incidents
control · Context
A.5.28 — Collection of evidence
Collection of evidence
control · Context
A.5.34 — Privacy and protection of personal identifiable information (PII)
Privacy and protection of personal identifiable information (PII)
control · Context
A.6.8 — Information security event reporting
Information security event reporting
control · Context
A.8.10 — Information deletion
Information deletion
control · Context
A.8.11 — Data masking
Data masking
control · Context
A.8.12 — Data leakage prevention
Data leakage prevention
control · Context
A.8.13 — Information backup
Information backup
control · Context
A.8.15 — Logging
Logging
control · Context
A.8.16 — Monitoring activities
Monitoring activities
control · Context
A.8.17 — Clock synchronization
Clock synchronization
control · Context
A.8.22 — Segregation of networks
Segregation of networks
control · Context
A.8.27 — Secure system architecture and engineering principles
Secure system architecture and engineering principles
control · Context
A.8.28 — Secure coding
Secure coding
control · Context
A.8.6 — Capacity management
Capacity management
control · Context
AC-4 — Information Flow Enforcement
Information Flow Enforcement
control · Context
AU-11 — Audit Record Retention
Audit Record Retention
control · Context
AU-12 — Audit Record Generation
Audit Record Generation
control · Context
AU-14 — Session Audit
Session Audit
control · Context
AU-16 — Cross-organizational Audit Logging
Cross-organizational Audit Logging
control · Context
AU-2 — Event Logging
Event Logging
control · Context
AU-3 — Content of Audit Records
Content of Audit Records
control · Context
AU-4 — Audit Log Storage Capacity
Audit Log Storage Capacity
control · Context
AU-5 — Response to Audit Logging Process Failures
Response to Audit Logging Process Failures
control · Context
AU-6 — Audit Record Review, Analysis, and Reporting
Audit Record Review, Analysis, and Reporting
control · Context
AU-7 — Audit Record Reduction and Report Generation
Audit Record Reduction and Report Generation
control · Context
AU-8 — Time Stamps
Time Stamps
control · Context
AU-9 — Protection of Audit Information
Protection of Audit Information
control · Context
CA-7 — Continuous Monitoring
Continuous Monitoring
control · Context
CP-10 — System Recovery and Reconstitution
System Recovery and Reconstitution
control · Context
CP-9 — System Backup
System Backup
control · Context
IR-2 — Incident Response Training
Incident Response Training
control · Context
IR-3 — Incident Response Testing
Incident Response Testing
control · Context
IR-4 — Incident Handling
Incident Handling
control · Context
IR-5 — Incident Monitoring
Incident Monitoring
control · Context
IR-6 — Incident Reporting
Incident Reporting
control · Context
IR-7 — Incident Response Assistance
Incident Response Assistance
control · Context
IR-8 — Incident Response Plan
Incident Response Plan
control · Context
IR-9 — Information Spillage Response
Information Spillage Response
control · Context
MP-4 — Media Storage
Media Storage
control · Context
MP-5 — Media Transport
Media Transport
control · Context
MP-8 — Media Downgrading
Media Downgrading
control · Context
PT-7 — Specific Categories of Personally Identifiable Information
Specific Categories of Personally Identifiable Information
control · Context
SA-17 — Developer Security and Privacy Architecture and Design
Developer Security and Privacy Architecture and Design
control · Context
SA-8 — Security and Privacy Engineering Principles
Security and Privacy Engineering Principles
control · Context
SC-2 — Separation of System and User Functionality
Separation of System and User Functionality
control · Context
SC-3 — Security Function Isolation
Security Function Isolation
control · Context
SC-32 — System Partitioning
System Partitioning
control · Context
SC-34 — Non-modifiable Executable Programs
Non-modifiable Executable Programs
control · Context
SC-39 — Process Isolation
Process Isolation
control · Context
SC-49 — Hardware-enforced Separation and Policy Enforcement
Hardware-enforced Separation and Policy Enforcement
control · Context
SC-50 — Software-enforced Separation and Policy Enforcement
Software-enforced Separation and Policy Enforcement
control · Context
SC-51 — Hardware-based Protection
Hardware-based Protection
control · Context
SC-7 — Boundary Protection
Boundary Protection
control · Context
SI-10 — Information Input Validation
Information Input Validation
control · Context
SI-12 — Information Management and Retention
Information Management and Retention
control · Context
SI-19 — De-identification
De-identification
control · Context
SI-4 — System Monitoring
System Monitoring
control · Context
NIST-AGI-05 — Verifiable agent action logs and authorization traceability
The paper asks how agent actions and intent can be logged in a verifiable, tamper-resistant way and traced back to human authorization; visibility includes actions, data, and outcomes.
control · Context
NIST-AGI-07 — Prompt provenance and data-flow tracking
The proposed project explores tracking the provenance of user prompts and input data so that risk assessments and policies can take those sources into account when deciding whether an agent may act.
control · Context
NIST-TEVV-04 — Test for disclosure of confidential information
Appendix B includes confidentiality attacks that test whether an AI system reveals confidential information or internal functionality, including user information and system-prompt leakage.
control · Context
DE.AE-02 — Adverse Event Analysis: Potentially adverse events are analyzed to better understand associated activities
Adverse Event Analysis: Potentially adverse events are analyzed to better understand associated activities
control · Context
DE.AE-03 — Adverse Event Analysis: Information is correlated from multiple sources
Adverse Event Analysis: Information is correlated from multiple sources
control · Context
DE.AE-04 — Adverse Event Analysis: The estimated impact and scope of adverse events are understood
Adverse Event Analysis: The estimated impact and scope of adverse events are understood
control · Context
DE.AE-06 — Adverse Event Analysis: Information on adverse events is provided to authorized staff and tools
Adverse Event Analysis: Information on adverse events is provided to authorized staff and tools
control · Context
DE.AE-07 — Adverse Event Analysis: Cyber threat intelligence and other contextual information are integrated into the analysis
Adverse Event Analysis: Cyber threat intelligence and other contextual information are integrated into the analysis
control · Context
DE.AE-08 — Adverse Event Analysis: Incidents are declared when adverse events meet the defined incident criteria
Adverse Event Analysis: Incidents are declared when adverse events meet the defined incident criteria
control · Context
DE.CM-01 — Continuous Monitoring: Networks and network services are monitored to find potentially adverse events
Continuous Monitoring: Networks and network services are monitored to find potentially adverse events
control · Context
DE.CM-03 — Continuous Monitoring: Personnel activity and technology usage are monitored to find potentially adverse events
Continuous Monitoring: Personnel activity and technology usage are monitored to find potentially adverse events
control · Context
DE.CM-06 — Continuous Monitoring: External service provider activities and services are monitored to find potentially adverse events
Continuous Monitoring: External service provider activities and services are monitored to find potentially adverse events
control · Context
ID.IM-03 — Improvement: Improvements are identified from execution of operational processes, procedures, and activities
Improvement: Improvements are identified from execution of operational processes, procedures, and activities
control · Context
ID.IM-04 — Improvement: Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved
Improvement: Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved
control · Context
PR.DS-11 — Data Security: Backups of data are created, protected, maintained, and tested
Data Security: Backups of data are created, protected, maintained, and tested
control · Context
PR.IR-01 — Technology Infrastructure Resilience: Networks and environments are protected from unauthorized logical access and usage
Technology Infrastructure Resilience: Networks and environments are protected from unauthorized logical access and usage
control · Context
PR.PS-04 — Platform Security: Log records are generated and made available for continuous monitoring
Platform Security: Log records are generated and made available for continuous monitoring
control · Context
RC.RP-01 — Incident Recovery Plan Execution: The recovery portion of the incident response plan is executed once initiated from the incident response process
Incident Recovery Plan Execution: The recovery portion of the incident response plan is executed once initiated from the incident response process
control · Context
RC.RP-02 — Incident Recovery Plan Execution: Recovery actions are selected, scoped, prioritized, and performed
Incident Recovery Plan Execution: Recovery actions are selected, scoped, prioritized, and performed
control · Context
RC.RP-03 — Incident Recovery Plan Execution: The integrity of backups and other restoration assets is verified before using them for restoration
Incident Recovery Plan Execution: The integrity of backups and other restoration assets is verified before using them for restoration
control · Context
RC.RP-05 — Incident Recovery Plan Execution: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
Incident Recovery Plan Execution: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
control · Context
RS.AN-03 — Incident Analysis: Analysis is performed to establish what has taken place during an incident and the root cause of the incident
Incident Analysis: Analysis is performed to establish what has taken place during an incident and the root cause of the incident
control · Context
RS.AN-06 — Incident Analysis: Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved
Incident Analysis: Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved
control · Context
RS.AN-07 — Incident Analysis: Incident data and metadata are collected, and their integrity and provenance are preserved
Incident Analysis: Incident data and metadata are collected, and their integrity and provenance are preserved
control · Context
RS.AN-08 — Incident Analysis: An incident's magnitude is estimated and validated
Incident Analysis: An incident's magnitude is estimated and validated
control · Context
RS.CO-02 — Incident Response Reporting and Communication: Internal and external stakeholders are notified of incidents
Incident Response Reporting and Communication: Internal and external stakeholders are notified of incidents
control · Context
RS.CO-03 — Incident Response Reporting and Communication: Information is shared with designated internal and external stakeholders
Incident Response Reporting and Communication: Information is shared with designated internal and external stakeholders
control · Context
RS.MA-01 — Incident Management: The incident response plan is executed in coordination with relevant third parties once an incident is declared
Incident Management: The incident response plan is executed in coordination with relevant third parties once an incident is declared
control · Context
RS.MA-02 — Incident Management: Incident reports are triaged and validated
Incident Management: Incident reports are triaged and validated
control · Context
RS.MA-03 — Incident Management: Incidents are categorized and prioritized
Incident Management: Incidents are categorized and prioritized
control · Context
RS.MA-04 — Incident Management: Incidents are escalated or elevated as needed
Incident Management: Incidents are escalated or elevated as needed
control · Context
RS.MA-05 — Incident Management: The criteria for initiating incident recovery are applied
Incident Management: The criteria for initiating incident recovery are applied
control · Context
RS.MI-01 — Incident Mitigation: Incidents are contained
Incident Mitigation: Incidents are contained
control · Context
RS.MI-02 — Incident Mitigation: Incidents are eradicated
Incident Mitigation: Incidents are eradicated
control · Context
500.6 — Audit trail
Audit trail
control · Context
PCI-Req10 — Log and monitor all access to system components and cardholder data
Log and monitor all access to system components and cardholder data
control · Context
SOC1-11 — System monitoring and incident management — controls provide reasonable assurance that system performance, security events, and incidents are monitored, identified, and resolved.
System monitoring and incident management — controls provide reasonable assurance that system performance, security events, and incidents are monitored, identified, and resolved.
control · Context
A1.2 — The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.
The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.
control · Context
C1.2 — The entity disposes of confidential information to meet the entity's objectives related to confidentiality.
The entity disposes of confidential information to meet the entity's objectives related to confidentiality.
control · Context
CC6.6 — The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
control · Context
CC7.2 — The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.
The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.
control · Context
CC7.3 — The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.
The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.
control · Context
CC7.4 — The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.
The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.
control · Context
CC7.5 — The entity identifies, develops, and implements activities to recover from identified security incidents.
The entity identifies, develops, and implements activities to recover from identified security incidents.
control · Context
P4.2 — The entity retains personal information consistent with the entity's objectives related to privacy.
The entity retains personal information consistent with the entity's objectives related to privacy.
control · Context
P4.3 — The entity securely disposes of personal information to meet the entity's objectives related to privacy.
The entity securely disposes of personal information to meet the entity's objectives related to privacy.
control · Context
P6.2 — The entity creates and retains a complete, accurate, and timely record of authorized disclosures of personal information to meet the entity's objectives related to privacy.
The entity creates and retains a complete, accurate, and timely record of authorized disclosures of personal information to meet the entity's objectives related to privacy.
control · Context
P6.3 — The entity creates and retains a complete, accurate, and timely record of detected or reported unauthorized disclosures (including breaches) of personal information to meet the entity's objectives related to privacy.
The entity creates and retains a complete, accurate, and timely record of detected or reported unauthorized disclosures (including breaches) of personal information to meet the entity's objectives related to privacy.
control · Context
P6.4 — The entity obtains privacy commitments from vendors and other third parties who have access to personal information to meet the entity's objectives related to privacy. The entity assesses those parties' compliance on a periodic and as-needed basis and takes corrective action, if necessary.
The entity obtains privacy commitments from vendors and other third parties who have access to personal information to meet the entity's objectives related to privacy. The entity assesses those parties' compliance on a periodic and as-needed basis and takes corrective action, if necessary.
control · Context
P6.5 — The entity obtains commitments from vendors and other third parties with access to personal information to notify the entity in the event of actual or suspected unauthorized disclosures of personal information. Such notifications are reported to appropriate personnel and acted on in accordance with established incident response procedures to meet the entity's objectives related to privacy.
The entity obtains commitments from vendors and other third parties with access to personal information to notify the entity in the event of actual or suspected unauthorized disclosures of personal information. Such notifications are reported to appropriate personnel and acted on in accordance with established incident response procedures to meet the entity's objectives related to privacy.
control · Context
P6.6 — The entity provides notification of breaches and incidents to affected data subjects, regulators, and others to meet the entity's objectives related to privacy.
The entity provides notification of breaches and incidents to affected data subjects, regulators, and others to meet the entity's objectives related to privacy.
control · Context
P6.7 — The entity provides data subjects with an accounting of the personal information held and disclosure of the data subjects' personal information, upon the data subjects' request, to meet the entity's objectives related to privacy.
The entity provides data subjects with an accounting of the personal information held and disclosure of the data subjects' personal information, upon the data subjects' request, to meet the entity's objectives related to privacy.
risk · Direct
Coordinated multi-stage / APT campaigns
Adversary coordinates continuous, adaptive, multi-staged campaigns (hopping across systems, combining insider/outsider/supply-chain vectors, spreading from existing presence) to persist and progressively undermine mission/business functions.
risk · Direct
Unauthorized disclosure / breach of sensitive information
Unauthorized disclosure of information to parties not entitled to receive it, whether by insecure controls (insecurity), spillage, or authorized users induced to expose data — resulting in identity theft, economic loss, and loss of trust.
risk · Direct
Failure to detect, assess, and notify breaches on time
Failure to detect, assess, and notify affected individuals and regulators of personal-data breaches within required timeframes and content (GDPR Art.33/34, HIPAA breach rule), resulting in sanctions and compounded individual harm.
risk · Direct
No or insufficient incident-response procedures
Without documented, tested incident-response procedures, breaches and failures are handled inconsistently, slowly, or ineffectively, prolonging exposure and amplifying loss.
risk · Direct
Missing or insufficient logging and audit trails
Absence of logging/audit trails means unauthorized activity cannot be detected, investigated, or attributed, and adversary actions (obfuscation of intrusion detection, tampering with logs) go unnoticed.
risk · Direct
No security monitoring or supervision of privileged activity
Absence of monitoring mechanisms and supervision of personnel actions (especially privileged users) allows undetected misuse, and no process exists to supervise and escalate detected security breaches.
risk · Direct
Ransomware disrupting operations and data availability
Criminal groups deploy ransomware that encrypts systems and data, disrupting operations, causing losses, and demanding extortion payment — a high-impact convergence of malware, availability, and continuity risk.
standard · Context
AIUC-1 (Jul 2026)
AIUC-1 — AI agent security, safety and reliability standard (requirement level)
standard · Context
CCPA/CPRA
CCPA/CPRA — California Consumer Privacy
standard · Context
COBIT 2019
COBIT 2019 Governance & Management Objectives
standard · Context
COSO ERM 2017
COSO ERM – Integrating with Strategy and Performance (2017)
standard · Context
COSO IC 2013
COSO Internal Control – Integrated Framework (2013)
standard · Context
EU DORA
EU DORA — Digital Operational Resilience Act
standard · Context
EU AI Act
EU AI Act — principal obligation areas (Chapters II, III, V and IX)
standard · Context
EU GDPR
EU GDPR — General Data Protection Regulation
standard · Context
HIPAA
HIPAA — Security, Privacy & Breach Notification
standard · Context
IIA 2024 Standards
IIA 2024 Global Internal Audit Standards
standard · Context
The Role of the Internal Audit Function in Enterprise Risk Management
The Role of the Internal Audit Function in Enterprise Risk Management
standard · Context
Three Lines Model: Assurance and Advice in Support of Effective Governance
Three Lines Model: Assurance and Advice in Support of Effective Governance
standard · Context
ISO/IEC 27001:2022
ISO/IEC 27001:2022 Annex A
standard · Context
ISO 31000:2018
ISO 31000:2018 Risk Management (principles/framework/process)
standard · Context
EU NIS2
EU NIS2 Directive
standard · Context
NIST SP 800-53 Rev5
NIST SP 800-53 Rev 5 — Security and Privacy Controls
standard · Context
NIST Agent Identity (draft, Feb 2026)
NIST NCCoE: Software and AI Agent Identity and Authorization
standard · Context
NIST TEVV-Athlon (draft, Aug 2026)
NIST AI 200-2: TEVV-Athlon Framework for Evaluating AI Systems
standard · Context
NIST CSF 2.0
NIST Cybersecurity Framework 2.0
standard · Context
NYDFS Part 500
NYDFS Part 500 — NY Cybersecurity Regulation
standard · Context
PCI DSS v4.0.1
PCI DSS v4.0.1
standard · Context
SOC 1
SOC 1 (SSAE 18 / ISAE 3402) — service-org ICFR control objectives
standard · Context
SOC 2 (TSC)
AICPA SOC 2 Trust Services Criteria (2017, rev. 2022)
standard · Context
SOX / PCAOB (ICFR)
SOX 404 / PCAOB AS 2201 — ICFR control taxonomy
unified · Context
UC-ACCESS-18 — Log and monitor system activity, capacity, and incidents
Systems generate log records that are protected and made available for continuous monitoring. Performance, capacity, and security events are monitored against thresholds, with alerts triaged and incidents identified and resolved through a tracked process. Resource use is projected and tuned to meet current and future capacity requirements.
unified · Direct
UC-ASSET-11 — Improve security plans and processes from operational lessons
Identify improvements from the execution of operational processes, procedures, and activities, and track them to implementation. Establish, communicate, maintain, and improve incident response and other cybersecurity plans that affect operations, updating them after exercises, incidents, and significant organizational or technical change.
unified · Context
UC-BCDR-03 — Back up data and verify restorability
Back up information, software, and system images at a frequency and scope aligned to defined recovery point objectives, protect backup copies from unauthorized access and modification, and keep copies separate from the primary environment. Verify backup integrity and restorability through periodic test restores, and verify the integrity of backups before using them for restoration.
unified · Context
UC-BCDR-06 — Resolve operational incidents and eliminate root causes
Log, classify, and prioritize operational and security incidents and service requests, respond within defined service levels, and escalate by severity until service is restored. Classify and report major ICT incidents to regulators, customers, and affected parties within required timeframes. Perform root-cause analysis of significant and recurring incidents, and track underlying problems through to permanent resolution.
unified · Context
UC-BCDR-07 — Execute recovery plans to restore systems and operations
When disruption occurs, execute the documented recovery procedures to restore systems, applications, and data to a known operational state within recovery time objectives. Select, scope, and prioritize recovery actions based on criticality and dependencies, verify the integrity of restored assets, and confirm normal operating status before returning systems to service.
unified · Context
UC-BCDR-13 — Operate continuous security protection services
Operate ongoing protection services, including malware defense, network and endpoint security, and security monitoring, so that attacks and disruptions do not compromise service availability or data. Review and tune these services regularly to keep security risk within accepted levels.
unified · Context
UC-DATA-04 — Restrict processing of special categories of personal data
Inventory all processing of special categories of personal data (e.g., health, biometric, genetic, race or ethnicity, religion, sexual orientation) and prohibit such processing unless a documented legal exception or explicit consent applies. Apply heightened safeguards to this data and record the exception relied upon for each processing activity.
unified · Context
UC-DATA-09 — Retain personal and confidential data per schedule, then destroy it
Maintain an approved retention schedule for personal and confidential information tied to documented legal and business requirements, and retain data no longer than the schedule permits. When retention ends, delete or irreversibly destroy the information wherever it resides, including in external services, using methods that prevent reconstruction, and record disposal actions as evidence.
unified · Context
UC-DATA-10 — Protect physical media containing sensitive data
Store physical media holding sensitive or personal data in secured, access-controlled locations. Protect media during transport outside controlled areas using authorized personnel or couriers, accountability tracking, and encryption or locked containers. Sanitize media commensurate with its highest recorded classification before downgrading, reuse, or release, and maintain storage, transfer, and sanitization records.
unified · Context
UC-DATA-11 — Control data flows, leakage, and cross-border transfers
Enforce approved authorizations for information flows within and between systems using technical flow-control mechanisms, and deploy data-leakage-prevention measures on systems and channels that could exfiltrate sensitive data. Transfer personal data across borders only under a valid transfer mechanism (adequacy decision, standard contractual clauses, binding corporate rules, or a documented derogation), with the transfer risk assessed and the safeguard recorded.
unified · Context
UC-DATA-12 — De-identify, mask, or pseudonymize personal data
Apply masking, pseudonymization, or de-identification when full identifiers are not required, following policy and the applicable legal standard (e.g., expert determination or safe-harbor methods, limited data sets under agreement). Protect the keys and mappings that could re-identify data, and prohibit re-identification attempts.
unified · Context
UC-DATA-13 — Safeguard personal information with reasonable security
Identify the statutory, regulatory, and contractual requirements that apply to the personal information the organization holds, and implement reasonable administrative, technical, and physical safeguards appropriate to its volume and sensitivity. Assign responsibility for PII protection, verify the safeguards periodically, and remediate identified gaps.
unified · Context
UC-DATA-14 — Maintain and provide an accounting of disclosures
Record every authorized disclosure of personal information - recipient, date, data categories, and purpose - completely, accurately, and in a timely manner. Upon a verified request, provide the data subject an accounting of the personal information held and its disclosures within the required timeframe.
unified · Context
UC-DATA-15 — Record and notify unauthorized disclosures of personal data
Log every detected or reported unauthorized disclosure or breach of personal information in a complete, accurate, and timely register. Notify affected data subjects, regulators, and other required parties within the applicable statutory windows, and retain the notifications and supporting analysis as evidence.
unified · Context
UC-DATA-16 — Bind third parties handling personal data to privacy commitments
Before granting vendors or other third parties access to personal information, obtain written privacy commitments covering permitted use, safeguards, and notification of actual or suspected unauthorized disclosures. Assess their compliance periodically and as needed, route their breach notifications into the incident-response process, and take corrective action or terminate access when commitments are not met.
unified · Direct
UC-IR-01 — Maintain an approved incident response plan
Maintain a written incident response plan that defines the mission and scope of the response capability, incident definitions and severity structure, roles, responsibilities, and communication paths, and how the capability coordinates with business continuity and third parties. Have the plan approved by designated management, distribute it to named response personnel, and review and update it on a defined frequency and after significant incidents or organizational changes, protecting it from unauthorized disclosure and modification.
unified · Direct
UC-IR-02 — Train responders and test the incident response capability
Provide role-based incident response training to users, responders, and leadership within a defined period of assuming the role, when systems or the plan change materially, and at least annually thereafter. Test the incident response capability on a defined schedule using exercises such as tabletop simulations, document results and lessons, and feed identified gaps back into the plan and the training program.
unified · Direct
UC-IR-03 — Provide channels to report events and obtain response help
Operate well-known channels — such as a monitored mailbox, hotline, or service portal — through which all personnel can and are directed to report observed or suspected security events as quickly as possible. Provide an incident response support resource, integral to the response capability, that offers advice and assistance to users on reporting and on handling suspected events. Acknowledge every report and route it into triage.
unified · Direct
UC-IR-04 — Triage, categorize, and escalate reported security events
Triage every reported security event: validate that it is genuine, assess it against the agreed classification scheme, and decide whether to declare it an incident. Categorize and prioritize declared incidents by type, severity, and business impact, and escalate or elevate them to defined roles and management tiers according to documented thresholds and timeframes. Record triage decisions and their rationale in the incident system of record.
unified · Direct
UC-IR-05 — Assess and validate incident scope, impact, and magnitude
For each declared or suspected incident, estimate the scope of affected systems, data, and business processes and the resulting impact, and validate those estimates as investigation proceeds. Document magnitude assessments — records affected, service disruption, and financial exposure — and update them at defined points so response priority, escalation, and notification decisions rest on current, validated figures.
unified · Direct
UC-IR-06 — Respond to, contain, and eradicate declared incidents
On declaration of an incident, execute the incident response plan in coordination with internal teams and relevant third parties such as providers, law enforcement, and insurers. Contain the incident using predefined strategies for its category, eradicate the cause by removing malicious artifacts and closing exploited weaknesses, and coordinate handling with contingency and recovery activities through to resolution. Communicate response status as the plan requires and document all response actions taken, feeding lessons into response procedures.
unified · Direct
UC-IR-07 — Investigate incidents and preserve evidence and records
Track and document every incident from declaration to closure in a system of record covering status, actions performed, decisions, and timeline. Collect incident data and evidence using documented procedures that preserve integrity, provenance, and chain of custody so evidence remains suitable for disciplinary and legal proceedings, and record investigation actions as they are performed. Perform analysis, including root-cause analysis, to establish what took place and why, and record the conclusions.
unified · Direct
UC-IR-08 — Notify authorities and affected parties within deadlines
Maintain a notification matrix of internal stakeholders, regulators, and other external parties with triggers, deadlines, content requirements, and approved communication owners. Require personnel to report suspected incidents to the response capability within defined timeframes, notify authorities and other required external bodies within their statutory windows, and share incident information with designated internal and external stakeholders as the communications plan directs. Notify affected individuals when thresholds are met — for high-risk personal-data breaches, communicate without undue delay in clear and plain language with mitigation advice; for regulated categories of data, notify individuals, media, and regulators within the mandated statutory windows when applicable thresholds are reached, honoring notification duties owed to partner organizations. Retain evidence of every notification's timing, audience, and content.
unified · Direct
UC-IR-09 — Recover from incidents using defined initiation criteria
Define objective criteria for initiating incident recovery — such as confirmed eradication, completed forensic preservation, and management authorization — and apply them before restoration begins. Identify, develop, and execute recovery activities that restore affected systems, data, and services to a known-good state, verifying integrity before return to production and confirming with business owners that normal operations have resumed.
unified · Direct
UC-IR-10 — Learn from incidents and communicate corrective actions
Hold post-incident reviews for incidents meeting defined thresholds to capture what happened, what worked, and what failed. Convert lessons into tracked corrective actions — updates to controls, plans, training, and configurations — and use incident trends to identify and reduce recurring exposure. Communicate identified deficiencies and corrective-action status in a timely manner to the parties responsible for remediation, including senior management and, where significant, the board.
unified · Direct
UC-IR-11 — Respond to information spillage with defined procedures
Maintain and execute a documented procedure for responding to information spillage — sensitive or regulated information landing on systems not authorized to hold it. On discovery, identify the information and the extent of contamination, alert designated personnel without amplifying exposure, isolate and eradicate the spilled information from affected systems and backups, and assess any obligations triggered by the exposure. Provide procedures and training for personnel exposed to spilled information and document each spill response.
unified · Context
UC-LOG-01 — Log security-relevant events across all systems
Enable audit logging on all systems, applications, and network components, generating records for a defined catalog of security-relevant event types — at minimum authentication, all access to sensitive or regulated data (such as cardholder data), privileged actions, account and configuration changes, and security-tool events. Review and update the event catalog periodically with system owners, ensure logging is enabled by default on newly deployed components, and verify logging coverage on a defined cadence.
unified · Context
UC-LOG-02 — Record complete audit content with synchronized clocks
Capture audit records whose content establishes what happened, when it happened, where it occurred, the source, the outcome, and the identity of associated users or subjects, with centrally managed additional fields where investigations require them. Synchronize clocks on all logging systems to an approved authoritative time source, record timestamps in a consistent format mappable to UTC with defined granularity, and monitor for and correct clock drift.
unified · Context
UC-LOG-03 — Protect audit logs and retain them for required periods
Protect audit information and logging tools from unauthorized access, modification, and deletion: restrict access to a need-to-know subset of personnel, forward records to storage that users of the source system cannot alter, and alert on tampering attempts. Allocate log storage capacity consistent with retention requirements, and alert designated personnel and take defined actions when logging fails or capacity thresholds are reached. Retain audit records per a documented schedule that satisfies the longest applicable legal and regulatory period — for example five years where transaction-reconstruction rules apply — with recent security logs readily available for analysis.
unified · Context
UC-LOG-04 — Continuously monitor systems for anomalous activity
Operate continuous monitoring under a documented strategy that defines what is monitored, the metrics, and the frequencies — including ongoing assessment of security-control effectiveness — and report security status to defined roles on a defined cadence. Deploy monitoring across hosts, networks, and applications, at the perimeter and interior, to detect attacks, indicators of compromise, unauthorized connections, and anomalous behaviour indicative of malicious acts, natural disasters, or errors. Analyze flagged anomalies promptly to determine whether they represent security events requiring further evaluation.
unified · Context
UC-LOG-05 — Correlate and analyze events centrally with threat intel
Aggregate logs and alerts into a central analysis capability (such as a SIEM) that correlates information from multiple internal and external sources and enriches it with cyber threat intelligence and contextual information. Review and analyze collected records on a defined cadence for indications of inappropriate or unusual activity, using record-reduction and on-demand report generation that does not alter the original records. Route findings and adverse-event information to authorized staff and tools, and communicate monitoring responsibilities and results internally so accountable parties can act.
unified · Context
UC-LOG-06 — Evaluate events and declare incidents against defined criteria
Define written criteria for declaring a security incident, including thresholds that identify a reportable personal-data breach. Evaluate analyzed events against those criteria, declare incidents and initiate the response process when criteria are met, and record the assessment and rationale for every evaluated event. For reportable personal-data breaches, notify the competent regulator within the mandated statutory window with the prescribed content, and document all breaches, their effects, and remediation regardless of whether notification was required.
unified · Context
UC-LOG-07 — Monitor user sessions and personnel activity
Monitor user and administrator activity for signs of misuse: capture and review session activity for defined high-risk circumstances such as privileged or remote sessions, with legal review and any required disclosure to users, and monitor personnel technology usage against acceptable-use expectations to surface potentially adverse events. Restrict access to captured session data to authorized reviewers and involve HR and legal counsel in handling findings.
unified · Context
UC-LOG-09 — Monitor providers and exchange audit data across organizations
Define monitoring requirements for external service providers and monitor their activities, service status, and security-relevant events against contractual obligations, reviewing provider-supplied logs and reports on a defined cadence. Where audit trails cross organizational boundaries, agree methods for coordinating, exchanging, and protecting audit information with the external parties and preserve the identity context needed to trace cross-organizational actions.
unified · Context
UC-NET-01 — Segment networks and defend the external boundary
Segment networks into zones based on trust level, sensitivity, and function, and mediate all traffic at managed interfaces (firewalls, gateways, proxies) with deny-by-default rules at the external boundary and key internal boundaries. Monitor and control communications crossing each boundary to protect against threats originating outside the system boundary, and review segmentation and rule sets periodically.
unified · Context
UC-NET-04 — Isolate system, user, and security functions
Separate user functionality, including user-interface services, from system-management functionality, and isolate security functions from non-security functions using partitioning, virtualization, or separate physical or logical components. Partition the system so components of differing sensitivity reside in separate domains, limiting the blast radius of a compromise.
unified · Context
UC-NET-06 — Enforce separation with hardware and software mechanisms
Employ hardware-enforced and software-enforced separation mechanisms to isolate critical security functions and enforce policy between execution domains. Use hardware-based protections such as write-protected or read-only memory, and load and execute key programs from hardware-enforced non-modifiable media so critical code cannot be altered at runtime.
unified · Context
UC-SDLC-04 — Engineer systems with secure architecture and design
Design and build systems using established secure architecture and engineering principles: least privilege, defense in depth, isolation of execution domains (process and memory separation), fail-safe defaults, and attack-surface minimization, applied from concept through implementation. Require developers to produce and maintain a security architecture description consistent with the enterprise architecture. Engineer solutions to remain accurate, robust, and resilient against errors, faults, and adversarial manipulation.
unified · Context
UC-SDLC-05 — Enforce secure coding and input validation standards
Establish and enforce secure coding standards for in-house and reused code, covering common weakness classes and secure use of components. Validate all information inputs for syntax, semantics, type, length, and range at trust boundaries, rejecting or safely encoding unsafe input. Verify adherence through code review and static analysis before release.
workflow · Context
Cybersecurity Assurance Review
Cybersecurity Assurance Review — a CAE-owned assurance engagement that runs on the EXISTING Audit item opened from the audit plan (audit_type=it_audit, status PLANNED, lead_auditor and scope already set): the workflow instance attaches to that item and enriches it end to end, never creating a duplicate engagement record. It covers the three IIA Cybersecurity Topical Requirement domains (governance, risk management, and control activities) over the cyber estate bounded in the engagement memo (in scope: named legal entities, networks, cloud tenants, and OT/ICS where included; out of scope: areas whose assurance is documented as delivered by other engagements), testing against the NIST 800-53 Rev 5 catalog with CSF 2.0 / ISO 27001 as the aggregation frame. It originates from the audit plan (no upstream workflow) and produces the findings register (one four-Cs Issue per finding), the cyber posture summary carrying the per-domain and overall Standard 14.5 conclusions, and the approved engagement package — which it hands to the downstream Audit Report Drafting workflow.
workflow · Context
Fraud & Forensic Investigation Engagement
Fraud & Forensic Investigation Engagement as a decision-aware workflow. It runs on a dedicated Audit item (audit_type: investigation) created for this allegation at intake — the confidential case record — with the workflow instance attached to that item and its visibility restricted to the named investigation team. In scope: one specific fraud allegation, worked predication-gated and confidentially from intake through evidence preservation, forensic procedures, interviews, loss quantification, and audit-committee reporting; the named deliverables are the chain-of-custody register, the findings memorandum with its loss-quantification schedule, and the privilege-marked audit-committee fraud report. Out of scope: the enterprise fraud risk profile (owned by Fraud Risk Assessment & Anti-Override Control Review, which receives scheme intelligence from this case rather than being rerun here) and any unrelated conduct discovered in passing (which gets its own intake record). It consumes the hotline intake package from Control Responsibility Communications & Ethics Hotline when so routed, and hands each control breakdown off as an Issue item — control-gap findings to Finding Remediation & Action-Plan Monitoring and ICFR-affecting deficiencies to SOX Deficiency Remediation — rather than duplicating that work.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
Continuous Controls Monitoring (ISCM) Cycle
Run the continuous controls monitoring (ISCM) cycle: pull the current-period control metrics and score them against thresholds, triage degraded and failed controls, update the POA&M, report control health to governance, recalibrate the monitoring strategy, then classify the disposition and prepare, hand off, and archive the cycle package. Each interval runs as one workflow instance attached to the existing Process item that represents the ISCM / continuous-controls-monitoring program (process_type = security_process) — enrich that program record every cycle, never create a duplicate. The monitored control set is the existing Control items (Control.frequency doubles as the monitoring cadence, Control.control_owner as the accountable owner) and the POA&M is the existing Issue register (issue_type = deficiency, source = self_assessment); metric definitions and pass/degraded/fail threshold bands have no native field, so they live in the ISCM strategy document carried on the anchor Process item. The cycle produces the control-health scorecard, the reconciled POA&M, the control-health / security-status report, and the recalibrated ISCM strategy. In scope: the recurring NIST 800-137 monitoring loop — metric collection, threshold comparison, triage, POA&M maintenance, security-status reporting, and monitoring-strategy tuning for the controls under continuous monitoring. Out of scope: formal security control assessment and driving gap remediation to closure, which is owned by the downstream Security Control Assessment & POA&M Remediation workflow that consumes this cycle's handoff package. No upstream workflow feeds this one; it is triggered by the arrival of the monitoring interval.
workflow · Context
Technical Security Testing & Pentest Engagement
Runs ON an existing Audit item (audit_type: it_audit) that represents the authorized penetration-test engagement — the workflow instance attaches to that record and enriches it (scope, ratings, dates, and the assurance conclusion write back to its fields); it never creates a duplicate engagement record. In scope: authorized technical testing (reconnaissance, discovery, exploitation validation, severity rating, reporting, and retest) of the defined system boundary against its control baseline and assessment objective, with each confirmed finding recorded as an Issue linked to the anchor Audit and its affected Controls. Out of scope: any testing beyond the agreed rules of engagement, and the downstream remediation program itself — confirmed control gaps and open POA&M findings are handed to the Security Control Assessment & POA&M Remediation workflow, and the assurance conclusion to the Cybersecurity Assurance Review workflow. No upstream workflow feeds this engagement; its inputs are the anchor Audit, the in-scope system boundary (Process items), the control baseline (Control items, framework nist-800-53), the assessment objective and signed authorization, and any open Issue items (source: penetration_test / vulnerability_scan) from prior engagements.
workflow · Context
Business Continuity & DR Test Exercise
Run one operating cycle of an existing business continuity / disaster recovery plan-testing Control (the BC/DR test control this instance attaches to, UC-BCDR-04 "tests"): plan, execute, and evaluate a BC/DR exercise against the RTO and RPO objectives, then fold the resulting gaps back into the BC and DR plans as versioned redlines — a decision-aware workflow. It consumes as declared inputs the in-force BC and DR plans (existing Policy items), the business impact analysis (BIA), and prior after-action reports; it creates an Audit item (audit_type=operational) as the definitive exercise record, and produces named deliverables: an approved exercise package, an actual-versus-target RTO/RPO scorecard, remediation findings (Issue items), and a signed-off after-action report with an indexed evidence package. In scope: scoping, running, and evaluating one scheduled or triggered BC/DR exercise for the selected in-scope systems and business services, and folding resulting gaps back into the BC and DR plans. Out of scope: real incident response, and recovery-objective (RTO or RPO) changes to systems outside the agreed exercise scope. Standalone: no upstream or downstream workflow is required; any cross-workflow linkage — for example a related incident-response or BIA-maintenance workflow — is expressed as a declared input, not a predecessor.
workflow · Context
Data Retention & Secure Disposal
Each cycle runs as a workflow instance attached to the existing data-retention-and-secure-disposal Control item in the control library (UC-DATA-09/UC-DATA-10) — enrich that Control with this run's evidence, never create a duplicate control. A decision-aware cycle covering expired-data identification, disposition approval, verifiable disposal, media sanitization, evidence assembly, and stakeholder reporting. In scope: identifying and disposing of data whose retention has expired across in-scope stores (databases, file shares, document repositories, email archives, backup sets, and physical media) governed by the approved retention schedule. Out of scope: authoring the retention schedule itself — it is consumed as a standing input (the retention Policy item and its attached schedule), not produced here — and any data under an active legal or audit hold, which is fenced off from disposal. No upstream workflow feeds this cycle; it is triggered by the disposal calendar, a storage threshold, a system decommission, or a data-subject erasure request. It produces a signed disposition list, a disposal evidence package (job logs, hash manifests, chain-of-custody records, and certificates of destruction), a cycle dashboard, and an approved cycle report mapped to ISO 27001 A.8.10/A.7.10, NIST SP 800-53 SI-12/MP-6, and GDPR Article 5(1)(e). Downstream it hands nothing to another workflow: open exceptions, deferrals, and accepted gaps carry forward as Issue items in the risk/issue register, and schedule-maintenance gaps are forwarded to the retention-schedule owner as a closure notice.
workflow · Context
Incident Reporting Channels & Spillage Response
Standing operator workflow that runs on the existing Control item for the incident-reporting and information-spillage control (UC-IR-03; framework nist-800-53 | iso-27001 | nis2, domains incident_management_response) — one recurring workflow instance per operating cycle attaches to and enriches that Control item, never a duplicate. It consumes the prior cycle's carry-forward from the same Control: the last-sweep timestamp from the previous instance's close-and-archive record, plus the still-open corrective-action and obligation Issues linked to the Control. In scope: intake acknowledgment and triage routing across the monitored mailbox, hotline, and service portal; spillage containment/eradication and obligation assessment; and maintenance of the authorities and special-interest-group (SIG) contact register — spanning NIST 800-53 IR-6, IR-7, IR-9, and PM-15; ISO 27001 A.6.8, A.5.5, A.5.6; and NIS2 reporting duties. Named deliverables: the deduplicated intake register and acknowledgment log, the batch routing decision, the spill case with verified eradication, the obligation assessment and exposed-personnel training evidence, the refreshed authority/SIG contact register, the capability-health dashboard, the corrective-action register, and the archived operating record. Out of scope: full containment, investigation, and forensic response for genuine security events — those are handed off to the detect-to-respond workflow (via the route_to_incident_triage routing decision plus the linked intake Issues) rather than duplicated here.
workflow · Context
Cybersecurity Incident Response
Cybersecurity incident-response cycle as a decision-aware workflow spanning detection and validation, scoping, incident declaration and response-plan activation, containment with evidence preservation, eradication and recovery, POA&M updates for the control deficiencies the incident exposed, and a technical lessons-learned retrospective, closed through a disposition decision and archival. The workflow instance runs on the incident record — an Issue item (issue_type=exception, source=management_identified, severity per the org scheme) created at detection, since the schema has no native Incident type — and enriches that one record through to archival rather than creating duplicates. In scope: security events and confirmed incidents affecting the system boundary and its NIST 800-53 IR-family controls — the detection sources (logging/monitoring Control items, UC-LOG-06), affected systems (Process items, UC-ASSET-11), containment and recovery actions, forensic evidence, the deficiency Issues that become the POA&M, and their linked Risk items. Out of scope: the enterprise incident-management ticketing lifecycle and external breach-notification/legal reporting, which run in their own workflows. Where an Incident Management Lifecycle workflow is running, this cycle consumes its handoff package (initial ticket, reporter, affected systems); it hands the closed incident's control-deficiency findings — the open POA&M Issues (issue_type=deficiency) — to the Continuous Controls Monitoring (ISCM) Cycle as shared items it queries directly.
workflow · Context
Network Segmentation & Boundary Rule Management
Network Segmentation & Boundary Rule Management as a decision-aware operator workflow covering trust-zone maintenance, gated rule-change implementation, boundary threat monitoring, the quarterly segmentation and rule-set review, and cross-domain exchange-policy enforcement. This cycle runs on the EXISTING boundary-protection Control item (domains network_communications_security; framework NIST 800-53, NIST CSF 2.0, ISO 27001, SOC 2; frequency quarterly; the boundary control owner as control_owner) — each quarterly run is one workflow instance attached to and enriching that Control, never a new control record. In scope: the trust-zone model, the managed interfaces (firewalls, gateways, proxies) mediating traffic between zones, the external boundary and key internal boundaries, and the cross-domain interconnection points, all under a deny-by-default baseline (NIST 800-53 SC-7, SC-16, SC-46; NIST CSF 2.0 PR.IR-01; ISO 27001 A.8.22; SOC 2 CC6.6). No upstream workflow feeds this cycle; it self-seeds from its own prior-cycle carry-forward — open corrective-action Issue items linked to the Control plus the prior run's closure record and archived rule-change record log. Named deliverables: the reconciled trust-zone model, the verified rule-change record log, the boundary threat-monitoring summary, the cross-domain exchange-policy enforcement report, the quarterly segmentation & rule-set review report, the boundary-posture dashboard, and corrective-action Issues linked to the Control. Downstream, it hands off only to its own next cycle via the carry-forward closure record; a confirmed intrusion is escalated to the incident-response workflow (out of scope), as are host/endpoint controls.
workflow · Context
Platform Isolation & Separation Enforcement
Platform Isolation & Separation Enforcement as a decision-aware operator workflow. Each semiannual run attaches to the existing platform-isolation Control item — UC-NET-04 (framework nist-800-53, family SC, frequency semi_annual, control_owner = security architect), with sibling Controls UC-NET-05 and UC-NET-06 linked — enriching that standing control with a fresh cycle of evidence rather than creating any new anchor; consecutive instances stack on the same Control as its cycle history. Three verification streams run in parallel — user/system-management/security function and sensitivity-domain separation, shared-resource sanitization and covert-channel bandwidth reduction, and hardware- and software-enforced separation-mechanism integrity — and converge into a single posture review and closure. It consumes the prior cycle's still-open findings (Issue items carried forward on the anchor Control) plus live platform telemetry, and produces named deliverables: the function-and-domain separation matrix, the shared-resource sanitization report, the covert-channel analysis report, the hardware/software-mechanism verification report, a consolidated isolation-posture dashboard and evidence summary, and a signed cycle closure record. In scope: the semiannual verification and corrective-action closure of platform isolation across all in-scope platform components. Out of scope: the platform-engineering re-architecture behind a fix (tracked here as corrective-action Issues, executed by platform engineering) and boundary/network-protection controls owned by their own cycle. No upstream workflow feeds this cycle; its only handoff is downstream to its own next run — open corrective actions are left as OPEN Issue items on the anchor Control and arrive as explicit inputs to the next semiannual instance.
workflow · Context
Audit Logging Coverage & Integrity Operations
Monthly operator cycle that verifies audit-logging coverage against the security-relevant event catalog, validates record content-completeness and clock synchronization, and confirms log protection, alerting, and retention, producing the coverage matrix, record content-completeness results, clock-drift report, and retention and capacity attestation evidence pack each cycle. Each instance attaches to the EXISTING audit-logging Control in the control library (control_id UC-LOG-01; framework nist-800-53 / iso-27001 / pci-dss / nydfs-500; domain logging_monitoring_detection; monthly frequency), with UC-LOG-02 / UC-LOG-03 linked by item relationships — enrich that Control's operating history, never create a duplicate control. Every gap, remediation, and carry-forward is logged as an Issue related back to that Control. In scope: every in-scope system, application, and network component, the security-relevant event catalog, and log protection and retention configuration. Out of scope: SIEM detection-rule tuning and incident investigation — surfaced detection gaps hand off to the SOC / SIEM-operations and incident-response workflows, not this cycle. No upstream workflow feeds this cycle; the prior cycle's open corrective-action and carry-forward Issue items (related to the anchor Control) plus the prior cycle's archived workflow instance are its only inputs, and close-and-archive seeds the next monthly run of itself.
workflow · Context
Security Monitoring & Detection Operations
Each weekly cycle is a recurring instance attached to the existing continuous security-monitoring Control item (domains: logging_monitoring_detection, control_type: detective, frequency: weekly) — the cycle enriches that standing Control with its operating record, never creating a duplicate control. It consumes the prior cycle's carry-forward (unresolved queue Issues, open watchlist entries, open corrective actions) and the documented continuous-monitoring strategy (a Policy item linked to the Control), and produces named deliverables: the deployment coverage-and-effectiveness assessment, the enriched central SIEM analysis queue, the maintained detection watchlist, and the signed cycle security-status report. In scope: verifying monitoring deployment and effectiveness, working the central SIEM threat-intel analysis queue, triaging flagged anomalies, maintaining the detection watchlist, reporting security status to the defined roles, and verifying continuous protection-service health and tuning across hosts, networks, and applications at both the perimeter and the interior. Out of scope: incident containment, eradication, and recovery — confirmed security events are handed off mid-cycle to the Security Incident Response workflow rather than duplicated here.
workflow · Context
User Activity & External Exposure Monitoring
Monthly operator cycle for the standing user-activity and external-exposure monitoring control (UC-LOG-07/UC-LOG-11) — a detective, monthly-frequency Control that already exists in the control library. Each cycle runs as one workflow instance attached to that existing Control (enrich it — never create a duplicate control); the accountable owner and cadence come from Control.control_owner and Control.frequency=monthly. The instance runs the restricted privileged/remote session and acceptable-use review alongside the external open-source and dark-web exposure sweep, then converges every confirmed finding from both halves — each recorded as an Issue item linked to the anchor Control — into one consolidated restricted case log (XLSX) for security-event evaluation. Consumes upstream: no workflow feeds it — session capture and the exposure sweep are the two parallel entry points; each cycle draws on the standing monitoring program's authorized-reviewer roster, the acceptable-use policy and employee-monitoring disclosure notice (Policy items), the external search-set markers, and the prior cycle's carry-forward Issues. Named deliverables: the personnel-activity and exposure disposition decisions, the HR/legal referral and takedown Issues, the cycle-health dashboard, and the consolidated restricted case log. Downstream handoff: confirmed findings hand into the security-event evaluation queue — an informal handoff recorded as a reference on each case-log entry and in each Issue.description, since the graph has no terminal handoff node. In scope: privileged/remote session review, personnel acceptable-use monitoring, and the external open-source/dark-web exposure sweep for one monthly cycle. Out of scope: the automated SIEM alerting pipeline and the downstream security-event evaluation itself.
workflow · Context
Network & Provider Service Monitoring
Each monthly run attaches to the EXISTING network & provider monitoring Control item (UC-LOG-08/UC-LOG-09, frequency = monthly; framework = iso-27001 | nist-csf-2 | nist-800-53) — enrich that Control's evidence trail, never create a duplicate control. The cycle keeps network devices hardened and controlled, network-service documentation (including outsourced services) current, delivered services monitored for conformance, and external providers reviewed against their contractual obligations, feeding every deviation into a single owned remediation log — Issue items linked to the anchor Control — and producing a signed monthly monitoring record archived under retention. In scope: in-scope network devices and services, external service providers (the Vendor register) and their contracts, cross-organizational audit-trail exchange arrangements, and the deviations they produce. Out of scope: incident response and investigation for a provider-reported security event, which is tracked in its own incident case rather than in this monitoring cycle. Consumes no upstream workflow — self-originating, triggered by its own monthly cadence, a newly onboarded network service or provider, or a carried-forward deviation requiring follow-up; the previous instance hands off its still-open remediation Issues (linked to the same Control) as this cycle's carry-forward inputs. Terminal: it hands off to nothing downstream — closure seeds its own next cycle.
workflow · Context
Incident Response Readiness Program
Standing operator workflow that runs against the EXISTING incident-response Control item — UC-IR-01 (domains=incident_management_response, frequency=annual) — with the training-and-testing Control UC-IR-02 linked to the same instance; both carry framework=[nist-800-53, iso-27001], and those governing standards drive the plan's required elements. It maintains and approves the written IR plan (a Policy item, policy_type=procedure, framework=[nist-800-53, iso-27001], review_frequency=annual, whose governed redline attaches to the item), distributes and protects it to named responders, delivers role-based training, runs the scheduled capability test (an Audit item, audit_type=readiness, linked back to the two Controls), and feeds exercise and training gaps back into the plan and training program as corrective-action Issue items (source=self_assessment). Named deliverables: the redlined IR plan on its Policy item, the exercise after-action report, the IR readiness dashboard, and the routed corrective-action register (Issue items). In scope: the IR plan's required elements (mission and scope, incident definitions and severity structure, roles and responsibilities, communication paths, and business-continuity/third-party coordination), the named-responder and leadership training population, and the scheduled capability test. Out of scope: live incident handling itself — this workflow builds and tests readiness, it does not run the response to an active incident. It runs on an annual cadence and off-cycle whenever a significant incident or a material organizational/system change occurs; no upstream workflow feeds it and it hands off to no downstream workflow — identified gaps re-enter this same workflow as corrective-action Issues.
workflow · Context
Secure SDLC Phase-Gate Program
Operate the secure SDLC phase-gate program as a modular, decision-aware workflow where the accountable control owner chairs the intake, requirements, design, and build/release gates end to end. Each recurring operating cycle runs as a new workflow instance attached to the existing secure-SDLC phase-gate Control item (domains = secure_development_sdlc; framework = nist-800-53 / iso-27001 / cobit-2019 / nist-csf-2) — that Control already exists in the library, so the instance enriches it with this cycle's gate evidence rather than creating a duplicate control. In scope: chairing those four security-integrated lifecycle gates for every development initiative due this cycle, remediating held or blocked initiatives, and monitoring the process itself; it is self-initiating and consumes no upstream workflow package, and it seeds its own next cycle. Out of scope and distinct from it: the independent SDLC gate review's release-milestone verification, and the release-security-gate's technical testing practice.
workflow · Context
Backup & Recovery Testing
Runs on the existing system item. Test recoverability for a system by performing an actual restoration and measuring the result against recovery objectives. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Incident & Problem Management
Runs on the existing system item. Record an incident on a system, evidence containment against response targets, and determine root cause with preventive action. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Security Control Assessment & POA&M Remediation
Run this assessment on the EXISTING Audit item for the engagement (audit_type: it_audit or compliance) — enrich that record, never create a duplicate: Audit.scope carries the authorization boundary and Audit.period_start/period_end the assessment window. Consumes, from the upstream SSP-development / system-categorization effort, the approved System Security Plan (SSP), the FIPS 199 system categorization, and the tailored NIST 800-53 baseline (existing Control items, framework: nist-800-53). Assess each in-scope control with 800-53A examine/interview/test methods, record satisfied / other-than-satisfied determinations, open a POA&M Issue for every gap, re-validate remediation, and issue the Security Assessment Report (SAR). In scope: control assessment, determinations, the POA&M lifecycle, and the SAR for the authorization boundary agreed at kickoff. Out of scope: the authorization (ATO) decision itself and the steady-state continuous-monitoring cadence. On completion, the frozen SAR and POA&M package are handed to the NIST RMF System Authorization (ATO) Cycle.
workflow · Context
ISO 27001 Stage 2 Annex A Controls Audit
Attach to the existing Audit engagement, owned by Internal Audit, using its approved Statement of Applicability, risk treatment plan, scope, review period and operating evidence; produce the Stage 2 Annex A Controls Audit report, four signed theme conclusions and finding register for the engagement and remediation owners. Apply the approved Statement of Applicability to ISO/IEC 27001:2022 Annex A.5.1–A.5.37, A.6.1–A.6.8, A.7.1–A.7.14 and A.8.1–A.8.34; document each exclusion and assess direct and inherited responsibilities. This Annex A assessment contributes to the engagement and does not independently establish full ISMS conformity or issue certification. Stage 1 and readiness remain separate workflows; any certification decision remains with the authorized certification body.
workflow · Context
SOC 2 Availability Assessment
Design-readiness review of the SOC 2 availability series: capacity management, environmental protections with backup and recovery infrastructure, and recovery plan testing (A1.1–A1.3). Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Confidentiality Assessment
Design-readiness review of the SOC 2 confidentiality series: identification and maintenance of confidential information and its secure disposal at end of life (C1.1–C1.2). Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Privacy Criteria Assessment
Design-readiness review of the full SOC 2 privacy series: notice and choice, collection through disposal, data subject access and disclosure, and data quality with dispute monitoring (P1.1–P8.1), concluded with dual sign-off on the criteria-bearing final assessment. Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Type II Interim Testing
Interim fieldwork for the Type II examination: cycle walkthroughs, design assessment against the Trust Services Criteria, the first operating-effectiveness testing wave over the agreed interim evidence window, and exception triage feeding remediation and retest planning before the period closes. Interim SOC 2 Type II fieldwork for the listed control selections and agreed interim window. Later-period testing and the service auditor's independent opinion remain outside this module. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
Third-Party Vendor Risk Lifecycle
Operate the third-party vendor risk lifecycle end to end: scope and tier the vendor population, gather and analyze assurance evidence (SOC reports and CUECs, plus C-SCRM controls), embed contractual protections, enroll ongoing monitoring, and reach a governed disposition and approval. The vendor register IS the set of Vendor items — tiered by criticality (tier) and data exposure (data_classification), owned (business_owner, risk_owner), and driven by reassessment_cadence with last/next assessment dates and monitoring_status; each assessment cycle runs as one workflow instance over that register. In scope: vendor and supplier third-party risk assessment, onboarding controls, and periodic reassessment. Out of scope: procurement sourcing and commercial negotiation, and the deeper fieldwork of a Third-Party Vendor Assurance Engagement, to which the approved package is handed off. This workflow is self-initiating and consumes no upstream workflow package.
workflow · Context
Vendor Due Diligence & Contracting Gate
Vendor Due Diligence & Contracting Gate as a modular, decision-aware workflow. Anchor: the vendor's register entry — the Vendor item (slug: vendor). For a net-new engagement the gate creates the Vendor item and populates its tier, data_classification, business_owner, and risk_owner; for a renewal it enriches the existing Vendor item rather than duplicating it (enrich, never recreate). This is the first-line pre-contract gate the vendor-management office runs for every new engagement or renewal - tiering criticality, running proportionate due diligence into the vendor due-diligence report, documenting the risk-acceptance decision and any risk-reducing sourcing conditions, binding the contract to required security, privacy, and regulatory clauses, authorizing the specific information exchange before access begins, and - where personal data is involved - obtaining the signed written privacy commitments and scheduling compliance monitoring and incident-response routing. In scope: pre-contract due diligence, risk acceptance, and contract execution for one vendor engagement, ending with the Vendor item enrolled in monitoring (Vendor.monitoring_status = enrolled). There is no upstream workflow — the engagement trigger (a new prospective vendor or a renewal) is its own entry point. Downstream handoff: the archived gate record exported at close is the handoff package the ongoing third-party risk monitoring / vendor oversight lifecycle picks up to sustain the scheduled compliance checks and incident routing; that linkage is a prose handoff of live controls on the same Vendor item, not a triggered downstream node.
workflow · Context
Incident Management Lifecycle
Run the enterprise incident management lifecycle on a single governed incident record — an Issue item created at intake that every step enriches (there is no separate Incident type; the workflow instance anchors to that Issue). Open the record, analyze scope and impact, anchor the regulatory and remediation notification clocks to the detection date, contain/eradicate/recover, execute severity-based notifications, run lessons-learned and CAPA, classify the disposition, then prepare, hand off, and archive the governance package. Named deliverables: the scope-and-impact assessment, the root-cause analysis, the owned CAPA / remediation action plan, and the final evidence-and-decision governance package. In scope: operational and security incidents from detection through closure, including regulatory-notification clock management and corrective/preventive actions. Upstream: the incident originates on detection itself, but for a security-category incident this workflow consumes the containment-and-forensics handoff package produced by the Cybersecurity Incident Response workflow (linked in at the eradicate-and-recover step) rather than re-running SOC triage. Out of scope: real-time SOC triage and containment mechanics (owned by that Cybersecurity Incident Response workflow) and board-level reporting — the final governance package is handed off to the Quarterly Board & Audit-Committee GRC Reporting workflow, which reports the outcome without re-investigating.
workflow · Context
Personal Data Quality & De-identification
Personal Data Quality & De-identification runs as a recurring operate cycle attached to the existing Control for personal-data quality & de-identification (framework gdpr/hipaa/ccpa/nist-800-53, domain data_protection_privacy): each period is a workflow instance that enriches that Control's operating record — never a new Control. The cycle consumes the data map / RoPA, the data-quality ruleset and retention schedule (Policy items), the individual correction-request queue, the disclosure log and the recipient/processor Vendor register, and the de-identification policy; it checks PII accuracy, relevance, timeliness, and completeness, corrects or deletes failing records and notifies downstream recipients under GDPR Art. 19, adjudicates individual correction requests within statutory deadlines, and de-identifies datasets that do not require full identifiers. It produces the exception register (exception Issue items), the corrected-and-deleted set, the recipient correction/deletion notices, and the de-identification and residual-risk reports; systemic findings hand off to the internal privacy backlog as Issue items. This is a terminal operate cycle — the archived, regulator-ready cycle record is the deliverable, not a handoff package for a named downstream workflow.
workflow · Context
Privacy Safeguards & Notice Management
Privacy Safeguards & Notice Management as a decision-aware cycle that runs as a workflow instance attached to the standing "Privacy Program" Process item (process_type: business_process, process_owner: the privacy officer) — one archived instance per period is the cycle file. Each run refreshes the privacy requirements inventory, confirms PII-protection accountability over the PII stores (modeled as processing-activity Process items), verifies administrative, technical, and physical safeguards against data volume and sensitivity (the safeguard set is the Control items with control_category administrative|technical|physical and framework gdpr|ccpa|hipaa protecting each store), remediates gaps as tracked Issues, and authors, publishes, and version-retains the privacy notices and registrations (modeled as Policy items) kept accurate to actual processing. In scope: the periodic privacy program cycle over the confirmed PII stores, their safeguard control set, and the published notice and registration population; every run reconciles the affected notices to actual processing — a cycle that skips notice reconciliation is a different workflow. No upstream or downstream workflow feeds or consumes this cycle; its inputs are the organization's own privacy program records, and open remediation, treatment expiries, and deferred drift carry forward as open Issues that seed the next cycle's intake.
workflow · Context
Privacy Breach Assessment & Notification
Personal-data breach response, anchored on a breach-register Issue item created for the breach (issue_type: exception, source: management_identified, identified_date = the awareness timestamp); the workflow instance attaches to that Issue and the breach register is the queryable set of these Issues. Consumes the Incident Management Lifecycle workflow's handoff package (incident record, containment status, investigation timeline) and drives it from handoff to closure: a frozen, dated exposure inventory; a per-jurisdiction notifiability determination against GDPR Article 33, US state (California/CCPA included), and HIPAA clocks; regulator and data-subject notifications with milestone tracking; processor coordination against the processor's Vendor record and DPA; remediation and support Issue items; the Article 33(5) breach-register entry; and a post-breach review that hands off to the DPIA / Privacy Impact Assessment workflow for each affected processing activity. In scope: the notifiability judgment and notification execution downstream of the incident handoff; out of scope: incident containment and forensics, which stay with incident response.
workflow · Context
Third-Party ICT Vendor Regulatory Assurance
Third-Party ICT Vendor Regulatory Assurance as a decision-aware workflow. Each cycle runs on its own Audit engagement item (audit_type = vendor_review) created at kickoff, with Audit.scope set to the in-scope legal entities, regimes, and vendor population; every workpaper, decision form, and gap attaches to that instance. In scope: ICT third-party service providers — including intra-group ICT providers — assessed against DORA, NIS2, and US interagency/FFIEC third-party expectations; out of scope: non-ICT vendors, which stay with the general vendor lifecycle. It consumes the arrangement-level inventory, tiering, and due-diligence handoff package from Third-Party Vendor Risk Lifecycle (whose provider records are the Vendor items); refers vendor SOC 1/SOC 2 reports carrying real reliance to the Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow and folds back its reliance conclusions; and produces a provision-cited, severity-rated gap register (Issue items linked to the anchor Audit and the affected Control/Vendor records) plus a qualified final assurance package. It hands the validated obligation statuses to the Regulatory Compliance Attestation Cycle, exchanging handoff packages with related workflows instead of duplicating repeated work.
workflow · Context
DSAR Fulfillment (Access & Deletion Requests)
DSAR Fulfillment (Access & Deletion Requests) as a modular, decision-aware workflow that verifies identity, locates and reviews personal data, applies exemptions, and delivers the response inside the statutory deadline. The workflow runs against the EXISTING "DSAR / Data-Subject Request Handling" Process item (process_type: business_process) — enrich it, never recreate it: one workflow instance per inbound request, and the instance itself is the DSAR register entry (there is no native DSAR/privacy-request item type; the register is the set of these instances). In scope: a single inbound data-subject access or deletion request under GDPR, CCPA/CPRA, or HIPAA, with the statutory clock started at receipt, carried from identity verification through data compilation, exemption review, delivery, and archival, with any correction or portability elements handled inline. It consumes the inbound request and identity artifacts uploaded at the first step, the data map / record of processing activities, the exemption playbook and retention schedule (Policy items with the governing documents attached), and the processor register (Vendor items, category: data_processing). Named deliverables: the access disclosure set or deletion certificate, the exemption log and redlined package, the reasoned rejection notice on the failed-verification path, the delivery evidence and completion-metrics record, systemic-finding Issue items routed to the privacy program, and the archived DSAR case file — the exported workflow record. Out of scope: unrelated privacy processes such as breach notification and privacy impact assessments, which run as their own workflows; this workflow takes no upstream handoff and produces no downstream workflow handoff.
workflow · Context
Production Operations & Processing Integrity Cycle
Runs on the existing Process item for production/IT operations (process_type: it_general_control, frequency: daily — e.g. "Production Batch Operations & Processing Integrity"): one recurring instance per daily bridge/shift attaches to and enriches that Process, never creating a duplicate, and is archived against it at close. It operates the unified controls UC-ACCESS-17/18/20 (Control items, framework containing soc1|nist-csf-2|iso-27001) and consumes the prior cycle's carry-forward Issue items (open incidents, aged exceptions, backup gaps, tuning actions) as its opening population. A decision-aware workflow covering authorized batch execution and monitoring, failure and incident resolution, backup and restore-test verification, performance/capacity/security event monitoring with capacity tuning, and daily data-processing integrity through interface reconciliation and authorized-only output distribution. In scope: the authorized batch, interface, and report population, monitoring thresholds, and the backup and restore-test calendar for the daily processing bridge with weekly capacity and restore-test reviews layered in. Out of scope: application change management and access provisioning, handled by their own ITGC workflows — suspected change-control bypasses and access findings are cross-referred to those owners. No upstream or downstream workflow feeds this cycle; the certified-and-filed evidence step seeds the next run of this same cycle with carry-forward Issue items linked to the Process.
workflow · Context
SOX ITGC Testing
SOX ITGC Testing as a modular, decision-aware workflow. It runs on the existing Audit engagement item for this ITGC cycle (audit_type: sox_testing, period_start/period_end = the test period) — enrich that item, never create a duplicate — while per-control operating-effectiveness results live on Control-hosted SOX testing workflows, one created per in-scope ITGC control per Workflow.customFields.sox.fiscalYear, each hosted directly on the Control under test. It consumes the ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment, produces the reperformable final ITGC testing package as its named deliverable, and hands the deficiencies off to SOX Deficiency Remediation. In scope: the operating-effectiveness conclusion on the ITGCs protecting in-scope financial systems, reached by referencing the controls-owned NIST 800-53 catalog and its test scripts — not by rebuilding procedures. Out of scope, owned by related workflows: scoping of significant accounts and applications (Annual ICFR Scoping & Risk Assessment), deep completeness-and-accuracy validation of system-generated populations (SOX IPE Validation), and remediation of what fails (SOX Deficiency Remediation, the downstream handoff). It can stand alone, but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.