Business Continuity & Disaster Recovery
336 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
B008 — Protect AI system deployment environment
Protect AI system deployment environment
control · Context
C001 — Define AI risk taxonomy
Define AI risk taxonomy
control · Context
C002 — Conduct pre-deployment testing
Conduct pre-deployment testing
control · Context
C008 — Monitor AI risk categories
Monitor AI risk categories
control · Context
E015 — Log AI system activity
Log AI system activity
control · Context
CCPA-1798.185 — CPPA regulations: cybersecurity audits and risk assessments
CPPA regulations: cybersecurity audits and risk assessments
control · Context
APO09 — Managed Service Agreements
Managed Service Agreements
control · Context
APO10 — Managed Vendors
Managed Vendors
control · Context
BAI03 — Managed Solutions Identification and Build
Managed Solutions Identification and Build
control · Context
BAI04 — Managed Availability and Capacity
Managed Availability and Capacity
control · Context
BAI06 — Managed IT Changes
Managed IT Changes
control · Context
BAI07 — Managed IT Change Acceptance and Transitioning
Managed IT Change Acceptance and Transitioning
control · Context
BAI08 — Managed Knowledge
Managed Knowledge
control · Context
BAI10 — Managed Configuration
Managed Configuration
control · Context
DSS01 — Managed Operations
Managed Operations
control · Context
DSS02 — Managed Service Requests and Incidents
Managed Service Requests and Incidents
control · Context
DSS03 — Managed Problems
Managed Problems
control · Context
DSS04 — Managed Continuity
Managed Continuity
control · Context
MEA04 — Managed Assurance
Managed Assurance
control · Context
DORA-Art17-23 — ICT-related incident management, classification and reporting
ICT-related incident management, classification and reporting
control · Context
DORA-Art24-27 — Digital operational resilience testing (incl. threat-led penetration testing)
Digital operational resilience testing (incl. threat-led penetration testing)
control · Context
DORA-Art28-44 — Managing of ICT third-party risk
Managing of ICT third-party risk
control · Context
DORA-Art5 — Governance and organisation (management body responsibility)
Governance and organisation (management body responsibility)
control · Context
DORA-Ch2 — ICT risk management framework (Art 5-16)
ICT risk management framework (Art 5-16)
control · Context
AIA-Art12 — Record-keeping / logging (high-risk)
Record-keeping / logging (high-risk)
control · Context
AIA-Art15 — Accuracy, robustness and cybersecurity (high-risk)
Accuracy, robustness and cybersecurity (high-risk)
control · Context
AIA-Art19 — Automatically generated logs — provider retention of high-risk system logs (minimum six months)
Automatically generated logs — provider retention of high-risk system logs (minimum six months)
control · Context
AIA-Art27 — Fundamental rights impact assessment for high-risk AI systems (deployers)
Fundamental rights impact assessment for high-risk AI systems (deployers)
control · Context
AIA-Art6-7 — Risk-based classification of high-risk AI systems
Risk-based classification of high-risk AI systems
control · Context
AIA-Art72 — Post-market monitoring by providers of high-risk AI systems
Post-market monitoring by providers of high-risk AI systems
control · Context
HIPAA-164.310 — Physical safeguards (facility access controls, workstation use/security, device and media controls)
Physical safeguards (facility access controls, workstation use/security, device and media controls)
control · Context
Std 9.5 — Coordination and Reliance
Coordination and Reliance
control · Context
IIA-POS-TLM-03 — Assurance Coordination and Reliance
Assurance providers coordinate and rely on one another only where independence, competence, evidence, and coverage support reliance; gaps and duplication remain visible to the board.
control · Context
A.5.11 — Return of assets
Return of assets
control · Context
A.5.19 — Information security in supplier relationships
Information security in supplier relationships
control · Context
A.5.22 — Monitoring, review and change management of supplier services
Monitoring, review and change management of supplier services
control · Context
A.5.23 — Information security for use of cloud services
Information security for use of cloud services
control · Context
A.5.26 — Response to information security incidents
Response to information security incidents
control · Context
A.5.29 — Information security during disruption
Information security during disruption
control · Context
A.5.30 — ICT readiness for business continuity
ICT readiness for business continuity
control · Context
A.5.35 — Independent review of information security
Independent review of information security
control · Context
A.7.1 — Physical security perimeters
Physical security perimeters
control · Context
A.7.11 — Supporting utilities
Supporting utilities
control · Context
A.7.12 — Cabling security
Cabling security
control · Context
A.7.13 — Equipment maintenance
Equipment maintenance
control · Context
A.7.2 — Physical entry
Physical entry
control · Context
A.7.3 — Securing offices, rooms and facilities
Securing offices, rooms and facilities
control · Context
A.7.4 — Physical security monitoring
Physical security monitoring
control · Context
A.7.5 — Protecting against physical and environmental threats
Protecting against physical and environmental threats
control · Context
A.7.6 — Working in secure areas
Working in secure areas
control · Context
A.7.8 — Equipment siting and protection
Equipment siting and protection
control · Context
A.8.13 — Information backup
Information backup
control · Context
A.8.14 — Redundancy of information processing facilities
Redundancy of information processing facilities
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.34 — Protection of information systems during audit testing
Protection of information systems during audit testing
control · Context
A.8.6 — Capacity management
Capacity management
control · Context
A.5.2 — AI system impact assessment process
AI system impact assessment process
control · Context
A.5.3 — Documentation of AI system impact assessments
Documentation of AI system impact assessments
control · Context
A.5.4 — Assessing AI system impact on individuals or groups of individuals
Assessing AI system impact on individuals or groups of individuals
control · Context
A.5.5 — Assessing societal impacts of AI systems
Assessing societal impacts of AI systems
control · Context
A.6.2.4 — AI system verification and validation
AI system verification and validation
control · Context
A.6.2.5 — AI system deployment
AI system deployment
control · Context
A.6.2.6 — AI system operation and monitoring
AI system operation and monitoring
control · Context
A.6.2.8 — AI system recording of event logs
AI system recording of event logs
control · Context
NIS2-Art21d — Supply chain security
Supply chain security
control · Context
CP-10 — System Recovery and Reconstitution
System Recovery and Reconstitution
control · Context
CP-11 — Alternate Communications Protocols
Alternate Communications Protocols
control · Context
CP-12 — Safe Mode
Safe Mode
control · Context
CP-13 — Alternative Security Mechanisms
Alternative Security Mechanisms
control · Context
CP-2 — Contingency Plan
Contingency Plan
control · Context
CP-3 — Contingency Training
Contingency Training
control · Context
CP-4 — Contingency Plan Testing
Contingency Plan Testing
control · Context
CP-6 — Alternate Storage Site
Alternate Storage Site
control · Context
CP-7 — Alternate Processing Site
Alternate Processing Site
control · Context
CP-8 — Telecommunications Services
Telecommunications Services
control · Context
CP-9 — System Backup
System Backup
control · Context
IR-4 — Incident Handling
Incident Handling
control · Context
PE-10 — Emergency Shutoff
Emergency Shutoff
control · Context
PE-11 — Emergency Power
Emergency Power
control · Context
PE-12 — Emergency Lighting
Emergency Lighting
control · Context
PE-13 — Fire Protection
Fire Protection
control · Context
PE-14 — Environmental Controls
Environmental Controls
control · Context
PE-15 — Water Damage Protection
Water Damage Protection
control · Context
PE-18 — Location of System Components
Location of System Components
control · Context
PE-2 — Physical Access Authorizations
Physical Access Authorizations
control · Context
PE-23 — Facility Location
Facility Location
control · Context
PE-3 — Physical Access Control
Physical Access Control
control · Context
PE-4 — Access Control for Transmission
Access Control for Transmission
control · Context
PE-6 — Monitoring Physical Access
Monitoring Physical Access
control · Context
PE-8 — Visitor Access Records
Visitor Access Records
control · Context
PE-9 — Power Equipment and Cabling
Power Equipment and Cabling
control · Context
PM-17 — Protecting Controlled Unclassified Information on External Systems
Protecting Controlled Unclassified Information on External Systems
control · Context
PM-30 — Supply Chain Risk Management Strategy
Supply Chain Risk Management Strategy
control · Context
RA-2 — Security Categorization
Security Categorization
control · Context
RA-9 — Criticality Analysis
Criticality Analysis
control · Context
SA-10 — Developer Configuration Management
Developer Configuration Management
control · Context
SA-17 — Developer Security and Privacy Architecture and Design
Developer Security and Privacy Architecture and Design
control · Context
SA-5 — System Documentation
System Documentation
control · Context
SA-8 — Security and Privacy Engineering Principles
Security and Privacy Engineering Principles
control · Context
SA-9 — External System Services
External System Services
control · Context
SC-2 — Separation of System and User Functionality
Separation of System and User Functionality
control · Context
SC-20 — Secure Name/Address Resolution Service (Authoritative Source)
Secure Name/Address Resolution Service (Authoritative Source)
control · Context
SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver)
Secure Name/Address Resolution Service (Recursive or Caching Resolver)
control · Context
SC-22 — Architecture and Provisioning for Name/Address Resolution Service
Architecture and Provisioning for Name/Address Resolution Service
control · Context
SC-24 — Fail in Known State
Fail in Known State
control · Context
SC-25 — Thin Nodes
Thin Nodes
control · Context
SC-29 — Heterogeneity
Heterogeneity
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-36 — Distributed Processing and Storage
Distributed Processing and Storage
control · Context
SC-39 — Process Isolation
Process Isolation
control · Context
SC-45 — System Time Synchronization
System Time Synchronization
control · Context
SC-47 — Alternate Communications Paths
Alternate Communications Paths
control · Context
SC-49 — Hardware-enforced Separation and Policy Enforcement
Hardware-enforced Separation and Policy Enforcement
control · Context
SC-5 — Denial-of-service Protection
Denial-of-service Protection
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-6 — Resource Availability
Resource Availability
control · Context
SI-10 — Information Input Validation
Information Input Validation
control · Context
SR-1 — Policy and Procedures
Policy and Procedures
control · Context
SR-12 — Component Disposal
Component Disposal
control · Context
SR-2 — Supply Chain Risk Management Plan
Supply Chain Risk Management Plan
control · Context
SR-3 — Supply Chain Controls and Processes
Supply Chain Controls and Processes
control · Context
SR-5 — Acquisition Strategies, Tools, and Methods
Acquisition Strategies, Tools, and Methods
control · Context
SR-6 — Supplier Assessments and Reviews
Supplier Assessments and Reviews
control · Context
SR-8 — Notification Agreements
Notification Agreements
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-TEVV-01 — Define evaluation objectives, context, and measurements
The framework starts with organizational goals and the system's operational context, then constructs measurement concepts, test events, and tools that address those objectives.
control · Context
NIST-TEVV-02 — Run evaluations and examine results and limitations
The framework applies the selected tests and synthesizes their results into evidence about system performance, while interrogating the measurements and what the findings support.
control · Context
NIST-TEVV-03 — Evaluate AI systems in realistic operating settings
The draft discusses testing in settings that better reflect real use, including interactions with users and the operating environment, to complement model tests and benchmarks.
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
GV.RR-04 — Roles, Responsibilities, and Authorities: Cybersecurity is included in human resources practices
Roles, Responsibilities, and Authorities: Cybersecurity is included in human resources practices
control · Context
GV.SC-01 — Cybersecurity Supply Chain Risk Management: A cybersecurity supply chain risk management program, strategy, objectives, policies, and processes are established and agreed to by organizational stakeholders
Cybersecurity Supply Chain Risk Management: A cybersecurity supply chain risk management program, strategy, objectives, policies, and processes are established and agreed to by organizational stakeholders
control · Context
GV.SC-02 — Cybersecurity Supply Chain Risk Management: Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally
Cybersecurity Supply Chain Risk Management: Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally
control · Context
GV.SC-03 — Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes
Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes
control · Context
GV.SC-04 — Cybersecurity Supply Chain Risk Management: Suppliers are known and prioritized by criticality
Cybersecurity Supply Chain Risk Management: Suppliers are known and prioritized by criticality
control · Context
GV.SC-06 — Cybersecurity Supply Chain Risk Management: Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships
Cybersecurity Supply Chain Risk Management: Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships
control · Context
GV.SC-07 — Cybersecurity Supply Chain Risk Management: The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship
Cybersecurity Supply Chain Risk Management: The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship
control · Context
GV.SC-08 — Cybersecurity Supply Chain Risk Management: Relevant suppliers and other third parties are included in incident planning, response, and recovery activities
Cybersecurity Supply Chain Risk Management: Relevant suppliers and other third parties are included in incident planning, response, and recovery activities
control · Context
GV.SC-09 — Cybersecurity Supply Chain Risk Management: Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle
Cybersecurity Supply Chain Risk Management: Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle
control · Context
GV.SC-10 — Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement
Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement
control · Context
ID.AM-08 — Asset Management: Systems, hardware, software, services, and data are managed throughout their life cycles
Asset Management: Systems, hardware, software, services, and data are managed throughout their life cycles
control · Context
PR.AA-06 — Identity Management, Authentication, and Access Control: Physical access to assets is managed, monitored, and enforced commensurate with risk
Identity Management, Authentication, and Access Control: Physical access to assets is managed, monitored, and enforced commensurate with risk
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-02 — Technology Infrastructure Resilience: The organization's technology assets are protected from environmental threats
Technology Infrastructure Resilience: The organization's technology assets are protected from environmental threats
control · Context
PR.IR-03 — Technology Infrastructure Resilience: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations
Technology Infrastructure Resilience: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations
control · Context
PR.IR-04 — Technology Infrastructure Resilience: Adequate resource capacity to ensure availability is maintained
Technology Infrastructure Resilience: Adequate resource capacity to ensure availability is maintained
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.CO-03 — Incident Recovery Communication: Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders
Incident Recovery Communication: Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders
control · Context
RC.CO-04 — Incident Recovery Communication: Public updates on incident recovery are shared using approved methods and messaging
Incident Recovery Communication: Public updates on incident recovery are shared using approved methods and messaging
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-04 — Incident Recovery Plan Execution: Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
Incident Recovery Plan Execution: Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
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
RC.RP-06 — Incident Recovery Plan Execution: The end of incident recovery is declared based on criteria, and incident-related documentation is completed
Incident Recovery Plan Execution: The end of incident recovery is declared based on criteria, and incident-related documentation is completed
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.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-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.11 — Third-party service provider security policy
Third-party service provider security policy
control · Context
500.16 — Incident response and business continuity management
Incident response and business continuity management
control · Context
SOC1-10 — Physical security and environmental controls — controls provide reasonable assurance that physical access to facilities and data centers is restricted and that environmental protections safeguard systems.
Physical security and environmental controls — controls provide reasonable assurance that physical access to facilities and data centers is restricted and that environmental protections safeguard systems.
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
SOC1-12 — Vendor / subservice organization management — controls provide reasonable assurance that subservice organizations relevant to user entities' ICFR are appropriately managed and monitored.
Vendor / subservice organization management — controls provide reasonable assurance that subservice organizations relevant to user entities' ICFR are appropriately managed and monitored.
control · Context
SOC1-4 — Computer operations / job scheduling — controls provide reasonable assurance that production batch jobs and scheduled processing are appropriately defined, executed, monitored, and that exceptions/failures are identified and resolved.
Computer operations / job scheduling — controls provide reasonable assurance that production batch jobs and scheduled processing are appropriately defined, executed, monitored, and that exceptions/failures are identified and resolved.
control · Context
SOC1-5 — Backup and recovery — controls provide reasonable assurance that data is backed up, retained, and recoverable, and that restoration is tested.
Backup and recovery — controls provide reasonable assurance that data is backed up, retained, and recoverable, and that restoration is tested.
control · Context
A1.1 — The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.
The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.
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
A1.3 — The entity tests recovery plan procedures supporting system recovery to meet its objectives.
The entity tests recovery plan procedures supporting system recovery to meet its objectives.
control · Context
CC1.4 — The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives.
The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives.
control · Context
CC6.4 — The entity restricts physical access to facilities and protected information assets (for example, data center facilities, back-up media storage, and other sensitive locations) to authorized personnel to meet the entity's objectives.
The entity restricts physical access to facilities and protected information assets (for example, data center facilities, back-up media storage, and other sensitive locations) to authorized personnel to meet the entity's objectives.
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
CC9.2 — The entity assesses and manages risks associated with vendors and business partners.
The entity assesses and manages risks associated with vendors and business partners.
control · Context
ITGC-OPS — Computer operations — job scheduling and batch processing, backup and recovery, incident/problem management, and monitoring of system processing and availability.
Computer operations — job scheduling and batch processing, backup and recovery, incident/problem management, and monitoring of system processing and availability.
risk · Direct
Public-safety harm from AI in critical infrastructure
Because AI acting as a safety component in critical digital infrastructure, road traffic, or utilities (Annex III(2)) operates without the required risk management, robustness, and human oversight, it can fail or behave unsafely, resulting in service disruption and threats to public safety and continuity.
risk · Direct
Insufficient AI resilience and fallback mechanisms
AI systems lacking fallback, redundancy, or graceful degradation fail catastrophically under adversarial conditions, infrastructure outages, or out-of-distribution inputs, disrupting dependent business processes.
risk · Direct
Aging hardware with no periodic replacement scheme
Because maintenance routines and replacement schedules are absent, equipment is run beyond its reliable service life, so hardware fails - including correlated, pervasive disk failures from same-batch aging - resulting in outages and data loss.
risk · Direct
IT resilience failure — unplanned outage, data loss, slow recovery
Critical technology infrastructure or applications experience unplanned outages, data loss, or prolonged recovery times — including failure of DR systems to activate — disrupting operations and harming stakeholders.
risk · Direct
Absent or untested business continuity / disaster recovery plan
No BCP/DR plan, or plans that exist but have never been exercised end-to-end, so a natural disaster, pandemic, civil unrest, or infrastructure failure disables critical processes with no tested recovery path.
risk · Direct
Single-site / single-region / single-supply concentration
Headquarters, data centers, or manufacturing concentrated in one region, single power feed or network path with no redundancy, and no failover — so one catastrophe or outage disables the whole service. Includes backup-facility loss destroying backups.
risk · Direct
Physical climate risk to facilities and supply chains
Extreme weather (flooding, wildfires, hurricanes, heat stress), sea-level rise, and resource scarcity damage owned/leased facilities, disrupt supplier operations, and impair logistics beyond insurance coverage.
risk · Direct
Critical talent loss, scarcity and succession gaps
Departure of key executives or irreplaceable specialists without succession or knowledge-transfer plans, plus inability to recruit/retain scarce skills (cyber, data, AI/ML), causing loss of institutional knowledge and execution capacity. Also covers loss of key personnel disrupting operations dependent on specialist knowledge.
risk · Direct
Denial-of-service and system saturation
Simple, targeted, or distributed denial-of-service attacks, wireless jamming, and saturation of systems or networks (adversarial or excessive legitimate load) make resources unavailable to intended users.
risk · Direct
Physical and cyber-physical attacks on facilities and infrastructure
Adversary conducts physical attacks on facilities (arson) or supporting infrastructure (cuts power/water), or cyber-physical attacks (remotely altering HVAC), damaging systems and supporting utilities.
risk · Direct
Physical damage to assets from disaster, terrorism or vandalism
Loss or damage to facilities, equipment, or physical property from natural disaster (earthquake, flood, hurricane, wildfire), terrorism, civil unrest, vandalism, utility-infrastructure damage, vehicle/aircraft collision, or environmental contamination.
risk · Direct
Inadequate protection against fire, flood and physical hazards
Absence of fire suppression, smoke detection, flood barriers, or drainage in facilities housing information assets, and poor cabling infrastructure susceptible to damage, tapping, or accidental disconnection.
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.
risk · Direct
Hardware and equipment failure
Malfunction or breakdown of storage, processing, communications, sensor, controller, or display equipment (aging, resource depletion, disk errors) disrupting availability or integrity — including intermittent/degraded operation producing incorrect results.
risk · Direct
Loss of essential services (power, HVAC, telecoms)
Interruption of power supply, air-conditioning/water utilities, or telecommunications — from unstable grids, single power feeds, UPS/generator failure, or carrier/fiber outages — stops operations or harms equipment and personnel.
risk · Direct
Software and information-system failure
Failure or malfunction of operating-system, networking, or application software (defects, resource depletion, failed releases) causing loss of availability/integrity and impeding mission/business functions — including core banking/payments outages.
risk · Direct
Critical vendor failure, insolvency or concentration
A key supplier, SaaS provider, or outsourced partner becomes insolvent, exits the market, or suffers a prolonged outage; sole-source and shared-tier concentration (multiple tier-1 vendors on a common tier-2) creates hidden single points of failure with no backup.
risk · Direct
Supply-chain disruption of critical inputs
Geopolitical events, natural disasters, port congestion, or logistics failures interrupt supply of critical raw materials or components (semiconductors, rare earths); just-in-time models are exposed to demand spikes.
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
ISO/IEC 42001:2023 (AI)
ISO/IEC 42001:2023 Annex A (AI Management System)
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 · Direct
UC-ACCESS-17 — Execute, monitor, and recover production processing
Production batch jobs and scheduled processing are defined, authorized, and monitored, with failures and exceptions logged, tracked, and resolved in a timely manner. Data is backed up on a defined schedule with protected, retained copies, and restoration is periodically tested to confirm recoverability within objectives.
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 · Context
UC-ACCESS-19 — Restrict physical access and maintain environmental safeguards
Physical access to facilities, data centers, and protected assets is authorized, badged, logged, monitored, and revoked on separation, commensurate with risk. Environmental protections including power conditioning and backup, fire detection and suppression, and temperature and humidity control safeguard systems, and physical access and environmental events are reviewed.
unified · Context
UC-ACCESS-21 — Manage subservice organizations supporting the system
Subservice organizations relevant to user entities' control objectives are identified, contractually bound to security and processing commitments, and monitored through review of their independent assurance reports, complementary user-entity controls, and performance. Identified issues are tracked to resolution.
unified · Context
UC-AI-04 — Assess impacts and classify AI systems before deployment
Operate a documented AI impact assessment process performed before deployment and repeated on significant change, assessing consequences for individuals, groups of individuals, and society, including fairness, safety, and fundamental-rights effects. Classify each system against applicable regulatory risk categories, including any high-risk designation, and record the classification rationale. Retain assessment reports, approvals, and reassessment triggers as evidence.
unified · Context
UC-AI-07 — Verify, validate, and control AI deployment and changes
Verify and validate each AI system against its requirements and responsible-AI objectives, documenting test plans, acceptance criteria, and results before release approval. Gate deployment on a documented deployment plan and sign-off confirming requirements are met. Route updates, retraining, and other changes through the same assessment and approval process, including impact reassessment where relevant, and retain verification records and deployment and change approvals.
unified · Context
UC-AI-08 — Log and monitor AI system behavior in operation
Ensure AI systems automatically record event logs that enable traceability of operation over the system's lifetime, including events relevant to identifying risk situations and substantial modification. Retain logs for at least the mandated regulatory minimum, or longer where required. Monitor deployed systems against defined performance and behavior metrics with alerting and escalation for anomalies and drift, and retain logs and monitoring reviews as evidence.
unified · Context
UC-ASSET-07 — Manage assets through their life cycle and recover them at exit
Manage systems, hardware, software, services, and data through their full life cycles from acquisition through secure retirement, with defined ownership and handling at each stage. Recover all organizational assets from personnel and other interested parties upon termination or change of engagement, tracking issuance and verified return.
unified · Direct
UC-ASSET-12 — Operate scheduled processing, backup, and availability monitoring
Schedule and monitor batch jobs and system processing, investigating and resolving failures through documented incident and problem management. Perform and verify data backups and periodically test recovery capability. Monitor system processing and availability against defined service expectations, with documented follow-up on deviations.
unified · Context
UC-AUDIT-23 — Coordinate independent assurance reviews across providers
The organization plans and obtains independent reviews of its approach to managing and implementing information security - including people, processes, and technologies - at planned intervals, after significant changes, and where required by applicable law or regulation. Before relying on another provider's work, each reliance decision assesses and records the provider's independence and objectivity, competence and methodology rigor, evidence quality and reperformance capability, and recency against the covered risk's cadence, together with the resulting reliance level and rationale. Assurance activities are coordinated across internal and external providers to ensure coverage, minimize duplication, and support reliance on others' work. Material reliance limitations, assurance gaps, and duplication remain visible to management and the board. Results are reported to management and the board and drive corrective actions.
unified · Direct
UC-BCDR-01 — Maintain business continuity and disaster recovery plans
Maintain documented, management-approved business continuity and disaster recovery plans that cover critical business functions and ICT services, recovery time and recovery point objectives, assigned roles, and how information security is preserved at required levels during disruption. Base the plans on a business impact analysis, distribute them to responsible personnel, and review and update them at least annually and after significant organizational or technology changes.
unified · Direct
UC-BCDR-02 — Establish and govern an ICT operational resilience framework
Establish a documented ICT risk management framework covering identification, protection, detection, response, recovery, and learning for critical ICT services, with a defined digital operational resilience strategy and risk tolerance. The management body approves the framework, assigns clear roles and responsibilities for ICT risk, allocates supporting budget, reviews the framework at least annually, and remains accountable for its effectiveness.
unified · Direct
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 · Direct
UC-BCDR-04 — Provide redundant and alternate processing, storage, and telecom
Implement redundancy and alternate capability sufficient to meet availability and recovery objectives: an alternate storage site for backup media, alternate processing capability sufficiently separated from the primary site to avoid shared hazards, and diverse or alternate telecommunications services with priority-of-service provisions. Ensure alternate facilities provide security controls equivalent to the primary site and can assume operations within recovery time objectives.
unified · Direct
UC-BCDR-05 — Manage capacity to meet availability requirements
Determine and monitor the processing capacity and utilization of infrastructure, data, and software against current and forecast demand, and add capacity before demand exceeds defined thresholds. Protect availability of shared resources through priority-based allocation or quotas, and alert responsible personnel when capacity thresholds are breached.
unified · Direct
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 · Direct
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 · Direct
UC-BCDR-08 — Declare recovery complete and set post-incident norms
Define criteria for ending incident recovery and formally declare recovery complete only when those criteria are met. Complete all incident and recovery documentation, and establish post-incident operational norms that account for critical mission functions and residual cybersecurity risk.
unified · Direct
UC-BCDR-09 — Communicate recovery status to stakeholders
Communicate recovery activities, progress, and estimated restoration timelines to designated internal and external stakeholders through pre-defined channels and cadences. Release public updates about incident recovery only through approved spokespersons, methods, and messaging.
unified · Direct
UC-BCDR-10 — Test recovery capabilities and train contingency personnel
Test business continuity, disaster recovery, and restoration capabilities at least annually through scenario exercises, failover and restore tests, and, where required for critical systems, advanced or threat-led penetration testing. Train all personnel with contingency roles on their responsibilities upon assignment and periodically thereafter. Review test and exercise results and remediate identified gaps.
unified · Direct
UC-BCDR-11 — Sustain operations via safe modes and alternate mechanisms
Design critical systems to continue operating safely when primary capabilities fail: enter a defined safe mode of operation that restricts functions when specified conditions are detected, switch to alternate communications protocols to maintain continuity, and employ alternative security mechanisms when primary security safeguards are unavailable.
unified · Direct
UC-BCDR-12 — Operate IT services according to defined procedures
Execute day-to-day IT operations, including job scheduling, processing, infrastructure monitoring, and facility management, according to documented operating procedures. Monitor operations against expected outcomes, record exceptions, and correct deviations to sustain reliable service delivery.
unified · Context
UC-HR-06 — Embed security and competence in HR practices
Human resources processes incorporate cybersecurity at each stage, from recruiting and onboarding through role change and separation, with defined security checkpoints. The organization defines competence requirements for roles, attracts and develops qualified personnel through training and performance evaluation, and plans for succession and contingency in security-relevant positions.
unified · Context
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 · Context
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 · Context
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 · 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-NET-07 — Secure name resolution and time services
Provide authoritative name-resolution service with origin authentication and integrity verification (e.g., DNSSEC), and perform data-origin authentication and integrity validation in recursive or caching resolvers. Architect name-resolution services to be fault tolerant and to enforce internal and external role separation, and synchronize system clocks to authoritative time sources so events can be correlated reliably.
unified · Context
UC-NET-08 — Maintain communications availability under attack and failure
Protect network services against denial-of-service events through capacity management, rate limiting, filtering, or upstream DoS-mitigation services. Ensure components fail to a known, secure state while preserving essential state information, and maintain alternate communications paths so operations can continue if primary channels degrade or fail.
unified · Context
UC-NET-09 — Reduce attack surface through resilient architecture
Architect infrastructure to resist attack and localize failures: deploy minimal-functionality (thin) nodes where feasible, employ heterogeneity in key technologies to avoid common-mode compromise, and distribute processing and storage across multiple physical locations or components. Review these architecture decisions against current threats periodically.
unified · Context
UC-PHYS-01 — Restrict physical access to facilities and secure areas
Define physical security perimeters and secure areas, and authorize, issue, and periodically review physical access credentials so only authorized personnel can enter facilities, offices, and sensitive locations such as data centers and backup media storage. Enforce entry controls at every access point, escort and log visitors, and apply defined rules for working in secure areas. Maintain physical access audit logs for entries and exits at controlled access points, and secure, inventory, and rotate physical access devices such as keys, combinations, and badges when compromised or when personnel change. Revoke or adjust physical access promptly upon termination or role change.
unified · Context
UC-PHYS-02 — Monitor physical access and retain visitor and entry records
Continuously monitor physical access to facilities and sensitive areas using surveillance, intrusion detection, and review of physical access logs. Maintain visitor access records including identity, date, time, and purpose of entry. Review monitoring output and access records on a defined cadence, retain them for the required period, and investigate anomalies and apparent violations.
unified · Context
UC-PHYS-03 — Protect facilities against fire, water, and environmental hazards
Design and equip facilities to protect technology assets from fire, water, temperature, humidity, and other physical and environmental threats. Deploy and independently maintain fire detection and suppression, water damage detection with accessible shutoff valves, and environmental monitoring and control at required levels. Configure alarms to notify responsible personnel automatically when protective systems activate or parameters go out of range.
unified · Context
UC-PHYS-04 — Site facilities and equipment to minimize hazards and exposure
Position facilities and system components to minimize damage from physical and environmental hazards and to reduce opportunities for unauthorized access and observation. Consider physical and environmental risk when selecting facility locations, and apply compensating safeguards for equipment sited in higher-risk locations.
unified · Context
UC-PHYS-05 — Provide emergency power, lighting, and resilient utilities
Protect supporting utilities such as power, HVAC, and telecommunications from failure and disruption, with inspection and maintenance on a defined schedule. Provide uninterruptible power and generator capacity sized to enable orderly shutdown or continued operation of critical systems, and automatic emergency lighting covering evacuation routes. Provide accessible, protected emergency shutoff capability to cut power to systems safely in an emergency.
unified · Context
UC-PHYS-06 — Protect power and communications cabling from damage and taps
Protect power equipment and power and telecommunications cabling from interception, interference, and damage, using measures such as protected conduits, separation of power and communications lines, and controlled access to patch panels, wiring closets, and transmission infrastructure. Periodically inspect cabling and access points for tampering or unauthorized devices.
unified · Context
UC-PHYS-08 — Maintain equipment to preserve availability and integrity
Maintain equipment according to manufacturer specifications and a defined schedule, using only authorized maintenance personnel. Record all maintenance activity and suspected or actual faults, and apply safeguards that prevent information exposure during servicing, including clearing or supervising equipment sent off site for repair.
unified · Context
UC-RISK-18 — Categorize systems and components by impact and criticality
Systems and the information they process, store, and transmit are categorized based on the potential impact of a loss of confidentiality, integrity, and availability, with categorization decisions documented and approved by accountable officials. Criticality analysis identifies critical system components, functions, and dependencies so protection and resilience investments are prioritized accordingly.
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.
unified · Context
UC-SDLC-06 — Maintain configuration control over systems and code
Maintain configuration management over solution components throughout development and operation: identify configuration items, establish and protect baselines for code, dependencies, and build settings, record and verify configuration information, and review deviations. Require developers to track the integrity of changes to configuration items, implement only approved changes, and track and resolve resulting security flaws.
unified · Context
UC-SDLC-07 — Approve, test, and accept changes before production release
Evaluate, prioritize, and authorize all IT changes, including emergency changes, before implementation, with documented impact and risk assessment. Establish acceptance criteria, perform acceptance testing in an environment representative of production, obtain business and IT approval, and promote releases through a controlled, auditable transition with fallback plans and post-implementation review.
unified · Context
UC-SDLC-08 — Maintain current system documentation and knowledge
Obtain, produce, and maintain current administrator and user documentation for systems, covering secure configuration, use, and maintenance, and protect and distribute it to authorized roles. Keep development and operational knowledge validated, current, and available to the personnel who need it.
unified · Context
UC-SDLC-13 — Plan solution availability and capacity
Plan, monitor, and manage the availability and capacity of solutions and services against current and forecast business requirements. Assess the impact of demand changes, address projected shortfalls through corrective plans, and validate that agreed availability and capacity targets are met.
unified · Context
UC-SDLC-14 — Protect production systems during audit testing
Plan and agree audit and assurance testing of operational systems between the tester and appropriate management before testing begins: define and approve scope, limit testers to read-only access where possible or use isolated copies, schedule tests to minimize disruption, and monitor and log all audit access.
unified · Context
UC-TPRM-01 — Operate a third-party security risk management program
Establish and operate a management-approved third-party and supply-chain risk management program with a written strategy, policies, and procedures, reviewed at defined intervals and after significant changes to the supply chain or threat landscape. Define and communicate roles and responsibilities for supplier, customer, and partner relationships, and integrate third-party and supply-chain risk into enterprise and cybersecurity risk management. Maintain a register of third-party relationships and contractual arrangements prioritized by criticality, and assess criticality, substitutability, and concentration risk before contracting. Apply risk-based due diligence, embed security requirements, audit and access rights, termination rights, and sub-outsourcing conditions in agreements, and protect organizational information processed, stored, or transmitted on external systems. Define, agree, and periodically review service agreements and supplier performance, reassess third parties on a defined cycle, operate controls to identify and address weaknesses across the relationship life cycle, and maintain documented, tested exit strategies for providers supporting critical or important functions.
unified · Context
UC-TPRM-02 — Perform risk-based due diligence before engaging vendors
Before entering a formal relationship, perform security due diligence on prospective vendors and business partners proportionate to their criticality, evaluating security posture, financial and operational risk, and supply-chain exposure, and document the acceptance decision. Use acquisition strategies, sourcing methods, and selection criteria designed to reduce supply-chain risk before contract award.
unified · Context
UC-TPRM-04 — Monitor vendor performance, services, and risk
Continuously monitor third-party performance, service delivery, and security posture against contractual and risk requirements throughout the relationship. Conduct periodic reassessments and reviews, such as questionnaires, assurance reports, and audits, at a frequency based on criticality, and manage changes to supplier services. Record, prioritize, and track identified vendor risks through response and remediation.
unified · Context
UC-TPRM-05 — Include suppliers in incident notification and response
Establish agreements or contractual provisions requiring suppliers to notify the organization of security incidents and supply-chain compromises within defined timeframes. Include relevant suppliers and third parties in incident-response planning, exercises, response, and recovery activities, with coordination roles defined in advance.
unified · Context
UC-TPRM-06 — Manage secure termination and disposal at relationship end
Include termination and post-relationship provisions in supplier agreements and supply-chain risk plans: return or verified destruction of data, revocation of access and credentials, service transition, and retention of required evidence. Dispose of data, documentation, tools, and system components securely at end of life or end of relationship using defined techniques, and record each disposal.
unified · Context
UC-TPRM-08 — Govern security of external and cloud service use
Define and enforce processes for acquiring, using, managing, and exiting external system services and cloud services in line with the organization's information security requirements. Require external providers to comply with those requirements, define oversight roles and responsibilities on both sides, agree service and exit terms, and monitor provider compliance on an ongoing basis.
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
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
Third-Party Vendor Assurance Engagement
Runs on the existing Audit item for this engagement (audit_type=vendor_review) — the workflow enriches that already-planned engagement record, it never creates a duplicate — consuming the confirmed scope, criteria, and calendar handed off from Audit Engagement Planning. An IA-led third-party vendor assurance engagement that concludes on the design and operating effectiveness of the organization’s TPRM program — governance, risk tiering, vendor control-environment reliance, monitoring, exclusions, and reporting. Vendors under test are the existing Vendor items, each finding is an Issue item, and the named deliverable is a reperformable engagement workpaper package. In scope: assuring the program (IA evaluates management’s third-party risk management; it does not operate it). Out of scope: operating the vendor lifecycle (onboarding, tier refresh, remediation), which belongs to the second-line Third-Party Vendor Risk Lifecycle workflow; deep single-report SOC work, which can be delegated to the reusable Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow; and ICT arrangements caught by regulatory regimes, which route to Third-Party ICT Vendor Regulatory Assurance. Findings and the engagement conclusion exit through Audit Report Drafting, and action plans route to Finding Remediation & Action-Plan Monitoring.
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
Vendor SOC 1/SOC 2 Report Review & CUEC Mapping
Reach a defensible reliance conclusion on a service organization's SOC 1/SOC 2 report. The workflow instance runs on an Audit item (audit_type: vendor_review) created for this vendor's SOC report period — enrich that item, never duplicate it; its native fields carry the report and reliance metadata (external_firm = CPA firm, opinion = service auditor's opinion, period_start/period_end = report coverage, report_date, rating = overall reliance verdict). Consumes the vendor risk handoff package from the Third-Party Vendor Risk Lifecycle workflow — the existing Vendor item, its tier, and the dependent Process items. In scope: report scope and type confirmation, the service auditor's opinion and exception analysis, complementary user entity control (CUEC) mapping, bridge/gap-period coverage, and the documented reliance decision — producing the SOC reliance memo and the reviewer-ready reliance package. Out of scope: the vendor's initial risk tiering and onboarding, and ongoing control monitoring. Hands the completed reliance package to the Continuous Controls Monitoring (ISCM) Cycle (and Third-Party ICT Vendor Regulatory Assurance) workflows.
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
ISMS Internal Audit & Management Review
Runs one ISO 27001 clause 9.2 internal audit and clause 9.3 management review cycle — including clause 10.1 corrective actions — against the existing Audit item for this cycle (audit_type=internal), whose scope, lead_auditor, and period dates already carry the ISMS audit-programme entry: the workflow enriches that Audit item and its findings, never creates a duplicate audit. Upstream it consumes the Annex A control population (Control items, framework iso-27001) and the applicability decisions in the Statement of Applicability, the risk register (Risk items) and treatment plan, the prior-cycle Audit and open Issue records, and the org's ISMS policies and procedures (Policy items) as audit criteria. Named deliverables: the internal audit findings report, the clause 10.1 corrective-action records (recorded on the finding Issue items), the management review pack, and the approved clause 9.3 minutes and action register. Out of scope: the certification-body external audit and day-to-day control operation. No upstream workflow feeds this cycle and no single downstream workflow consumes its output; at close the cycle is archived on the Audit item as retained ISMS documented information, and carry-forward items re-enter the audit programme (the next PLANNED Audit item), the risk register, or the next review's inputs.
workflow · Context
SOC 2 Readiness & Evidence Collection
SOC 2 Readiness & Evidence Collection runs ON an already-opened Audit item — the SOC examination engagement record (audit_type readiness, or external_attestation) whose scope (report type and Type 1/Type 2), examination period (period_start/period_end), and CPA firm (external_firm) are already set. That Audit item is an INPUT: this workflow enriches it and attaches its run to it, never creating a duplicate engagement. It consumes the organization's own Control library — the Control items, framework tagged soc2/soc1 — and no upstream workflow feeds it. In scope: one SOC examination cycle end to end — map the Control library to each in-scope Trust Services criterion (Security always; Availability, Confidentiality, Processing Integrity, or Privacy only where a customer commitment requires it) and SOC 1 control objective, close readiness gaps, run the provided-by-client (PBC) evidence request list with QA, and coordinate the CPA firm through fieldwork and follow-ups. Named deliverables: the criteria-to-control mapping matrix and graded gap matrix, the owned PBC evidence request list, the QA'd evidence set, and the cross-referenced PBC response package — all attached to the anchor Audit and its workflow instance. Out of scope: the SOC report the CPA firm drafts and continuous control monitoring between examinations. No downstream workflow is declared; this run's next-cycle seed artifacts (the PBC list and control calendar) stay on the close step as the de facto handoff to the next examination.
workflow · Context
Joiner-Mover-Leaver Access Lifecycle
Run one instance per HR-triggered joiner, mover, or leaver event as a decision-routed access-lifecycle control that enriches the EXISTING Control item for JML / user-access provisioning-deprovisioning (control library, domains=access_control_identity, framework nist-800-53 + iso-27001) - attach the instance to that control, never create a duplicate. Consume the authoritative HR event record from the external HR system of record (the trigger): classify the event, then provision role-based access, adjust with SoD checks on transfer, or evidence timely removal on exit, and file the named audit-ready access-lifecycle evidence package before closing. In scope: identity-provider, directory, HR-system, ERP, and connected-SaaS entitlements for the affected worker. Out of scope: HR record creation itself, physical-security badge policy, and system-owner entitlement design. The run is terminal - no upstream or downstream AssureSwarm workflow: it starts from the external HR event and ends at the archived evidence package attached to the Control item. The anchor Control links (item relationship) to the access Risk it mitigates.
workflow · Context
CSF 2.0 Profile & Maturity Assessment
Runs on an Audit item created for this assessment cycle (audit_type = readiness) — the CSF assessment engagement the workflow instance attaches to and enriches as it progresses (scope, period, rating, and report fields are written on that Audit item; every in-scope Control is linked to it so the controls-scoped profile is queryable). Build, against that boundary, a NIST CSF 2.0 Current Profile, a Target Profile, an organizational Tier rating, a subcategory gap analysis, and a CISO-ready remediation roadmap. The workflow originates on its own — scoping ingests prior CSF profiles and open POA&M (Issue) items as data, not as a named upstream handoff. In scope: rating the in-scope control set against the CSF 2.0 Core, setting target outcomes, assigning a Tier, and producing a prioritized roadmap. Out of scope: executing the remediation projects themselves and re-performing independent assurance testing. The named deliverable is the assessment package (profiles, gap analysis, Tier, posture report, roadmap, closure artifact), handed off to TWO downstream workflows that consume it rather than repeat the profiling: the Cybersecurity Assurance Review (always) and the AI Governance & Risk/Impact Assessment (only when AI systems fall inside the boundary).
workflow · Context
System Categorization, Security Planning & Authorization
Operator workflow for the system owner and authorizing official to categorize a system by impact and criticality, maintain the approved system security and privacy plan, authorize internal connections, and grant and track authorization to operate, as a decision-aware flow with categorization-approval and authorization branches. In scope: a single system — its impact and criticality categorization, the system security and privacy plan, internal-connection authorization, and the authorization-to-operate decision with reauthorization tracking. Out of scope: the control assessments and testing that feed the authorization risk view (consumed as an input) and enterprise categorization-policy setting; there is no upstream or downstream workflow, so any cross-workflow dependency is declared as a step input rather than routed.
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
Facility Access Administration & Monitoring
Standing monthly operator workflow anchored to the existing **Facility Access Administration** Process item (process_type: security_process), with the operated Control items UC-PHYS-01, UC-PHYS-02, and UC-ACCESS-19 (control_category: physical, frequency: monthly) linked to it; each cycle runs as a fresh workflow instance and its reconciliation packages, decision forms, and Issue items attach to that instance. It covers credential authorization, entry control and visitor logging, key/badge custody and revocation — plus the monthly surveillance, access-log, and environmental-safeguards review with facilities, including the data-center and protected-asset access confirmation. In scope: authorization, issuance, and periodic re-justification of physical credentials; entry-control and visitor-escort enforcement; key/combination/badge custody, rotation, and revocation; and the monthly surveillance, access-log, visitor-record, and environmental-safeguards review across all facilities, perimeters, and secure areas including the data center and other protected-asset locations. Out of scope: logical/system access provisioning and full incident-response investigation — a confirmed intrusion or data-center compromise is handed off to the incident-response process. No upstream workflow feeds this capability; it runs on its own monthly cadence and on personnel-change and reported-anomaly triggers, and terminates at close-and-archive (the run itself is the retained audit trail — no other downstream workflow consumes the cycle package). Control references: NIST 800-53 PE-2/PE-3/PE-6/PE-8, ISO 27001 A.7.1–A.7.4/A.7.6.
workflow · Context
Environmental & Utility Systems Maintenance
Standing operator workflow for the monthly environmental and utility systems preventive-maintenance calendar — fire/water/environmental protection, emergency power and lighting, protected cabling, and electromagnetic shielding — producing the single maintenance-and-inspection log required as evidence. Anchor: each monthly cycle runs as a new workflow instance attached to the existing umbrella physical/environmental-maintenance Control item in the control library (control_category=physical, frequency=monthly, framework nist-800-53|iso-27001|nist-csf-2), with the specific UC-PHYS-03/05/06/07 Control items linked — the run enriches that Control's execution history, never creates a duplicate control. Consumes its inputs directly with no feeder workflow: the PM calendar entry, the fire/water/power/lighting/cabling/shielding asset inventories, and the independent maintenance vendor's service tickets and test records (the vendor is a Vendor item in the third-party register; its tickets attach as step evidence). The prior cycle's archived export and its still-open deficiency Issues (linked to the anchor Control) are the only carry-forward channel. In scope: the physical environmental and utility protection systems for the in-scope facilities and rooms (fire detection and suppression, water-damage detection and shutoff valves, temperature/humidity monitoring, UPS and generators, emergency lighting and power shutoffs, protected cabling and wiring closets, and electromagnetic shielding). Out of scope: logical access, network security, and the building's base construction. There is no downstream workflow: this standing cycle drains to its own retained archive and seeds next month's cycle with the corrective-action Issues left open.
workflow · Context
Equipment Maintenance, Movement & Marking Control
Standing operator workflow that runs on the existing physical-equipment Control item (the UC-PHYS-04/08/10/12 control, domains=physical_environmental_security, frequency=quarterly): each maintenance, movement, or installation/relocation event opens one workflow instance against that Control item and enriches it with the cycle's evidence, never creating a duplicate control. It covers equipment maintenance, asset movement, and installation/relocation siting and marking, converging into the quarterly reconciliation that ties all three evidence streams together. In scope: scheduled and unscheduled maintenance events, asset delivery/removal/movement events through isolated loading areas, and installation/relocation siting and hardware marking within the facility's data halls, plus the quarterly reconciliation of the three. Out of scope: media sanitization and data-disposal workflows and physical access-control administration, which are governed by their own controls. Named deliverables: the maintenance record pack, the asset movement record with designated-asset tracking reconciliation, the siting-and-marking record, and the consolidated quarterly reconciliation evidence set, plus Issue items for faults, movement investigations, and marking gaps. No upstream workflow feeds this cycle and it hands off to no downstream workflow; it is triggered directly by a maintenance, movement, installation/relocation, or quarterly-reconciliation event, is owned by the Data Center Operations Coordinator, and its close-and-archive step seeds its own next cycle via carry-forward Issue items linked to the Control.
workflow · Context
IT Availability & Resilient Failure Operations
Standing operator workflow for the monthly IT availability and resilient-failure-operations cycle: batch and processing monitoring with incident and problem resolution, backup and restore verification, availability-to-SLA tracking, network capacity and DoS-mitigation posture, fail-secure and alternate-communications readiness, and the mean-time-to-failure replacement queue with verified fail-safe procedures, as a decision-aware flow that escalates an urgent reliability gap immediately and rolls routine findings into a single end-of-cycle corrective-action log. Each monthly instance runs against the EXISTING Control item for this IT-availability and resilient-failure-operations control (frequency: monthly; framework: nist-800-53 + sox; domains: business_continuity_disaster_recovery, network_communications_security, incident_management_response) — it enriches that standing control with the cycle's evidence rather than creating a new record: per-stream evidence attaches as documents on the workflow instance's steps, operational failures and gaps become Issue items linked to that Control, and the named deliverable is the signed monthly control record (the classify-cycle-disposition form plus its disposition summary), backed by the monitoring roll-up, incident-and-problem log, backup-and-restore summary, availability dashboard, capacity and fail-secure verification records, and the corrective-action register. In scope: the in-scope batch jobs and system processing, network services and communications paths, and components tracked for mean-time-to-failure named in the operating brief, measured against their defined availability and processing service expectations; out of scope: application change management, access provisioning, and physical-environment controls, which are operated by their own workflows. This is a standing monthly cycle with no upstream workflow dependency and no downstream handoff — its inputs are the organization's own scheduler and monitoring feeds, backup history, capacity telemetry, and asset/MTTF inventory; its archived record seeds the next monthly instance of the same control.
workflow · Context
Change & Release Management (CAB)
Change & Release Management (CAB) as a decision-aware workflow that runs one recurring weekly instance against the EXISTING change-management ITGC Control item in the control library (domains: secure_configuration_change_management; mapped via Control.framework to nist-800-53, cobit-2019, iso-27001, and soc1, alongside the related UC-CONFIG-02/03, UC-ACCESS-16, and UC-SDLC-06/07/08/09 controls) — it enriches that control's operating evidence each cycle, it does not create the control. Upstream it consumes the open change-request queue and the emergency-change log exported from the ticketing system, plus the prior cycle's closure export as its carry-forward backlog. It covers change intake, security and risk impact analysis, environment segregation and configuration-baseline control, acceptance testing, the single CAB authorization gate, the emergency-change path, and controlled deployment with rollback and post-implementation verification — producing the prioritized CAB agenda and authorization packet, per-change risk-assessment memos, the environment-and-baseline verification memo, acceptance-testing summaries, the deployment-and-verification record, and the archived per-cycle evidence set. In scope: application, database, infrastructure, configuration, and procedure changes across development, test, and production environments. Out of scope: authoring the change itself — this workflow governs authorization and release, not development of the underlying code or configuration. Studio ships no native Change Request item type, so per-change records live as lines in step documents and in the workflow instance rather than as items. This is a terminal workflow with no downstream handoff: closure archives the cycle evidence set in place under retention, and the next cycle's intake reads this instance's closure export as its carry-forward source.
workflow · Context
Secure Connectivity & Network Trust Services Operation
Standing operator workflow for remote/wireless/mobile access re-authorization, session trusted-channel and termination verification, and DNSSEC/name-resolution and time-service assurance, as a decision-aware quarterly cycle that contains rogue access before continuing and routes gaps to tracked corrective action. Each quarterly instance attaches to the existing standing Process item (process_type: security_process, frequency: quarterly) for Secure Connectivity & Network Trust Services — it enriches that Process cycle-over-cycle, never creating a duplicate — and that Process is related to the existing Control items UC-NET-02, UC-NET-03, and UC-NET-07 the cycle operates. In scope: remote-access methods, wireless networks, and organization-controlled mobile devices; systems hosting security-relevant sessions; authoritative DNS zones, recursive and caching resolvers, and authoritative time sources. Out of scope: endpoint hardening and identity/credential lifecycle beyond out-of-band key delivery. The cycle runs on its own quarterly trigger and consumes no upstream workflow handoff package; it produces the re-authorization register, the sweep and containment logs, the session-trust and name-resolution/time assurance records, the connectivity trust-posture dashboard and summary, and a corrective-action register — closing into an internal carry-forward that seeds the next quarterly instance (no handoff to a distinct downstream workflow).
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
Resilient Architecture & Non-Persistence Operations
Standing operator workflow that runs each quarter against the existing NIST 800-53 resilient-architecture / non-persistence Control item in the control library (framework=nist-800-53, SI/SC family covering SI-14, SI-21, SI-22, SI-23, SC-25, SC-29, SC-36, frequency=quarterly, control_owner = Infrastructure Architecture Lead); the recurring instance attaches to and enriches that Control — it never creates a new control. In scope: non-persistent provisioning and information refresh, diverse sourcing and fragmentation of high-value data, and the resilient-architecture review of thin nodes, technology heterogeneity, and distributed processing and storage against current threats. It consumes no upstream workflow handoff; its inputs are the standing non-persistence and resilient-architecture inventories — the critical-information suppliers adopt the native Vendor type, while the infrastructure components, information stores, and fragmentation entries have no native item type and are held as register documents on the anchor Control — plus any open carryover Issue items from the prior cycle. Named deliverables: the refresh-and-attestation log, the sourcing-diversity and fragmentation-verification report, the thin-node / heterogeneity / distribution assessments, the combined resilience-posture dashboard and posture-review summary, and the adjustment-action register; exceptions, drift, and gaps normalize into Issue items linked to the Control. Out of scope: incident response itself — a suspected refresh-source compromise is contained and escalated to the incident-response team (an escalation, not a workflow handoff) — and application-layer change management. This is a terminal recurring cycle: close-and-archive exports the run as the durable operating record and seeds the next quarter's inputs.
workflow · Context
Resilience & Failover Readiness Verification
Standing quarterly operator workflow that verifies alternate storage, alternate processing, and diverse telecommunications capability (UC-BCDR-04) and validates the safe-mode, alternate-communications, and alternate-security-mechanism design configured on critical systems (UC-BCDR-11). Each quarterly instance runs against the EXISTING UC-BCDR-04 alternate-capability Control item in the Control library (frequency quarterly), with the UC-BCDR-11 degraded-mode Control item linked as the second in-scope control — it enriches the evidence trail on those existing controls, never creating a duplicate control. Self-originating: it consumes no upstream workflow handoff, reading the two governing Control items (control_id UC-BCDR-04 and UC-BCDR-11), the prior quarter's archived readiness instance, and the open corrective-action Issues carried forward on those controls; all operational reference data (backup schedule, alternate-site media/replication log, site records, telecom inventory, system design specs and configs) enters as PBC uploads on the verifying step, since none of it is item-typed. In scope: confirming that this alternate capability and degraded-mode design remain current, hazard-separated, secured to primary-site parity, and ready to assume operations within RTO. Out of scope: the live failover exercise that actually cuts over to the alternate site, run separately by the assure-line DR test workflow that consumes the readiness state this workflow maintains. Named deliverables: six verification memos (storage-site, processing-capability, telecom, safe-mode, alternate-communications, alternate-security), a readiness dashboard and a signed readiness summary, and a corrective-action register — every gap converts into an owned corrective-action Issue (issue_type: deficiency, source: self_assessment) linked to the impaired Control, with any recovery-time-impacting gap escalated immediately rather than held for end-of-cycle closure. Downstream handoff: the archived readiness summary and dashboard serve as the readiness-state package the assure-line DR test workflow reads (no terminal handoff node exists yet — see the closure step).
workflow · Context
IT Operations & Capacity Management Cycle
Standing operator workflow for the weekly IT operations and capacity management cycle. It runs on the EXISTING **Process** item "IT Operations & Capacity Management" (process_type: operational, process_owner: IT operations manager, frequency: weekly): each weekly cycle is a new workflow instance attached to that Process — the Process is enriched, never recreated — with the operated **Control** items (job-scheduling, infrastructure-monitoring, and capacity controls; frequency: weekly) linked to it via a Control ↔ Process relationship. The instance executes and reconciles daily job scheduling, processing, infrastructure monitoring, and facility management against documented procedure, then assesses capacity and utilization against forecast demand, triggers capacity additions and priority-allocation safeguards ahead of threshold breach, and produces the named evidence set: the weekly operations review minutes, the consolidated exception log, and the capacity-and-utilization report (plus a recurring capacity-and-utilization dashboard). In scope: daily job scheduling, processing, infrastructure monitoring, and facility management for the operator's named in-scope systems and facilities, plus the weekly capacity and utilization review of infrastructure, data, and software against forecast demand. Out of scope: incident response, change management, and disaster-recovery testing, which run as their own workflows; this cycle raises corrective actions and capacity-addition requests (tracked as Issue items) that feed change management in substance but models no explicit handoff node — it is a terminal, self-originating operate-line cycle that does not itself execute infrastructure changes. No upstream workflow feeds it: its inputs are the operator's own job schedules, monitoring and facility feeds, the governing operating-procedure and capacity-threshold and quota **Policy** items, and the prior cycle's carryover **Issue** items (created when the signed weekly operations review closes the cycle) that arrive as tracked inputs — and the cycle seeds its own next-cycle carryover the same way.
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
Technology Lifecycle & Capacity Review
Standing operator workflow for the quarterly solution-asset lifecycle review and the availability/capacity planning cycle, from asset reconciliation and end-of-support disposition through capacity monitoring, corrective planning, and prior-period target validation. Each quarterly run is a recurring workflow instance attached to the EXISTING technology-lifecycle-and-capacity-management Control item (UC-SDLC-12/13; frequency = quarterly; control_owner = the IT control owner) — the instance enriches that standing Control and its linked records, never a fresh duplicate; the governing COBIT 2019 / NIST 800-53 mapping rides on Control.framework. In scope: the in-scope solutions, applications, and supporting infrastructure components (the services they run are Process items) with named owners, and the services carrying agreed availability and capacity (SLA/SLO) targets. Out of scope: the projects that execute an approved replacement or upgrade (each tracked externally as its own project item) and live incident response for availability outages. Named deliverables: the reconciled solution-asset register and optimization actions, the ranked end-of-support exposure list and disposition, funded replacement/upgrade plans (Issue items) and compensating-control records (Control items) with signed risk acceptances (policy_exception Issues carrying exception_expiry_date, on treatment: accept Risks), the capacity/availability dashboard and corrective plans, and the validated prior-period target package. No upstream workflow feeds this cycle and there is no separate downstream workflow to hand off to — the still-open replacement/upgrade plans, capacity corrective plans, and risk-acceptance expiries (their existing Issue and Risk items, linked to the anchor Control) carry forward as explicit inputs to the next quarterly run of this same workflow.
workflow · Context
AI Operations Monitoring & Incident Response
Each monthly instance runs against the existing Control item for AI operations monitoring and incident response (framework eu-ai-act + iso-42001; domains ai_governance / logging_monitoring_detection / incident_management_response; frequency monthly; control_owner AI Operations Manager) — the run enriches that Control's execution history and is its evidence of operation, it never creates a duplicate. The decision-aware cycle covers event-logging and retention verification, alert resolution, human-oversight confirmation, AI-use screening against legal prohibitions, and AI concern-and-incident triage through required communications and regulator reporting, consolidating all five streams into a named cycle report and cycle dashboard while every residual gap is booked as an Issue (source: management_identified) linked to the anchor Control. In scope: every deployed production, limited-risk, and high-risk AI system under the EU AI Act, its event-log sources and monitoring dashboards, the human-oversight roster, the AI use inventory, and the AI concern-reporting channels. Out of scope: pre-deployment model development and conformity assessment, and third-party/vendor AI due diligence, which are governed by their own workflows. This cycle consumes no upstream workflow handoff; it hands off only to the next monthly run of itself, seeding it with the open carry-forward Issues (corrective actions, in-flight blocks, incident follow-ups) that the cycle-metrics-and-report step links to the anchor Control so next month can query them as its prior-cycle input.
workflow · Context
ISO 27001 SoA Review & Controls Assessment
Review the ISO 27001 Statement of Applicability and assess the controls behind it. Each run attaches to an Audit item created for the review cycle (audit_type = compliance, e.g. "ISO 27001 SoA Review 2026-H2"), which accumulates the scope, the per-control test instances, the assessment package, the approval, and the rating. The workflow locks the assessment workplan, reconciles every Annex A control's applicable/excluded decision and justification against the current risk treatment plan, verifies implementation evidence, assesses the sampled controls for design and operating effectiveness, routes deficiencies to owners, and approves and publishes the version-controlled Statement of Applicability (SoA) — then classifies the disposition and prepares, approves, hands off, and archives the review package. In scope: reconciling and assessing the SoA's Annex A control applicability decisions and their implementation for the ISMS in scope, and publishing the approved SoA version. It consumes the ISMS Risk Assessment & Treatment Cycle's handoff package (the current risk register, the risk treatment decisions, and the required-controls determination) and hands its named deliverable — the approved, version-controlled published SoA and the assessment package — off to the downstream ISO 27001 Certification Readiness workflow. Out of scope: the enterprise risk assessment and treatment decisions that determine which controls are required (owned upstream by the ISMS Risk Assessment & Treatment Cycle) and the certification audit preparation that follows (owned by the downstream ISO 27001 Certification Readiness workflow, which consumes this review's approved package). The trigger is the scheduled SoA review interval or a material change to scope, risk, or the control environment.
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
Job Scheduling & Batch Monitoring
Runs on the existing system item. Review scheduled job execution for a system over a period, evidencing failure detection, escalation, and resolution. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Change Request, Approval & Migration
Runs on the existing system item. Move a system change from request through independent testing and approval to production migration, evidencing developer-migrator segregation. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Emergency Change
Runs on the existing system item. Record an emergency change that bypassed normal change control, evidence the elevated access used, and retrospectively test whether the bypass was justified. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
New System Implementation (SDLC)
Runs on the existing system item. Take a new system from control requirements through testing and acceptance to an evidenced go-live readiness decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
NIST RMF System Authorization (ATO) Cycle
Runs the seven NIST SP 800-37r2 RMF phases — Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor — against a single information system to reach and then sustain an authorization-to-operate (ATO) decision. The cycle is anchored on an Audit item created per authorization ("RMF ATO Cycle — <system> <year>", audit_type=it_audit, scope=the authorization boundary, period_start/period_end=the AO decision calendar); the information system itself is enriched as an existing Process item (process_type=security_process). Studio has no System/Asset type, so the RMF-specific facts (FIPS 199 categorization, selected baseline, ATO decision, authorization-termination date) live in the phase documents and on the Audit anchor rather than in dedicated fields. In scope: the defined authorization boundary and its inherited, hybrid, and system-specific controls (existing Control items). Out of scope: enterprise-wide common-control-provider programs and standalone penetration testing, which run as their own engagements and are consumed here only as assessment evidence. Named deliverables: the FIPS 199 categorization memo, the System Security Plan (SSP), the Security Assessment Report (SAR), the Plan of Action & Milestones (POA&M), and the signed ATO letter — assembled into one authorization package for the authorizing official. No upstream workflow feeds this cycle; it originates at Prepare. Downstream it hands off to itself: the Monitor phase's reauthorization triggers re-instantiate this template against the same system, and the Monitor phase's closing export is the authorization record the next cycle's Prepare consumes.
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 1 ISMS Documentation Review
Certification-body Stage 1 review of the ISMS against ISO/IEC 27001:2022 clauses 4–10: context and leadership, planning and support, operation, and performance evaluation with improvement - walking each clause group against the governing documents and the operating processes that carry it, and concluding Stage 2 readiness with dual sign-off. Stage 1 documentation and readiness review for ISO/IEC 27001:2022 clauses 4–10, conducted under the engagement methodology. It informs Stage 2 planning and does not issue a certification decision. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
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 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
Employee Onboarding
Run on an existing personnel item using signed engagement, screening references and an approved role profile. Produce an Onboarding Readiness Package with IT access evidence for HR, the manager and subsequent access reviews.
workflow · Context
GCP Physical and Environmental Subservice Reliance
Evaluate GCP assurance-report scope, physical and environmental controls, exceptions and user responsibilities; record a bounded reliance decision rather than claiming to operate provider facilities. This customer-side review relies on relevant independent reports, disclosed provider information and customer implementation evidence. It does not operate or certify GCP facility access or environmental safeguards. Preserve each report's permitted-use restrictions.
workflow · Context
System ITGC Operation
Operate and evidence the IT general controls on a system: authentication and password configuration, access provisioning and deprovisioning, the periodic user access review, change management (testing, sign-off, logs), and subservice SOC report reliance.
workflow · Context
SOC 2 Reporting and Management Assertion
Reporting close for the Type II examination: drafting and validating the system description under the carve-out method, preparing the management assertion, reviewing complementary user entity controls and subservice reliance, and the dual-approval close of the examination file at the agreed period end. Management-owned SOC 2 Type II reporting support: system description, management assertion, CUECs, subservice reliance, and auditee file closure. The independent service auditor retains responsibility for examination conclusions and the CPA opinion. Attach this workflow to the existing SOC 2 evidence or reporting process item; retain evidence and conclusions on its workflow steps.
workflow · Context
System and Third-Party Risk Review
Runs on the existing system item. Review system and provider dependencies, assess current risk and control evidence, select response actions, and approve the review record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Vendor Risk Assessment and Disposition
Runs on one existing System with vendor=true. Uses the supplier record, contracts, assurance/CUECs, access and continuity evidence to produce a reviewed vendor risk assessment and authorized disposition for the business/risk owner and readiness evidence consumers. Two checkpoints retain expert challenge and the owner’s choice of conditions, treatment and monitoring; executor work is recorded in step results and documents, with no collection forms or runtime branches.
workflow · Context
ISO/IEC 42001 AI Management System Internal Audit
An independent internal-audit cycle for the AI management system: set scope and criteria, test governance, risk, documentation, operations, value-chain controls, and reporting, then issue findings and an evidence-backed conclusion. The audit supports management improvement and assurance; it does not certify conformity.
workflow · Context
AI Governance & Risk/Impact Assessment
Assess a single AI system end to end under ISO/IEC 42001 (AIMS) and the NIST AI RMF: govern and register the system, map context and risks, measure risks and impacts, manage treatment, produce transparency artifacts, and authorize deployment with monitoring. The instance attaches to an Audit item created for this assessment cycle (audit_type compliance, or advisory for a pre-deployment review); because Studio has no native AI System type, the system under assessment is named in that Audit's scope and its lifecycle/EU-AI-Act detail lives in the scoping memo and step documents. In scope: one named AI system or use case and its lifecycle risk posture. Out of scope: enterprise-wide AI policy authoring and detailed EU AI Act legal obligation mapping, which are consumed as an input handoff package from the EU AI Act Obligation Impact Analysis workflow. The named deliverable is the approved AI assessment package (executive summary plus recommended governance decision), backed by the AI risk register (Risk items, category ai_governance), the model/system card and AI impact-assessment record, and a deployment authorization with live drift/fairness monitoring; approved outputs hand off to Quarterly Board & Audit-Committee GRC Reporting.
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
IT Governance Objective Review (COBIT)
Periodic review of selected COBIT 2019 governance and management objectives, run per cycle on an Audit item (audit_type: it_audit; scope = the in-scope objectives; period_start/period_end = the assessment cycle) that the workflow instance attaches to and archives at close. Each in-scope COBIT objective is a Process item (process_type: it_general_control) linked to that Audit, and the review produces named deliverables against it: an evidence register and pre-scored capability sheet, a signed capability profile, a gap table with the benchmark decision, a committed improvement roadmap of Issue initiatives, and the governance board report and dashboard. In scope: the COBIT 2019 objectives selected for this cycle, each with a justified 0-5 target capability level, a named accountable owner, and the review cadence; out of scope: objectives explicitly excluded with recorded rationale. Self-originating: its scope sheet and target profile are supplied as workflow inputs, and it hands off to no distinct downstream workflow — the carry-forward improvement Issues and the archived instance seed its own next cycle.
workflow · Context
Risk & Resilience Framework Governance
Risk & Resilience Framework Governance as a decision-aware workflow. The instance runs on the "Enterprise Risk Management Framework" Process item (process_type: business_process, process_owner = the framework owner, frequency: annual) - created on the first cycle at "Design core ERM framework" and enriched every cycle thereafter, never duplicated; that Process item is the governance register entry, and each governance cycle runs as a workflow instance attached to it, so the at-least-annual cadence is provable from one item's instance history. Working from the organization's context and the ISO 31000 / COSO ERM / DORA reference models - no upstream workflow package feeds it, because this workflow establishes the governance layer - it establishes or refreshes the enterprise risk management framework, extends it for ICT operational resilience and regulated technologies, secures management-body approval and budget, drives implementation across the organization, and runs the at-least-annual review, filling the governance layer the risk-cycle workflows run inside but never establish. The named deliverable is the approved risk & resilience framework package (core ERM design + ICT operational-resilience (DORA) extension + any regulated-technology lifecycle extension), archived at close as durable governance evidence. In scope: the enterprise risk framework, its always-in-scope ICT operational-resilience (DORA) extension, and any regulated-technology (e.g. high-risk AI) extensions to be evaluated. Out of scope: executing the individual risk-cycle workflows (identify / assess / treat / monitor) that run inside this framework - this workflow governs them but does not perform them, and consumes no upstream workflow package. Downstream, the archived framework enables those risk-cycle workflows, which reference it as their governing baseline (the relationship is real but not modeled as a node).
workflow · Context
Combined Assurance Mapping
Combined Assurance Mapping as a decision-aware workflow. Each cycle runs as one workflow instance attached to an Audit item created for the cycle (audit_type: advisory, scope = the combined-assurance mapping scope for the period, period_start/period_end = the cycle period) — no other Studio type represents an assurance-coordination cycle, so the workflow enriches that Audit item rather than any pre-existing engagement. In scope: mapping assurance coverage across the Three Lines of Defense for the confirmed risk universe and entities this cycle — cataloging assurance providers, mapping their coverage onto the risk universe, assessing reliance, identifying gaps and duplication, coordinating coverage plans, publishing the combined assurance map, and preparing audit-committee reporting inputs. Out of scope: performing the underlying assurance engagements themselves (owned by internal audit, second-line functions, and external providers) and any risk, entity, or provider not named in this cycle's confirmed scope. It consumes the risk universe and residual positions (Risk items with their residual_rating and treatment) from the upstream Enterprise Risk Assessment & Portfolio Oversight Cycle and hands its named deliverables — the published combined assurance map, the reliance conclusions, and the gap action plans — to the downstream Quarterly Board & Audit-Committee GRC Reporting workflow rather than duplicating repeated work.
workflow · Context
Subservice Organization & Third-Party Personnel Oversight
Subservice Organization & Third-Party Personnel Oversight as a checkpoint graph. Anchor: each run enriches the existing subservice-organization **Vendor** register entry for one provider - the workflow instance and every step document attach to it, and it is never recreated (initial vendor selection and onboarding due diligence are out of scope). In scope: the subservice organizations and third-party suppliers whose services support user-entity control objectives or whose personnel access the organization's systems or data - reconciling and enriching their Vendor register entries, verifying subservice and personnel-security contract terms, reviewing assurance (SOC) reports and mapping complementary user-entity controls (CUECs) to internal Control items, routing exceptions to tracked Issue items, collecting third-party personnel-compliance evidence, monitoring vendor performance, and running the quarterly issue follow-up through to closure. Out of scope: initial vendor selection and onboarding due diligence, and the organization's own internal personnel controls. Upstream: no workflow feeds it - it is built from the existing Vendor register, the prior cycle's archived vendor file, open Issue items, and the internal Control inventory, plus contracts, SOC reports, and performance data uploaded as evidence. Downstream: self-contained - no single workflow consumes its output; the archived, auditor-ready vendor file is the durable evidence record. It runs on the annual per-vendor cycle with quarterly issue follow-up.
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
Third-Party Risk Program & Vendor Oversight Cycle
A standing quarterly cycle the vendor-management office runs as control owner. The workflow instance is a recurring run attached to the EXISTING Process item "Third-Party / Vendor Risk Management" (process_type: operational, process_owner: Vendor Risk Program Lead, frequency: quarterly), linked to the Control items for the unified controls it operates (UC-TPRM-01/04/05/08) — it enriches that standing program, never recreating it. It consumes no upstream workflow handoff: each run is self-feeding, drawing its criteria and prior state from the program's own standing artifacts — the SCRM plan, third-party risk policy, and program strategy held as Policy items; the criticality-tiered Vendor register (Vendor items); and the prior cycle instance's step documents (the DORA Article 28(3) register of information and the ICT concentration-risk view). In scope: reaffirming or revising the governing Policy items; re-tiering the Vendor register; refreshing the DORA Article 28(3) register of information and the concentration-risk view (a dashboard over the Vendor items); verifying critical-provider exit strategies; executing this cycle's tier-based reassessments and driving findings to tracked third-party Risk items (remediation or risk-committee escalation); confirming external and cloud service provider oversight; and verifying critical suppliers carry live incident-notification coverage. Named deliverables: the refreshed criticality-tiered Vendor register, the updated DORA Article 28(3) register of information, the recomputed ICT concentration-risk view, the exit-readiness summary, this cycle's tracked Risk items, and the archived cycle evidence package on the workflow instance. Terminal at close-and-archive with no downstream handoff — open or escalated vendor risks persist as Risk items in the risk register. Out of scope and handled by separate workflows: the continuous monitor-line vendor lifecycle and the per-engagement due-diligence gate for onboarding a new vendor.
workflow · Context
Vendor Offboarding & Secure Termination
Vendor Offboarding & Secure Termination as a decision-aware workflow triggered on a relationship termination. It runs on the vendor's existing Vendor register item - the offboarding enriches that record, it never creates a duplicate: the run marks the Vendor `monitoring_status: exited` and stamps `contract_end_date`, and where the vendor's risk is registered it links to the existing third-party Risk item (`category: third_party`). In scope: executing one vendor's contractual exit end to end - inventorying the vendor's access, data, and dedicated components; containing access immediately on for-cause exits; transitioning each service to its successor; revoking every credential; verifying data return or destruction; disposing of internal-side components using defined techniques; and retaining the post-relationship evidence. Out of scope: the underlying contract-termination or renewal business decision and any separately-governed affiliate contracts. Initial inputs are the termination trigger and effective date, the vendor's contractual exit provisions (master agreement, data processing addendum, exit plan) - which also carry the data-disposition and evidence-retention clauses consumed downstream - and the existing Vendor register item with its risk tier; there is no upstream workflow. The named deliverable is the retained, audit-standing termination evidence package assembled at compile-termination-evidence-and-retain; the workflow is terminal - close-and-archive exports the run and hands off nothing downstream.
workflow · Context
Regulatory Exam & External Audit Management
Manage a live regulator examination or external audit end to end — from notification intake through request fulfillment, QC’d evidence release, fieldwork support, preliminary-findings response, and commitment closure. Runs on an Audit engagement item created per exam (audit_type = regulatory_exam, or external_attestation for an external audit); the workflow instance attaches to that Audit anchor, and preliminary findings and their corrective-action commitments become linked Issue items. No upstream workflow feeds this — it is triggered by the exam or audit notification itself. In scope: coordinating examiner requests, controlled evidence release, and management responses for a single exam or audit engagement. Out of scope: remediating the underlying control gaps — the findings and committed corrective actions hand off to Finding Remediation & Action-Plan Monitoring — and standing up new obligations surfaced by the exam, which hand off to Regulatory Horizon Scanning & Triage and Regulatory Obligation Implementation.
workflow · Context
SOC Report, Subservice & CUEC Review
Runs on the existing system item. Evaluate a service-organization report, subservice coverage, exceptions, and complementary user-entity controls for a governed reliance decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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
AI System Development, Data & Deployment Gate
Runs as a standalone per-release gate cycle — one workflow instance per new AI system or substantial modification. The schema has no native AI System item type, so the instance links (Item relationship) to the existing Control items it operates (UC-AI-04/05/06/07/09; framework eu-ai-act|iso-42001, domains ai_governance) and to the ai_governance Risk it mitigates, and all cycle evidence attaches to its steps. It consumes the AI system inventory profile and the enterprise responsible-AI objectives (Policy items) upstream; the release board then approves those objectives and the per-system requirements before build, governs training, validation, and test data with bias mitigation, executes the pre-deployment impact assessment and EU AI Act risk classification, applies the high-risk conformity obligations where they trigger, assembles Annex IV-grade technical documentation, and records verification-and-validation results and the deployment sign-off. Named deliverables: the risk-classification decision, the pre-deployment impact-assessment report, the Annex IV technical-documentation package, the verification-and-validation report, and the recorded sign-off. Retraining and substantial changes re-enter the same gate as a fresh instance (a self-loop, no downstream handoff).
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
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.