Risk Assessment & Management
673 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
A007 — Prevent IP violations
Prevent IP violations
control · Context
B001 — Third-party testing of adversarial robustness
Third-party testing of adversarial robustness
control · Context
B006 — Prevent unauthorized AI agent actions
Prevent unauthorized AI agent actions
control · Context
B007 — Enforce user access privileges to AI systems
Enforce user access privileges to AI systems
control · Context
B008 — Protect AI system deployment environment
Protect AI system deployment environment
control · Context
B009 — Limit output over-exposure
Limit output over-exposure
control · Context
C002 — Conduct pre-deployment testing
Conduct pre-deployment testing
control · Context
C003 — Prevent harmful outputs
Prevent harmful outputs
control · Context
C004 — Prevent out-of-scope outputs
Prevent out-of-scope outputs
control · Context
C005 — Prevent agent-specific high risk outputs
Prevent agent-specific high risk outputs
control · Context
C006 — Prevent output vulnerabilities
Prevent output vulnerabilities
control · Context
C007 — Flag high risk outputs for human review
Flag high risk outputs for human review
control · Context
C008 — Monitor AI risk categories
Monitor AI risk categories
control · Context
C009 — Enable real-time feedback and intervention
Enable real-time feedback and intervention
control · Context
C010 — Third-party testing for harmful outputs
Third-party testing for harmful outputs
control · Context
C011 — Third-party testing for out-of-scope outputs
Third-party testing for out-of-scope outputs
control · Context
C012 — Third-party testing for customer-defined risk
Third-party testing for customer-defined risk
control · Context
D001 — Prevent hallucinated outputs
Prevent hallucinated outputs
control · Context
D002 — Third-party testing for hallucinations
Third-party testing for hallucinations
control · Context
D003 — Restrict unsafe tool calls
Restrict unsafe tool calls
control · Context
D004 — Third-party testing of tool calls
Third-party testing of tool calls
control · Context
E001 — AI failure plan for security breaches
AI failure plan for security breaches
control · Context
E002 — AI failure plan for harmful outputs
AI failure plan for harmful outputs
control · Context
E003 — AI failure plan for hallucinations
AI failure plan for hallucinations
control · Context
E006 — Conduct vendor due diligence
Conduct vendor due diligence
control · Context
E008 — Review internal processes
Review internal processes
control · Context
E009 — Monitor third-party access
Monitor third-party access
control · Context
E010 — Establish AI acceptable use policy
Establish AI acceptable use policy
control · Context
E013 — Implement quality management system
Implement quality management system
control · Context
E015 — Log AI system activity
Log AI system activity
control · Context
E016 — Implement AI disclosure mechanisms
Implement AI disclosure mechanisms
control · Context
E017 — Document system transparency policy
Document system transparency policy
control · Context
F001 — Prevent AI cyber misuse
Prevent AI cyber misuse
control · Context
F002 — Prevent catastrophic misuse
Prevent catastrophic misuse
control · Context
APO01 — Managed I&T Management Framework
Managed I&T Management Framework
control · Context
APO02 — Managed Strategy
Managed Strategy
control · Context
APO03 — Managed Enterprise Architecture
Managed Enterprise Architecture
control · Context
APO04 — Managed Innovation
Managed Innovation
control · Context
APO05 — Managed Portfolio
Managed Portfolio
control · Context
APO06 — Managed Budget and Costs
Managed Budget and Costs
control · Context
APO07 — Managed Human Resources
Managed Human Resources
control · Context
APO08 — Managed Relationships
Managed Relationships
control · Context
APO09 — Managed Service Agreements
Managed Service Agreements
control · Context
APO10 — Managed Vendors
Managed Vendors
control · Context
APO12 — Managed Risk
Managed Risk
control · Context
BAI02 — Managed Requirements Definition
Managed Requirements Definition
control · Context
BAI03 — Managed Solutions Identification and Build
Managed Solutions Identification and Build
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
DSS04 — Managed Continuity
Managed Continuity
control · Context
DSS05 — Managed Security Services
Managed Security Services
control · Context
DSS06 — Managed Business Process Controls
Managed Business Process Controls
control · Context
EDM01 — Ensured Governance Framework Setting and Maintenance
Ensured Governance Framework Setting and Maintenance
control · Context
EDM02 — Ensured Benefits Delivery
Ensured Benefits Delivery
control · Context
EDM03 — Ensured Risk Optimization
Ensured Risk Optimization
control · Context
EDM04 — Ensured Resource Optimization
Ensured Resource Optimization
control · Context
EDM05 — Ensured Stakeholder Engagement
Ensured Stakeholder Engagement
control · Context
MEA01 — Managed Performance and Conformance Monitoring
Managed Performance and Conformance Monitoring
control · Context
MEA03 — Managed Compliance With External Requirements
Managed Compliance With External Requirements
control · Context
E10 — Identifies Risk
Identifies Risk
control · Context
E11 — Assesses Severity of Risk
Assesses Severity of Risk
control · Context
E12 — Prioritizes Risks
Prioritizes Risks
control · Context
E13 — Implements Risk Responses
Implements Risk Responses
control · Context
E14 — Develops Portfolio View
Develops Portfolio View
control · Context
E15 — Assesses Substantial Change
Assesses Substantial Change
control · Context
E16 — Reviews Risk and Performance
Reviews Risk and Performance
control · Context
E17 — Pursues Improvement in Enterprise Risk Management
Pursues Improvement in Enterprise Risk Management
control · Context
E18 — Leverages Information and Technology
Leverages Information and Technology
control · Context
E19 — Communicates Risk Information
Communicates Risk Information
control · Context
E2 — Establishes Operating Structures
Establishes Operating Structures
control · Context
E20 — Reports on Risk, Culture, and Performance
Reports on Risk, Culture, and Performance
control · Context
E3 — Defines Desired Culture
Defines Desired Culture
control · Context
E4 — Demonstrates Commitment to Core Values
Demonstrates Commitment to Core Values
control · Context
E5 — Attracts, Develops, and Retains Capable Individuals
Attracts, Develops, and Retains Capable Individuals
control · Context
E6 — Analyzes Business Context
Analyzes Business Context
control · Context
E7 — Defines Risk Appetite
Defines Risk Appetite
control · Context
E8 — Evaluates Alternative Strategies
Evaluates Alternative Strategies
control · Context
E9 — Formulates Business Objectives
Formulates Business Objectives
control · Context
P1 — The organization demonstrates a commitment to integrity and ethical values.
The organization demonstrates a commitment to integrity and ethical values.
control · Context
P10 — The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
control · Context
P11 — The organization selects and develops general control activities over technology to support the achievement of objectives.
The organization selects and develops general control activities over technology to support the achievement of objectives.
control · Context
P14 — The organization internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.
The organization internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.
control · Context
P3 — Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives.
Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives.
control · Context
P4 — The organization demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives.
The organization demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives.
control · Context
P5 — The organization holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
The organization holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
control · Context
P6 — The organization specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
The organization specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
control · Context
P7 — The organization identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
The organization identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
control · Context
P8 — The organization considers the potential for fraud in assessing risks to the achievement of objectives.
The organization considers the potential for fraud in assessing risks to the achievement of objectives.
control · Context
P9 — The organization identifies and assesses changes that could significantly impact the system of internal control.
The organization identifies and assesses changes that could significantly impact the system of internal control.
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-Art10 — Data and data governance (high-risk)
Data and data governance (high-risk)
control · Context
AIA-Art11 — Technical documentation (high-risk)
Technical documentation (high-risk)
control · Context
AIA-Art12 — Record-keeping / logging (high-risk)
Record-keeping / logging (high-risk)
control · Context
AIA-Art13 — Transparency and provision of information to deployers (high-risk)
Transparency and provision of information to deployers (high-risk)
control · Context
AIA-Art14 — Human oversight (high-risk)
Human oversight (high-risk)
control · Context
AIA-Art15 — Accuracy, robustness and cybersecurity (high-risk)
Accuracy, robustness and cybersecurity (high-risk)
control · Context
AIA-Art17 — Quality management system (providers of high-risk AI systems)
Quality management system (providers of high-risk AI systems)
control · Context
AIA-Art18 — Documentation keeping — 10-year retention of technical documentation, QMS records and conformity documents (providers)
Documentation keeping — 10-year retention of technical documentation, QMS records and conformity documents (providers)
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-Art20 — Corrective actions and duty of information for non-conforming high-risk AI systems
Corrective actions and duty of information for non-conforming high-risk AI systems
control · Context
AIA-Art5 — Prohibited AI practices
Prohibited AI practices
control · Context
AIA-Art50 — Transparency obligations for certain AI systems (deepfakes, chatbots, emotion recognition)
Transparency obligations for certain AI systems (deepfakes, chatbots, emotion recognition)
control · Context
AIA-Art53 — Obligations for providers of general-purpose AI (GPAI) models
Obligations for providers of general-purpose AI (GPAI) models
control · Context
AIA-Art55 — Obligations for GPAI models with systemic risk
Obligations for GPAI models with systemic risk
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
AIA-Art73 — Reporting of serious incidents (providers; deployers inform providers)
Reporting of serious incidents (providers; deployers inform providers)
control · Context
AIA-Art9 — Risk management system (high-risk)
Risk management system (high-risk)
control · Context
GDPR-Art24 — Responsibility of the controller
Responsibility of the controller
control · Context
GDPR-Art32 — Security of processing
Security of processing
control · Context
GDPR-Art33 — Notification of a personal data breach to the supervisory authority
Notification of a personal data breach to the supervisory authority
control · Context
GDPR-Art35 — Data protection impact assessment (DPIA)
Data protection impact assessment (DPIA)
control · Context
GDPR-Art37-39 — Designation and tasks of the Data Protection Officer
Designation and tasks of the Data Protection Officer
control · Context
GDPR-Art5 — Principles relating to processing of personal data
Principles relating to processing of personal data
control · Context
HIPAA-164.312(a) — Technical access control for ePHI (unique user ID, emergency access, automatic logoff, encryption/decryption)
Technical access control for ePHI (unique user ID, emergency access, automatic logoff, encryption/decryption)
control · Context
HIPAA-164.312(d) — Person or entity authentication before ePHI access
Person or entity authentication before ePHI access
control · Context
Principle 7 — Positioned Independently
Positioned Independently
control · Context
Purpose — Purpose of Internal Auditing — Internal auditing strengthens the organization's ability to create, protect, and sustain value by providing the board and management with independent, risk-based, and objective assurance, advice, insight, and foresight.
Purpose of Internal Auditing — Internal auditing strengthens the organization's ability to create, protect, and sustain value by providing the board and management with independent, risk-based, and objective assurance, advice, insight, and foresight.
control · Context
Std 11.5 — Communicating the Acceptance of Risks
Communicating the Acceptance of Risks
control · Context
Std 12.3 — Oversee and Improve Engagement Performance
Oversee and Improve Engagement Performance
control · Context
Std 14.6 — Engagement Documentation
Engagement Documentation
control · Context
Std 15.2 — Confirming the Implementation of Recommendations or Action Plans
Confirming the Implementation of Recommendations or Action Plans
control · Context
Std 7.1 — Organizational Independence
Organizational Independence
control · Context
Std 7.2 — Chief Audit Executive Qualifications
Chief Audit Executive Qualifications
control · Context
Std 8.4 — External Quality Assessment
External Quality Assessment
control · Context
IIA-POS-ERM-01 — Board, Management, and Internal Audit Accountabilities
The board oversees risk, management owns and manages risk, and internal audit provides independent assurance and advice without assuming management responsibility.
control · Context
IIA-POS-ERM-02 — ERM Activity and Service Boundaries
ERM activities operate through Identify, Assess, Manage, Monitor, and Report, with internal-audit assurance, advisory, and administrative boundaries defined for each phase.
control · Context
IIA-POS-ERM-03 — Safeguards for Expanded ERM Responsibility
Expanded internal-audit ERM responsibility requires documented allocation, board approval, separation, disclosure, independent assurance, cooling-off, periodic review, and transition where temporary.
control · Context
IIA-POS-TLM-01 — Activity-Level Three Lines Responsibilities
First, second, and third lines have distinct but complementary responsibilities; roles are classified by the activity performed, and outsourcing does not transfer accountability.
control · Context
IIA-POS-TLM-02 — Independence and Self-Review Safeguards
Independence requires structural safeguards, board-approved expanded remit, protection against self-review, and at least 12 months between operational responsibility and assurance.
control · Context
A.5.17 — Authentication information
Authentication information
control · Context
A.5.19 — Information security in supplier relationships
Information security in supplier relationships
control · Context
A.5.2 — Information security roles and responsibilities
Information security roles and responsibilities
control · Context
A.5.29 — Information security during disruption
Information security during disruption
control · Context
A.5.3 — Segregation of duties
Segregation of duties
control · Context
A.5.30 — ICT readiness for business continuity
ICT readiness for business continuity
control · Context
A.5.31 — Legal, statutory, regulatory and contractual requirements
Legal, statutory, regulatory and contractual requirements
control · Context
A.5.32 — Intellectual property rights
Intellectual property rights
control · Context
A.5.4 — Management responsibilities
Management responsibilities
control · Context
A.5.7 — Threat intelligence
Threat intelligence
control · Context
A.5.8 — Information security in project management
Information security in project management
control · Context
A.5.9 — Inventory of information and other associated assets
Inventory of information and other associated assets
control · Context
A.8.16 — Monitoring activities
Monitoring activities
control · Context
A.8.26 — Application security requirements
Application security requirements
control · Context
A.8.27 — Secure system architecture and engineering principles
Secure system architecture and engineering principles
control · Context
A.8.3 — Information access restriction
Information access restriction
control · Context
A.8.4 — Access to source code
Access to source code
control · Context
A.8.5 — Secure authentication
Secure authentication
control · Context
A.8.6 — Capacity management
Capacity management
control · Context
31000-FW1 — Leadership and commitment
Leadership and commitment
control · Context
31000-FW2 — Integration
Integration
control · Context
31000-FW3 — Design
Design
control · Context
31000-FW4 — Implementation
Implementation
control · Context
31000-FW5 — Evaluation
Evaluation
control · Context
31000-FW6 — Improvement
Improvement
control · Context
31000-P1 — Integrated
Integrated
control · Context
31000-P2 — Structured and comprehensive
Structured and comprehensive
control · Context
31000-P3 — Customized
Customized
control · Context
31000-P4 — Inclusive
Inclusive
control · Context
31000-P5 — Dynamic
Dynamic
control · Context
31000-P6 — Best available information
Best available information
control · Context
31000-P7 — Human and cultural factors
Human and cultural factors
control · Context
31000-P8 — Continual improvement
Continual improvement
control · Context
31000-PR1 — Communication and consultation
Communication and consultation
control · Context
31000-PR2 — Scope, context and criteria
Scope, context and criteria
control · Context
31000-PR3 — Risk assessment: risk identification
Risk assessment: risk identification
control · Context
31000-PR4 — Risk assessment: risk analysis
Risk assessment: risk analysis
control · Context
31000-PR5 — Risk assessment: risk evaluation
Risk assessment: risk evaluation
control · Context
31000-PR6 — Risk treatment
Risk treatment
control · Context
31000-PR7 — Monitoring and review
Monitoring and review
control · Context
31000-PR8 — Recording and reporting
Recording and reporting
control · Context
A.10.3 — Suppliers
Suppliers
control · Context
A.10.4 — Customers
Customers
control · Context
A.2.2 — AI policy
AI policy
control · Context
A.2.3 — Alignment with other organizational policies
Alignment with other organizational policies
control · Context
A.2.4 — Review of the AI policy
Review of the AI policy
control · Context
A.3.3 — Reporting of concerns
Reporting of concerns
control · Context
A.4.2 — Resource documentation
Resource documentation
control · Context
A.4.3 — Data resources
Data resources
control · Context
A.4.4 — Tooling resources
Tooling resources
control · Context
A.4.5 — System and computing resources
System and computing resources
control · Context
A.6.1.2 — Objectives for responsible development of AI systems
Objectives for responsible development of AI systems
control · Context
A.6.1.3 — Processes for responsible AI system design and development
Processes for responsible AI system design and development
control · Context
A.6.2.2 — AI system requirements and specification
AI system requirements and specification
control · Context
A.6.2.3 — Documentation of AI system design and development
Documentation of AI system design and development
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.7 — AI system technical documentation
AI system technical documentation
control · Context
A.6.2.8 — AI system recording of event logs
AI system recording of event logs
control · Context
A.7.2 — Data for development and enhancement of AI systems
Data for development and enhancement of AI systems
control · Context
A.7.3 — Acquisition of data
Acquisition of data
control · Context
A.7.4 — Data quality for AI systems
Data quality for AI systems
control · Context
A.7.5 — Data provenance
Data provenance
control · Context
A.7.6 — Data preparation
Data preparation
control · Context
A.8.2 — System documentation and information for users
System documentation and information for users
control · Context
A.8.3 — External reporting
External reporting
control · Context
A.8.4 — Communication of incidents
Communication of incidents
control · Context
A.8.5 — Information for interested parties
Information for interested parties
control · Context
A.9.2 — Processes for responsible use of AI systems
Processes for responsible use of AI systems
control · Context
A.9.3 — Objectives for responsible use of AI systems
Objectives for responsible use of AI systems
control · Context
A.9.4 — Intended use of the AI system
Intended use of the AI system
control · Context
NIS2-Art21b — Incident handling
Incident handling
control · Context
NIS2-Art21c — Business continuity, backup management and disaster recovery, crisis management
Business continuity, backup management and disaster recovery, crisis management
control · Context
NIS2-Art21d — Supply chain security
Supply chain security
control · Context
NIS2-Art21i — Human resources security, access control policies and asset management
Human resources security, access control policies and asset management
control · Context
NIS2-Art23 — Reporting obligations (early warning 24h, incident notification 72h, final report 1 month)
Reporting obligations (early warning 24h, incident notification 72h, final report 1 month)
control · Context
AC-1 — Policy and Procedures
Policy and Procedures
control · Context
AC-16 — Security and Privacy Attributes
Security and Privacy Attributes
control · Context
AC-24 — Access Control Decisions
Access Control Decisions
control · Context
AC-25 — Reference Monitor
Reference Monitor
control · Context
AC-3 — Access Enforcement
Access Enforcement
control · Context
AC-7 — Unsuccessful Logon Attempts
Unsuccessful Logon Attempts
control · Context
AC-8 — System Use Notification
System Use Notification
control · Context
AC-9 — Previous Logon Notification
Previous Logon Notification
control · Context
AU-10 — Non-repudiation
Non-repudiation
control · Context
AU-16 — Cross-organizational Audit Logging
Cross-organizational Audit Logging
control · Context
AU-6 — Audit Record Review, Analysis, and Reporting
Audit Record Review, Analysis, and Reporting
control · Context
AU-7 — Audit Record Reduction and Report Generation
Audit Record Reduction and Report Generation
control · Context
CA-5 — Plan of Action and Milestones
Plan of Action and Milestones
control · Context
CA-7 — Continuous Monitoring
Continuous Monitoring
control · Context
CM-8 — System Component Inventory
System Component Inventory
control · Context
CP-1 — Policy and Procedures
Policy and Procedures
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
IA-1 — Policy and Procedures
Policy and Procedures
control · Context
IA-10 — Adaptive Authentication
Adaptive Authentication
control · Context
IA-12 — Identity Proofing
Identity Proofing
control · Context
IA-2 — Identification and Authentication (Organizational Users)
Identification and Authentication (Organizational Users)
control · Context
IA-5 — Authenticator Management
Authenticator Management
control · Context
IA-6 — Authentication Feedback
Authentication Feedback
control · Context
IA-8 — Identification and Authentication (Non-organizational Users)
Identification and Authentication (Non-organizational Users)
control · Context
IR-1 — Policy and Procedures
Policy and Procedures
control · Context
PL-4 — Rules of Behavior
Rules of Behavior
control · Context
PL-8 — Security and Privacy Architectures
Security and Privacy Architectures
control · Context
PM-11 — Mission and Business Process Definition
Mission and Business Process Definition
control · Context
PM-12 — Insider Threat Program
Insider Threat Program
control · Context
PM-16 — Threat Awareness Program
Threat Awareness Program
control · Context
PM-17 — Protecting Controlled Unclassified Information on External Systems
Protecting Controlled Unclassified Information on External Systems
control · Context
PM-18 — Privacy Program Plan
Privacy Program Plan
control · Context
PM-19 — Privacy Program Leadership Role
Privacy Program Leadership Role
control · Context
PM-2 — Information Security Program Leadership Role
Information Security Program Leadership Role
control · Context
PM-20 — Dissemination of Privacy Program Information
Dissemination of Privacy Program Information
control · Context
PM-21 — Accounting of Disclosures
Accounting of Disclosures
control · Context
PM-22 — Personally Identifiable Information Quality Management
Personally Identifiable Information Quality Management
control · Context
PM-25 — Minimization of Personally Identifiable Information Used in Testing, Training, and Research
Minimization of Personally Identifiable Information Used in Testing, Training, and Research
control · Context
PM-26 — Complaint Management
Complaint Management
control · Context
PM-27 — Privacy Reporting
Privacy Reporting
control · Context
PM-28 — Risk Framing
Risk Framing
control · Context
PM-29 — Risk Management Program Leadership Roles
Risk Management Program Leadership Roles
control · Context
PM-3 — Information Security and Privacy Resources
Information Security and Privacy Resources
control · Context
PM-30 — Supply Chain Risk Management Strategy
Supply Chain Risk Management Strategy
control · Context
PM-4 — Plan of Action and Milestones Process
Plan of Action and Milestones Process
control · Context
PM-5 — System Inventory
System Inventory
control · Context
PM-7 — Enterprise Architecture
Enterprise Architecture
control · Context
PM-8 — Critical Infrastructure Plan
Critical Infrastructure Plan
control · Context
PM-9 — Risk Management Strategy
Risk Management Strategy
control · Context
PS-1 — Policy and Procedures
Policy and Procedures
control · Context
PT-1 — Policy and Procedures
Policy and Procedures
control · Context
RA-1 — Policy and Procedures
Policy and Procedures
control · Context
RA-10 — Threat Hunting
Threat Hunting
control · Context
RA-2 — Security Categorization
Security Categorization
control · Context
RA-3 — Risk Assessment
Risk Assessment
control · Context
RA-7 — Risk Response
Risk Response
control · Context
RA-8 — Privacy Impact Assessments
Privacy Impact Assessments
control · Context
RA-9 — Criticality Analysis
Criticality Analysis
control · Context
SA-17 — Developer Security and Privacy Architecture and Design
Developer Security and Privacy Architecture and Design
control · Context
SA-8 — Security and Privacy Engineering Principles
Security and Privacy Engineering Principles
control · Context
SC-39 — Process Isolation
Process Isolation
control · Context
SI-4 — System Monitoring
System Monitoring
control · Context
SR-1 — Policy and Procedures
Policy and Procedures
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
NIST-AGI-02 — Agent authentication and credential lifecycle
The paper asks what constitutes strong agent authentication and how keys are issued, updated, and revoked; workload identity and identity lifecycle standards are among the approaches considered.
control · Context
NIST-AGI-03 — Context-sensitive authorization and least privilege
The paper asks how zero trust, changing agent context, aggregated data sensitivity, least privilege, and proof of authority for a specific action can inform agent authorization.
control · Context
NIST-AGI-04 — Delegated authority and human accountability
The project explores linking agents to the users on whose behalf they act, with delegation controls and a binding between agent identity and human authorization.
control · Context
NIST-AGI-05 — Verifiable agent action logs and authorization traceability
The paper asks how agent actions and intent can be logged in a verifiable, tamper-resistant way and traced back to human authorization; visibility includes actions, data, and outcomes.
control · Context
NIST-AGI-06 — Prompt-injection prevention and limits on resulting harm
The paper explicitly asks which controls help prevent direct and indirect prompt injection and which controls can limit its impact after an injection succeeds.
control · Context
NIST-AGI-07 — Prompt provenance and data-flow tracking
The proposed project explores tracking the provenance of user prompts and input data so that risk assessments and policies can take those sources into account when deciding whether an agent may act.
control · Context
NIST-TEVV-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
NIST-TEVV-04 — Test for disclosure of confidential information
Appendix B includes confidentiality attacks that test whether an AI system reveals confidential information or internal functionality, including user information and system-prompt leakage.
control · Context
NIST-TEVV-06 — Test agent tool misuse and unauthorized external actions
Appendix B includes tests for misuse of connected tools and external actions, including unsafe tool selection, excessive agency, unauthorized action attempts, and harmful task execution.
control · Context
DE.AE-02 — Adverse Event Analysis: Potentially adverse events are analyzed to better understand associated activities
Adverse Event Analysis: Potentially adverse events are analyzed to better understand associated activities
control · Context
DE.AE-03 — Adverse Event Analysis: Information is correlated from multiple sources
Adverse Event Analysis: Information is correlated from multiple sources
control · Context
DE.AE-06 — Adverse Event Analysis: Information on adverse events is provided to authorized staff and tools
Adverse Event Analysis: Information on adverse events is provided to authorized staff and tools
control · Context
DE.AE-07 — Adverse Event Analysis: Cyber threat intelligence and other contextual information are integrated into the analysis
Adverse Event Analysis: Cyber threat intelligence and other contextual information are integrated into the analysis
control · Context
DE.AE-08 — Adverse Event Analysis: Incidents are declared when adverse events meet the defined incident criteria
Adverse Event Analysis: Incidents are declared when adverse events meet the defined incident criteria
control · Context
DE.CM-01 — Continuous Monitoring: Networks and network services are monitored to find potentially adverse events
Continuous Monitoring: Networks and network services are monitored to find potentially adverse events
control · Context
DE.CM-02 — Continuous Monitoring: The physical environment is monitored to find potentially adverse events
Continuous Monitoring: The physical environment is monitored to find potentially adverse events
control · Context
DE.CM-06 — Continuous Monitoring: External service provider activities and services are monitored to find potentially adverse events
Continuous Monitoring: External service provider activities and services are monitored to find potentially adverse events
control · Context
GV.OC-01 — Organizational Context: The organizational mission is understood and informs cybersecurity risk management
Organizational Context: The organizational mission is understood and informs cybersecurity risk management
control · Context
GV.OC-02 — Organizational Context: Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered
Organizational Context: Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered
control · Context
GV.OC-03 — Organizational Context: Legal, regulatory, and contractual requirements regarding cybersecurity — including privacy and civil liberties obligations — are understood and managed
Organizational Context: Legal, regulatory, and contractual requirements regarding cybersecurity — including privacy and civil liberties obligations — are understood and managed
control · Context
GV.OC-04 — Organizational Context: Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organization are understood and communicated
Organizational Context: Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organization are understood and communicated
control · Context
GV.OC-05 — Organizational Context: Outcomes, capabilities, and services that the organization depends on are understood and communicated
Organizational Context: Outcomes, capabilities, and services that the organization depends on are understood and communicated
control · Context
GV.OV-02 — Oversight: The cybersecurity risk management strategy is reviewed and adjusted to ensure coverage of organizational requirements and risks
Oversight: The cybersecurity risk management strategy is reviewed and adjusted to ensure coverage of organizational requirements and risks
control · Context
GV.OV-03 — Oversight: Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed
Oversight: Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed
control · Context
GV.RM-01 — Risk Management Strategy: Risk management objectives are established and agreed to by organizational stakeholders
Risk Management Strategy: Risk management objectives are established and agreed to by organizational stakeholders
control · Context
GV.RM-02 — Risk Management Strategy: Risk appetite and risk tolerance statements are established, communicated, and maintained
Risk Management Strategy: Risk appetite and risk tolerance statements are established, communicated, and maintained
control · Context
GV.RM-03 — Risk Management Strategy: Cybersecurity risk management activities and outcomes are included in enterprise risk management processes
Risk Management Strategy: Cybersecurity risk management activities and outcomes are included in enterprise risk management processes
control · Context
GV.RM-04 — Risk Management Strategy: Strategic direction that describes appropriate risk response options is established and communicated
Risk Management Strategy: Strategic direction that describes appropriate risk response options is established and communicated
control · Context
GV.RM-05 — Risk Management Strategy: Lines of communication across the organization are established for cybersecurity risks, including risks from suppliers and other third parties
Risk Management Strategy: Lines of communication across the organization are established for cybersecurity risks, including risks from suppliers and other third parties
control · Context
GV.RM-06 — Risk Management Strategy: A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated
Risk Management Strategy: A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated
control · Context
GV.RM-07 — Risk Management Strategy: Strategic opportunities (i.e., positive risks) are characterized and are included in organizational cybersecurity risk discussions
Risk Management Strategy: Strategic opportunities (i.e., positive risks) are characterized and are included in organizational cybersecurity risk discussions
control · Context
GV.RR-01 — Roles, Responsibilities, and Authorities: Organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving
Roles, Responsibilities, and Authorities: Organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving
control · Context
GV.RR-02 — Roles, Responsibilities, and Authorities: Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced
Roles, Responsibilities, and Authorities: Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced
control · Context
GV.RR-03 — Roles, Responsibilities, and Authorities: Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies
Roles, Responsibilities, and Authorities: Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies
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
ID.AM-01 — Asset Management: Inventories of hardware managed by the organization are maintained
Asset Management: Inventories of hardware managed by the organization are maintained
control · Context
ID.AM-02 — Asset Management: Inventories of software, services, and systems managed by the organization are maintained
Asset Management: Inventories of software, services, and systems managed by the organization are maintained
control · Context
ID.IM-01 — Improvement: Improvements are identified from evaluations
Improvement: Improvements are identified from evaluations
control · Context
ID.IM-02 — Improvement: Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties
Improvement: Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties
control · Context
ID.RA-04 — Risk Assessment: Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded
Risk Assessment: Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded
control · Context
ID.RA-05 — Risk Assessment: Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization
Risk Assessment: Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization
control · Context
ID.RA-06 — Risk Assessment: Risk responses are chosen, prioritized, planned, tracked, and communicated
Risk Assessment: Risk responses are chosen, prioritized, planned, tracked, and communicated
control · Context
ID.RA-07 — Risk Assessment: Changes and exceptions are managed, assessed for risk impact, recorded, and tracked
Risk Assessment: Changes and exceptions are managed, assessed for risk impact, recorded, and tracked
control · Context
PR.AA-02 — Identity Management, Authentication, and Access Control: Identities are proofed and bound to credentials based on the context of interactions
Identity Management, Authentication, and Access Control: Identities are proofed and bound to credentials based on the context of interactions
control · Context
PR.AA-03 — Identity Management, Authentication, and Access Control: Users, services, and hardware are authenticated
Identity Management, Authentication, and Access Control: Users, services, and hardware are authenticated
control · Context
PR.AA-04 — Identity Management, Authentication, and Access Control: Identity assertions are protected, conveyed, and verified
Identity Management, Authentication, and Access Control: Identity assertions are protected, conveyed, and verified
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
500.10 — Cybersecurity personnel and intelligence
Cybersecurity personnel and intelligence
control · Context
500.11 — Third-party service provider security policy
Third-party service provider security policy
control · Context
500.12 — Multi-factor authentication
Multi-factor authentication
control · Context
500.16 — Incident response and business continuity management
Incident response and business continuity management
control · Context
500.17 — Notices to superintendent (incident notification and annual certification)
Notices to superintendent (incident notification and annual certification)
control · Context
500.18 — Confidentiality
Confidentiality
control · Context
500.19 — Exemptions
Exemptions
control · Context
500.4 — Chief Information Security Officer (CISO)
Chief Information Security Officer (CISO)
control · Context
500.9 — Risk assessment
Risk assessment
control · Context
PCI-Req8 — Identify users and authenticate access to system components
Identify users and authenticate access to system components
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-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
SOC1-6 — Data transmission / interface controls — controls provide reasonable assurance that data transmitted to and from the system and across interfaces is complete, accurate, authorized, and timely.
Data transmission / interface controls — controls provide reasonable assurance that data transmitted to and from the system and across interfaces is complete, accurate, authorized, and timely.
control · Context
SOC1-7 — Data input — controls provide reasonable assurance that transactions and data input into the system are complete, accurate, and authorized.
Data input — controls provide reasonable assurance that transactions and data input into the system are complete, accurate, and authorized.
control · Context
SOC1-8 — Data processing — controls provide reasonable assurance that transactions are processed completely, accurately, and in the proper period.
Data processing — controls provide reasonable assurance that transactions are processed completely, accurately, and in the proper period.
control · Context
SOC1-9 — Data output / reporting — controls provide reasonable assurance that output and reports provided to user entities are complete, accurate, and distributed only to authorized recipients.
Data output / reporting — controls provide reasonable assurance that output and reports provided to user entities are complete, accurate, and distributed only to authorized recipients.
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.1 — The entity demonstrates a commitment to integrity and ethical values.
The entity demonstrates a commitment to integrity and ethical values.
control · Context
CC1.3 — Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives.
Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives.
control · Context
CC1.5 — The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
control · Context
CC2.2 — The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.
The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.
control · Context
CC2.3 — The entity communicates with external parties regarding matters affecting the functioning of internal control.
The entity communicates with external parties regarding matters affecting the functioning of internal control.
control · Context
CC3.1 — The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
control · Context
CC3.2 — The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
control · Context
CC3.3 — The entity considers the potential for fraud in assessing risks to the achievement of objectives.
The entity considers the potential for fraud in assessing risks to the achievement of objectives.
control · Context
CC3.4 — The entity identifies and assesses changes that could significantly impact the system of internal control.
The entity identifies and assesses changes that could significantly impact the system of internal control.
control · Context
CC4.1 — The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
control · Context
CC4.2 — The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate.
The entity evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate.
control · Context
CC6.1 — The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
control · Context
CC7.2 — The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.
The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity's ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.
control · Context
CC7.3 — The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.
The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.
control · Context
CC9.1 — The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions.
The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions.
control · Context
PI1.2 — The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity's objectives.
The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity's objectives.
control · Context
PI1.3 — The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity's objectives.
The entity implements policies and procedures over system processing to result in products, services, and reporting to meet the entity's objectives.
control · Context
PI1.4 — The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity's objectives.
The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity's objectives.
control · Context
PI1.5 — The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity's objectives.
The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity's objectives.
control · Context
ELC-CE — Control Environment — tone at the top, integrity and ethical values, code of conduct, board/audit committee oversight, organizational structure, assignment of authority and responsibility, commitment to competence, HR policies.
Control Environment — tone at the top, integrity and ethical values, code of conduct, board/audit committee oversight, organizational structure, assignment of authority and responsibility, commitment to competence, HR policies.
control · Context
ELC-MGMT-OVR — Anti-fraud and management override controls — controls addressing the risk of management override of controls, including journal-entry review and review of significant estimates.
Anti-fraud and management override controls — controls addressing the risk of management override of controls, including journal-entry review and review of significant estimates.
control · Context
ELC-RA — Risk Assessment — entity objective-setting, identification and analysis of risks to financial reporting, fraud risk assessment, and assessment of changes affecting internal control.
Risk Assessment — entity objective-setting, identification and analysis of risks to financial reporting, fraud risk assessment, and assessment of changes affecting internal control.
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.
control · Context
PLC-AUTH — Authorization and approval — transactions, journal entries, and changes are reviewed and approved by authorized personnel in accordance with delegation-of-authority policies before being recorded or executed.
Authorization and approval — transactions, journal entries, and changes are reviewed and approved by authorized personnel in accordance with delegation-of-authority policies before being recorded or executed.
control · Context
PLC-CALC — Automated processing / configurable controls — system-enforced calculations, three-way matches, tolerance checks, and configurable application controls operating as designed.
Automated processing / configurable controls — system-enforced calculations, three-way matches, tolerance checks, and configurable application controls operating as designed.
control · Context
PLC-EXCEPTION — Exception and edit-report controls — review and timely resolution of system-generated exception, error, and edit reports.
Exception and edit-report controls — review and timely resolution of system-generated exception, error, and edit reports.
control · Context
PLC-INPUT — Input controls — edit/validation checks, completeness checks, and field/format controls that ensure data entered into systems is complete, accurate, and valid.
Input controls — edit/validation checks, completeness checks, and field/format controls that ensure data entered into systems is complete, accurate, and valid.
control · Context
PLC-INTF — Interface controls — controls ensuring data transferred between systems and across interfaces is complete, accurate, and processed only once (reconciliation of record counts/control totals, error handling).
Interface controls — controls ensuring data transferred between systems and across interfaces is complete, accurate, and processed only once (reconciliation of record counts/control totals, error handling).
control · Context
PLC-PHYS — Physical safeguards / custody controls — controls over physical custody of assets, inventory counts, and safeguarding of negotiable instruments and records.
Physical safeguards / custody controls — controls over physical custody of assets, inventory counts, and safeguarding of negotiable instruments and records.
control · Context
PLC-RECON — Reconciliations — account and subledger-to-general-ledger reconciliations performed completely and accurately, with timely review, approval, and resolution of reconciling items.
Reconciliations — account and subledger-to-general-ledger reconciliations performed completely and accurately, with timely review, approval, and resolution of reconciling items.
control · Context
PLC-SOD — Segregation of duties — incompatible duties (authorization, recording, custody, reconciliation) are divided among different people to reduce the risk of error or fraud.
Segregation of duties — incompatible duties (authorization, recording, custody, reconciliation) are divided among different people to reduce the risk of error or fraud.
risk · Direct
Environmental footprint of AI training and infrastructure
Training and large-scale inference consume disproportionate energy and generate greenhouse-gas emissions; rapid AI-hardware obsolescence produces e-waste and pressures critical-mineral supply chains, with environmental and geopolitical risk.
risk · Direct
Inaccurate, unreliable or hallucinated AI outputs
AI outputs contain factual errors, hallucinations, or confidently wrong predictions; inappropriate proxy metrics, overfitting/underfitting, or insufficient pre-deployment testing undermine trust in decisions made on their basis.
risk · Direct
AI power concentration and erosion of societal trust
Disproportionate access to data, compute, and AI talent creates winner-take-all dynamics foreclosing competition; proliferation of AI-generated synthetic media and automated influence operations degrades the shared epistemic environment and democratic institutions.
risk · Direct
AI safety failures causing physical or psychological harm
AI errors in safety-critical systems (autonomous vehicles, medical devices, industrial controls) cause injury or death; safety-constraint violations by agentic AI, cascading failures across coupled systems, and AI-generated misinformation/deepfakes cause harm.
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
Client suitability, disclosure and fiduciary breaches
Recommending unsuitable products, failing to disclose conflicts of interest, breaching fiduciary duty, KYC failures, inadequate disclosure of fees/risks, negligent advisory activities, and product flaws causing systematic customer harm.
risk · Direct
Environmental regulatory non-compliance
Unauthorized emissions or discharges, improper hazardous-waste handling, missing permits, or non-compliance with PFAS/chemical-reporting rules under EPA/RCRA/Clean Air & Water Acts — driving penalties and remediation.
risk · Direct
Adverse regulatory or policy change
Changes in law, regulation, tax policy, or government programs materially alter the entity’s cost structure, competitive dynamics, or permissible business practices, requiring costly adaptation.
risk · Direct
Sector regulatory non-compliance (financial, healthcare, trade)
Non-compliance with sector regimes — banking prudential rules, consumer-lending laws, payment-network rules, healthcare (FDA/HIPAA/CMS, Anti-Kickback/Stark, False Claims), export controls (EAR/ITAR), antitrust, and environmental/labor rules — triggering fines, sanctions, or loss of license.
risk · Direct
Client selection, sponsorship and exposure-limit breaches
Failure to investigate clients per guidelines, exceeding single-counterparty exposure limits without approval, and sponsoring transactions without adequate counterparty-risk assessment or AML/CTF screening.
risk · Direct
Attacks by capable, motivated threat actors
Because capable, motivated threat actors - outsiders, privileged and non-privileged insiders, organized groups, competitors, malicious partners or suppliers, and nation-states - actively target the organization's cyber resources, deliberate attacks are attempted against its systems and data, resulting in compromise, disruption, or theft when defenses are outmatched.
risk · Direct
Climate transition risk — carbon pricing and stranded assets
Carbon taxes, cap-and-trade, and mandatory Scope 1-2-3 reporting increase operating costs or strand carbon-intensive assets; failure to credibly plan a net-zero transition jeopardizes access to capital and changing consumer preferences.
risk · Direct
Money laundering, sanctions and financial-crime program failures
Failure to prevent money laundering or terrorist financing, file SARs/CTRs, perform adequate KYC/beneficial-ownership due diligence, screen for PEPs, or avoid processing transactions for OFAC-sanctioned parties; BSA/AML program deficiencies.
risk · Direct
Credit and market (rate/FX) risk
Counterparty/customer default exceeding collateral, receivables concentration in deteriorating credits, and unhedged exposure to interest-rate, foreign-exchange, commodity, or equity movements causing material P&L or cash-flow volatility.
risk · Direct
Liquidity, capital-structure and refinancing risk
Cash-flow shortfall from working-capital deterioration, covenant breaches accelerating debt, loss of revolving credit, or capital-market disruption; debt maturity walls and downgrades limiting refinancing at acceptable terms; insufficient capital to absorb losses.
risk · Direct
External fraud — third-party theft, forgery, payment and account fraud
Third parties defraud the entity: cheque/payment-card forgery, counterfeit currency, identity theft, account takeover with stolen credentials, fraudulent loan applications, and first-party (bust-out) fraud by customers.
risk · Direct
Internal fraud — asset misappropriation, embezzlement, forgery
Employees defraud the entity for financial gain: embezzlement or theft of company/client funds, fraudulent expense/payroll claims, forgery to obtain unauthorized disbursements, bribery/kickback schemes, insider trading on own account, and wilful tax evasion.
risk · Direct
Unauthorized activity — rogue trading, position mismarking, concealment
Losses from transactions not reported or of an unauthorized type, deliberate mismarking of positions, fictitious trade bookings to conceal losses, and circumvention of position/risk limits without disclosure (e.g. rogue trader).
risk · Direct
Major project / program delivery failure
Large programs — ERP implementations, digital transformations, or major capital projects — fail to deliver expected benefits on time and within budget due to poor governance, scope creep, or capability gaps.
risk · Direct
Innovation and R&D governance failure
Insufficient investment in or poor governance of innovation and R&D pipelines results in loss of competitive differentiation, failure to meet customer expectations, and premature obsolescence of products and services.
risk · Direct
Negligent advisory activities and breach of duty of care
Losses from disputes over M&A, structuring, financial-planning, or hedging advice where the firm has a duty of care — including failure to advise clients of material risks in recommended transactions.
risk · Direct
Core process breakdown and inability to scale
Poorly designed, undocumented, or poorly executed business processes lead to errors, rework, cost overruns, service failures, and inability to scale operations reliably; large change programs fail to deliver benefits on time and budget.
risk · Direct
Trade-counterparty performance and settlement disputes
Counterparty default on OTC derivatives, settlement disputes with brokers/custodians, failure of a central counterparty, netting/close-out disputes, and margin-call miscalculations cause direct losses.
risk · Direct
Client intake, documentation and account-management failures
Missing signed agreements, incomplete legal/ISDA documentation, unretained KYC/AML records, misfiled client files, unauthorized access to client accounts, and negligent loss of client assets held in custody.
risk · Direct
Transaction-processing and execution errors
Data-entry (fat-finger) errors, incorrect settlement instructions, collateral-management errors, reconciliation failures, and mis-application of corporate actions cause failed settlement, penalties, and undetected position discrepancies.
risk · Direct
Product design and model errors
Defective product design, errors in model or pricing assumptions embedded in products, and failure to investigate customer complaints cause systematic customer harm and mis-selling losses.
risk · Direct
Product and service quality failure
Outputs fail to meet specifications, customer requirements, or regulatory standards, leading to recalls, warranty claims, customer attrition, and reputational harm; product-safety incidents generate scrutiny and brand-equity erosion.
risk · Direct
Brand and reputational crisis
Product-safety/quality failures, executive misconduct, data breaches, adverse media, or viral social-media/activist campaigns erode customer trust, investor confidence, partnerships, and brand equity — with long-term value loss exceeding near-term financial impact.
risk · Direct
Stakeholder trust and social-license erosion
Gradual loss of trust and social license among customers, employees, investors, regulators, and communities — from perceived values misalignment, poor ESG/governance conduct, or repeated service failures — weakening stakeholder relationships and long-term enterprise value even absent a single acute crisis.
risk · Direct
Inadequate or absent risk assessment process
No systematic process to identify, analyse, evaluate, and treat risk — including missing fraud-risk assessment and no ongoing risk monitoring — leaving material exposures unidentified and untreated before they materialise.
risk · Direct
Product, customer or market concentration
Revenue or gross profit concentrated in a single product line, customer, channel, or geography; loss of one major customer or an adverse regulatory change to a dominant product creates existential revenue risk.
risk · Direct
Competitive disruption and business-model obsolescence
A new entrant with a superior model, lower cost, or breakthrough technology captures share faster than the company can respond; industry/technology/customer shifts render the existing business model obsolete.
risk · Direct
Geopolitical, macroeconomic and sovereign risk
Armed conflict, political instability, sanctions, trade-policy reversals (tariffs, export bans, data-localization, forced tech transfer), expropriation/nationalization, and adverse macroeconomic cycles disrupt operations, supply chains, and cost structures.
risk · Direct
Innovation shortfall and emerging-technology adoption risk
Because the organization under-invests in or poorly governs its innovation pipeline while adopting unproven emerging technologies (AI/ML, blockchain, cloud) without adequate diligence, it faces both loss of differentiation and obsolescence and implementation failure, vendor lock-in, or ethical exposure, resulting in eroded competitiveness and failed technology bets.
risk · Direct
Failed M&A, integration or divestiture
Acquisitions fail to achieve synergies due to cultural misalignment, IT-integration failure, or customer attrition; overpayment and hidden liabilities materialise as goodwill impairment; divestitures disrupt shared-service dependencies.
risk · Direct
Strategic misalignment and execution failure
Because strategic objectives are poorly defined, internally inconsistent, or misaligned with mission and stakeholders, approved strategies cannot be executed - resource gaps and weak governance of change compound the shortfall - resulting in resource misallocation, missed objectives, and value destruction.
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 · Context
UC-ACCESS-05 — Enforce approved authorizations for information and functions
Systems mediate every access attempt through a tamper-resistant, always-invoked enforcement mechanism that applies approved authorizations before granting access to information or functions. Restrictions use roles and security attributes bound to data and subjects, limiting access to sensitive information, source code, and administrative functions to explicitly authorized identities. Enforcement rules are applied consistently across applications, databases, and infrastructure and are tested for effectiveness.
unified · Context
UC-ACCESS-07 — Proof identities before binding credentials
The identity of users is verified through documented evidence checks proportional to the assurance level of the access requested before initial credentials are issued. The proofed identity is bound to its credentials and recorded, and re-proofing occurs on credential recovery or other high-risk changes.
unified · Context
UC-ACCESS-08 — Manage and protect authenticators across their lifecycle
Authenticators (passwords, tokens, keys, certificates) are issued through a verified process, with vendor defaults changed before use and minimum strength requirements enforced. Authentication information is protected in storage (salted hashing or encryption) and in transmission, masked during entry, and never embedded in code or scripts. Authenticators are revoked on compromise or separation and rotated at defined intervals or events.
unified · Context
UC-ACCESS-09 — Authenticate all users with multi-factor authentication
Every user is uniquely identified and authenticated before access, with multi-factor authentication enforced for remote access, privileged access, and access to sensitive data environments. Authentication follows secure log-on practices: credentials are validated only over protected channels, and federated identity assertions (e.g., SAML/OIDC tokens) are signed, protected, and verified. External and non-organizational users are held to the same authentication rigor, with authentication strength documented against the risk of the interaction.
unified · Context
UC-ACCESS-11 — Defend logons against brute-force and anomalous attempts
Accounts lock or are throttled after a defined number of consecutive failed logon attempts for a set duration or until administrator release. Risk-based signals such as location, device, and behavior trigger adaptive responses including step-up authentication, additional verification, or denial for anomalous logon attempts. Lockout and anomaly events are logged for review.
unified · Context
UC-ACCESS-13 — Notify users of system terms and previous logon activity
An approved system-use notification is displayed before logon, stating monitoring, usage terms, and privacy expectations, and requiring acknowledgment where mandated. Upon successful logon, the system displays the date and time of the user's last logon, and failed attempts where supported, so users can detect unauthorized use of their accounts.
unified · Context
UC-ACCESS-15 — Design control activities over technology access
Management selects and develops control activities, including general controls over technology, that mitigate identified access-related risks to acceptable levels, documented in a control matrix mapping risks to controls. Control designs cover the technology infrastructure, security management, and acquisition and development processes relevant to access, and are updated as risks and systems change.
unified · Context
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-20 — Ensure complete, accurate, and authorized data processing
Transactions and data entering the system are validated for completeness, accuracy, and authorization through edit checks, batch totals, and exception queues. Interfaces and transmissions between systems are controlled with reconciliation, error handling, and timeliness checks, and processing applies complete and accurate logic in the proper period. Outputs and reports are validated and distributed only to authorized recipients.
unified · Context
UC-AI-01 — Maintain and periodically review the AI policy
Establish a management-approved AI policy that sets principles and requirements for developing and using AI systems, and keep it demonstrably consistent with related organizational policies such as security, privacy, and ethics. Review the policy at planned intervals and upon significant regulatory or technology change, recording review outcomes and revisions. Publish the current version to all relevant personnel and retain prior versions as evidence.
unified · Context
UC-AI-03 — Document AI system resources and dependencies
Maintain a documented inventory of the resources each AI system depends on, covering data resources, tooling such as frameworks, libraries, and models, and system and computing resources, together with their owners and locations. Record sufficient detail for each resource to support impact assessment, reproducibility, and supplier accountability. Keep the inventory current through the change process and review it periodically.
unified · Context
UC-AI-05 — Set responsible AI development objectives and requirements
Define objectives for responsible AI development, such as fairness, safety, security, transparency, and accountability, and embed them in a documented design and development process. Specify and document requirements for each AI system, including intended purpose, performance criteria, and constraints, before build begins. Evidence includes the development process definition, per-system requirement specifications, and design-stage approvals.
unified · Context
UC-AI-06 — Maintain AI system technical documentation
Produce and maintain technical documentation for each AI system covering design and development decisions, architecture, model and data characteristics, performance, and limitations, including all content mandated by applicable regulation for higher-risk systems. Keep documentation up to date through changes and retain it for the regulatorily mandated period. Documentation must be sufficient for regulators and assessors to evaluate compliance.
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-AI-09 — Govern AI data quality, provenance, and preparation
Govern training, validation, and test data under documented data-management practices covering acquisition, selection, provenance recording, and preparation activities such as labelling, cleaning, and enrichment. Apply and record quality criteria appropriate to the intended purpose, including relevance, representativeness, and, to the best extent possible, completeness and freedom from errors, and examine datasets for biases with mitigation of those likely to affect health, safety, or fundamental rights. Retain data documentation and provenance records for each AI system.
unified · Context
UC-AI-10 — Meet transparency obligations for AI systems
Provide users, deployers, and other interested parties with documentation and instructions for each AI system describing its intended purpose, capabilities, limitations, performance characteristics, and required human-oversight measures. Disclose when people are interacting with an AI system, and mark AI-generated or manipulated content, including deepfakes, in a machine-readable and clearly perceptible way where required. Keep transparency materials current with system changes and retain distribution evidence.
unified · Context
UC-AI-11 — Operate AI concern, incident, and external reporting channels
Operate channels through which personnel and other stakeholders can report concerns about the organization's role in developing or using AI systems, with documented triage and follow-up. Define and execute procedures for communicating AI incidents to affected users and interested parties, and for making required reports to regulators and other external bodies within mandated timeframes. Retain concern reports, incident communications, and resolution records as evidence.
unified · Context
UC-AI-12 — Enforce responsible and lawful use of AI systems
Define objectives and documented processes for responsible use of AI systems, and ensure each system is used only in accordance with its intended use and accompanying documentation. Screen proposed and existing uses against legal prohibitions on unacceptable practices — such as manipulative techniques, social scoring, and untargeted facial-image scraping — and block or discontinue prohibited uses. Retain use approvals and screening records.
unified · Context
UC-AI-14 — Manage responsible AI with suppliers and customers
Govern supplier relationships that provide AI systems, components, or data through a documented process that verifies supplier alignment with the organization's responsible-AI requirements. Ensure the organization's responsible development and use of AI considers customer needs and expectations, and provide customers with the information they need to use AI systems responsibly. Retain supplier evaluations and customer communications as evidence.
unified · Context
UC-AI-15 — Fulfill general-purpose AI model provider obligations
Where the organization provides general-purpose AI models, maintain model technical documentation and information for downstream providers, implement a policy to comply with applicable copyright law including reservation-of-rights opt-outs, and publish a sufficiently detailed summary of training content. For models designated as posing systemic risk, additionally perform state-of-the-art model evaluations including adversarial testing, assess and mitigate systemic risks, track and report serious incidents to the competent authority, and ensure adequate cybersecurity protection for the model and its infrastructure.
unified · Context
UC-AI-16 — Ensure human oversight of AI decisions
Design and operate high-risk AI systems so that natural persons can effectively oversee them during use, through human-machine interface tools and oversight measures built into the system or defined for the deployer. Assign oversight to persons who understand the system's capacities and limitations, can monitor operation, remain aware of automation bias, correctly interpret output, and can decide not to use, override, or halt the system. Evidence includes oversight procedures, oversight assignments, and intervention records.
unified · Context
UC-AI-19 — Constrain agent actions and tool use to authorized scope
Bound what autonomous agents may do: allow-list the tools, connectors, and actions each agent may invoke; scope its permissions to the task, user, and context; require human approval for irreversible, high-value, or out-of-policy actions; execute agent-generated code only in isolated sandboxes; and scan agent configuration artifacts such as hooks, skills, and rules for injected instructions. Log every tool call with its authorization decision and review denied and escalated calls.
unified · Context
UC-AI-20 — Prevent harmful, out-of-scope, hallucinated, and over-exposed AI outputs
Filter and shape every AI output before release: block or transform content that matches the system's harmful-output taxonomy, keep responses within the declared scope and capabilities, detect agent-specific high-risk outputs and route them to defined responses by severity, ground factual claims in cited sources and verify them to limit hallucination, withhold system prompts, internal data, and other over-exposed information, and sanitize outputs consumed by downstream systems so they cannot carry executable or injected payloads. Measure filter effectiveness and retain configurations, block logs, and review samples as evidence.
unified · Context
UC-AI-21 — Commission independent third-party AI evaluations on a quarterly cadence
Engage an independent evaluator at least quarterly to test each in-scope AI system against its defined risk categories: adversarial robustness and jailbreak resistance, harmful and out-of-scope outputs, agent-specific high-risk outputs, hallucination rates, and unsafe or unauthorized tool calls. Fix the test scope and pass thresholds in advance, track every finding to remediation and retest, and retain evaluator reports, methodologies, and remediation evidence.
unified · Context
UC-AI-23 — Prevent misuse of AI systems for cyber offense and catastrophic harm
Recognize and refuse requests that seek meaningful uplift for offensive cyber operations or for biological, chemical, nuclear, or radiological harm, calibrated to the capability level of the deployed models; monitor for misuse patterns, escalate and report confirmed attempts, and keep refusal policies, classifiers, and escalation procedures current as capabilities change. Retain misuse-detection configurations, incident records, and periodic review evidence.
unified · Context
UC-AI-24 — Operate an AI quality management system
Establish and maintain a documented quality management system for AI products covering quality objectives and responsibilities; documented design, development, testing, and release procedures; change management; data management procedures; issue tracking and corrective action; stakeholder and regulator communication procedures; and record keeping. Review the system periodically for effectiveness and continual improvement, and retain the quality manual, procedures, review records, and corrective-action logs as evidence.
unified · Context
UC-ASSET-01 — Maintain a complete inventory of systems, hardware, and software
Maintain a documented inventory of all hardware, software, systems, and services, recording owner, location, and the attributes needed for accountability and security management. Update the inventory as part of component installation, removal, and change, and reconcile it at least quarterly to correct discrepancies. Include every in-scope component so the inventory serves as the authoritative record of protected information assets for audit and compliance scoping.
unified · Direct
UC-ASSET-10 — Assess and track changes and exceptions for risk impact
Manage changes and exceptions to the environment and to security requirements through a process that assesses risk impact before approval. Record each change or exception with its assessment, approver, owner, and expiry or review date, and track open items to closure.
unified · Context
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-01 — Maintain an independent internal audit function
The organization maintains an internal audit function that provides the board and management with independent, risk-based, and objective assurance, advice, insight, and foresight to protect and sustain organizational value. The function is positioned independently of management activities it audits: the chief audit executive reports functionally to the board, holds the qualifications and competencies the role requires, and has unrestricted access to the board. Independence is affirmed to the board at least annually.
unified · Context
UC-AUDIT-15 — Document and supervise engagement work
Engagement work is documented in workpapers sufficient for an experienced internal auditor to understand the work performed and the support for results and conclusions, and is retained according to defined retention requirements. Engagement performance is supervised and reviewed throughout the engagement, with review notes resolved before results are communicated, to ensure quality and conformance with methodologies.
unified · Context
UC-AUDIT-17 — Follow up on findings and escalate risk acceptance
Findings, recommendations, and management action plans - including improvements identified from security tests and exercises, and those coordinated with suppliers and third parties - are tracked in a follow-up process, and implementation is confirmed through evidence-based verification before closure. When management has accepted a level of risk that may exceed the organization's risk appetite, the matter is discussed with senior management and, if unresolved, escalated to the board. Follow-up logs and escalation records are retained.
unified · Context
UC-AUDIT-20 — Obtain external quality assessments of internal audit
An external quality assessment of the internal audit function is obtained at the frequency mandated by applicable professional standards from a qualified, independent assessor or assessment team, evaluating conformance with applicable professional internal auditing standards. The board participates in determining the assessment scope and assessor selection and receives the results directly, and resulting improvement actions are planned and tracked to completion.
unified · Context
UC-AUDIT-22 — Review risk strategy and performance with leadership
Leadership periodically reviews the cybersecurity and risk management strategy and program performance against defined metrics, targets, and conformance requirements. Review outcomes are used to adjust strategy, direction, and program activities to ensure coverage of organizational requirements and risks. Performance and conformance monitoring follows a defined cadence with documented results and assigned follow-up actions.
unified · Context
UC-AUDIT-24 — Manage compliance with external legal and regulatory requirements
The organization identifies applicable external legal, regulatory, and contractual requirements - including intellectual property rights and software licensing obligations - and maintains them in a compliance register with assigned owners. Compliance with these requirements is evaluated on a defined cadence, confirmed through documented reviews, and non-compliance is remediated with status reported to management. The register and evaluation results are retained as evidence.
unified · Context
UC-AUDIT-27 — Govern expanded internal audit ERM responsibilities
Any ERM, compliance, risk-management, or other second-line responsibility assigned to the internal audit function or chief audit executive is classified as assurance, advisory, administrative, supervisory, or operational; justified and documented in the internal audit charter or a board-approved appendix; and approved by the board with the associated independence and objectivity risks. Internal audit does not select or own risk responses or other management decisions. Expanded responsibilities are time-bounded with a transition plan when intended to be temporary, and actual or perceived impairments are disclosed to the board. Internal auditors do not provide assurance over an activity they designed, operated, managed, or supervised during the preceding 12 months; another suitably qualified and independent party provides assurance for affected areas. Safeguards, alternative assurance, and transition status are reviewed periodically.
unified · Context
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 · Context
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 · Context
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 · Context
UC-BCDR-13 — Operate continuous security protection services
Operate ongoing protection services, including malware defense, network and endpoint security, and security monitoring, so that attacks and disruptions do not compromise service availability or data. Review and tune these services regularly to keep security risk within accepted levels.
unified · Context
UC-BCDR-14 — Embed control activities in business processes
Define and operate control activities embedded within key business processes - input, processing, and output controls, segregation of duties and levels of authority, error and exception handling, and traceability of transactions - so that information processed remains complete, accurate, and valid.
unified · Context
UC-FIN-03 — Perform and review account reconciliations
Perform account and subledger-to-general-ledger reconciliations for in-scope accounts on a defined frequency, verifying the completeness and accuracy of balances. Require independent, timely review and approval of each reconciliation, and age, track, and resolve reconciling items within defined thresholds. Retain completed reconciliations, approvals, and resolution evidence.
unified · Context
UC-FIN-04 — Authorize transactions with attributable approvals
Require transactions, journal entries, and master-data or configuration changes to be reviewed and approved by authorized personnel in accordance with the delegation-of-authority matrix before they are recorded or executed. Capture approvals in systems under unique authenticated user accounts with tamper-evident audit trails that irrefutably bind each approval to the individual who performed it, so that approval actions cannot be repudiated. Evidence includes the delegation-of-authority matrix, approval workflow configurations, and approval audit trails.
unified · Context
UC-FIN-05 — Segregate incompatible financial duties
Divide incompatible duties, including authorization, recording, custody of assets, and reconciliation, among different individuals across financial processes so that no one person can both perpetrate and conceal an error or fraud. Enforce the segregation through role design and system access, maintain a documented segregation-of-duties conflict matrix, and review conflicts periodically with documented mitigating controls where segregation is impracticable.
unified · Context
UC-FIN-06 — Validate completeness and accuracy of system inputs
Implement input controls over data entered into financial systems, including edit and validation checks, required-field and format controls, completeness checks, and rejection or suspense handling of invalid entries, so that inputs are complete, accurate, and valid. Define these controls in documented policies and procedures over system inputs and retest their configuration on change. Evidence includes configuration baselines, validation rules, and rejected-input handling records.
unified · Context
UC-FIN-07 — Control automated processing and resolve exceptions
Configure automated processing controls, including system-enforced calculations, three-way matches, tolerance checks, and other configurable application controls, under documented policies and procedures so transactions are processed completely, accurately, and in the proper period. Generate exception, error, and edit reports from processing, and review and resolve reported items timely with documented disposition. Evidence includes control configurations, configuration change approvals, and exception-report review records.
unified · Context
UC-FIN-08 — Control interface transfers and output delivery
Control data transferred between systems and delivered as output so that it is complete, accurate, timely, and processed only once, using record counts, control totals, or hash checks reconciled at each interface with automated error handling and alerting for failures. Deliver or make output available in accordance with documented specifications, and investigate and resolve interface or delivery failures timely. Evidence includes the interface inventory, reconciliation results, and failure-resolution logs.
unified · Context
UC-FIN-10 — Safeguard assets and stored financial data
Restrict physical custody of financial assets, negotiable instruments, and accounting records to authorized custodians, and perform periodic counts and inspections reconciled to the accounting records. Store transaction inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications and retention requirements, protecting them against loss and unauthorized alteration. Evidence includes custody logs, count results, and storage and retention configurations.
unified · Context
UC-GOV-01 — Establish and maintain the enterprise governance framework
Design, implement, and maintain an enterprise governance system for information and technology that sets direction, decision rights, and accountability, together with a supporting management framework (organizational structures, policies, processes, and culture) that puts governance direction into operation. Evaluate the effectiveness of the governance and management framework periodically and adjust it as the enterprise context, strategy, and regulatory environment change.
unified · Context
UC-GOV-02 — Understand organizational context and stakeholder expectations
Identify and document the organization's mission, its internal and external stakeholders and their needs and expectations, the critical objectives, capabilities, and services that stakeholders depend on, and the outcomes, capabilities, and services the organization itself depends on. Use this business context to scope and prioritize risk management activities, communicate it to those who need it, and refresh it when the business environment changes.
unified · Context
UC-GOV-03 — Identify and manage legal, regulatory, and contractual obligations
Identify, document, and keep current all legal, statutory, regulatory, and contractual requirements relevant to information security and privacy — including privacy and civil-liberties obligations — and define and assign the organization's approach to meeting each. Assess and document applicability determinations, including any regulatory exemptions claimed, and file the notices required to support those determinations. Review the obligations register at planned intervals and upon regulatory or business change.
unified · Context
UC-GOV-04 — Set tone at the top: integrity, ethics, and risk-aware culture
Leadership defines and demonstrates commitment to integrity, core ethical values, and the desired risk-aware culture through an adopted code of conduct, consistent leadership behavior, and periodic evaluation of adherence with timely remediation of deviations. Organizational leadership is responsible and accountable for cybersecurity and internal-control risk and fosters a culture that is ethical, risk-aware, and continually improving, with expectations communicated to all personnel and business partners.
unified · Context
UC-GOV-06 — Define security roles, responsibilities, and authorities
Establish and document organizational structures, reporting lines, and the roles, responsibilities, and authorities for information security, risk management, and internal control, with board oversight of their design. Communicate assignments to the individuals and teams concerned, keep them current through organizational and personnel change, and enforce them in practice so that ownership of each security obligation is unambiguous.
unified · Context
UC-GOV-07 — Hold individuals accountable for control responsibilities
Management requires all personnel to apply information security in accordance with established policies and procedures and holds individuals accountable for their internal control responsibilities. Accountability is enforced through defined expectations, documented rules of behavior acknowledged before access is granted and re-acknowledged when updated, performance measures and incentives, and disciplinary consequences for violations.
unified · Context
UC-GOV-08 — Segregate conflicting duties and areas of responsibility
Identify duties and areas of responsibility that conflict — such as requesting versus approving access, development versus production deployment, or initiating versus approving transactions — and segregate them among different individuals or roles. Where segregation is impracticable, apply and document compensating controls such as enhanced monitoring, logging, or independent review.
unified · Context
UC-GOV-09 — Appoint accountable security leadership (CISO)
Designate a qualified senior leader (e.g., a Chief Information Security Officer) with organization-wide responsibility, accountability, authority, and resources to develop, implement, and enforce the information security program, and designate accountable leadership roles for the risk management program. The security leader reports in writing on the program, material cybersecurity risks, and remediation plans to the board or equivalent governing body at least annually.
unified · Context
UC-GOV-10 — Attract, develop, and retain competent personnel
Plan and manage the workforce so the organization attracts, develops, and retains individuals competent for their security and control responsibilities, including qualified cybersecurity personnel sufficient to manage the organization's risks and perform core security functions. Define required competencies, evaluate them periodically, address gaps through training, development, and succession planning, and verify that key security personnel maintain current knowledge of evolving threats and countermeasures.
unified · Context
UC-GOV-11 — Allocate adequate resources and budget for security
Allocate and manage funding, personnel, and other resources commensurate with the organization's cybersecurity risk strategy, roles, responsibilities, and policies, ensuring security and privacy requirements are addressed in capital planning, budgeting, and investment decisions. Periodically evaluate resource allocation and utilization for adequacy and optimization, and adjust budgets as priorities and risks change.
unified · Context
UC-GOV-12 — Align strategy and business objectives with mission and risk
Define and maintain an enterprise and technology strategy aligned with the organization's mission, evaluating alternative strategy options in light of the risk profile and formulating business objectives at all levels that align with and support the chosen strategy. Translate the strategy into a communicated roadmap and monitor execution against it, revisiting objectives when context or risk changes.
unified · Context
UC-GOV-13 — Govern the technology investment portfolio for value
Govern the portfolio of technology investments and innovation to secure optimal value: define investment criteria, evaluate and prioritize initiatives — including emerging technologies and innovation opportunities — based on benefit, cost, and risk, and monitor programs against expected benefits. Take corrective action, including reprioritization or termination, when expected value is not being realized.
unified · Context
UC-GOV-17 — Establish enterprise risk management strategy and appetite
Establish, document, and communicate a leadership-approved enterprise risk management strategy, including risk management objectives agreed by stakeholders, defined risk appetite and tolerance statements, and a documented risk assessment policy with procedures and a consistent methodology for identifying, analyzing, prioritizing, and responding to risk. Ensure governance activities keep risk-taking optimized within appetite, and review and update the strategy, appetite, and policy at planned intervals.
unified · Context
UC-GOV-19 — Maintain enterprise security and privacy architecture
Establish and maintain an enterprise architecture, including security and privacy architectures, that describes how systems, information flows, and protections align with the organization's mission and strategy and address security and privacy risks. Review and update the architecture at defined intervals and reflect it in system security plans, solution designs, and acquisition decisions.
unified · Context
UC-GOV-21 — Communicate and report risk and control information
Establish channels, responsibilities, and cadences to communicate risk, control, and performance information internally at all levels — including objectives and internal control responsibilities — and with external stakeholders, business partners, and the technology function. Leverage information systems to capture, process, and deliver this reporting, and report on risk, culture, and performance to stakeholders at defined intervals and on significant events.
unified · Context
UC-GOV-24 — Notify regulators of incidents and file required certifications
Maintain documented procedures to notify supervisory and regulatory bodies of reportable cybersecurity events within mandated regulatory timelines, including any staged early-warning, detailed-notification, and final-report deadlines, and to submit required periodic compliance certifications and filings. Handle regulatory submissions and related materials confidentially, and retain evidence of all notifications, certifications, and supporting records.
unified · Context
UC-GOV-25 — Operate a privacy program with accountable leadership
Establish and maintain a privacy program and program plan defining the technical and organisational measures by which the organization ensures, and is able to demonstrate, compliance with privacy requirements. Designate a qualified, appropriately independent privacy leader (a Data Protection Officer where required) with defined tasks, adequate resources, and direct reporting to the highest level of management. Disseminate privacy program information to the workforce and the public, and report on privacy posture and program effectiveness at defined intervals.
unified · Context
UC-GOV-26 — Enforce personal-data processing principles and minimization
Adopt and enforce policies and procedures requiring that personal data is processed lawfully, fairly, and transparently; collected for specified, explicit purposes; limited to what is necessary; kept accurate through defined quality-management checks and correction procedures; stored no longer than needed; and protected — with accountability demonstrable through documentation. Minimize or use de-identified personally identifiable information in testing, training, and research, applying documented techniques where full data is not required.
unified · Context
UC-GOV-27 — Manage privacy complaints and account for disclosures
Implement a process to receive, track, and resolve privacy-related complaints, concerns, and questions from individuals within defined response times, including escalation paths and feedback to complainants. Maintain an accurate accounting of disclosures of personal information — including date, nature, purpose, and recipient — retained for the required period and made available to the individuals concerned upon request.
unified · Context
UC-GOV-31 — Maintain access control, identity, and personnel security policies
Establish, document, and disseminate policies and procedures governing logical access control, identification and authentication, and personnel (human resources) security — covering authorization based on need-to-know and least privilege, credential and authenticator management, and personnel screening, transfer, and termination requirements. Communicate these policies to the workforce and review and update them at defined intervals and upon significant change.
unified · Context
UC-GOV-34 — Maintain business continuity and contingency planning policy
Establish, document, and disseminate contingency planning policy and procedures, identify risks arising from potential business disruptions — including to critical infrastructure and essential services — and select and develop mitigation activities (including consideration of insurance and other risk transfer) proportionate to those risks. Review and update the policy and the mitigation portfolio at defined intervals and after significant disruptions.
unified · Context
UC-GOV-35 — Maintain incident response policy and procedures
Establish, document, and disseminate an incident response policy and supporting procedures that define what constitutes a security incident, roles, responsibilities, and authorities, and requirements for detection, internal reporting, handling, escalation, and post-incident review. Review and update the policy and procedures at defined intervals and after significant incidents or exercises.
unified · Context
UC-GOV-37 — Operate insider-threat and threat-awareness programs
Implement an insider threat program that includes a cross-discipline insider threat incident handling team and defined indicators, reporting channels, and response procedures, together with a threat awareness program that shares current threat information across the organization, including with leadership and security personnel. Review the effectiveness of both programs at defined intervals and adjust them to the evolving threat environment.
unified · Context
UC-GOV-38 — Assign and maintain Three Lines accountability by risk activity
For every material risk and each applicable enterprise-risk-management activity — identify, assess, manage, monitor, and report — the organization assigns a named first-line owner accountable for risk decisions and responses, a second-line role providing specialist support, monitoring, and challenge, and an independent third-line assurance role where warranted. External providers are classified according to the role performed for the activity rather than the function that engaged them. Assignments are documented at activity level, acknowledged by the assigned parties, approved by the appropriate governance authority, and reviewed at least annually and upon significant organizational or responsibility changes. The review identifies missing ownership, incompatible duties, duplicate coverage, and self-assurance. Outsourcing does not transfer management or board accountability.
unified · Context
UC-LOG-04 — Continuously monitor systems for anomalous activity
Operate continuous monitoring under a documented strategy that defines what is monitored, the metrics, and the frequencies — including ongoing assessment of security-control effectiveness — and report security status to defined roles on a defined cadence. Deploy monitoring across hosts, networks, and applications, at the perimeter and interior, to detect attacks, indicators of compromise, unauthorized connections, and anomalous behaviour indicative of malicious acts, natural disasters, or errors. Analyze flagged anomalies promptly to determine whether they represent security events requiring further evaluation.
unified · Context
UC-LOG-05 — Correlate and analyze events centrally with threat intel
Aggregate logs and alerts into a central analysis capability (such as a SIEM) that correlates information from multiple internal and external sources and enriches it with cyber threat intelligence and contextual information. Review and analyze collected records on a defined cadence for indications of inappropriate or unusual activity, using record-reduction and on-demand report generation that does not alter the original records. Route findings and adverse-event information to authorized staff and tools, and communicate monitoring responsibilities and results internally so accountable parties can act.
unified · Context
UC-LOG-06 — Evaluate events and declare incidents against defined criteria
Define written criteria for declaring a security incident, including thresholds that identify a reportable personal-data breach. Evaluate analyzed events against those criteria, declare incidents and initiate the response process when criteria are met, and record the assessment and rationale for every evaluated event. For reportable personal-data breaches, notify the competent regulator within the mandated statutory window with the prescribed content, and document all breaches, their effects, and remediation regardless of whether notification was required.
unified · Context
UC-LOG-09 — Monitor providers and exchange audit data across organizations
Define monitoring requirements for external service providers and monitor their activities, service status, and security-relevant events against contractual obligations, reviewing provider-supplied logs and reports on a defined cadence. Where audit trails cross organizational boundaries, agree methods for coordinating, exchanging, and protecting audit information with the external parties and preserve the identity context needed to trace cross-organizational actions.
unified · Context
UC-LOG-10 — Monitor the physical environment for adverse events
Monitor the physical environment of facilities hosting systems and data — using mechanisms such as camera surveillance, badge and entry logs, and environmental sensors — to detect potentially adverse physical events. Review physical-access records and environmental alerts on a defined cadence and feed anomalies into security-event analysis.
unified · Direct
UC-RISK-01 — Establish and maintain a tailored risk management framework
Senior leadership establishes, approves, and visibly sponsors an enterprise risk management framework customized to the organization's external and internal context. The framework design defines accountabilities, resources, and processes for managing risk, and the framework is implemented across the organization on a planned schedule. Where regulated technologies such as high-risk AI systems are in scope, the framework is extended with the required lifecycle-specific risk processes. Approved framework documentation and implementation plans are retained as evidence.
unified · Direct
UC-RISK-02 — Integrate risk management into enterprise processes and projects
Risk management is integrated into organizational structures, decision-making, and business activities rather than operated as a standalone silo. Cybersecurity and information security risk activities are incorporated into enterprise risk management processes, and information security risk is addressed within project management for all projects from initiation through delivery. ERM artifacts referencing cyber risk and project gate documentation with security risk sections evidence operation.
unified · Direct
UC-RISK-03 — Define risk appetite, tolerance, and risk assessment criteria
The organization documents its risk framing: risk appetite and tolerance statements, assumptions, constraints, priorities, and the scope and context within which risk is managed. A standardized, structured methodology for calculating, documenting, categorizing, and prioritizing risks is defined, approved, communicated, and maintained. Risk criteria and appetite statements are reviewed periodically and after significant organizational change.
unified · Direct
UC-RISK-04 — Define objectives and business context for risk assessment
The organization specifies business objectives with sufficient clarity to enable the identification and assessment of risks relating to those objectives. Mission-essential and business processes are defined, including their information protection needs, and serve as the basis for risk assessment scoping. Objective and process definitions are documented, approved, and revisited when strategy or operations change.
unified · Direct
UC-RISK-05 — Communicate and consult with stakeholders on risk
Established lines of communication ensure risk information flows across the organization and with external stakeholders, including risks from suppliers and other third parties. Stakeholders are appropriately and inclusively involved through structured communication and consultation at each step of the risk process, and human and cultural factors are explicitly considered. Consultation records, meeting minutes, and risk communication distributions evidence operation.
unified · Direct
UC-RISK-06 — Perform periodic enterprise risk assessments
The organization performs an enterprise-wide risk assessment at least annually and upon significant change, identifying and analyzing risks to the achievement of objectives, including cybersecurity, privacy, and financial reporting risks. Assessments follow the documented methodology, address the design of the control environment and evolving threats and technologies, and are approved by management. Assessment reports, methodology references, and approvals are retained as evidence.
unified · Direct
UC-RISK-07 — Identify and analyze risks and opportunities to objectives
Risks and strategic opportunities (positive risks) are systematically identified at entity and process levels, and each identified risk is analyzed for likelihood and potential impact using the best available historical, current, and forward-looking information. Severity is assessed with consistent scales to support comparison across the risk universe. Results, sources, and analysis assumptions are recorded.
unified · Direct
UC-RISK-08 — Evaluate and prioritize risks against risk criteria
Analyzed risks are evaluated against the established risk criteria to determine inherent risk and whether treatment is required. Risks are prioritized based on severity, risk appetite, and organizational context to direct treatment resources and response sequencing. Prioritization outcomes and rationale are documented and communicated to risk owners.
unified · Direct
UC-RISK-09 — Select, plan, and implement risk treatments
For each risk exceeding tolerance, a response (accept, avoid, mitigate, or share/transfer) is selected consistent with the organization's strategic risk response direction. Treatment plans with owners, actions, and timelines are formulated, approved, implemented, and tracked to completion, and residual risk is re-evaluated against tolerance. Response decisions and treatment status are communicated to stakeholders.
unified · Direct
UC-RISK-10 — Maintain a risk register and report the portfolio view
A risk register records identified risks with analysis results, owners, treatment plans, and current status, and is updated on a defined cycle and upon significant change. Portfolio-level views aggregate risks across the entity and are reported to management and the board to support oversight and resource decisions. Register extracts and portfolio reports evidence operation.
unified · Direct
UC-RISK-11 — Assess changes that could significantly affect risk and control
The organization identifies and assesses internal and external changes - new business models, leadership, systems, regulations, and operating environment - that could significantly affect its risk profile or system of internal control. Risk assessments and responses are updated dynamically as changes and emerging risks are detected. Change-triggered assessments and resulting updates are documented.
unified · Direct
UC-RISK-12 — Assess and mitigate fraud risk including management override
A documented fraud risk assessment considers fraudulent reporting, asset misappropriation, and corruption, evaluating incentives, pressures, opportunities, and rationalizations, and explicitly addresses the risk of management override of controls. Specific anti-override controls operate, including review of journal entries and significant estimates at an appropriate level of precision. The assessment and mitigating controls are refreshed at least annually with documented results.
unified · Direct
UC-RISK-13 — Monitor and review risk management performance
The organization performs ongoing and separate evaluations of risk management and internal control performance, periodically measuring the framework's effectiveness against its design and intended outcomes. Risk and business performance are reviewed together at defined intervals and results are reported to accountable management. Evaluation schedules, results, and review minutes are retained as evidence.
unified · Direct
UC-RISK-14 — Track deficiencies to closure with remediation action plans
Control deficiencies and assessment findings are evaluated and communicated in a timely manner to the parties responsible for corrective action, including senior management and the board as appropriate. A remediation action plan (or equivalent log) documents planned corrective actions, owners, required resources, and completion dates for each finding. Plans are maintained, kept current, and tracked through closure.
unified · Direct
UC-RISK-15 — Continually improve the risk management program
Lessons from evaluations, monitoring, and operating experience are translated into improvements to the risk management framework and process. Improvement actions are planned, assigned owners, and tracked to completion, and the framework is continually adapted to remain suitable for the organization. Improvement backlogs and completed-action evidence demonstrate operation.
unified · Direct
UC-RISK-16 — Conduct privacy impact assessments for high-risk processing
Privacy / data protection impact assessments are conducted before initiating processing likely to result in high risk to individuals, covering a systematic description of processing, necessity and proportionality analysis, risk assessment, and mitigation measures, with advice from the designated privacy officer and consultation with the competent regulator where required. Assessments are documented, approved, reviewed when processing changes, and retained.
unified · Direct
UC-RISK-17 — Operate threat intelligence and threat hunting
Information relating to threats is collected from internal and external sources and analyzed to produce actionable strategic, tactical, and operational threat intelligence that informs risk assessments and defensive measures. A threat hunting capability proactively searches organizational systems for indicators of compromise that evade existing detection controls. Intelligence products and hunt reports are produced on a defined cadence and drive response actions.
unified · Direct
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-03 — Define and approve security requirements for applications
Elicit, analyze, document, and approve functional and non-functional requirements, including application security requirements such as authentication, authorization, input and output handling, logging, and data protection, before solution design and build, assessing feasibility and alternative options. Manage requirement changes and requirements risk, and obtain stakeholder and management approval of the final requirements.
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-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-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.
workflow · Context
Cybersecurity Assurance Review
Cybersecurity Assurance Review — a CAE-owned assurance engagement that runs on the EXISTING Audit item opened from the audit plan (audit_type=it_audit, status PLANNED, lead_auditor and scope already set): the workflow instance attaches to that item and enriches it end to end, never creating a duplicate engagement record. It covers the three IIA Cybersecurity Topical Requirement domains (governance, risk management, and control activities) over the cyber estate bounded in the engagement memo (in scope: named legal entities, networks, cloud tenants, and OT/ICS where included; out of scope: areas whose assurance is documented as delivered by other engagements), testing against the NIST 800-53 Rev 5 catalog with CSF 2.0 / ISO 27001 as the aggregation frame. It originates from the audit plan (no upstream workflow) and produces the findings register (one four-Cs Issue per finding), the cyber posture summary carrying the per-domain and overall Standard 14.5 conclusions, and the approved engagement package — which it hands to the downstream Audit Report Drafting workflow.
workflow · Context
Fraud & Forensic Investigation Engagement
Fraud & Forensic Investigation Engagement as a decision-aware workflow. It runs on a dedicated Audit item (audit_type: investigation) created for this allegation at intake — the confidential case record — with the workflow instance attached to that item and its visibility restricted to the named investigation team. In scope: one specific fraud allegation, worked predication-gated and confidentially from intake through evidence preservation, forensic procedures, interviews, loss quantification, and audit-committee reporting; the named deliverables are the chain-of-custody register, the findings memorandum with its loss-quantification schedule, and the privilege-marked audit-committee fraud report. Out of scope: the enterprise fraud risk profile (owned by Fraud Risk Assessment & Anti-Override Control Review, which receives scheme intelligence from this case rather than being rerun here) and any unrelated conduct discovered in passing (which gets its own intake record). It consumes the hotline intake package from Control Responsibility Communications & Ethics Hotline when so routed, and hands each control breakdown off as an Issue item — control-gap findings to Finding Remediation & Action-Plan Monitoring and ICFR-affecting deficiencies to SOX Deficiency Remediation — rather than duplicating that work.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
Internal Audit Engagement Lifecycle
Internal Audit Engagement Lifecycle: run an IIA-aligned engagement on the existing Audit item (audit_type=internal) created by Audit Engagement Planning — it enriches that item and never creates a duplicate; the workflow instance attaches to the Audit item and is archived on it at close. In scope: evidence requests, fieldwork, finding evaluation, supervisory QA, conclusions per objective, and action-plan registration for the auditable entity and period fixed at planning (Audit.scope, Audit.period_start/period_end). Named deliverables: the evaluated findings register (one Issue item per finding), conclusions per objective (recorded on the Audit item as rating/opinion), and the report-ready handoff package. Out of scope: report wording (owned by Audit Report Drafting) and remediation validation (owned by Finding Remediation & Action-Plan Monitoring). It consumes the approved planning handoff package from Audit Engagement Planning and hands off to BOTH downstream workflows — Audit Report Drafting (the findings register and conclusions) and Finding Remediation & Action-Plan Monitoring (the registered action records) — rather than duplicating their work.
workflow · Context
Audit Engagement Planning
Audit Engagement Planning runs ON an already-opened Audit item — the engagement record the annual audit plan created. The audit is an INPUT: this workflow enriches that item, it never creates a duplicate. In scope: producing the planning package — scope, the engagement risk assessment and mapped control population (Risk and Control items linked to the Audit; together the engagement Risk & Control Matrix, the RCM), the sampling plan, the planning memos, and the enriched audit record. Out of scope: fieldwork, findings, and reporting, which belong to the downstream Internal Audit Engagement Lifecycle workflow that consumes this workflow's handoff package (the RCM travels with it). There is no upstream workflow; planning starts from the audit-plan entry itself.
workflow · Context
Finding Remediation & Action-Plan Monitoring
Finding Remediation & Action-Plan Monitoring runs on the EXISTING parent Audit item — the issued engagement whose report findings are being followed up — enriching that Audit and its linked findings rather than creating a new engagement; the workflow instance attaches to that Audit item, and each report finding is an Issue item linked to it. It tracks issued-report findings and their agreed management actions from registration through evidence validation, closure, extension, risk acceptance, escalation, and committee reporting, and produces a verified disposition register and a signed final evidence-and-decision package. In scope: all open findings from the engagement plus any prior-cycle findings still open against the same auditee. Out of scope: re-performing engagement fieldwork and re-wording report findings (both belong to the upstream Audit Report Drafting workflow) and assembling the board pack (the downstream Quarterly Board & Audit-Committee GRC Reporting workflow consumes this cycle's outputs). It consumes the issued final report and findings register handed off from Audit Report Drafting and hands its verified outputs to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Quality Assurance & Improvement Program Cycle
Operate the Quality Assurance & Improvement Program (QAIP) cycle: ongoing-monitoring evidence, periodic self-assessment, external quality assessment (EQA) support, improvement planning, and board reporting. This cycle runs on an Audit item created per cycle (audit_type = internal — the schema has no quality_assessment option; scope = "QAIP cycle FYxx"; period_start/period_end span the period under assessment); the workflow instance attaches to that Audit item and every cycle output — the per-standard conformance ratings matrix, the below-GC finding Issue items, the improvement and action plan, and the QAIP results report — links back to it. It consumes the period's existing engagement Audit items and their completed engagement-workflow runs as the population and test evidence, plus the standing QAIP framework, charter, and methodology-manual Policy items. In scope: assessing the internal audit function's conformance with the Global Internal Audit Standards for the period. Out of scope: engagement-level rework — this cycle assesses quality, it does not redo fieldwork, which belongs to the engagement workflows. There is no upstream feeder; this workflow starts the quality chain and hands its approved results — overall conclusion, per-domain ratings, and conformance-statement wording — to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Audit Report Drafting
Runs on the existing Audit using approved fieldwork conclusions, findings and management responses. Produces the audit report after management factual confirmation and independent IA management approval of the exact draft, then the issued report, completion announcement and tenant-bound MAR survey dispatch record for remediation monitoring and QAIP.
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
Internal Audit Charter, Independence & Board Governance Cycle
Runs on one Audit item created per governance cycle (audit_type: internal; scope set to the internal-audit charter/independence/board-governance cycle for the period) — the workflow instance attaches to that cycle item and writes to it throughout. The internal audit function and its board-approved charter — a Policy item (policy_type: charter) with its own version lineage — already exist and are reviewed, reaffirmed, or amended here, never recreated. The cycle as a decision-aware procedure: the CAE delivers functional reporting to the audit committee, affirms organizational independence in writing and treats any impairment, reviews and reapproves the board mandate and charter with its unrestricted-access provisions, runs the executive session and committee action on the CAE and the plan and budget, executes the stakeholder communication plan, and retains the governance evidence. Consumes upstream: closed assurance-engagement records (Audit items with their linked Issue findings) produced by the individual engagement workflows, the recommendation-tracking register (Issue items), and the prior cycle's carry-forward (open Issue items plus the prior run's carry-forward list). Named deliverables: the CAE functional reporting pack, the written organizational-independence affirmation, the reaffirmed or reapproved audit charter, the audit-committee minutes and resolution records, the stakeholder communication log, and the control-linked governance evidence set. In scope: the board-governance cycle for the internal audit function itself — charter, independence, committee reporting, and stakeholder communication; out of scope: the individual assurance engagements whose results feed the committee report, which run under their own workflows. Terminal by design: no downstream workflow is chained from this cycle; open threads carry forward to seed the next run of this same cycle.
workflow · Context
Continuous Controls Monitoring (ISCM) Cycle
Run the continuous controls monitoring (ISCM) cycle: pull the current-period control metrics and score them against thresholds, triage degraded and failed controls, update the POA&M, report control health to governance, recalibrate the monitoring strategy, then classify the disposition and prepare, hand off, and archive the cycle package. Each interval runs as one workflow instance attached to the existing Process item that represents the ISCM / continuous-controls-monitoring program (process_type = security_process) — enrich that program record every cycle, never create a duplicate. The monitored control set is the existing Control items (Control.frequency doubles as the monitoring cadence, Control.control_owner as the accountable owner) and the POA&M is the existing Issue register (issue_type = deficiency, source = self_assessment); metric definitions and pass/degraded/fail threshold bands have no native field, so they live in the ISCM strategy document carried on the anchor Process item. The cycle produces the control-health scorecard, the reconciled POA&M, the control-health / security-status report, and the recalibrated ISCM strategy. In scope: the recurring NIST 800-137 monitoring loop — metric collection, threshold comparison, triage, POA&M maintenance, security-status reporting, and monitoring-strategy tuning for the controls under continuous monitoring. Out of scope: formal security control assessment and driving gap remediation to closure, which is owned by the downstream Security Control Assessment & POA&M Remediation workflow that consumes this cycle's handoff package. No upstream workflow feeds this one; it is triggered by the arrival of the monitoring interval.
workflow · Context
Technical Security Testing & Pentest Engagement
Runs ON an existing Audit item (audit_type: it_audit) that represents the authorized penetration-test engagement — the workflow instance attaches to that record and enriches it (scope, ratings, dates, and the assurance conclusion write back to its fields); it never creates a duplicate engagement record. In scope: authorized technical testing (reconnaissance, discovery, exploitation validation, severity rating, reporting, and retest) of the defined system boundary against its control baseline and assessment objective, with each confirmed finding recorded as an Issue linked to the anchor Audit and its affected Controls. Out of scope: any testing beyond the agreed rules of engagement, and the downstream remediation program itself — confirmed control gaps and open POA&M findings are handed to the Security Control Assessment & POA&M Remediation workflow, and the assurance conclusion to the Cybersecurity Assurance Review workflow. No upstream workflow feeds this engagement; its inputs are the anchor Audit, the in-scope system boundary (Process items), the control baseline (Control items, framework nist-800-53), the assessment objective and signed authorization, and any open Issue items (source: penetration_test / vulnerability_scan) from prior engagements.
workflow · Context
Vulnerability & Patch Management Cycle
Recurring vulnerability & patch management lifecycle covering NIST SP 800-53 RA-5 (vulnerability scanning) and SI-2 (flaw remediation) and NIST CSF 2.0 ID.RA and PR.PS. Each cycle runs as one recurring instance anchored to the EXISTING vulnerability & patch management Control item (a Control with domains = vulnerability_patch_management — e.g. the UC-VULN-01 scanning control, control_owner = cycle owner); the instance enriches that Control's evidence trail rather than creating a new subject, and the instance itself is the cycle record. In scope: authenticated scanning of the confirmed asset inventory, severity-based triage against the SLA matrix, standard and emergency remediation, rescan verification, time-bound risk acceptance of residuals, metrics reporting, and cycle closure. Named deliverables: the deduplicated, enriched finding register (one vulnerability_scan Issue per finding, linked to the Control), rescan closure evidence, time-bound compensating-control-backed risk-acceptance exceptions (policy_exception Issues), and the cycle KPI & trend report. Consumed as inputs, not produced: the authoritative asset inventory / CMDB and the enterprise change-approval policy (a Policy item). The workflow is self-triggered by its own scheduled scan window (or an actively-exploited advisory) with no upstream or downstream workflow — its carry-forward package feeds the next iteration of this same cycle at intake.
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
Threat Intelligence & Insider Threat Program
Runs on the existing Process item "Threat Intelligence & Insider Threat Program" (process_type=security_process, process_owner = program lead) — a long-lived program record related to the Control items it operates (UC-RISK-17, UC-BCDR-16, UC-GOV-37); each cycle is one recurring workflow instance attached to that Process, enriching the standing program rather than creating a new one. Decision-aware, covering NIST SP 800-53 PM-12, PM-16, and RA-10 and NIST CSF 2.0 ID.RA and DE.CM. In scope: cyclic intake and curation of threat intelligence into a validated intake register and intel cards, governed internal dissemination and TLP-marked outbound sharing packages, intel-driven threat hunts (producing the hunt summary) and any resulting investigation record, and privacy-guarded review of insider-threat indicators with a governed board disposition and a restricted insider case file, closing with a program-effectiveness report and a reperformable cycle archive. No upstream workflow feeds it; the only cross-run input is the prior cycle's carry-forward package (the carry-forward document from the previous instance's program-effectiveness report step, which closes each cycle), and each cycle emits the next one. Out of scope and handed off only in prose (no terminal handoff node): incident-response execution (the incident-response process, once an incident is declared at open-investigation) and HR/legal employment actions (owned by those functions within an insider case). Each cycle's intel-and-hunt track and its insider-threat track start in parallel from their own inputs.
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
Information Security Program Governance Review
Standing operator workflow for the CISO's quarterly information security program governance review and its annual leg. Each cycle runs as one workflow instance attached to the existing "Information Security Program Governance" Process item (process_type: security_process, owner CISO), with the four governing Control items UC-GOV-06/09/10/15 linked to it. It is a decision-aware flow that enriches — never recreates — the senior-management-approved information security program plan (held as a Policy item) and the current role assignments every cycle, and branches into the written board report, workforce competency review, and plan reapproval when the annual interval or a significant change requires it. Named deliverables: the reapproved information security program plan (the Policy item, re-versioned and re-signed), the roles-and-authorities register, the annual written board report to the governing body, and the workforce competency review — each retained on the workflow instance. In scope: the program plan, security roles/authorities/reporting lines, the annual board report, and workforce competency for this organization; out of scope: executing the underlying protective controls and enterprise ERM governance, which are owned by their own workflows (coso-erm is referenced here only for oversight-of-design of the governance structure). There is no upstream or downstream workflow handoff — this cycle is genuinely self-contained: it starts from its own cadence trigger, consumes its own prior-cycle governance record, and seeds the next cycle at close.
workflow · Context
Security Policy Suite Review
Standing operator workflow for the security policy owner's annual (and change-triggered) review, redline, reapproval, and dissemination of the full security policy suite -- secure acquisition/development/configuration-management/maintenance, asset/media/physical protection, access/identity/personnel security, communications/cryptography, security awareness and cyber-hygiene, audit-logging/monitoring/system-integrity, contingency planning and disruption mitigation, and incident response. Anchor: each run is a workflow instance attached to the existing "Security Policy Management" Process item (process_type=security_process, process_owner=policy owner, frequency=annual) -- that instance IS the cycle record the tracked review items roll up to; the eight policy families are the existing Policy items the cycle enriches (never recreates). In scope: reviewing each Policy item against current risk and threat inputs, consolidating findings into one suite-level revision disposition, routing redlines to the right stakeholders, reapproving under accountable security leadership (writing Policy.approved_by / version / effective_date / next_review_date back onto each policy), and tracking dissemination and workforce acknowledgment as a single evidence set. Out of scope: authoring net-new policy domains and operating the technical controls the policies govern. The workflow has no upstream feeder workflow -- its inputs are the policy register (the eight Policy items), the prior-cycle workflow instance and its exported operating record, and the annual review calendar carried on Policy.next_review_date -- and no named downstream workflow; open corrective actions (Issue items) carry forward as explicit inputs to the next cycle. The eight domain reviews run in parallel and converge on a single revision-disposition decision.
workflow · Context
Security & Privacy Architecture Review Board
Standing operator workflow for the Security & Privacy Architecture Review Board. Each cycle runs as a recurring workflow instance attached to the existing UC-GOV-19 Control item (security & privacy architecture governance; framework nist-800-53 + cobit-2019) in the control library — it enriches that Control and its evidence trail, never creates a duplicate, and the chain of archived instances is that control's execution log (Control has no native execution-log field). The cycle maintains the enterprise, security, and privacy architecture views (across the business, data, application, technology, security, and privacy domains), runs a scheduled annual full-refresh branch, reviews solution designs and acquisition decisions for architectural alignment with a remediation loop, and pushes approved architecture updates into system security plans and acquisition requirements. It consumes: the prior cycle's archived baseline and architecture-view documents plus its open carryover Issue items; the live system/application inventory and mission/strategy statements (uploaded from external systems, no native item type); and the Risk items that form the security (category cyber_security) and privacy (category privacy) risk registers. Named deliverables: the refreshed enterprise architecture baseline package and drift log, the updated security and privacy architecture views with risk-crosswalk gap lists, the alignment assessment register, the pushed-updates package of SSP and acquisition-requirement changes, and the program-health dashboard. In scope: enterprise/security/privacy architecture maintenance, solution-design and acquisition alignment review, and SSP and acquisition-requirement updates. Out of scope: implementing the individual system security controls and running procurement themselves — those execute in the owning system-authorization (ATO) and acquisition/procurement workflows, which are the real downstream consumers of this cycle's SSP and acquisition-requirement updates. No upstream workflow feeds this cadence; it is triggered by the standing quarterly ARB cadence, the annual refresh date, or an ad hoc urgent design or acquisition submission.
workflow · Context
Privileged Access & Authorization Model Management
Standing operator workflow for the quarterly privileged-access recertification cycle, separate-account and utility-program controls, and application allowlisting, paired with role and security-attribute authorization-model maintenance and enforcement spot-testing across applications, databases, and infrastructure. Each quarterly instance runs as the operating cycle of the existing privileged-access Control item in the control library (UC-ACCESS-04, with UC-ACCESS-05 linked) — it enriches that Control's operating-effectiveness record rather than creating a new subject, and reads risk context from the linked Risk item (category cyber_security, domains access_control_identity). Consumes standing account, log, change-queue, and org-change feeds pulled live from IAM/PAM, directory, SIEM, allowlist tooling, and the HR system of record, plus the prior quarter's archived instance for its inventory register and carryover exceptions; it consumes no upstream workflow's handoff package. In scope: privileged and administrative accounts, control-overriding utility programs, the application allowlist, and the role and attribute authorization model with its enforcement points. Out of scope: standard non-privileged joiner-mover-leaver provisioning, network and perimeter controls, and application change management, each handled by its own workflow. Every exception and enforcement gap normalizes to an Issue item linked to the anchor Control, and the archived workflow instance is the cycle's evidence of record — open Issues are the cross-cycle carry-forward. Runs on a routine quarterly cadence, or out of cycle when an audit finding, incident, or major organizational change (reorg, new system, acquisition) requires it; no upstream workflow feeds it and it hands off to no single downstream workflow. Owned by the IAM Operations Lead.
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
Identity & Authenticator Lifecycle Administration
Standing operator workflow for identity issuance and ownership, shared-identifier exception handling, the dormancy and non-reuse sweep, identity proofing and credential binding, and the full authenticator lifecycle from verified issuance through protection, exposure scanning, and scheduled rotation or revocation. Each monthly cycle runs as a new workflow instance attached to the existing identity & authenticator lifecycle Control item (the UC-ACCESS-06/07/08 family; domains=access_control_identity, frequency=monthly) — the run enriches that standing control's evidence trail, never creating a duplicate control. It consumes no upstream workflow: its inputs are the prior cycle's own carry-forward Issue items (open corrective actions, pending shared-ID review dates, deferred rotations, each linked to the anchor Control) plus current request, source, and inventory extracts. Named deliverables: the issuance & ownership register, the dormancy/non-reuse sweep log, the shared-ID exception disposition and its compensating-control Control items, the identity-proofing evidence package with credential-binding records, the authenticator issuance/strength/default-change log, the protection/exposure-scan disposition, the rotation-and-revocation log, and the identity & authenticator lifecycle-health dashboard — all rolled into an archived, immutable operating record. Because no Identifier/Authenticator/Credential item type exists in the schema, per-identifier, per-binding, and per-authenticator records live as rows in these step-attached registers and logs; only exceptions, gaps, and carry-forwards are promoted to Issue items linked to the anchor Control, and approved shared-identifier waivers are recorded as compensating-control Control items plus a policy_exception Issue. In scope: unique-identifier issuance and ownership mapping for users, services, and devices; shared/group-identifier exceptions; the monthly dormancy and non-reuse sweep; identity proofing proportional to assurance level and credential binding; and authenticator issuance, hardening, protection, exposure remediation, rotation, and revocation across passwords, tokens, keys, and certificates. Out of scope: access authorization and entitlement reviews, joiner/mover/leaver approval routing, and privileged-session management, which are operated by their own workflows. There is no downstream handoff workflow — corrective actions and carry-forward items are tracked to closure within this cycle and seed the next monthly instance of the same control.
workflow · Context
Authentication Platform & Session Policy Operations
Monthly authentication-platform operating cycle. Anchor: this instance runs on the existing Process item for authentication-platform / session-management operations (process_type: security_process, frequency: monthly) — enrich that standing Process each cycle, never create a duplicate — with the four operated Control items UC-ACCESS-09/11/12/13 (framework tags carrying the standards mapping, domains: access_control_identity) linked to it. In scope: MFA enforcement and enrollment across remote, privileged, and sensitive-data access; secure log-on and federation-trust verification; lockout and anomalous-logon defense; session lifecycle controls (inactivity lock, automatic termination, concurrent-session limits, re-authentication for sensitive operations); and system-use, last-logon, and failed-attempt notices, across the IdP or SSO tenant, VPN or remote-access gateway, PAM tooling, and applications classified as housing sensitive data. Out of scope: identity provisioning and joiner-mover-leaver lifecycle, access certification, and privileged-access request approval, which are operated by their own workflows. There is no upstream workflow dependency: the instance is self-originating on its own initial inputs — the authentication-platform inventory (a document on the anchor Process, refreshed each cycle) and the prior-cycle operating record (the prior Workflow instance on the same Process plus its carried-forward open Issue items). The four operating areas run in parallel and reconverge at the platform-posture disposition. Named deliverables: the MFA enforcement-coverage register, the authentication-posture memo, the lockout-and-anomaly log, the session-policy compliance matrix, the banner-and-notice verification record, the platform-health dashboard and readiness summary, and the corrective-action register — each attached to its step, with every gap raised as a self_assessment Issue linked to the Control it degrades. There is no downstream handoff: this terminal recurring cycle seeds its own successor via carry-forward Issue items at close.
workflow · Context
IT Asset Inventory & Classification Upkeep
Standing operator workflow for the quarterly IT asset inventory reconciliation and the information and asset classification and labeling review. Anchor: each quarterly run is a workflow instance attached to the EXISTING Control item for the IT asset inventory & classification control (domains asset_management_inventory, frequency quarterly, framework including nist-800-53 / iso-27001 — e.g. control_id CM-8 / UC-ASSET-01) as its operating and execution record; enrich that Control, never create a duplicate. In scope: reconciling the authoritative hardware, software, systems, and services inventory against network, endpoint, cloud, and SaaS discovery scans and change records for the in-scope business units, and reviewing the classification, priority, and labeling of information and associated assets including physical media. Out of scope: the remediation engineering behind a decommission or security investigation (handed to those owners) and the downstream security-scoping processes that consume this cycle's outputs. Upstream: no upstream workflow — the cycle runs on the org's live inventory and discovery systems (external ITAM/CMDB, scanners, change/ticketing) plus the prior run's carry-forward Issue items linked to the anchor Control. Converges on two named deliverables — a signed reconciliation record and an updated classification register with an exported extract; that packaged, dual-signed record is the de-facto handoff package that downstream security-scoping processes consume (there is no named downstream workflow).
workflow · Context
Control Design
This instance runs against the Control item it creates: drafted at the objective step and committed to the Risk & Control Matrix (RCM) at record-the-control, so the archived instance is that control's design audit trail. It consumes no upstream workflow — a control is motivated by an existing Risk item or an audit Issue (finding/deficiency), which it links to rather than rebuilds. Design one new control end to end: control objective and attributes, risk mapping to the register, evidence and test-approach design, RCM record creation, disposition, packaging, and archival. The named deliverable is a new, uniquely identified control record in the RCM (a Control item) carrying a design determination statement, plus its test plan. In scope: designing and recording a single new control so it is operable and testable. Out of scope: executing the control's operating-effectiveness tests and remediating deficiencies, which are handed off downstream to the Security Control Assessment & POA&M Remediation workflow.
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
Identity Assurance Review
This review runs on an Audit engagement item created for the review cycle (audit_type: it_audit; scope: the identity assurance boundary) — the workflow instance attaches to that Audit, and the five in-scope UC-ACCESS Control items (UC-ACCESS-07/08/09/11/12) link to it. It is self-originating: no upstream workflow feeds it — it starts from the review trigger, the governing controls, and the collected evidence. Review the IAL, AAL, and FAL assurance requirements against the current identity proofing, authentication, and federation controls for the in-scope systems, then remediate, document, and hand off open gaps. It produces the target-level register, the current-state control inventory, the scored gap register, the per-control assurance determination memo, and the compiled assurance review package; each open gap is recorded as an Issue (POA&M) item linked to its UC-ACCESS Control and the anchor Audit. In scope: NIST SP 800-63 identity assurance levels for the systems named in the locked workplan. Out of scope: broader access provisioning, joiner-mover-leaver lifecycle, and privileged-access certification. Hands off the assurance determination and any open POA&M items to the Security Control Assessment and POA&M Remediation workflow.
workflow · Context
Security Monitoring & Detection Operations
Each weekly cycle is a recurring instance attached to the existing continuous security-monitoring Control item (domains: logging_monitoring_detection, control_type: detective, frequency: weekly) — the cycle enriches that standing Control with its operating record, never creating a duplicate control. It consumes the prior cycle's carry-forward (unresolved queue Issues, open watchlist entries, open corrective actions) and the documented continuous-monitoring strategy (a Policy item linked to the Control), and produces named deliverables: the deployment coverage-and-effectiveness assessment, the enriched central SIEM analysis queue, the maintained detection watchlist, and the signed cycle security-status report. In scope: verifying monitoring deployment and effectiveness, working the central SIEM threat-intel analysis queue, triaging flagged anomalies, maintaining the detection watchlist, reporting security status to the defined roles, and verifying continuous protection-service health and tuning across hosts, networks, and applications at both the perimeter and the interior. Out of scope: incident containment, eradication, and recovery — confirmed security events are handed off mid-cycle to the Security Incident Response workflow rather than duplicated here.
workflow · Context
Network & Provider Service Monitoring
Each monthly run attaches to the EXISTING network & provider monitoring Control item (UC-LOG-08/UC-LOG-09, frequency = monthly; framework = iso-27001 | nist-csf-2 | nist-800-53) — enrich that Control's evidence trail, never create a duplicate control. The cycle keeps network devices hardened and controlled, network-service documentation (including outsourced services) current, delivered services monitored for conformance, and external providers reviewed against their contractual obligations, feeding every deviation into a single owned remediation log — Issue items linked to the anchor Control — and producing a signed monthly monitoring record archived under retention. In scope: in-scope network devices and services, external service providers (the Vendor register) and their contracts, cross-organizational audit-trail exchange arrangements, and the deviations they produce. Out of scope: incident response and investigation for a provider-reported security event, which is tracked in its own incident case rather than in this monitoring cycle. Consumes no upstream workflow — self-originating, triggered by its own monthly cadence, a newly onboarded network service or provider, or a carried-forward deviation requiring follow-up; the previous instance hands off its still-open remediation Issues (linked to the same Control) as this cycle's carry-forward inputs. Terminal: it hands off to nothing downstream — closure seeds its own next cycle.
workflow · Context
Physical Environment Monitoring Review
Standing operator workflow for the monthly physical-environment monitoring review across facilities hosting systems and data — badge and entry logs, camera surveillance coverage and footage, and environmental sensor alerts. Each cycle runs as a recurring workflow instance attached to the existing UC-LOG-10 Control item (control_type=detective, control_category=physical, frequency=monthly, framework=nist-csf-2, domains include physical_environmental_security and logging_monitoring_detection) — it enriches that Control's execution history and never creates a duplicate control. In scope: physical-access, surveillance, and environmental monitoring of the in-scope facilities and the systems and data they host. Out of scope: logical-access review and the downstream analysis and remediation of confirmed events, which are handed off to the security-event analysis workflow. Runs on a routine monthly cadence (or out-of-cycle after a triggering incident) with no upstream workflow feeding it — it originates from the anchor Control, its prior-cycle instance, and the prior cycle's still-open Issue items. Consolidates findings into a de-duplicated physical-event register, packages every confirmed adverse physical event as a security-event case handed off to the security-event analysis workflow, and tracks monitoring coverage gaps to closure as owned corrective-action Issues. Implements NIST CSF 2.0 continuous detection monitoring (control UC-LOG-10).
workflow · Context
ISMS Risk Assessment & Treatment Cycle
Perform an ISO 27005 information security risk assessment and treatment cycle for a defined ISMS scope. The recurring cycle instance attaches to the existing Process item (process_type=security_process) that represents the ISMS scope — enrich that item, never create a duplicate; the risk register it produces is the set of Risk items the run creates and updates. The cycle: establish context and risk criteria, identify information security risks, analyze and evaluate them against the criteria, select treatment options, draft the risk treatment plan, obtain residual-risk acceptance, and retain the documented information. In scope: risk identification through treatment planning and residual-risk acceptance for the ISMS boundary. Out of scope: the Statement of Applicability control-applicability determination and control operating-effectiveness testing, which are handled downstream. This workflow has no upstream workflow — its boundary and inventory are initial inputs: the in-scope business processes are existing Process items, while the asset/information inventory and risk criteria are uploaded documents (no native Asset type). It produces the named deliverables — the current risk register (Risk items), the Risk Treatment Plan (RTP), and the SoA inputs — handed off to the ISO 27001 SoA Review & Controls Assessment workflow.
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
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
AI Guardrail Configuration & Agent Permission Review
Each monthly or release-triggered instance runs against the existing Control item for AI guardrail configuration and agent permission review (framework aiuc-1 + iso-42001 + eu-ai-act; frequency monthly and per release; control_owner AI Platform Security Lead) — the run enriches that Control's execution history and is its evidence of operation, never a duplicate. The decision-aware cycle confirms the in-scope agent population and baseline; reviews input defenses and endpoint limits, tool allow-lists, permissions and sandboxing, output filters and grounding, misuse refusals, secrets redaction, and secure-code-generation defaults; decides on agent permission scope and on guardrail drift with a remediation branch for each; and consolidates the results into a signed guardrail attestation with cycle metrics and owned actions, booking every residual gap as an Issue (source: management_identified) linked to the anchor Control. In scope: every production AI agent and inference endpoint, its guardrail configuration, tool-call and detection logs, and configuration artifacts. Out of scope: model development, pre-deployment evaluation, and vendor AI due diligence, which have their own workflows. The cycle hands off only to its next instance through the carry-forward Issues that the guardrail attestation step links to the anchor Control.
workflow · Context
Quarterly Third-Party AI Evaluation Cycle
Each quarterly instance runs against the existing Control item for independent third-party AI evaluation (framework aiuc-1 + iso-42001 + eu-ai-act; domains ai_governance; frequency quarterly; control_owner AI Product Lead) — the run enriches that Control's execution history and is its evidence of operation, it never creates a duplicate Control; the one record it does create is a per-quarter Audit item (audit_type: it_audit) for the evaluator engagement. The decision-aware cycle confirms the quarter's in-scope systems and risk taxonomy, engages an independent evaluator with the test plan, categories, and pass thresholds fixed in advance, provisions contained test access, triages every finding by category and severity against the tested control, routes failed thresholds through remediation and evaluator retest, gates acceptance of the evaluator report, publishes the accepted evidence (trust-portal summary, customer-facing attestation, evidence register), and tunes guardrails from the findings. In scope: every in-scope AI system and agent under the AIUC-1 program and its six mandatory third-party test categories (B001 adversarial robustness, C010 harmful outputs, C011 out-of-scope outputs, C012 agent-specific risk, D002 hallucinations, D004 tool calls). Out of scope: internal red-teaming, pre-release model evaluation, and vendor AI due diligence, which run in their own workflows. It hands off only to the next quarterly run of itself, seeding it with the open carry-forward finding Issues that the publish-evidence-and-tune-guardrails step links to the anchor Control.
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
Remediation Delivery & Validation
Runs on the existing remediation item. Plan and deliver corrective action, independently validate it against agreed closure criteria, and approve a traceable remediation record. 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
Data Conversion & Migration
Runs on the existing system item. Convert data into a target system with evidenced completeness and accuracy reconciliation between source and target. 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
End-User Computing Inventory & Validation
Runs on the existing system item. Inventory the spreadsheets and end-user tools feeding reporting for a system, and test their access, change, and integrity controls. 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
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
Control Exception Evaluation and Remediation
Runs on the existing control item. Validate a control-test exception, evaluate its scope and implications, determine disposition, and establish accountable remediation where needed. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control Remediation Retest and Closure
Runs on the existing control item. Verify remediation readiness, independently retest the changed control, evaluate sustained results, and approve a supported closure decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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 Processing Integrity Assessment
Design-readiness review of the SOC 2 processing integrity series: processing definitions and specifications, input controls, processing controls, output delivery, and storage integrity (PI1.1–PI1.5). 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
Remediation Delivery
Deliver one corrective action against a finding and capture the evidence it produces. Validation and closure approval happen on the finding’s own workflow, where every action raised against it is judged together.
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
Domain Oversight and Management Review
Quarterly management review of one process area - the process area's own oversight run. The domain owner reviews the registers the domain operates (systems, tenants, audits), the health and evidence of the operating-process runs, the domain's risks, issues and metrics, and the operation of its controls, then records direction and a dual sign-off. Instantiated once per process area; the operating processes keep their own runs.
workflow · Context
Issue Remediation and Verification
Triage a finding, agree the Remediations that will clear it, then validate and approve the closure of each one before closing the finding itself.
workflow · Context
Risk Assessment and Treatment Review
Runs on the existing risk item. Assess a risk against current context and evidence, select a supported treatment response, and approve a traceable review record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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
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
Quarterly Board & Audit-Committee GRC Reporting
Runs on the existing standing "Board & Audit-Committee GRC Reporting" governance Process item (process_type=business_process, frequency=quarterly): one workflow instance per quarter attaches to that Process and enriches it (the Process is not created here), and each closed instance is the prior-quarter baseline for the next run. The named deliverable is the quarterly board & audit-committee GRC pack (six-domain narrative deck, Word + PDF, redaction-cleared). It compiles that pack across six domains — risk profile, control health, open issues, regulatory deadlines, audit-plan progress, and SOX posture — computed over one quarter window. In scope: aggregating and synthesizing existing GRC records (Risk, Control, Issue, Audit, and Control-hosted SOX testing workflows) into a board-level narrative, obtaining executive and committee approval, and archiving the decision and action register. Out of scope: performing the underlying risk assessments, audits, or control tests themselves. Consumes two upstream handoff packages: the Enterprise Risk Assessment & Portfolio Oversight Cycle package (risk register, residual scores, appetite positions) and the Audit Report Drafting & Regulatory Compliance Attestation Cycle package (audit-plan status, issued reports, attestation status); there is no downstream workflow — the closed package feeds the next quarterly run of this workflow.
workflow · Context
Risk Appetite Definition & Board Reporting
Define enterprise risk appetite statements, tolerances, and KRIs, secure executive and board approval, monitor actuals against tolerances, and report the appetite position to the board. Runs as a standalone recurring instance per appetite cycle (typically annual): appetite spans the whole Risk register rather than a single item, so the register, tolerance and KRI matrix, monitoring workbook, and reporting pack attach to the workflow instance's steps as the versioned documents of record, with the existing Risk items as the linked reference data and KRI breaches recorded as Issue items (issue_type: exception, linked to their Risk). In scope: appetite-statement definition, tolerance and KRI design, executive validation, board approval, ongoing monitoring, and ERM board reporting. Out of scope: the enterprise-wide risk identification and scoring that produces the risk universe, and the assembly of the full quarterly board deck. Consumes the risk-assessment handoff package from the Enterprise Risk Assessment & Portfolio Oversight Cycle (the risk universe as Risk items plus inherent and residual ratings) rather than re-deriving it, and hands the board-approved appetite package to the Quarterly Board & Audit-Committee GRC Reporting workflow.
workflow · Context
Risk Register Intake
Intake one newly identified risk into the enterprise register. The instance creates a new Risk item at the first step and attaches to that Risk item for the whole run — every rating, control link, and disposition enriches that single record. It consumes the initial risk identification (no upstream workflow) plus existing Control items, Policy items, and evidence carried on Issue, Audit, and Control-hosted SOX testing workflows, and produces the named deliverable: a review-ready risk intake package attached to the Risk item. On completion it hands that package to the Enterprise Risk Register Lifecycle workflow for ongoing monitoring. In scope: intake and initial assessment of one new risk. Out of scope: portfolio-level aggregation, periodic re-assessment, and risk-treatment project execution, which the Enterprise Risk Register Lifecycle workflow owns.
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
Policy Exception & Risk Acceptance
Policy Exception & Risk Acceptance as a decision-aware workflow. It carries a waiver from request and justification through risk assessment, compensating controls, time-bound approval, registration with expiry, and re-review so no exception outlives its rationale. The exception IS an Issue item (issue_type: policy_exception) — the workflow runs on it, and the exception register is simply the set of those Issues, queryable by their filterable exception_expiry_date. The affected policy is a Policy item the Issue links to; a granted acceptance also sets treatment: accept on the linked Risk item. In scope: time-bound exceptions/waivers to an existing policy that are risk-accepted for a bounded window. Out of scope: permanent policy-change proposals, which route to the Policy Lifecycle Management workflow (the Policy item's revision process) rather than this waiver workflow. No upstream or downstream workflow feeds or consumes this one; the exception request is the initial input, and recurring-exception patterns are compiled as feedback onto the affected Policy items at close.
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
Board Risk & Internal Control Oversight Cycle
Board Risk & Internal Control Oversight Cycle as a decision-aware workflow: the governance office verifies board independence and expertise, compiles the board risk & internal-control oversight pack, routes the at-least-annual governance-framework effectiveness evaluation, facilitates the independent board's approval of the risk strategy and material policies, captures and minutes the directed adjustments, and launches and tracks them as an owned open directives register. It is standalone: the governing body and the governance framework are not Studio item types, so there is no natural item anchor — each cycle runs as a fresh recurring workflow instance and its deliverables attach to the run's own steps. The named deliverables are the composition-and-independence summary, the board risk & internal-control oversight pack, the annual governance-and-management-framework effectiveness evaluation when in scope, the adopted board/committee minutes, and the board directives-and-adjustments register (one Issue item per directive, linked across cycles). The risk strategy and material policies the board approves are Policy items (approved_by, version, next_review_date); board directives, approval conditions, and framework adjustments are Issue items (issue_type: observation, source: management_identified). In scope: a single named governing body's quarterly (or specially convened) risk and internal-control oversight meeting and, where the annual clock or a substantial-change trigger applies, that cycle's enterprise governance and management framework effectiveness evaluation. Out of scope: the day-to-day first- and second-line control operation, testing, and assurance that feed the pack — no workflow hands into this cycle, and the board's directives flow onward into control-remediation and policy-update execution as prose, not a wired downstream template.
workflow · Context
Code of Conduct & Workforce Accountability Cycle
Code of Conduct & Workforce Accountability Cycle as a decision-aware workflow that runs on an existing ethics Process item ("Ethics & Code of Conduct Program", process_type: business_process, frequency: annual): each annual cycle is a workflow instance attached to that Process, and the archived instances on it ARE the ethics register - version history plus the open-deviation log. The code of conduct and the rules of behavior are Policy items (policy_type: policy and procedure) enriched each cycle - never recreated - and the tone-at-the-top and acknowledgment Controls (UC-GOV-04, UC-GOV-07) are linked to the Process via item relationships. The cycle reissues the code and rules of behavior, secures leadership adoption, communicates expectations to personnel and business partners, gates access on acknowledgment, and evaluates adherence - routing violations through the documented disciplinary process and remediating deviations timely, with deviations and violations recorded as Issue items carrying the full remediation lifecycle. Named deliverables: the reissued code of conduct and rules of behavior (Policy items plus redline/change summary), the leadership adoption decision, the acknowledgment coverage report with access-gating evidence, the deviation and violation inventory (Issues), the disciplinary and remediation outcomes, and the archived self-contained cycle evidence package. In scope: one annual accountability cycle (a full reissue or an update-driven re-acknowledgment) covering all in-scope personnel and the business-partner populations bound by the code. Out of scope: the ethics-hotline intake that feeds reported concerns - an input, not a step here. No upstream workflow is required to start the cycle; it is triggered by its annual cadence or by a material change to the code or rules of behavior. Downstream, the operational access-provisioning system consumes this cycle's acknowledgment gate - the workflow's terminal handoff - before it grants access.
workflow · Context
Technology Investment & Project Risk Governance
Technology Investment & Project Risk Governance as a decision-aware checkpoint graph, run as a recurring workflow instance attached to the existing Process item for the technology-investment / portfolio-governance process (process_type: business_process) — each quarterly board cycle enriches that standing process record rather than creating a new one. In the cycle the investment board refreshes its criteria, scores and prioritizes the technology and innovation portfolio, routes the annual capital-planning leg that allocates security funding to the risk strategy, monitors in-flight value and reprioritizes or terminates where value is not realized, and enforces security-risk sections in every project gate with ERM-linked artifacts. In scope: the quarterly technology investment-board review (always), the annual capital-planning and security-budget leg (when the funding and staffing envelope must be set or re-planned this cycle), and every project stage gate falling due. Out of scope: individual project execution and delivery mechanics and day-to-day security operations. The cycle consumes the ERM cyber-risk register (Risk items, category: cyber_security) and the approved program business cases as standing inputs, and produces a board decision record and evidence pack as its named deliverable. There is no downstream workflow hand-off, so cross-references are recorded as linked records (Issue ↔ Risk) rather than routed onward; the scored portfolio, in-flight programs, and stage-gated projects have no native item type and live as step documents.
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
Strategic Context & Objectives Alignment Cycle
Strategic Context & Objectives Alignment Cycle as a decision-aware workflow. Anchor: this recurring governance cycle runs on and enriches the existing "Strategic Planning & Objectives Alignment" Process item (process_type business_process, annual frequency) that represents the strategy-refresh process itself; where no such convention item is seeded it runs standalone with every output attached to the workflow instance. No upstream workflow feeds this cycle — it is the top of the governance chain and its own trigger, run annually or on an event-driven change such as an acquisition, a new market or regulation, a material risk-profile shift, or a significant incident; its only prior-cycle input is this workflow's own previous run, archived at close-and-archive. It refreshes the mission statement and stakeholder register, builds a bidirectional objectives-and-dependency map, communicates that context to risk-scoping owners, realigns and cascades strategy into a published and monitored roadmap, and closes by documenting mission-essential business processes as Process items with their information-protection needs as the approved basis for risk-assessment scoping. Named deliverables: the refreshed mission statement (DOCX) and stakeholder register (XLSX), the objectives-and-dependency map, the published context package and change summary, the strategy realign-or-reaffirm decision, the realigned enterprise and technology strategy (realign branch), the cascaded objectives and published roadmap, the mission-essential Process definitions, and the archived cycle record. In scope: the mission and stakeholder context refresh, strategy realignment and objective cascade, and the mission-essential process and risk-scoping definitions. Out of scope: executing the risk assessment itself. Downstream handoff: the exported cycle record and the approved mission-essential Process items are the scoping basis consumed by the Enterprise risk-assessment cycle.
workflow · Context
Enterprise Risk Treatment Operations Cycle
Enterprise Risk Treatment Operations Cycle as a decision-aware workflow: it runs the documented risk methodology each cycle - identification and analysis of risks and opportunities, evaluation and prioritization against risk criteria, treatment selection and tracking for risks exceeding tolerance with residual re-evaluation, and risk-register and portfolio reporting to management and the board - triggering dynamic reassessment when internal or external change shifts the risk profile. This cycle has no anchor item of its own: the enterprise risk register it maintains IS the Risk item population, and the workflow instance is the cycle record and durable audit trail. In scope: entity-level and process-level risk across the enterprise, explicitly including cybersecurity, privacy, and financial-reporting risk alongside operational and strategic risk and opportunity. Out of scope: detailed control design and testing, which downstream control workflows own - a mitigate or share/transfer plan that creates or strengthens a control hands that work off to those workflows, which anchor on the affected Control items. This cycle has no upstream workflow feeding it; its starting inputs are the documented methodology, the consistent likelihood/impact scoring scales, the board-approved risk criteria and appetite/tolerance statements, and the risk-acceptance delegation matrix - all carried as Policy items - plus the existing control, insurance and transfer information (Control items and step documents) and the prior cycle's Risk register. Named deliverables: the maintained enterprise risk register (the Risk items), the prioritized risk heat-map dashboard, and the management and board portfolio report package.
workflow · Context
Risk Communication, Reporting & Performance Review
Risk Communication, Reporting & Performance Review as a decision-aware workflow that runs each quarter or on an out-of-cycle significant matter. Because none of the eight Studio item types represents the ERM reporting cycle itself, the workflow instance IS the durable record: its named deliverables - the tiered internal and external risk, control and performance reporting package, the event-driven report on a significant matter, the management-signed risk-and-control performance-review pack, and the tracked improvement actions - attach to its steps, its item-level writes land on the existing Risk, Control, and Issue items (improvement actions are tracked as Issues with source: self_assessment); control-testing results are read from SOX testing workflows hosted directly on the relevant Controls; and the risk-management framework is read as its Policy item (policy_type: charter) for the evaluation baseline and the suppliers and third parties consulted as their Vendor items. In scope: stakeholder consultation across every risk-process step (identification, assessment, response, monitoring) including suppliers and third parties; the cadenced internal and external reporting package; event-driven reporting on significant matters; the periodic review of risk-management and internal-control performance against the framework's design intent with accountable management; and converting lessons into owned, tracked improvement actions. Out of scope: running the underlying risk assessments, control testing, or business-performance measurement themselves - this workflow consumes their results as inputs. It starts on its own trigger (the quarterly cadence or a significant event) and has no upstream feeder workflow and no named downstream handoff workflow; each run's close-and-archive leaves the stakeholder, risk, and improvement registers current - the informal handoff both to the next cycle of this workflow and to the downstream risk-assessment and control-testing workflows whose results this cycle consumes.
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
Enterprise Risk Assessment & Portfolio Oversight Cycle
Second-line ERM oversight cycle. Each run is anchored to a cycle Audit item created for the period (audit_type: operational, scope = the assessment boundary, period_start/period_end = the cycle window, report_date = the approval date); the workflow instance attaches to it as the durable audit trail, and the enterprise Risk items are the register it assesses and updates in place. Establish the assessment context (scope, criteria, appetite, scoring calibration), identify risks, score inherent and residual severity, select responses, publish the portfolio view, and route the package through disposition and governance approval. In scope: enterprise-level risk identification, assessment, response selection, and portfolio reporting for the current cycle. Out of scope: defining the board-approved risk appetite statement itself and preparing the board reporting deck, which are handled by downstream workflows. Consumes the prior-cycle risk-register handoff package (the existing Risk items plus the linked register document) from the Enterprise Risk Register Lifecycle workflow, and hands its named deliverables — the residual portfolio view (dashboard), the risk-movement narrative, and the approved assessment package — to the Risk Appetite Definition & Board Reporting and Quarterly Board & Audit-Committee GRC Reporting workflows.
workflow · Context
AI Governance Framework, Roles & Obligations Review
AI Governance Framework, Roles & Obligations Review as a modular, decision-aware workflow. Each quarterly instance runs on the existing "AI Governance Program" Process item (process_type operational, quarterly, process_owner = AI Governance Officer) and enriches its standing registers — it never recreates them. It keeps the AI policy current and republished, refreshes the RACI and competency records, maintains each AI system's resource and dependency inventory, and walks the value-chain obligations register so every provider and deployer duty traces to an owner and evidence. Consumes at launch: the cycle trigger (interval, folded-in annual re-approval, or a regulatory/technology change) and prior-cycle registers — the AI policy as a Policy item (framework iso-42001 + eu-ai-act, domains ai_governance), the obligations register as EU AI Act / ISO 42001 Control items (control_owner = obligation owner), plus the in-scope AI system list, the RACI and competency register, and the per-system resource inventory, which have no native item type and travel as versioned step documents. Deliverables: the republished AI policy version, the refreshed RACI and competency register, the current resource and dependency inventory, the walked obligations register, and a four-area cycle evidence package. In scope: those four governance registers for the AI systems in boundary this quarter; out of scope: the AI systems' own development, risk assessment, and control testing. Terminal — no downstream workflow consumes the output; the cycle closes to its own archived workflow record, linked back to the anchor Process item.
workflow · Context
Risk & Control Self-Assessment (RCSA) Program
Risk & Control Self-Assessment (RCSA) Program as a modular, decision-aware workflow. Each wave runs on its own Audit item — created per wave (audit_type: operational; period_start/period_end = the wave window; report_date = the risk-committee date) — with the workflow instance attached to that item and the wave's questionnaires, attested returns, and calibration record kept inside the run. Each wave rebuilds the assessment universe from the existing Process, Risk, and Control items and their owners (enriching them, never recreating them), issues rating questionnaires to named control and process owners, collects attested self-assessments with structured exception capture, chases completeness, subjects the results to second-line challenge and calibration, aggregates a residual-risk view across units, updates the risk register's residual ratings, and routes self-identified issues to remediation and exceptions to time-bound acceptance before the results reach the risk committee. In scope: first-line self-assessment of in-scope business units and shared functions against their own risks and controls. Out of scope: independent testing/audit of those controls, and the remediation and formal risk-acceptance of what the wave surfaces, which are handed off downstream to the Finding Remediation & Action-Plan Monitoring (deficiencies), Policy Exception & Risk Acceptance (risk-acceptances/waivers), and Quarterly Board & Audit-Committee GRC Reporting (the wave report) workflows.
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
Control Library Lifecycle
One control, one record: intake, author, classify, link, publish, review, retire — the library that audit RCM and SOX scoping read from.
workflow · Context
AI Service Data Policy & Quality Management Cycle
AI Service Data Policy & Quality Management Cycle as a modular, decision-aware workflow. Each annual instance — and each semiannual regulatory-compliance checkpoint — runs on the existing "AI Service Data Policy & Quality Management" Process item (process_type operational, process_owner = AI Product Owner) and enriches its standing records; it never recreates them. Run by the AI Governance Lead (second line) and owned by the AI Product Owner (first line), it refreshes the customer-facing input data policy and output data policy, collects customer acknowledgements where the changes are material, reviews the AI quality management system for effectiveness, and refreshes the regulatory compliance documentation and obligations register shared with customers. Consumes at launch: the cycle trigger and mode, the in-scope AI service list with each service's value-chain role (a step document — there is no AI System item type), both data policies and the quality manual and procedures as Policy items, and the obligations register as Control items. Deliverables: the published policy versions with their acknowledgement records, the quality management system review record, the refreshed compliance statement and obligations register, the corrective-action log, and an indexed cycle evidence pack. Out of scope: the AI services' own development, risk assessment, and control testing, and fulfilment of individual customer data requests. Terminal — the cycle closes to its own archived workflow record, linked back to the anchor Process item.
workflow · Context
Emerging Risk & Horizon Scan
Runs on the existing risk item. Scan the forward horizon for signals of an emerging exposure, assess plausibility and velocity, and decide whether it enters the register or stays on the watchlist. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Issue Triage & Disposition
Runs on the existing issue item. Substantiate a reported issue, assess its severity and cause, select a governed disposition, and approve the triage record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Risk Appetite & Tolerance Calibration
Runs on the existing risk item. Set or recalibrate the appetite statement and tolerance thresholds for a risk, test the current position against them, and approve the escalation record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ERM Risk Identification & Register Refresh
Runs on the existing risk item. Run a periodic enterprise risk identification cycle, consolidate candidate risks, and approve the resulting register changes. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Enterprise Risk Register Lifecycle
Enterprise Risk Register Lifecycle as a decision-aware workflow. This is a standalone recurring instance (quarterly or annual) that runs against the existing Risk item population — the enterprise risk register itself — enriching those Risk items in place rather than recreating a register: per-risk results are written onto the individual Risk items, and cycle-level deliverables attach to the workflow instance's steps. In scope: maintaining the register across the confirmed entities, business units, and risk-taxonomy categories for this cycle — intake and deduplication of new risks, Three-Lines ownership, control and assurance mapping, KRIs, periodic review and escalation, and retirement. Out of scope: any entity, unit, or category not named in this cycle's confirmed scope. It consumes the candidate-risk handoff package from the upstream Risk Register Intake workflow and hands its maintained register, residual positions, and escalations to two downstream workflows — Enterprise Risk Assessment & Portfolio Oversight Cycle (the maintained register, the concentration and correlation flags, and the residual positions) and Risk Appetite Definition & Board Reporting (the above-appetite entries, the escalations, and the acceptances) — rather than duplicating repeated work.
workflow · Context
ESG-Related Risk Materiality & Integration
ESG-Related Risk Materiality & Integration as a decision-aware workflow. Each cycle runs on the existing portfolio-level ESG Risk item (a Risk with category: esg — e.g. "ESG / sustainability risk — enterprise"): it enriches that umbrella entry and the ESG-tagged slice of the Risk register (Risk items tagged category: esg / taxonomies: esg_sustainability) rather than recreating them, and fans per-topic detail out onto the individual Risk items it creates or updates for each impact, risk, and opportunity (IRO). In scope: assessing ESG-related risks across the confirmed environmental, social, and governance topics, entities, and value-chain boundary for this cycle — defining the ESG risk universe (impacts, risks, opportunities), engaging affected stakeholders and information users, assessing double materiality and prioritizing the material topics, mapping controls and management responses, defining KRIs and disclosure metrics, and assembling disclosure inputs. Its named deliverables are the double-materiality assessment (the ranked material topic set with a materiality matrix), the control/response and assurance mapping, the disclosure metrics and leading KRIs, and the framework-mapped disclosure index (ESRS/CSRD, ISSB S1/S2, GRI, SEC climate). Out of scope: any ESG topic, entity, or business unit not named in this cycle's confirmed scope, and the drafting of the external sustainability report itself. It consumes the enterprise risk portfolio and residual positions from the upstream Enterprise Risk Assessment & Portfolio Oversight Cycle and hands its material ESG topics, KRIs, and disclosure inputs to the downstream Quarterly Board & Audit-Committee GRC Reporting workflow rather than duplicating repeated work.
workflow · Context
Framework Adoption & Cross-Mapping
Adopt or refresh a security/compliance framework (for example NIST CSF 2.0, ISO/IEC 27001:2022, or SOC 2) by scoping the target framework, rating the current profile, defining the target profile, crosswalking requirements to existing controls and adjacent frameworks, prioritizing gaps, and maintaining a live mapping table. The workflow instance runs on an Audit item created at the start of each adoption cycle (audit_type: readiness, or compliance) — its scope/period fields carry the assessment boundary and cycle window, and every step document versions against it. No upstream workflow feeds this one; it consumes the organization's own existing inventory: the risk register (Risk items), the control library / RCM (Control items and their Risk links), the in-scope Process inventory, and any prior Audit items for this or adjacent frameworks. Named deliverables: the framework mapping table (the crosswalk), the risk-ranked prioritized gap list, the coverage/gap dashboard, and the versioned adoption package. In scope: profile construction, crosswalk mapping, gap prioritization, and the closure disposition. Out of scope: authoring the policies and designing the new controls the gaps demand — those are handed off downstream to TWO workflows, Policy Lifecycle Management (policy-driven gaps) and Control Design (control-build gaps).
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
Enterprise GRC Platform Integration Bridge
Runs on a Process item created at kickoff (process_type = it_general_control, process_owner = the integration owner, frequency = the sync cadence) that represents the bridge as an operated, auditable IT process — the workflow instance attaches to and enriches that Process item, never a duplicate. Bridges an external enterprise GRC platform (e.g., RSA Archer, ServiceNow GRC, Workday, AuditBoard) with AssureSwarm: define field and ID mappings, run the initial migration or provisioning (which creates Risk / Control / Issue / Audit / Policy items and Control-hosted testing workflows for imported control-test records), operate a monitored bidirectional scheduled sync, resolve conflicts, and confirm system-of-record agreement. This workflow originates the integration project — it consumes no upstream handoff. In scope: mapping design, initial load, ongoing sync operation and health monitoring, conflict resolution, and system-of-record sign-off. Out of scope: standing up the external GRC platform itself, and the downstream assurance analysis. The named deliverable is a version-stamped final bridge package (evidence index, executive summary, authoritative per-field system-of-record coverage table, open-items list), handed to the Combined Assurance Mapping workflow, which consumes it rather than re-deriving the record inventory.
workflow · Context
Policy Lifecycle Management
Run one policy through its full lifecycle, anchored to a Policy item in the policy library — created at authoring for a net-new policy, enriched in place on each refresh cycle (never duplicated). In scope: authoring and control/authority linkage, stakeholder review, formal approval, publication and workforce attestation, acknowledgement tracking, disposition, and scheduled alignment refresh. Consumes read-only upstream: the enterprise risk assessment (Risk items), control design (Control items), and obligation mapping — this workflow neither produces nor edits them. Produces four named deliverables: the published policy version, a frozen workforce attestation completion record, a section-by-section alignment verdict, and a single approval-ready policy package. Out of scope: enterprise risk assessment, control design, and obligation mapping. The approved policy package is handed off to the Regulatory Compliance Attestation Cycle, which runs the recurring regulatory attestation; the acknowledgement campaign launched here is the one-time publication attestation and is explicitly flagged in the handoff as not-to-be-repeated downstream.
workflow · Context
Regulatory Compliance Attestation Cycle
Regulatory Compliance Attestation Cycle: runs on and enriches the existing Audit item created for this authority and reporting period (audit_type = compliance or regulatory_exam; scope = certification boundary; period_start/period_end = the reporting period) — that Audit item is the attestation record the cycle updates throughout, never a duplicate. Over the cycle: compile evidence for the authority source across the reporting period, validate and resolve evidence gaps, produce the five-section regulatory attestation package, route certifying-officer certification, and archive the package. In scope: the legal entities, products, geographies, and systems named in the certification boundary for that authority and period. Consumes the implemented, owned, control-mapped obligation baseline as the handoff package from the Regulatory Obligation Implementation workflow (the implementations themselves are the Control items whose framework multiselect includes this authority, linked to the anchor Audit). Out of scope: obligations under other authorities, entities outside the certification boundary, and the obligation-to-control implementation itself. Hands the certification outcome, exception register, action plans, and accepted risks off to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Privacy Safeguards & Notice Management
Privacy Safeguards & Notice Management as a decision-aware cycle that runs as a workflow instance attached to the standing "Privacy Program" Process item (process_type: business_process, process_owner: the privacy officer) — one archived instance per period is the cycle file. Each run refreshes the privacy requirements inventory, confirms PII-protection accountability over the PII stores (modeled as processing-activity Process items), verifies administrative, technical, and physical safeguards against data volume and sensitivity (the safeguard set is the Control items with control_category administrative|technical|physical and framework gdpr|ccpa|hipaa protecting each store), remediates gaps as tracked Issues, and authors, publishes, and version-retains the privacy notices and registrations (modeled as Policy items) kept accurate to actual processing. In scope: the periodic privacy program cycle over the confirmed PII stores, their safeguard control set, and the published notice and registration population; every run reconciles the affected notices to actual processing — a cycle that skips notice reconciliation is a different workflow. No upstream or downstream workflow feeds or consumes this cycle; its inputs are the organization's own privacy program records, and open remediation, treatment expiries, and deferred drift carry forward as open Issues that seed the next cycle's intake.
workflow · Context
Legal & Regulatory Compliance Register Evaluation
Runs the compliance office's recurring register-evaluation cycle as a compliance-review engagement: the workflow instance attaches to an Audit item created per cycle (audit_type: compliance, period_start/period_end bounding the evaluation period, lead_auditor = the compliance officer), and every gap, management directive, and result produced this cycle links back to that Audit. A decision-aware cycle that refreshes the register of applicable legal, regulatory, and contractual requirements — including intellectual-property and software-licensing obligations — confirms ownership, schedules and performs documented compliance evaluations on each requirement's defined cadence, remediates non-compliance, reports status to management, and retains the register and results as evidence. Consumes upstream: between-cycle regulatory change flows in as a data feed from the Regulatory Horizon Scanning & Triage workflow, swept at the register-refresh entry point (a feed, not a formal handoff package). Named deliverables: the dated register of record, the period evaluation schedule, the evaluation results register, the compliance determination, the exposure-ranked remediation set (Issues linked to the cycle Audit), the compliance status report and dashboard, and the retained cycle evidence set. Hands off downstream: obligations that need standing up route to the Regulatory Obligation Implementation workflow — named in prose at close-and-archive, with no handoff package produced here. In scope: the legal, regulatory, and contractual requirements already in the compliance register that fall due for evaluation this period — cadence-due, overdue, or event-triggered. Out of scope: standing up brand-new obligations. The cycle scope — register population, the due subset including overdue catch-ups, and the period boundaries — is set at the register-refresh entry point.
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
AI Transparency & Value-Chain Communications
Each quarterly instance runs against the existing "AI Transparency & Value-Chain Communications" Process item (process_type: business_process, frequency: quarterly), enriching it rather than recreating it, and links to the existing Control items UC-AI-10 and UC-AI-14 (framework: iso-42001 + eu-ai-act, domains: ai_governance) that the cycle executes. A recurring operate cycle that keeps AI system documentation, interaction disclosures, and content marking current with system changes, retains distribution evidence, evaluates AI suppliers (Vendor items) against responsible-AI requirements, and reviews customer needs and communications; the transparency policy and content-marking standard it enforces are Policy items. It consumes no upstream handoff package (a self-originating quarterly cadence) and terminates in no downstream workflow — systemic findings and carry-forwards land as Issue items in the AI governance backlog. In scope: every AI system in production or customer-facing use and every AI supplier providing an AI system, model component, training data, or inference service; out of scope: risk-classification and conformity assessment itself — purpose or risk-class drift is routed to the EU AI Act Impact Analysis workflow (as an observation Issue referencing it) rather than resolved in this cycle.
workflow · Context
GPAI Model Provider Compliance Cycle
Recurring operate cycle that fulfills Article 53 general-purpose AI model provider duties every release and quarterly refresh, and layers in Article 55 systemic-risk duties for models designated as posing systemic risk. The cycle runs as one Workflow instance on the existing Process item "GPAI model governance / provider compliance" (process_type: business_process, process_owner: Head of Model Governance) — enriched each cycle, never recreated — and links to the Control item implementing UC-AI-15. It consumes the prior cycle's archived instance on the same Process anchor (the per-model scope/exemption register and the prior version-of-record documentation carry forward), and produces the archived, authority-producible provider-obligation cycle record as its named deliverable. Note: the Studio catalog has no AI-Model item type, so per-model artifacts — scope, open-source-exemption determination, documentation and pack versions, publication records — live as version-stamped step documents and on the Workflow instance rather than on a model item, with the per-model scope register carried as a document on the anchor Process item. In scope: every general-purpose AI model this provider places on the EU market, scoped per model to Article 53 alone or Article 53 plus Article 55, with per-model provider-status and Article 53(2) open-source-exemption determinations carried on that scope register. Out of scope: the downstream integrator's own AI-system risk-class obligations, which each deployer operates separately; there is no named downstream workflow this cycle hands off to.
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
Requirement Applicability & Control Mapping
Runs on the existing requirement item. Interpret a requirement, determine supported applicability, map obligations to controls and evidence, and approve the mapping record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Regulatory Change Intake & Impact Assessment
Runs on the existing requirement item. Validate a new or amended external obligation against its authoritative source, determine applicability, and assess the impact on controls, policies, processes and systems. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Obligation Implementation & Adoption
Runs on the existing requirement item. Deliver the control, policy and process changes an obligation requires, validate readiness evidence, and approve the adoption record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
EU AI Act Obligation Impact Analysis
EU AI Act Obligation Impact Analysis runs on a compliance Audit item created at intake (`audit_type: compliance`, `scope` = the fixed entities/AI-systems/markets boundary) — the "impact-analysis item" the whole run enriches and closes. It parses in-scope EU AI Act provisions, classifies affected AI use cases by operator role and risk tier, crosswalks obligations to existing Control items, rates conformity gaps as Issue items, and routes high-risk gaps to the AIMS (ISO/IEC 42001 AI management system). Consumes the horizon-scanning handoff package from Regulatory Horizon Scanning & Triage. Named deliverables: the locked workplan, the obligation register (the durable run-to-run workbook), the per-use-case classification set, the obligation-to-control crosswalk, the ranked conformity-exposure list, and the version-pinned final analysis package. Hands its approved gap-and-action package to Regulatory Obligation Implementation. In scope: obligation parsing, use-case classification, control crosswalk, and gap rating for the entities, AI systems, and markets fixed at intake. Out of scope: implementing remediations, performing conformity assessments, and running fundamental-rights impact assessments (FRIAs) — FRIAs route to the AI Governance & Risk/Impact Assessment module.
workflow · Context
Compliance Monitoring & Attestation
Runs on the existing requirement item. Refresh evidence for an obligation on its review cycle, test continued conformance, and record the owner attestation with any exceptions. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Regulatory Horizon Scanning & Triage
Regulatory Horizon Scanning & Triage as a modular, decision-aware workflow. Each cycle runs on an Audit item created for the scan window — `audit_type` = compliance, titled "Regulatory Horizon Scanning — <period>", with `period_start`/`period_end` set to the detection window; the workflow instance attaches to that Audit and is archived against it at close. It can stand alone, but is designed to exchange handoff packages with related workflows instead of duplicating repeated work. In scope: detecting and summarizing regulator publications, routing them to the authority-source register, applicability screening against the compliance profile, entity profile, and activity inventory, owner assignment, and queueing. Out of scope: obligation mapping, gap and impact analysis, and implementation — those belong to the downstream Regulatory Impact Analysis & Obligation Mapping workflow, which consumes this workflow's named deliverables: the prioritized impact-analysis intake queue and the cycle evidence package. There is no upstream workflow and no prior handoff to consume; this is the sensing edge of the regulatory-change chain, and its standing inputs are the monitored feed list, the prior cycle's cursor, the authority-source register, and the Policy items that cite those authorities.
workflow · Context
Regulatory Impact Analysis & Obligation Mapping
Regulatory Impact Analysis & Obligation Mapping runs on a compliance Audit engagement record — an Audit item created per triggering instrument (audit_type=compliance) whose scope holds the locked scope statement and to which every gap Issue, risk acceptance, and the workflow instance attach. It consumes two upstream inputs: the triage handoff package from Regulatory Horizon Scanning & Triage (instrument, canonical citation, publication and effective dates, triage disposition) and the canonical instrument text itself — the Official Journal or regulator-register version, the authoritative source the whole analysis cites. It parses that instrument into obligations, maps them to the existing Policy and Control library, classifies and rates gaps, and reconciles the obligation register. Named deliverables: the cited regulatory impact note, the obligation inventory, the authority-to-policy crosswalk, the classified and rated gap Issues, the versioned obligation register, and the final evidence and decision package. In scope: obligation analysis, crosswalk, gap classification, exposure rating, and register reconciliation for the in-scope entities, products, and jurisdictions. Out of scope: remediation build-out (handed off to Regulatory Obligation Implementation) and re-prioritizing the instrument (owned by Regulatory Horizon Scanning & Triage). Confirmed gaps and their action plans hand off to Regulatory Obligation Implementation.
workflow · Context
Regulatory Obligation Implementation
Implement a new or changed regulatory obligation end to end on the Audit item created for this implementation (audit_type = compliance or readiness): its scope names the obligation and authority, its period_end holds the effective (compliance-by) date, and the workflow instance attaches to it. There is no native Regulation type, so the regulator, region, and obligation summary live in the anchor Audit.description with the operative source text uploaded to the gap-analysis step. The work — gap analysis, policy updates (Policy items), control design (Control items), process operationalization (a Process item), and coverage validation — enriches that Audit rather than creating a parallel record. In scope are the legal entities, products, systems, and vendor relationships (Vendor items) the obligation touches; entities and processing below the regulation's applicability thresholds are out of scope. This workflow consumes the obligation map handed off from Regulatory Impact Analysis & Obligation Mapping and hands its named deliverable — a validated coverage package (the gap list, the drafted policies and controls, the operationalized process, and the validation run) — to the Regulatory Compliance Attestation Cycle.
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
DPIA / Privacy Impact Assessment
GDPR Article 35 data protection impact assessment as a decision-aware workflow, run on the existing Process item (process_type=business_process) that represents the processing activity under assessment — the Process item doubles as the AssureSwarm proxy for the activity's records-of-processing (RoPA) entry, and the instance enriches it rather than creating a duplicate. It draws on upstream evidence — the RoPA extract, the data inventory and data-flow map, the Article 28 processor arrangements and transfer impact assessment from vendor due diligence, and the security risk assessment for the hosting systems — and moves the activity from screening, through necessity and proportionality and privacy-risk treatment, to a residual-risk decision with Article 36 prior consultation where needed and DPO sign-off. The named deliverable is the signed, versioned DPIA package (or, on the screened-out path, a defensible screening memo), registered against the Process item with tracked mitigation actions; close-and-archive hands that package off to records-of-processing maintenance. In scope: one processing activity (or a set of similar operations with comparable risks per Article 35(1)) from screening through sign-off; out of scope: the related workflows it draws on or feeds — vendor due diligence for new processors, transfer impact assessment for third-country transfers, security risk assessment for the hosting systems, and the records-of-processing maintenance that absorbs the outcome.
workflow · Context
Privacy Program Operations (Consent, Complaints & Sharing)
Runs the standing **Privacy Program Operations** process — an existing operational Process item (process_type=operational, process_owner = the privacy officer) — on a recurring cycle: this workflow instance attaches to that Process and IS the cycle record. It enriches what already exists rather than recreating it: the anchor Process, the in-scope RoPA processing-activity Process items, the privacy Control and Policy items, and the still-open Issues carried forward from prior cycles. Three parallel streams run inside the cycle — reconcile consent and preferences against processing activities, resolve privacy complaints with an accounting of disclosures, and govern data-sharing agreements against actual flows — each consuming verifiable extracts (consent-platform events, the disclosure log, integration/transfer logs) and producing named deliverables: the consent reconciliation report, the complaint register (Issue items), executed agreement renewals with any legal-approved interim risk treatments, and the cycle metrics pack, before the cycle is archived to its retention schedule. Self-contained recurring cycle; the approved metrics pack informs downstream privacy governance / committee reporting.
workflow · Context
Annual ICFR Scoping & Risk Assessment
Runs on the fiscal year’s existing SOX Audit, using financial balances, prior-year RCM and deficiency history, business changes, and the approved IA plan. Produces the Fiscal Year Audit Scope Memo, Risk & Control Matrix, approved workplan, kickoff records and recipient-specific annual communications for process walkthroughs and control testing.
workflow · Context
Fraud Risk Assessment & Anti-Override Control Review
Runs on an Audit item created for the cycle (audit_type internal or sox_testing; scope = "Annual fraud risk assessment & anti-override review FYxx"; period_start/period_end = the assessed period). The workflow instance attaches to that Audit, which is the cycle's durable record - a fresh Audit per cycle keeps successive years separable; the workflow enriches it, it does not create a duplicate. Covers the fraud triangle across fraudulent reporting, asset misappropriation, and corruption, the explicit assessment of management override risk, anti-override control recalibration (journal-entry review criteria and significant-estimates scrutiny), and audit committee reporting. Consumes upstream: the prior-period fraud risk register (Risk items, category financial_reporting, with their inherent_rating/residual_rating/treatment and dispositions) as the baseline; the SOX-scoped Process population; in-period Issue signals (deficiencies, findings); and the existing Control inventory - specifically the journal-entry-review and significant-estimates-challenge Control items whose description/frequency/control_owner hold the current criteria. In scope: the current SOX-scoped entity and process population, judged against the prior-period baseline; an event-triggered refresh scopes to the affected entities and fraud vectors, not automatically the whole map. No upstream workflow feeds this cycle - it originates from the prior-period assessment and interim events since. Named deliverable: the fraud risk assessment report and the audit committee package (fraud risk register, heat map, the explicit management-override determination, and the recalibrated anti-override control specification). Hands off to the journal-entry-review and significant-estimates control operators, who run the recalibrated anti-override controls; accepted residual risks persist as Risk items (treatment accept) that seed the next annual cycle's baseline.
workflow · Context
Financial Controls Policy & Segregation-of-Duties Governance
Financial controls policy and segregation-of-duties governance as a decision-aware workflow covering annual policy-suite reapproval and communication, quarterly SoD conflict-matrix refresh, role and system-access conflict screening, mitigating-control documentation, and owner-assignment confirmation, closed out with a control-indexed certified evidence package. Each run is one workflow instance on the existing Process item "Financial Controls Policy & SoD Governance" (process_type: financial_reporting, quarterly cadence), enriching — never recreating — the financial-control Policy suite (entity-wide ITGC and period-end financial reporting oversight policies held as Policy items) and the existing Control items UC-FIN-01 and UC-FIN-05 that the cycle operates. In scope: reapproval and communication of the Policy suite and segregation-of-duties screening across the in-scope entities, finance systems, and personnel, with the cycle running either annual policy reapproval plus the quarterly SoD review or the quarterly SoD review alone; out of scope: access provisioning and remediation execution themselves. As a standing governance control it takes no upstream workflow feed and runs on its own annual/quarterly cadence, but it hands off the remediation and deficiency Issues it raises — elimination-path access conflicts and recorded deficiencies — to the access-management and deficiency-evaluation processes that execute them.
workflow · Context
Financial Systems Transaction Integrity Monitoring
Each cycle runs as a workflow instance attached to the EXISTING financial-reporting Process item (process_type=financial_reporting) that represents financial-systems transaction processing; the four unified controls it operates (UC-FIN-06 through UC-FIN-09) are EXISTING Control items linked to that Process — enrich them, never recreate them. A decision-aware workflow covering input-control queue clearance and configuration revalidation, automated-processing exception disposition and configuration-change approval, interface reconciliation and failure resolution, and system-generated report validation and baselining. It consumes the prior cycle's carry-forward open items (Issue items created when that cycle's evidence package was certified and closed, linked to their Control) as this cycle's scope. In scope each cycle: every in-scope input control, automated processing control, interface, and relied-upon standard report for the cycle window, with change-flagged items retested and prior-cycle carryovers carried forward. The named deliverable is the control-indexed cycle evidence package with the owner's signed certification statement. There is no downstream workflow — the workflow is terminal and self-seeding: the open items this cycle discloses become carry-forward Issue items that seed the next run of this same cycle on the same Process.
workflow · Context
Physical Asset Custody & Count Program
Physical-asset custody and count program as a decision-aware workflow that operates control UC-FIN-10 (physical asset custody & count) each cycle. The instance attaches to the EXISTING UC-FIN-10 Control item — a preventive, physical control run on the standing count calendar — enriching that control's operating history each cycle rather than creating a new record; every variance, custody exception, storage gap, deficiency, and carry-forward it raises is an Issue linked back to that Control. It covers count-package preparation, blind physical count and inspection, book reconciliation, custody-log authorization review, storage and retention verification, and certified, audit-ready evidence archival. In scope each cycle: cash funds (petty cash, tills, vault), negotiable instruments on hand, and physical accounting records under retention, counted against the standing count calendar. It consumes no upstream workflow and hands off to none; cross-cycle continuity is item-based — this cycle's carry-forward Issue items become the next cycle's scoping inputs — so there is no handoff package.
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
Year-End Deficiency Aggregation & Severity Evaluation
Year-End Deficiency Aggregation & Severity Evaluation as a modular, decision-aware workflow. The instance runs against the existing fiscal-year ICFR assessment engagement — the Audit item with audit_type=sox_testing whose period_end is fiscal year end — enriching it rather than creating a duplicate: the frozen register snapshot and the full evaluation memo trail attach to its steps, and the overall ICFR conclusion lands on that Audit item (rating/opinion/report_date). It closes the gap between per-deficiency handling and the portfolio view: it freezes the register, reconciles it to every failed test, aggregates related deficiencies, concludes control deficiency versus significant deficiency versus material weakness, and hands conclusions to certification support, remediation, and audit-committee reporting instead of duplicating their work. The named deliverables are the year-end deficiency-evaluation memo (carrying the overall ICFR conclusion) and the countersigned final severity schedule. In scope: freezing and severity-evaluating the year-end deficiency population as of the fiscal-year-end assessment date, kept live through the 10-K filing date under a late-arrival rule. Out of scope, handed off rather than duplicated: fixing the deficiencies (SOX Deficiency Remediation) and reporting them to the board (Quarterly Board & Audit-Committee GRC Reporting). Severity thresholds and the contributing-test population are consumed from the Annual ICFR Scoping & Risk Assessment, SOX Key Control TOD/TOE Test, and SOX ITGC Testing runs — the deficiency register itself is the Issue population (issue_type deficiency, escalating to significant_deficiency and material_weakness as this workflow finalizes).
workflow · Context
Quarterly 302/906 Sub-Certification Cascade
Quarterly 302/906 sub-certification as a modular, decision-aware workflow: it maintains the certifier hierarchy, refreshes the questionnaire for new systems, reorgs, known control issues, and pending deficiencies, launches the tiered cascade, tracks completion and cures gaps at the cutoff, triages exceptions and qualifications with escalation to the disclosure committee where material, summarizes the population for principal-officer 302/906 sign-off, and archives the certification evidence with the period's support. The instance runs against a campaign-record Audit item created for the quarter (audit_type: compliance; period_start/period_end = the quarter; scope = the in-scope entity and process population), enriching that one record — every questionnaire form, certification register, decision form, dashboard, and attestation package hangs off it and the run's own instance is the audit trail. It consumes the in-scope Process items (each carrying its process_owner) and the open deficiency Issue log, originates on its own recurring quarterly cadence with no upstream handoff, and hands its deficiencies downstream as linked Issue items into the SOX Deficiency Remediation, Year-End Deficiency Aggregation & Severity Evaluation, and Quarterly Board & Audit-Committee GRC Reporting workflows. In scope: the quarter's in-scope entities and processes per the current consolidation scope, from process-owner sub-certification through principal-officer 302/906 sign-off and archival, back-planned from the SEC filing date. Out of scope: the officers' external SEC filing mechanics, and the deficiency, year-end aggregation, and board reporting handled by the downstream SOX Deficiency Remediation, Year-End Deficiency Aggregation & Severity Evaluation, and Quarterly Board & Audit-Committee GRC Reporting workflows this cascade routes into.
workflow · Context
FSLI Significance Assessment
Runs on the existing fsli item. Assess quantitative and qualitative significance for a financial statement line item and approve its scoped assertions, locations, and process dependencies. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Management Assessment & Assertion
Runs on the existing audit item. Assemble and govern management’s annual ICFR assessment record, including scope, test results, deficiencies, certifications, disclosures, and assertion approval. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Deficiency Evaluation & Committee
Runs on the existing audit item. Evaluate SOX control deficiencies individually and in aggregate, obtain management challenge, and govern committee communication and disposition. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOX Deficiency Remediation
SOX Deficiency Remediation carries one control deficiency's full lifecycle — grade, root cause, remediation, validation, and closure. The workflow runs on the deficiency **Issue item** it opens at grading — `issue_type` set to the exact SOX grade (deficiency / significant_deficiency / material_weakness) and `severity` on the mapped AssureSwarm scale — linked to the affected Control(s), the source Control-hosted SOX testing workflow (template kind: sox-testing), and the current-year SOX audit (Audit, `audit_type: sox_testing`); the remediation actions and the validation retest live as steps on this Issue's own workflow. In scope: a single deficiency triggered by a failed test or unresolved exception. It **consumes** the concluded, reviewed failed-test workpaper handoff package owned upstream (SOX Key Control TOD/TOE Test and SOX ITGC Testing) and **hands off** the closed-or-carried deficiency outcome — with its intact severity history and any triggered communication obligations — to Quarterly Board & Audit-Committee GRC Reporting, which aggregates the full deficiency population into the period's ICFR conclusion and audit-committee materials. It exchanges handoff packages with those related workflows rather than duplicating their work.
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.
workflow · Context
SOX Key Control TOD/TOE Test
Runs directly on an existing SOX-applicable Control for the fiscal year, using the approved walkthrough, scope, methodology and evidence. Produces an independently approved TOD memo before sampling, period-specific TOE results and reviewed exception evidence for interim/year-end assessment and deficiency remediation. Require that the Control fields.sox_applicable value is the literal boolean true; use Workflow.customFields.sox.fiscalYear for the cycle. TOD/TOE test periods remain step-level facts.
workflow · Context
SOX Scoping Decision
Runs on the existing Process item for the one business process under decision — it enriches that Process item and the Control and Risk items in its RCM, never creating a duplicate. Determine whether the process is SOX-relevant and, if so, scope its key controls — otherwise document the exclusion. Consumes the Annual ICFR Scoping & Risk Assessment handoff package (accepted materiality set, scoping thresholds, aggregation floor). Named deliverables: the assessment worksheet, the SOX-relevance determination memo, the resulting Risk & Control Matrix (RCM) scope (Control and Risk items with live links), and the exclusion memo — compiled into a signed scoping decision package. Hands that signed package off to the downstream SOX Process Walkthrough for the in-scope slice, or routes a full exclusion into the annual monitoring/refresh cycle. Out of scope: entity-level materiality, significant accounts, and fraud-risk assessment, which are owned by the upstream Annual ICFR Scoping & Risk Assessment, and process understanding and control verification, which are owned by the downstream SOX Process Walkthrough.
workflow · Context
SOX Process Walkthrough
Runs on the existing Process item being walked (process_type=financial_reporting) — one workflow instance per walkthrough unit (process × location × variant), with the SOX program's Audit item (audit_type=sox_testing) linked as engagement context. It enriches that Process item and seeds its controls; it never creates a duplicate process. Consumes upstream: the significant-account and location scoping baseline, which it takes as a handoff package from the SOX Scoping Decision workflow rather than re-deriving. Produces the named deliverables: the documented process understanding, the identified key controls and their attributes, the control-to-risk mapping (the Risk & Control Matrix, RCM), the walkthrough memo (which doubles as the process's standing narrative), and draft Control records seeded into the register. Out of scope, owned downstream: design-effectiveness conclusions, sampling, and control testing — the handoff splits the control population so confirmed-design controls go to the SOX Key Control TOD/TOE Test workflow and open-design-gap controls go to the Control Design workflow first. It can stand alone but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.
workflow · Context
SOX Key Control Operation (Close Cycle)
Runs against the existing Financial Close **Process** item (process_type: financial_reporting, monthly) — one workflow instance per close period that operates that period's SOX key controls and is archived when the control owner's sub-certification closes the period, as the period's durable, control-indexed evidence trail; it enriches the standing Process and Control records, never recreating them. Consumes upstream: the in-scope close-cycle key-control population from the risk & control matrix — **Control** items (key_control: true, framework includes sox + coso-ic, domains includes financial_reporting_controls) produced by the *Annual ICFR Scoping & Risk Assessment* workflow and linked to this Financial Close Process — plus the prior period's carry-forward **Issue** items (aged reconciling items, approved carryovers). In scope: the close-cycle key controls operating each period — account reconciliations, management review controls, and journal-entry approval — scoped against the period-end close boundary. Named deliverables: the period IPE log, the signed account reconciliations, the completed MRC checklists, the journal-entry approval register, the control-indexed period evidence package, and the control owner's signed sub-certification (supporting the officers' Section 302 certification). Downstream handoff: the archived evidence package and control execution log stand as the sampling population for the *SOX Key Control TOD/TOE Test*; escalated potential deficiencies continue in the *Year-End Deficiency Aggregation & Severity Evaluation* (deficiency-evaluation) track. Out of scope: deficiency severity evaluation and TOD/TOE testing themselves, both of which consume this cycle's archived evidence.