Governance, Policy & Oversight
731 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
A001 — Establish input data policy
Establish input data policy
control · Context
A002 — Establish output data policy
Establish output data policy
control · Context
A007 — Prevent IP violations
Prevent IP violations
control · Context
B006 — Prevent unauthorized AI agent actions
Prevent unauthorized AI agent actions
control · Context
C001 — Define AI risk taxonomy
Define AI risk taxonomy
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
D003 — Restrict unsafe tool calls
Restrict unsafe 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
E004 — Assign accountability
Assign accountability
control · Context
E006 — Conduct vendor due diligence
Conduct vendor due diligence
control · Context
E008 — Review internal processes
Review internal processes
control · Context
E010 — Establish AI acceptable use policy
Establish AI acceptable use policy
control · Context
E012 — Document regulatory compliance
Document regulatory compliance
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
CCPA-1798.140 — Service-provider and contractor contract requirements
Service-provider and contractor contract requirements
control · Context
CCPA-1798.185 — CPPA regulations: cybersecurity audits and risk assessments
CPPA regulations: cybersecurity audits and risk assessments
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
APO11 — Managed Quality
Managed Quality
control · Context
APO12 — Managed Risk
Managed Risk
control · Context
APO13 — Managed Security
Managed Security
control · Context
APO14 — Managed Data
Managed Data
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
MEA02 — Managed System of Internal Control
Managed System of Internal Control
control · Context
MEA03 — Managed Compliance With External Requirements
Managed Compliance With External Requirements
control · Context
MEA04 — Managed Assurance
Managed Assurance
control · Context
E1 — Exercises Board Risk Oversight
Exercises Board Risk Oversight
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
P15 — The organization communicates with external parties regarding matters affecting the functioning of internal control.
The organization communicates with external parties regarding matters affecting the functioning of internal control.
control · Context
P16 — The organization selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
The organization selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
control · Context
P2 — The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.
The board of directors demonstrates independence from management and exercises oversight of the development and performance 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-Art28-44 — Managing of ICT third-party risk
Managing of ICT third-party risk
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-Art16 — Obligations of providers of high-risk AI systems
Obligations of providers of high-risk AI systems
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-Art21-22 — Cooperation with competent authorities; authorised representatives of non-EU providers
Cooperation with competent authorities; authorised representatives of non-EU providers
control · Context
AIA-Art23-25 — Obligations of importers and distributors; responsibilities along the AI value chain
Obligations of importers and distributors; responsibilities along the AI value chain
control · Context
AIA-Art26 — Obligations of deployers of high-risk AI systems
Obligations of deployers of high-risk AI systems
control · Context
AIA-Art27 — Fundamental rights impact assessment for high-risk AI systems (deployers)
Fundamental rights impact assessment for high-risk AI systems (deployers)
control · Context
AIA-Art43 — Conformity assessment of high-risk AI systems
Conformity assessment of high-risk AI systems
control · Context
AIA-Art47-49 — EU declaration of conformity, CE marking and registration in the EU database
EU declaration of conformity, CE marking and registration in the EU database
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-Art6-7 — Risk-based classification of high-risk AI systems
Risk-based classification of high-risk AI systems
control · Context
AIA-Art72 — Post-market monitoring by providers of high-risk AI systems
Post-market monitoring by providers of high-risk AI systems
control · Context
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-Art28 — Processor obligations and data processing agreements
Processor obligations and data processing agreements
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.314 — Organizational requirements (business associate contracts, group health plan requirements)
Organizational requirements (business associate contracts, group health plan requirements)
control · Context
HIPAA-164.316 — Policies and procedures and documentation requirements
Policies and procedures and documentation requirements
control · Context
Principle 10 — Manage Resources
Manage Resources
control · Context
Principle 11 — Communicate Effectively
Communicate Effectively
control · Context
Principle 12 — Enhance Quality
Enhance Quality
control · Context
Principle 13 — Plan Engagements Effectively
Plan Engagements Effectively
control · Context
Principle 15 — Communicate Engagement Results and Monitor Action Plans
Communicate Engagement Results and Monitor Action Plans
control · Context
Principle 2 — Maintain Objectivity
Maintain Objectivity
control · Context
Principle 3 — Demonstrate Competency
Demonstrate Competency
control · Context
Principle 5 — Maintain Confidentiality
Maintain Confidentiality
control · Context
Principle 6 — Authorized by the Board
Authorized by the Board
control · Context
Principle 7 — Positioned Independently
Positioned Independently
control · Context
Principle 8 — Overseen by the Board
Overseen by the Board
control · Context
Principle 9 — Plan Strategically
Plan Strategically
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 10.1 — Financial Resource Management
Financial Resource Management
control · Context
Std 10.2 — Human Resources Management
Human Resources Management
control · Context
Std 10.3 — Technological Resources
Technological Resources
control · Context
Std 11.1 — Building Relationships and Communicating with Stakeholders
Building Relationships and Communicating with Stakeholders
control · Context
Std 11.2 — Effective Communication
Effective Communication
control · Context
Std 11.3 — Communicating Results
Communicating Results
control · Context
Std 11.4 — Errors and Omissions
Errors and Omissions
control · Context
Std 11.5 — Communicating the Acceptance of Risks
Communicating the Acceptance of Risks
control · Context
Std 12.1 — Internal Quality Assessment
Internal Quality Assessment
control · Context
Std 12.2 — Performance Measurement
Performance Measurement
control · Context
Std 12.3 — Oversee and Improve Engagement Performance
Oversee and Improve Engagement Performance
control · Context
Std 13.1 — Engagement Communication
Engagement Communication
control · Context
Std 13.2 — Engagement Risk Assessment
Engagement Risk Assessment
control · Context
Std 13.3 — Engagement Objectives and Scope
Engagement Objectives and Scope
control · Context
Std 13.4 — Evaluation Criteria
Evaluation Criteria
control · Context
Std 13.5 — Engagement Resources
Engagement Resources
control · Context
Std 13.6 — Work Program
Work Program
control · Context
Std 14.3 — Evaluation of Findings
Evaluation of Findings
control · Context
Std 14.4 — Recommendations and Action Plans
Recommendations and Action Plans
control · Context
Std 14.5 — Engagement Conclusions
Engagement Conclusions
control · Context
Std 14.6 — Engagement Documentation
Engagement Documentation
control · Context
Std 15.1 — Final Engagement Communication
Final Engagement Communication
control · Context
Std 15.2 — Confirming the Implementation of Recommendations or Action Plans
Confirming the Implementation of Recommendations or Action Plans
control · Context
Std 2.1 — Individual Objectivity
Individual Objectivity
control · Context
Std 2.2 — Safeguarding Objectivity
Safeguarding Objectivity
control · Context
Std 2.3 — Disclosing Impairments to Objectivity
Disclosing Impairments to Objectivity
control · Context
Std 3.1 — Competency
Competency
control · Context
Std 3.2 — Continuing Professional Development
Continuing Professional Development
control · Context
Std 5.1 — Use of Information
Use of Information
control · Context
Std 5.2 — Protection of Information
Protection of Information
control · Context
Std 6.1 — Internal Audit Mandate
Internal Audit Mandate
control · Context
Std 6.2 — Internal Audit Charter
Internal Audit Charter
control · Context
Std 6.3 — Board and Senior Management Support
Board and Senior Management Support
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.1 — Board Interaction
Board Interaction
control · Context
Std 8.2 — Resources
Resources
control · Context
Std 8.3 — Quality
Quality
control · Context
Std 8.4 — External Quality Assessment
External Quality Assessment
control · Context
Std 9.1 — Understanding Governance, Risk Management, and Control Processes
Understanding Governance, Risk Management, and Control Processes
control · Context
Std 9.2 — Internal Audit Strategy
Internal Audit Strategy
control · Context
Std 9.3 — Methodologies
Methodologies
control · Context
Std 9.4 — Internal Audit Plan
Internal Audit Plan
control · Context
Std 9.5 — Coordination and Reliance
Coordination and Reliance
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-ERM-04 — Assurance and Advisory Portfolio Calibration
The assurance/advisory mix is calibrated to ERM maturity and resources, strategic and risk context, other-provider strength, and board direction.
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
IIA-POS-TLM-03 — Assurance Coordination and Reliance
Assurance providers coordinate and rely on one another only where independence, competence, evidence, and coverage support reliance; gaps and duplication remain visible to the board.
control · Context
A.5.1 — Policies for information security
Policies for information security
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.20 — Addressing information security within supplier agreements
Addressing information security within supplier agreements
control · Context
A.5.22 — Monitoring, review and change management of supplier services
Monitoring, review and change management of supplier services
control · Context
A.5.23 — Information security for use of cloud services
Information security for use of cloud services
control · Context
A.5.3 — Segregation of duties
Segregation of duties
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.35 — Independent review of information security
Independent review of information security
control · Context
A.5.36 — Compliance with policies, rules and standards for information security
Compliance with policies, rules and standards for information security
control · Context
A.5.37 — Documented operating procedures
Documented operating procedures
control · Context
A.5.4 — Management responsibilities
Management responsibilities
control · Context
A.5.5 — Contact with authorities
Contact with authorities
control · Context
A.5.6 — Contact with special interest groups
Contact with special interest groups
control · Context
A.5.8 — Information security in project management
Information security in project management
control · Context
A.6.2 — Terms and conditions of employment
Terms and conditions of employment
control · Context
A.6.4 — Disciplinary process
Disciplinary process
control · Context
A.6.6 — Confidentiality or non-disclosure agreements
Confidentiality or non-disclosure agreements
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.2 — Allocating responsibilities
Allocating responsibilities
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.2 — AI roles and responsibilities
AI roles and responsibilities
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.4.6 — Human resources
Human resources
control · Context
A.5.2 — AI system impact assessment process
AI system impact assessment process
control · Context
A.5.3 — Documentation of AI system impact assessments
Documentation of AI system impact assessments
control · Context
A.5.4 — Assessing AI system impact on individuals or groups of individuals
Assessing AI system impact on individuals or groups of individuals
control · Context
A.5.5 — Assessing societal impacts of AI systems
Assessing societal impacts of AI systems
control · Context
A.6.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.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-Art20 — Governance and management body accountability / training
Governance and management body accountability / training
control · Context
NIS2-Art21a — Policies on risk analysis and information system security
Policies on risk analysis and information system security
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-Art21e — Security in acquisition, development and maintenance of network and information systems (incl. vulnerability handling and disclosure)
Security in acquisition, development and maintenance of network and information systems (incl. vulnerability handling and disclosure)
control · Context
NIS2-Art21f — Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
control · Context
NIS2-Art21g — Basic cyber hygiene practices and cybersecurity training
Basic cyber hygiene practices and cybersecurity training
control · Context
NIS2-Art21h — Policies on the use of cryptography and encryption
Policies on the use of cryptography and encryption
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-Art21j — Use of multi-factor authentication, secured communications and emergency communication systems
Use of multi-factor authentication, secured communications and emergency communication systems
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
AT-1 — Policy and Procedures
Policy and Procedures
control · Context
AU-1 — Policy and Procedures
Policy and Procedures
control · Context
AU-10 — Non-repudiation
Non-repudiation
control · Context
CA-1 — Policy and Procedures
Policy and Procedures
control · Context
CA-2 — Control Assessments
Control Assessments
control · Context
CA-3 — Information Exchange
Information Exchange
control · Context
CA-5 — Plan of Action and Milestones
Plan of Action and Milestones
control · Context
CM-1 — Policy and Procedures
Policy and Procedures
control · Context
CP-1 — Policy and Procedures
Policy and Procedures
control · Context
IA-1 — Policy and Procedures
Policy and Procedures
control · Context
IR-1 — Policy and Procedures
Policy and Procedures
control · Context
MA-1 — Policy and Procedures
Policy and Procedures
control · Context
MP-1 — Policy and Procedures
Policy and Procedures
control · Context
PE-1 — Policy and Procedures
Policy and Procedures
control · Context
PL-1 — Policy and Procedures
Policy and Procedures
control · Context
PL-10 — Baseline Selection
Baseline Selection
control · Context
PL-11 — Baseline Tailoring
Baseline Tailoring
control · Context
PL-2 — System Security and Privacy Plans
System Security and Privacy Plans
control · Context
PL-4 — Rules of Behavior
Rules of Behavior
control · Context
PL-7 — Concept of Operations
Concept of Operations
control · Context
PL-8 — Security and Privacy Architectures
Security and Privacy Architectures
control · Context
PL-9 — Central Management
Central Management
control · Context
PM-1 — Information Security Program Plan
Information Security Program Plan
control · Context
PM-10 — Authorization Process
Authorization Process
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-14 — Testing, Training, and Monitoring
Testing, Training, and Monitoring
control · Context
PM-15 — Security and Privacy Groups and Associations
Security and Privacy Groups and Associations
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-23 — Data Governance Body
Data Governance Body
control · Context
PM-24 — Data Integrity Board
Data Integrity Board
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-31 — Continuous Monitoring Strategy
Continuous Monitoring Strategy
control · Context
PM-32 — Purposing
Purposing
control · Context
PM-4 — Plan of Action and Milestones Process
Plan of Action and Milestones Process
control · Context
PM-6 — Measures of Performance
Measures of Performance
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
PS-6 — Access Agreements
Access Agreements
control · Context
PS-7 — External Personnel Security
External Personnel Security
control · Context
PS-8 — Personnel Sanctions
Personnel Sanctions
control · Context
PS-9 — Position Descriptions
Position Descriptions
control · Context
PT-1 — Policy and Procedures
Policy and Procedures
control · Context
RA-1 — Policy and Procedures
Policy and Procedures
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
SA-1 — Policy and Procedures
Policy and Procedures
control · Context
SA-4 — Acquisition Process
Acquisition Process
control · Context
SA-9 — External System Services
External System Services
control · Context
SC-1 — Policy and Procedures
Policy and Procedures
control · Context
SI-1 — Policy and Procedures
Policy and Procedures
control · Context
SR-1 — Policy and Procedures
Policy and Procedures
control · Context
SR-12 — Component Disposal
Component Disposal
control · Context
SR-2 — Supply Chain Risk Management Plan
Supply Chain Risk Management Plan
control · Context
SR-3 — Supply Chain Controls and Processes
Supply Chain Controls and Processes
control · Context
SR-5 — Acquisition Strategies, Tools, and Methods
Acquisition Strategies, Tools, and Methods
control · Context
SR-6 — Supplier Assessments and Reviews
Supplier Assessments and Reviews
control · Context
SR-8 — Notification Agreements
Notification Agreements
control · Context
NIST-AGI-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-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
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-01 — Oversight: Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction
Oversight: Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction
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.PO-01 — Policy: Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced
Policy: Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced
control · Context
GV.PO-02 — Policy: Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission
Policy: Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission
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
GV.SC-05 — Cybersecurity Supply Chain Risk Management: Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties
Cybersecurity Supply Chain Risk Management: Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties
control · Context
GV.SC-06 — Cybersecurity Supply Chain Risk Management: Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships
Cybersecurity Supply Chain Risk Management: Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships
control · Context
GV.SC-07 — Cybersecurity Supply Chain Risk Management: The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship
Cybersecurity Supply Chain Risk Management: The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship
control · Context
GV.SC-08 — Cybersecurity Supply Chain Risk Management: Relevant suppliers and other third parties are included in incident planning, response, and recovery activities
Cybersecurity Supply Chain Risk Management: Relevant suppliers and other third parties are included in incident planning, response, and recovery activities
control · Context
GV.SC-09 — Cybersecurity Supply Chain Risk Management: Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle
Cybersecurity Supply Chain Risk Management: Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle
control · Context
GV.SC-10 — Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement
Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement
control · Context
ID.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
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.13 — Asset management and data retention limitations
Asset management and data retention limitations
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.2 — Cybersecurity program
Cybersecurity program
control · Context
500.3 — Cybersecurity policy
Cybersecurity policy
control · Context
500.4 — Chief Information Security Officer (CISO)
Chief Information Security Officer (CISO)
control · Context
500.8 — Application security
Application security
control · Context
500.9 — Risk assessment
Risk assessment
control · Context
PCI-Req12 — Support information security with organizational policies and programs
Support information security with organizational policies and programs
control · Context
SOC1-12 — Vendor / subservice organization management — controls provide reasonable assurance that subservice organizations relevant to user entities' ICFR are appropriately managed and monitored.
Vendor / subservice organization management — controls provide reasonable assurance that subservice organizations relevant to user entities' ICFR are appropriately managed and monitored.
control · Context
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.2 — The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.
The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.
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
CC5.1 — The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
control · Context
CC5.2 — The entity also selects and develops general control activities over technology to support the achievement of objectives.
The entity also selects and develops general control activities over technology to support the achievement of objectives.
control · Context
CC5.3 — The entity deploys control activities through policies that establish what is expected and in procedures that put policies into action.
The entity deploys control activities through policies that establish what is expected and in procedures that put policies into action.
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
CC9.2 — The entity assesses and manages risks associated with vendors and business partners.
The entity assesses and manages risks associated with vendors and business partners.
control · Context
PI1.1 — The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services.
The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications, to support the use of products and services.
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.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-CA — Control Activities (entity-level) — policies and procedures, period-end financial reporting process oversight, and entity-wide control activities including technology general controls policies.
Control Activities (entity-level) — policies and procedures, period-end financial reporting process oversight, and entity-wide control activities including technology general controls policies.
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-MON — Monitoring Activities — ongoing and separate evaluations (internal audit, management self-assessment, disclosure committee), and evaluation/communication of control deficiencies.
Monitoring Activities — ongoing and separate evaluations (internal audit, management self-assessment, disclosure committee), and evaluation/communication of control deficiencies.
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
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-IPE — Information Produced by the Entity (IPE) / completeness and accuracy — controls over the completeness and accuracy of system-generated reports, queries, and spreadsheets used in the operation of controls or in financial reporting.
Information Produced by the Entity (IPE) / completeness and accuracy — controls over the completeness and accuracy of system-generated reports, queries, and spreadsheets used in the operation of controls or in financial reporting.
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
AI accountability gaps and organizational liability
Ambiguous responsibility across developers, deployers, and operators means no party is clearly accountable when AI causes harm; organizations face reputational damage, regulatory sanctions, and civil liability from AI failures at scale, and operational disruption when AI is unavailable.
risk · Direct
Harm to due process and democratic integrity from AI
Because AI assisting judicial decisions or intended to influence elections or voter behaviour (Annex III(8)) operates without human oversight, transparency, and integrity safeguards, it can distort legal outcomes or manipulate electorates, resulting in threats to due process and democratic integrity.
risk · Direct
Inappropriate human/AI task allocation and end-of-life risk
Tasks needing contextual judgment, ethics, or accountability are improperly delegated to AI; and decommissioning raises data-persistence in weights, loss of institutional knowledge, and service-continuity gaps.
risk · Direct
Insufficient human oversight and automation complacency
Because consequential AI decisions run under full automation with reviewers who lack the authority, information, or AI literacy to intervene, meaningful human control is absent and automation complacency erodes vigilance, so erroneous or harmful automated decisions reach individuals unchecked.
risk · Direct
Lack of AI explainability, documentation and disclosure
Because AI models are opaque, model cards and datasheets are missing, and AI involvement in consequential interactions is not disclosed, affected individuals cannot obtain recourse and operators cannot see failure modes, resulting in unaccountable decisions, uninformed consent, and misplaced confidence in spurious, non-causal model reasoning.
risk · Direct
Improper business or market practices
Losses from antitrust violations, market manipulation (spoofing, layering, front-running), benchmark/rate rigging, unlicensed business activity, and sanctions/export-control violations in the conduct of business.
risk · Direct
Litigation, investigation and enforcement exposure
Adverse judgments, class actions, contract/IP disputes, government subpoenas, DOJ/FTC/SEC investigations, consent decrees, or deferred-prosecution agreements imposing penalties, remediation, and management distraction.
risk · Direct
Lack of independent audit and compliance review
Because independent internal and external audit and review of information security are not performed, control deficiencies and non-conformities are neither detected nor challenged, so weaknesses persist unremediated and management and the board lose reliable assurance over control effectiveness.
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
ESG disclosure gaps and greenwashing
Public ESG commitments (carbon neutrality, DEI, supply-chain ethics) unsubstantiated by verifiable data, and non-compliant or inaccurate mandatory sustainability disclosures (CSRD, California SB 253/261, SEC climate rule) — inviting enforcement, investor backlash, and NGO campaigns.
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
Ineffective ICFR / undisclosed material weakness
Because internal control over financial reporting is not maintained effectively - material weaknesses undetected or undisclosed and certifications signed despite known deficiencies - financial statements may be materially misstated and filings delayed or restated, resulting in SEC enforcement, delisting, securities-fraud liability, and loss of investor confidence.
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
Organizational change and transformation failure
Significant structural or cultural change (restructuring, ERP/digital transformation) causes employee resistance, productivity loss, or talent departures that undermine the entity’s capacity to adapt to strategic imperatives.
risk · Direct
Inadequate board and management oversight of risk and control
Because board and management oversight of risk and control is weak - unclear tone at the top, ineffective board composition or independence, poor committee structure, and limited senior-management commitment - control priorities are not enforced and resources are withheld, so risks accumulate unmanaged and control failures go uncorrected across the entity.
risk · Direct
Missing or insufficient security and privacy policies
Because documented, approved, and enforced security and privacy policies are missing and roles and duties are undefined, personnel operate without guidance on required controls and behaviours, so controls are applied inconsistently and accountability gaps leave violations undetected and unaddressed.
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
Weak internal control environment enabling fraud and error
Because the internal control environment is weak - segregation of duties absent, authorization frameworks inadequate, and tone at the top poor - fraudulent and erroneous transactions can be initiated and concealed, resulting in material misstatement and financial, regulatory, and reputational loss.
risk · Direct
Missing security terms in contracts and no disciplinary process
Employment and supplier contracts omit security/confidentiality obligations, and there is no disciplinary process for security violations — removing legal recourse and the deterrent effect against repeat offenders.
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
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
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
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.
risk · Direct
Weak supplier security requirements and monitoring
Because supplier contracts omit security requirements and SLAs and third-party service delivery is not monitored, processors and sub-processors operate without equivalent, audited obligations, so third-party weaknesses and breaches propagate into the organization undetected.
standard · Context
AIUC-1 (Jul 2026)
AIUC-1 — AI agent security, safety and reliability standard (requirement level)
standard · Context
CCPA/CPRA
CCPA/CPRA — California Consumer Privacy
standard · Context
COBIT 2019
COBIT 2019 Governance & Management Objectives
standard · Context
COSO ERM 2017
COSO ERM – Integrating with Strategy and Performance (2017)
standard · Context
COSO IC 2013
COSO Internal Control – Integrated Framework (2013)
standard · Context
EU DORA
EU DORA — Digital Operational Resilience Act
standard · Context
EU AI Act
EU AI Act — principal obligation areas (Chapters II, III, V and IX)
standard · Context
EU GDPR
EU GDPR — General Data Protection Regulation
standard · Context
HIPAA
HIPAA — Security, Privacy & Breach Notification
standard · Context
IIA 2024 Standards
IIA 2024 Global Internal Audit Standards
standard · Context
The Role of the Internal Audit Function in Enterprise Risk Management
The Role of the Internal Audit Function in Enterprise Risk Management
standard · Context
Three Lines Model: Assurance and Advice in Support of Effective Governance
Three Lines Model: Assurance and Advice in Support of Effective Governance
standard · Context
ISO/IEC 27001:2022
ISO/IEC 27001:2022 Annex A
standard · Context
ISO 31000:2018
ISO 31000:2018 Risk Management (principles/framework/process)
standard · Context
ISO/IEC 42001:2023 (AI)
ISO/IEC 42001:2023 Annex A (AI Management System)
standard · Context
EU NIS2
EU NIS2 Directive
standard · Context
NIST SP 800-53 Rev5
NIST SP 800-53 Rev 5 — Security and Privacy Controls
standard · Context
NIST Agent Identity (draft, Feb 2026)
NIST NCCoE: Software and AI Agent Identity and Authorization
standard · Context
NIST TEVV-Athlon (draft, Aug 2026)
NIST AI 200-2: TEVV-Athlon Framework for Evaluating AI Systems
standard · Context
NIST CSF 2.0
NIST Cybersecurity Framework 2.0
standard · Context
NYDFS Part 500
NYDFS Part 500 — NY Cybersecurity Regulation
standard · Context
PCI DSS v4.0.1
PCI DSS v4.0.1
standard · Context
SOC 1
SOC 1 (SSAE 18 / ISAE 3402) — service-org ICFR control objectives
standard · Context
SOC 2 (TSC)
AICPA SOC 2 Trust Services Criteria (2017, rev. 2022)
standard · Context
SOX / PCAOB (ICFR)
SOX 404 / PCAOB AS 2201 — ICFR control taxonomy
unified · Direct
UC-ACCESS-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-21 — Manage subservice organizations supporting the system
Subservice organizations relevant to user entities' control objectives are identified, contractually bound to security and processing commitments, and monitored through review of their independent assurance reports, complementary user-entity controls, and performance. Identified issues are tracked to resolution.
unified · Context
UC-AI-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-02 — Define AI roles, responsibilities, and competencies
Define and assign roles, responsibilities, and authorities for AI governance and for each AI system life-cycle stage, recording them in a maintained RACI or equivalent register. Document the human resources involved in AI development, deployment, and operation, including the competences each role requires and how competence gaps are addressed. Review assignments and competence records when systems, personnel, or obligations change.
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-04 — Assess impacts and classify AI systems before deployment
Operate a documented AI impact assessment process performed before deployment and repeated on significant change, assessing consequences for individuals, groups of individuals, and society, including fairness, safety, and fundamental-rights effects. Classify each system against applicable regulatory risk categories, including any high-risk designation, and record the classification rationale. Retain assessment reports, approvals, and reassessment triggers as evidence.
unified · Context
UC-AI-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-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-13 — Assign AI value-chain roles and discharge obligations
For each AI system, determine and document the organization's role in the value chain, such as provider or deployer, and allocate life-cycle responsibilities among the organization, partners, suppliers, and customers. Maintain a register of the obligations attached to each role, including provider duties for high-risk systems (quality management, conformity assessment, CE marking, registration) and deployer duties (instruction-compliant operation, oversight assignment, log retention), tracking each obligation to an owner and evidence. Review the register when systems or regulations change.
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-17 — Define customer data-use and output-rights policies for AI services
Publish and maintain customer-facing policies for AI services that state how customer inputs are used for model training and inference, how long inputs and outputs are retained, who owns and may use generated outputs, and how customers can opt in or out, request deletion, or exercise other data rights. Communicate the policies before onboarding, version them, and retain customer acknowledgements and periodic review records as evidence.
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-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-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-02 — Establish a board-approved internal audit mandate and charter
The board establishes and approves the internal audit mandate - the function's authority, role, and responsibilities - and documents it in an internal audit charter that is reviewed and reapproved periodically. The charter grants unrestricted access to the records, personnel, and physical property relevant to engagements, and the board and senior management visibly champion and support the mandate. The approved charter and review records are retained.
unified · Context
UC-AUDIT-03 — Ensure board oversight and support of internal audit
The board oversees the internal audit function through regular interaction with the chief audit executive, including executive sessions without management present, and approves the CAE's appointment, remuneration, evaluation, and removal. The board reviews and approves the internal audit plan and budget and ensures the function has sufficient resources to fulfill its mandate. Board meeting minutes and approvals evidence oversight.
unified · Context
UC-AUDIT-05 — Maintain auditor objectivity and disclose impairments
Internal auditors maintain individual objectivity - an unbiased professional attitude free from conflicts of interest - in all engagements. The chief audit executive implements safeguards such as conflict screening, assignment rotation, and recusal to protect objectivity, and auditors promptly disclose actual or perceived impairments so they can be managed and, where necessary, communicated to affected stakeholders. A complete prior-responsibility register is maintained and used for every engagement assignment. An auditor who held operational, design, management, or supervisory responsibility for an activity during the preceding 12 months is subject to a 12-month cooling-off period; if that requirement is not met, the engagement is reassigned or a suitably qualified independent party provides assurance. Portfolio-level reporting to senior management and the board identifies actual and perceived self-review threats and their safeguards. Conflict declarations, prior-responsibility screening, reassignment or independent-assurance results, and safeguard records are retained.
unified · Context
UC-AUDIT-06 — Ensure auditor competency and continuing development
The internal audit function collectively possesses, and individual auditors apply, the knowledge, skills, and abilities required for their responsibilities, engaging qualified assistance where gaps exist. Auditors maintain and enhance their competency through continuing professional development, which is planned, tracked, and reviewed at least annually. Training records and competency assessments evidence operation.
unified · Context
UC-AUDIT-08 — Protect confidential information obtained in audit work
Internal auditors use information obtained during their work only for legitimate professional purposes and in conformance with applicable laws, regulations, and organizational policies. Information is protected against unauthorized access, use, or disclosure during and after engagements, and confidentiality obligations extend to parties assisting the internal audit function. Confidentiality acknowledgments and access controls over audit files evidence operation.
unified · Context
UC-AUDIT-09 — Develop a risk-based internal audit strategy and plan
The chief audit executive develops an internal audit strategy aligned with organizational objectives and stakeholder expectations, grounded in a documented understanding of the organization's governance, risk management, and control processes. The strategy includes a documented assurance, advisory, and administrative capacity mix calibrated against ERM maturity and resourcing; strategic change and the current risk environment; the strength and reliability of other assurance providers; and board direction and stakeholder expectations. A risk-based internal audit plan covering the audit universe is created at least annually, approved by the board, and adjusted as the risk landscape changes. The capacity mix is reconsidered whenever the plan is refreshed, and material changes are communicated to senior management and the board with their coverage impact. The strategy, plan, capacity mix, board approvals, refresh decisions, and communications are retained.
unified · Context
UC-AUDIT-10 — Manage internal audit financial, human, and technology resources
The chief audit executive manages the function's resources to deliver the approved audit plan: a sufficient budget, recruitment, development, and deployment of qualified personnel, and technology that supports the audit process. Resource sufficiency is reassessed against the plan on a defined cadence, and the impact of any constraints on audit coverage is communicated to senior management and the board.
unified · Context
UC-AUDIT-11 — Establish audit methodologies and engagement work programs
The chief audit executive establishes documented methodologies that govern how engagements are planned, performed, and reported. For each engagement, auditors communicate with relevant stakeholders during planning, allocate appropriate and sufficient engagement resources, and develop a work program specifying the procedures for achieving the engagement objectives, which is approved before fieldwork begins. Methodology documents and approved work programs evidence operation.
unified · Context
UC-AUDIT-12 — Plan engagements with risk-based objectives, scope, and criteria
Each internal audit engagement is planned effectively: auditors perform an engagement-level risk assessment of the activity under review, define engagement objectives and scope that address the assessed risks, and establish evaluation criteria against which the subject matter will be assessed. Planning decisions and their rationale are documented in the engagement file and approved by engagement supervision.
unified · Context
UC-AUDIT-14 — Evaluate findings and develop recommendations and action plans
Engagement findings are evaluated individually and collectively to formulate engagement conclusions relative to the engagement objectives, considering the significance of the findings. Recommendations and/or management action plans addressing root causes are developed, collaboratively where appropriate, and are supported by documented evidence. Conclusions and recommendations are reviewed before communication.
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-16 — Communicate final engagement results to stakeholders
A final engagement communication is issued to appropriate parties for every engagement, presenting the objectives, scope, conclusions, findings, and recommendations or management action plans. Communications meet the quality expectations of being accurate, objective, clear, concise, constructive, complete, and timely. If a final communication contains a significant error or omission, corrected information is communicated to all recipients of the original.
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-18 — Communicate with stakeholders on assurance matters
The internal audit function builds relationships and communicates regularly with its stakeholders - the board, management, and relevant external parties such as regulators and external auditors - to develop trust and mutual understanding on internal control and assurance matters. Communication approaches are tailored to stakeholder needs and delivered through defined channels, and significant control matters are shared with external parties as appropriate. Communication plans and records evidence operation.
unified · Context
UC-AUDIT-19 — Operate an audit quality assurance and improvement program
The chief audit executive develops, implements, and maintains a quality assurance and improvement program covering all aspects of the internal audit function, including ongoing monitoring and periodic internal quality assessments of conformance with applicable professional internal auditing standards. Performance objectives and measures for the function are established and tracked, and results, action plans, and progress are reported to senior management and the board, which oversee audit quality.
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-21 — Assess control effectiveness through testing and monitoring
Management operates a monitoring program over the system of internal control that combines ongoing evaluations with separate assessments, including management self-assessments and internal audit evaluations. Controls are assessed for design and operating effectiveness on a defined frequency by assessors with a level of independence appropriate to the assessment, under documented assessment plans, and plans for security testing, training exercises, and monitoring are developed, maintained, and executed. Identified deficiencies are evaluated and communicated to those responsible for corrective action, including senior management and the board as appropriate.
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-23 — Coordinate independent assurance reviews across providers
The organization plans and obtains independent reviews of its approach to managing and implementing information security - including people, processes, and technologies - at planned intervals, after significant changes, and where required by applicable law or regulation. Before relying on another provider's work, each reliance decision assesses and records the provider's independence and objectivity, competence and methodology rigor, evidence quality and reperformance capability, and recency against the covered risk's cadence, together with the resulting reliance level and rationale. Assurance activities are coordinated across internal and external providers to ensure coverage, minimize duplication, and support reliance on others' work. Material reliance limitations, assurance gaps, and duplication remain visible to management and the board. Results are reported to management and the board and drive corrective actions.
unified · 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-FIN-01 — Deploy financial control activities through policies
Deploy control activities over financial reporting through formally approved policies and procedures that state what is expected and how it is performed, including entity-wide policies for technology general controls and oversight of the period-end financial reporting process. Assign owners, communicate the policies to responsible personnel, and review and reapprove them periodically. Evidence includes the approved policy set, periodic review sign-offs, and communication records.
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-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-09 — Ensure quality of information used in reporting
Define and communicate the information requirements for financial processing and reporting, including data definitions and report specifications. Validate the completeness and accuracy of system-generated reports, queries, and spreadsheets used in the operation of controls or in financial reporting by verifying source data, report logic and parameters, and totals before reliance, and baseline standard reports with revalidation on change. Retain validation evidence for each report relied upon.
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
UC-GOV-05 — Ensure board-level oversight of risk and internal control
The board of directors (or equivalent governing body), demonstrating independence from management and appropriate expertise, oversees the development and performance of internal control and the cybersecurity risk management program, approving the risk strategy and material policies. The board periodically reviews risk-management outcomes, program effectiveness, and management reporting, and directs adjustments to strategy and direction; oversight activities and decisions are documented in minutes and supporting materials.
unified · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
UC-GOV-14 — Establish and maintain approved security policies and procedures
Establish, approve, publish, and maintain the organization's information-security policy suite as a governed whole: a top-level policy plus the topic-specific policies, each with an accountable owner, board/management approval, planned review cycles, and communication to relevant parties. Domain-specific policy content is governed by its own unified control; this objective owns the suite-level lifecycle (inventory, approval chain, review cadence, communication, exceptions).
unified · Direct
UC-GOV-15 — Operate a management-approved information security program
Establish, implement, and maintain an organization-wide information security program, documented in a program plan approved by senior management and based on the organization's risk assessment. Define the program's scope, security objectives, protective functions (identify, protect, detect, respond, recover), supporting management processes, and coordination among organizational entities, and review and update the program plan at planned intervals and after significant change.
unified · Direct
UC-GOV-16 — Select and tailor a risk-based control baseline
Select and document a baseline of security and privacy controls — including general controls over technology — responsive to assessed risks, and tailor it to the organization's environment, complexity, and risk appetite, considering an appropriate mix of preventive and detective control types and segregation of duties. Centrally identify, manage, and deploy common controls where appropriate, and document and approve the rationale for all tailoring decisions.
unified · Direct
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 · Direct
UC-GOV-18 — Document and approve system security and privacy plans
Develop, approve, and maintain security and privacy plans for systems that describe each system's authorized purpose, boundary, operating context and concept of operations, requirements, and the controls in place or planned. Distribute plans to authorized personnel, protect them from unauthorized disclosure and modification, review them at defined intervals, and update them to address changes — verifying that systems continue to be used only for their intended and authorized purposes.
unified · Direct
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 · Direct
UC-GOV-20 — Govern data as an asset with accountable oversight bodies
Establish data governance: policies and standards for managing data through its life cycle, and formally chartered governance bodies (e.g., a data governance body and, where required, a data integrity board) with defined membership and responsibilities. These bodies oversee data management, data quality and integrity, and the review and approval of data-sharing and matching agreements, and report on data governance at defined intervals.
unified · Direct
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 · Direct
UC-GOV-22 — Assess control effectiveness and authorize systems
Maintain a documented assessment and authorization policy with procedures, defined performance measures, and quality monitoring to regularly evaluate whether security policies, standards, and risk-management measures are implemented, complied with, and effective — including managers' reviews of compliance within their areas of responsibility. Feed assessment results into a formal, risk-based authorization process in which a senior official explicitly accepts residual risk before systems operate and at defined intervals thereafter, and track findings to closure.
unified · Direct
UC-GOV-23 — Maintain contacts with authorities and special interest groups
Establish, document, and maintain contacts and communication channels with relevant authorities (e.g., regulators, supervisory bodies, law enforcement) and with special interest groups, security forums, and professional associations, defining when and by whom each contact is used, including during incidents. Review contact lists at defined intervals to keep them current, and use these channels to stay abreast of recommended practices, emerging threats, and regulatory expectations.
unified · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
UC-GOV-29 — Maintain secure acquisition, development, and maintenance policies
Establish, document, and disseminate policies and procedures governing security in system and services acquisition, in-house application development, configuration management, and system maintenance — including secure development standards, evaluation criteria for externally developed applications, and baseline configuration requirements. Review, assess, and update these policies and procedures at least annually under accountable security leadership and after significant changes.
unified · Direct
UC-GOV-30 — Maintain asset, media, and physical protection policies
Establish, document, and disseminate policies and procedures for asset management, media protection, and physical and environmental protection — including maintenance of a complete asset inventory, secure handling, marking, storage, and sanitization of media, and data retention limits with secure disposal of nonpublic information no longer required for business or legal purposes. Review and update these policies and procedures at defined intervals and upon significant change.
unified · Direct
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 · Direct
UC-GOV-32 — Maintain security awareness and cyber-hygiene policies
Establish, document, and disseminate policies and procedures for security awareness, training, and basic cyber-hygiene practices applicable to all personnel, defining required content, frequency, audiences, and completion tracking. Review and update the policy and program requirements at defined intervals and in response to changes in threats and incidents.
unified · Direct
UC-GOV-33 — Maintain logging, monitoring, and system integrity policies
Establish, document, and disseminate policies and procedures for audit logging and accountability and for system and information integrity, and define an organization-wide continuous monitoring strategy specifying metrics, monitoring and assessment frequencies, and how results inform risk decisions. Review and update the policies and the monitoring strategy at defined intervals and upon significant change.
unified · Direct
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 · Direct
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 · Direct
UC-GOV-36 — Maintain communications security and cryptography policies
Establish, document, and disseminate policies and procedures for system and communications protection, including the required use of cryptography and encryption, secured communication channels, and multi-factor and strong authentication expectations for remote and privileged access. Review and update these policies at defined intervals and as cryptographic standards and threats evolve.
unified · Direct
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 · Direct
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-HR-02 — Formalize security responsibilities in employment terms
Employment contracts and terms state each individual's information security responsibilities, including obligations that survive employment. Personnel sign confidentiality or non-disclosure agreements and access agreements before being granted access, and re-sign when agreements are materially updated. Position descriptions document role-specific security duties, and signed acknowledgments are retained as evidence.
unified · Context
UC-HR-04 — Enforce a formal disciplinary process for violations
A formal, communicated disciplinary process is applied to personnel who violate information security policies, providing graduated, consistent sanctions proportional to severity and intent. Violations, sanctions applied, and notifications to defined roles are documented and retained, and outcomes feed back into awareness and control improvements.
unified · Context
UC-HR-05 — Hold third-party personnel to equivalent security terms
Contracts with suppliers and external organizations whose personnel access systems or data require equivalent personnel security measures, including screening, confidentiality agreements, and defined security responsibilities, and oblige the provider to notify the organization of personnel transfers or terminations affecting access. Third-party compliance with these personnel requirements is monitored.
unified · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
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 · Context
UC-TPRM-01 — Operate a third-party security risk management program
Establish and operate a management-approved third-party and supply-chain risk management program with a written strategy, policies, and procedures, reviewed at defined intervals and after significant changes to the supply chain or threat landscape. Define and communicate roles and responsibilities for supplier, customer, and partner relationships, and integrate third-party and supply-chain risk into enterprise and cybersecurity risk management. Maintain a register of third-party relationships and contractual arrangements prioritized by criticality, and assess criticality, substitutability, and concentration risk before contracting. Apply risk-based due diligence, embed security requirements, audit and access rights, termination rights, and sub-outsourcing conditions in agreements, and protect organizational information processed, stored, or transmitted on external systems. Define, agree, and periodically review service agreements and supplier performance, reassess third parties on a defined cycle, operate controls to identify and address weaknesses across the relationship life cycle, and maintain documented, tested exit strategies for providers supporting critical or important functions.
unified · Context
UC-TPRM-02 — Perform risk-based due diligence before engaging vendors
Before entering a formal relationship, perform security due diligence on prospective vendors and business partners proportionate to their criticality, evaluating security posture, financial and operational risk, and supply-chain exposure, and document the acceptance decision. Use acquisition strategies, sourcing methods, and selection criteria designed to reduce supply-chain risk before contract award.
unified · Context
UC-TPRM-03 — Bind vendors to security and privacy terms by contract
Include binding security and privacy requirements in contracts and agreements with vendors, service providers, and processors before access, service delivery, or data exchange begins: required security controls, confidentiality, breach notification, audit rights, subcontractor terms, and data handling, return, and deletion obligations. Document and authorize each information exchange or system interconnection under an appropriate agreement, and review agreements periodically. Ensure agreements satisfy the contractual clause requirements mandated by applicable privacy and security regulations for the data and services involved.
unified · Context
UC-TPRM-04 — Monitor vendor performance, services, and risk
Continuously monitor third-party performance, service delivery, and security posture against contractual and risk requirements throughout the relationship. Conduct periodic reassessments and reviews, such as questionnaires, assurance reports, and audits, at a frequency based on criticality, and manage changes to supplier services. Record, prioritize, and track identified vendor risks through response and remediation.
unified · Context
UC-TPRM-05 — Include suppliers in incident notification and response
Establish agreements or contractual provisions requiring suppliers to notify the organization of security incidents and supply-chain compromises within defined timeframes. Include relevant suppliers and third parties in incident-response planning, exercises, response, and recovery activities, with coordination roles defined in advance.
unified · Context
UC-TPRM-06 — Manage secure termination and disposal at relationship end
Include termination and post-relationship provisions in supplier agreements and supply-chain risk plans: return or verified destruction of data, revocation of access and credentials, service transition, and retention of required evidence. Dispose of data, documentation, tools, and system components securely at end of life or end of relationship using defined techniques, and record each disposal.
unified · Context
UC-TPRM-08 — Govern security of external and cloud service use
Define and enforce processes for acquiring, using, managing, and exiting external system services and cloud services in line with the organization's information security requirements. Require external providers to comply with those requirements, define oversight roles and responsibilities on both sides, agree service and exit terms, and monitor provider compliance on an ongoing basis.
workflow · Context
Cybersecurity Assurance Review
Cybersecurity Assurance Review — a CAE-owned assurance engagement that runs on the EXISTING Audit item opened from the audit plan (audit_type=it_audit, status PLANNED, lead_auditor and scope already set): the workflow instance attaches to that item and enriches it end to end, never creating a duplicate engagement record. It covers the three IIA Cybersecurity Topical Requirement domains (governance, risk management, and control activities) over the cyber estate bounded in the engagement memo (in scope: named legal entities, networks, cloud tenants, and OT/ICS where included; out of scope: areas whose assurance is documented as delivered by other engagements), testing against the NIST 800-53 Rev 5 catalog with CSF 2.0 / ISO 27001 as the aggregation frame. It originates from the audit plan (no upstream workflow) and produces the findings register (one four-Cs Issue per finding), the cyber posture summary carrying the per-domain and overall Standard 14.5 conclusions, and the approved engagement package — which it hands to the downstream Audit Report Drafting workflow.
workflow · Context
Internal Audit Ethics, Objectivity & Competency Program
Runs on an Audit item created per cycle as the anchor — audit_type=internal, scope set to the IA professional-practice program for the period, period_start/period_end = the cycle window (a program cycle, not an engagement, so this is a documented reuse of the Audit type; it is the "cycle item" every stream links its evidence to and closes at the end). A decision-aware annual cycle that attests the ethics and professional-courage expectations and documents deviations, screens per-engagement conflicts and manages objectivity impairments, collects confidentiality acknowledgments and restricts audit-file access, and assesses competency against role requirements with approved, tracked continuing-professional-development plans for each auditor. It consumes no upstream workflow: prior-cycle carryover (unresolved-deviation and monitored-impairment Issue items still open against the prior cycle's Audit item, plus in-progress development plans) is its own input, and the population is confirmed against the HR roster, engagement staffing, and the audit-file access list before measurement begins. Named deliverables: the professional-practice requirements memo, the ethics attestation register, the conflict-of-interest declarations and impairment register, the confidentiality acknowledgment register and before/after audit-file access review, the competency assessments with coverage matrix and CPD plans, and the signed CAE conformance report to the audit committee — assembled into an indexed cycle evidence file on the anchor Audit item. Downstream is self-feeding: the carry-forward list produced at close hands off to the next run of this same workflow; there is no distinct downstream workflow. In scope: every auditor and assisting party (employees plus co-source, outsourced, and guest auditors) who performed internal audit work or holds audit-file access during the period, across all four expectation streams (ethics, objectivity, confidentiality, competency); out of scope: the audit engagements' own subject-matter conclusions and any HR, legal, or ethics-office investigation a disclosed concern is referred into.
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
Audit Fieldwork, Findings & Reporting
Runs on the existing audit item. Execute approved audit procedures, evaluate and clear observations, issue a supported report, and close the engagement record with tracked actions. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
Continuous Monitoring & Agent Evaluation
Runs on the existing standing Audit item for a monitoring cycle. Inputs are the approved KRI definitions, current Issue, Remediation, Control, System and Personnel records, and the agent-drafted suggestions and step results produced since the previous cycle. Deliver the monitoring dashboard, breach triage and quality scorecard to the engagement lead, with owned corrective actions and the next run date.
workflow · Context
Fraud Risk Assessment & JE Testing
Runs ON an audit item (an existing engagement). Assesses fraud risks across the fraud triangle and management override, maps anti-fraud controls to those risks, validates and characterizes the journal-entry population for the period, selects entries by pattern flag plus a reproducible random draw from the unflagged remainder, tests every selected entry for support, approval and business purpose, and raises every unsupported anomaly as an issue linked to its FSLI and control. Hands off to engagement reporting for issue disposition and reporting.
workflow · Context
Substantive Testing & Data Analytics
Runs on an existing Audit engagement (`audit`) already scoped to one or more significant FSLIs; enriches it, never re-creates it. Inputs: the scoped FSLI(s) (`fsli.balance`, `fsli.assertions`, `fsli.significant`) and a source-system extract per population under test. Named deliverables: the validated population record, the reproducible sample draw, the whole-population analytics results, and the FSLI assertion conclusion (`fsli.rationale`). Handoff: fraud risk and journal-entry testing (the fraud-risk-je-testing workflow) once every exception is dispositioned and the assertion conclusion is recorded.
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
Annual Internal Audit Planning & Resource Management
Runs the chief audit executive's annual internal audit planning cycle on a per-cycle Audit item created for the year (audit_type=internal, e.g. "Annual IA Planning Cycle FY20XX", status PLANNED→COMPLETE, period_start/period_end = the plan year) — the anchor the workflow instance and every cycle document and link hang off, since no native plan/cycle type exists. It consumes the standing (prior-year) audit universe carried in as Process items plus the prior cycle's archived instance and universe memo, and enriches rather than recreates it: it refreshes the audit universe and the documented understanding of governance, risk, and control processes, ranks the universe by residual risk, develops the internal audit strategy and the risk-based audit plan, resources it with a budget, staffing, and technology plan, tests resource sufficiency, obtains board approval, and reassesses the plan and resources on the quarterly refresh. In scope is the enterprise-level planning cycle from audit-universe refresh through board approval, plus the quarterly plan-and-resource reassessment; delivering the individual engagements is out of scope — the approved engagement list (the created engagement Audit items) hands off to each engagement's own audit engagement planning workflow.
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
Vendor SOC 1/SOC 2 Report Review & CUEC Mapping
Reach a defensible reliance conclusion on a service organization's SOC 1/SOC 2 report. The workflow instance runs on an Audit item (audit_type: vendor_review) created for this vendor's SOC report period — enrich that item, never duplicate it; its native fields carry the report and reliance metadata (external_firm = CPA firm, opinion = service auditor's opinion, period_start/period_end = report coverage, report_date, rating = overall reliance verdict). Consumes the vendor risk handoff package from the Third-Party Vendor Risk Lifecycle workflow — the existing Vendor item, its tier, and the dependent Process items. In scope: report scope and type confirmation, the service auditor's opinion and exception analysis, complementary user entity control (CUEC) mapping, bridge/gap-period coverage, and the documented reliance decision — producing the SOC reliance memo and the reviewer-ready reliance package. Out of scope: the vendor's initial risk tiering and onboarding, and ongoing control monitoring. Hands the completed reliance package to the Continuous Controls Monitoring (ISCM) Cycle (and Third-Party ICT Vendor Regulatory Assurance) workflows.
workflow · Context
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
Incident Reporting Channels & Spillage Response
Standing operator workflow that runs on the existing Control item for the incident-reporting and information-spillage control (UC-IR-03; framework nist-800-53 | iso-27001 | nis2, domains incident_management_response) — one recurring workflow instance per operating cycle attaches to and enriches that Control item, never a duplicate. It consumes the prior cycle's carry-forward from the same Control: the last-sweep timestamp from the previous instance's close-and-archive record, plus the still-open corrective-action and obligation Issues linked to the Control. In scope: intake acknowledgment and triage routing across the monitored mailbox, hotline, and service portal; spillage containment/eradication and obligation assessment; and maintenance of the authorities and special-interest-group (SIG) contact register — spanning NIST 800-53 IR-6, IR-7, IR-9, and PM-15; ISO 27001 A.6.8, A.5.5, A.5.6; and NIS2 reporting duties. Named deliverables: the deduplicated intake register and acknowledgment log, the batch routing decision, the spill case with verified eradication, the obligation assessment and exposed-personnel training evidence, the refreshed authority/SIG contact register, the capability-health dashboard, the corrective-action register, and the archived operating record. Out of scope: full containment, investigation, and forensic response for genuine security events — those are handed off to the detect-to-respond workflow (via the route_to_incident_triage routing decision plus the linked intake Issues) rather than duplicated here.
workflow · Context
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
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
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
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
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
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 Design Assessment
Runs on the existing control item. Assess whether a control is clearly specified and designed to address its stated risk before deciding what follow-up or testing is appropriate. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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
Control Walkthrough
Runs on the existing control item. Walk one representative transaction or event through the control to understand actual execution, evidence, handoffs, and changes. 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
Audit Planning and Scoping
Runs on the existing audit item. Plan an audit engagement from four independent starting points — management self-identified issues, the external threat and regulatory landscape, prior audit history, and the in-scope risk and control set — which converge into the walkthrough question set, the walkthrough, and the approved risk and control matrix that governs fieldwork. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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
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
Annual Policy Review
Runs on the existing policy item. Canonical annual policy review: establish scope, obtain the policy owner and policy team sign-offs, record any required change path, and approve a documented review outcome and next review date. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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
Policy Change
Runs on the existing policy item. Canonical policy-change governance: scope and propose a controlled change, obtain policy-team approval, publish only the approved version, and close with a traceable document and communication record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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
Vendor Risk Assessment and Disposition
Runs on one existing System with vendor=true. Uses the supplier record, contracts, assurance/CUECs, access and continuity evidence to produce a reviewed vendor risk assessment and authorized disposition for the business/risk owner and readiness evidence consumers. Two checkpoints retain expert challenge and the owner’s choice of conditions, treatment and monitoring; executor work is recorded in step results and documents, with no collection forms or runtime branches.
workflow · Context
Interim Operating Effectiveness Testing
Runs on the existing SOX Audit using approved Control-hosted TOD/TOE results and the interim scope. Produces the program coverage and exception register, remaining-period commitments, all-controls auditor handoff and management status communications for year-end roll-forward.
workflow · Context
Period-End Roll-Forward Testing
Runs on the existing SOX Audit using approved interim results and remaining-period commitments. Produces independently reviewed year-end coverage, a separate Year-end Management Inquiry Package and the full-year conclusion for audit reporting and deficiency aggregation.
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
Data Governance Council Operations
Data Governance Council Operations as a decision-aware workflow. Each quarterly cycle runs as one workflow instance attached to the existing UC-GOV-20 Control item (data governance council oversight; domains=governance_policy_oversight, frequency=quarterly) — it enriches that Control as its execution record and never creates a governing body. It validates the chartered council's charter and membership, runs the annual policy and lifecycle-standards review when due, compiles data-quality and integrity metrics, reviews and approves data-sharing and matching agreements, convenes the council with recorded minutes, and reports data governance status at the defined interval. Upstream, it consumes the prior cycle's archived governance record — the council and data-integrity-board charters (Policy items, policy_type: charter) and membership rosters, the current data-governance policy and data-lifecycle standards library (Policy items), the prior minutes and status report, and the open action-item register (Issue items linked to the Control). Named deliverables: the data-quality and integrity dashboard, the data-management oversight summary, the chair-approved council (and integrity board) minutes, the per-agreement dispositions, and the data-governance status report; the annual branch adds the refreshed policy and standards redlines and the charter and roster amendments. In scope each quarterly cycle: the named business units and data domains, the data governance council (always), and the data integrity board wherever data-matching (Privacy Act computer matching) or new data-sharing requires its review; a metrics-only cycle need not convene the integrity board. Out of scope: bodies and data domains not named in the cycle's scope. Downstream the workflow is self-contained — no separate workflow depends on it — but it chains cycle to cycle: this cycle's archived governance record, filed with the status report, is the next quarterly instance's primary input.
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
Subservice Organization & Third-Party Personnel Oversight
Subservice Organization & Third-Party Personnel Oversight as a checkpoint graph. Anchor: each run enriches the existing subservice-organization **Vendor** register entry for one provider - the workflow instance and every step document attach to it, and it is never recreated (initial vendor selection and onboarding due diligence are out of scope). In scope: the subservice organizations and third-party suppliers whose services support user-entity control objectives or whose personnel access the organization's systems or data - reconciling and enriching their Vendor register entries, verifying subservice and personnel-security contract terms, reviewing assurance (SOC) reports and mapping complementary user-entity controls (CUECs) to internal Control items, routing exceptions to tracked Issue items, collecting third-party personnel-compliance evidence, monitoring vendor performance, and running the quarterly issue follow-up through to closure. Out of scope: initial vendor selection and onboarding due diligence, and the organization's own internal personnel controls. Upstream: no workflow feeds it - it is built from the existing Vendor register, the prior cycle's archived vendor file, open Issue items, and the internal Control inventory, plus contracts, SOC reports, and performance data uploaded as evidence. Downstream: self-contained - no single workflow consumes its output; the archived, auditor-ready vendor file is the durable evidence record. It runs on the annual per-vendor cycle with quarterly issue follow-up.
workflow · Context
Personnel Screening, Agreements & Sanctions Administration
Runs on the existing "Personnel Security Administration" Process item (process_type: security_process; process_owner: the HR Personnel Security Partner): each cycle is one workflow instance attached to that Process - enriching the standing process, never creating a duplicate - and on the disciplinary track the violation-case Issue it opens becomes the cycle's second anchor, linked back to that Process. A modular, decision-aware workflow: it designates position risk, runs proportional background verification for new hires, role changes, and the annual high-risk rescreen sweep, produces and retains the signed employment security and confidentiality agreements required before access, and - when a policy violation is reported - runs the graduated disciplinary process through sanction determination, PS-8 notification, and retention. It originates on its own HR triggers (no upstream workflow feeds it) and hands access provisioning and revocation to the downstream Joiner-Mover-Leaver Access Lifecycle workflow rather than performing them here. Named deliverables per cycle: the position-risk designation memo and derived screening set, the background-verification packet, the signed employment security and confidentiality agreements plus security-bearing position description, the violation-case Issue, the sanction documentation and PS-8 notification record, the awareness and control-improvement feedback Issues, and the archived cycle record. In scope: one personnel-security trigger per cycle - a single new hire, role change, annual high-risk rescreen, or material agreement re-signature on the screening-and-agreements track, or one reported policy violation on the disciplinary track; a role change that also surfaces a violation is run as two separate cycles.
workflow · Context
Vendor Due Diligence & Contracting Gate
Vendor Due Diligence & Contracting Gate as a modular, decision-aware workflow. Anchor: the vendor's register entry — the Vendor item (slug: vendor). For a net-new engagement the gate creates the Vendor item and populates its tier, data_classification, business_owner, and risk_owner; for a renewal it enriches the existing Vendor item rather than duplicating it (enrich, never recreate). This is the first-line pre-contract gate the vendor-management office runs for every new engagement or renewal - tiering criticality, running proportionate due diligence into the vendor due-diligence report, documenting the risk-acceptance decision and any risk-reducing sourcing conditions, binding the contract to required security, privacy, and regulatory clauses, authorizing the specific information exchange before access begins, and - where personal data is involved - obtaining the signed written privacy commitments and scheduling compliance monitoring and incident-response routing. In scope: pre-contract due diligence, risk acceptance, and contract execution for one vendor engagement, ending with the Vendor item enrolled in monitoring (Vendor.monitoring_status = enrolled). There is no upstream workflow — the engagement trigger (a new prospective vendor or a renewal) is its own entry point. Downstream handoff: the archived gate record exported at close is the handoff package the ongoing third-party risk monitoring / vendor oversight lifecycle picks up to sustain the scheduled compliance checks and incident routing; that linkage is a prose handoff of live controls on the same Vendor item, not a triggered downstream node.
workflow · Context
Third-Party Risk Program & Vendor Oversight Cycle
A standing quarterly cycle the vendor-management office runs as control owner. The workflow instance is a recurring run attached to the EXISTING Process item "Third-Party / Vendor Risk Management" (process_type: operational, process_owner: Vendor Risk Program Lead, frequency: quarterly), linked to the Control items for the unified controls it operates (UC-TPRM-01/04/05/08) — it enriches that standing program, never recreating it. It consumes no upstream workflow handoff: each run is self-feeding, drawing its criteria and prior state from the program's own standing artifacts — the SCRM plan, third-party risk policy, and program strategy held as Policy items; the criticality-tiered Vendor register (Vendor items); and the prior cycle instance's step documents (the DORA Article 28(3) register of information and the ICT concentration-risk view). In scope: reaffirming or revising the governing Policy items; re-tiering the Vendor register; refreshing the DORA Article 28(3) register of information and the concentration-risk view (a dashboard over the Vendor items); verifying critical-provider exit strategies; executing this cycle's tier-based reassessments and driving findings to tracked third-party Risk items (remediation or risk-committee escalation); confirming external and cloud service provider oversight; and verifying critical suppliers carry live incident-notification coverage. Named deliverables: the refreshed criticality-tiered Vendor register, the updated DORA Article 28(3) register of information, the recomputed ICT concentration-risk view, the exit-readiness summary, this cycle's tracked Risk items, and the archived cycle evidence package on the workflow instance. Terminal at close-and-archive with no downstream handoff — open or escalated vendor risks persist as Risk items in the risk register. Out of scope and handled by separate workflows: the continuous monitor-line vendor lifecycle and the per-engagement due-diligence gate for onboarding a new vendor.
workflow · Context
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
Vendor Offboarding & Secure Termination
Vendor Offboarding & Secure Termination as a decision-aware workflow triggered on a relationship termination. It runs on the vendor's existing Vendor register item - the offboarding enriches that record, it never creates a duplicate: the run marks the Vendor `monitoring_status: exited` and stamps `contract_end_date`, and where the vendor's risk is registered it links to the existing third-party Risk item (`category: third_party`). In scope: executing one vendor's contractual exit end to end - inventorying the vendor's access, data, and dedicated components; containing access immediately on for-cause exits; transitioning each service to its successor; revoking every credential; verifying data return or destruction; disposing of internal-side components using defined techniques; and retaining the post-relationship evidence. Out of scope: the underlying contract-termination or renewal business decision and any separately-governed affiliate contracts. Initial inputs are the termination trigger and effective date, the vendor's contractual exit provisions (master agreement, data processing addendum, exit plan) - which also carry the data-disposition and evidence-retention clauses consumed downstream - and the existing Vendor register item with its risk tier; there is no upstream workflow. The named deliverable is the retained, audit-standing termination evidence package assembled at compile-termination-evidence-and-retain; the workflow is terminal - close-and-archive exports the run and hands off nothing downstream.
workflow · Context
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
SOC Report, Subservice & CUEC Review
Runs on the existing system item. Evaluate a service-organization report, subservice coverage, exceptions, and complementary user-entity controls for a governed reliance decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
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
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
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
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
SOX Annual Planning & Risk Assessment
Runs on the existing audit item. Plan the annual SOX program through materiality, entity and account scoping, risk and control mapping, reliance strategy, calendar, and governance approval. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control Interim Testing Record
Runs on the existing control item. Test a defined interim-period population using a documented sampling and attribute plan, then record exceptions and a bounded conclusion. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Period-End Roll-Forward / Rollover Testing
Runs on the existing control item. Bridge an approved interim control test through period end by assessing change, remaining occurrences, incremental evidence, and unresolved exceptions. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOX Control Testing
Runs on an existing SOX-applicable Control under a sox-testing template. SAMPLE reviews history, attributes and reproducible selection; TEST reviews evidence, exceptions and the approved result artifact. Keep fiscal year on Workflow.customFields.sox.fiscalYear and hand the published result to the SOX program.
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
Process Walkthrough & Design Assessment
Runs on the existing process item. Perform a SOX process walkthrough, update the ICFR narrative and control mapping, and document design observations for management follow-up. 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
Year-End Planning & Roll-Forward
Runs on the existing audit item. Plan and govern SOX year-end and roll-forward coverage based on interim results, changes, deficiencies, remaining populations, and reporting deadlines. 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 IPE Validation
SOX IPE Validation as a modular, decision-aware workflow that runs on — and enriches — the existing relying Control item (a key control, framework⊇sox) whose evidence depends on an Information Produced by the Entity (IPE) report: the report's identity, test history, and C&A test date are recorded onto that control rather than into a separate record. In scope: the completeness-and-accuracy conclusion for one IPE report for one period. It consumes its starting key-control population from the upstream SOX scoping / RCM build — the Control library with its Control ↔ Risk links. Its named deliverables are a reperformable completeness-and-accuracy (C&A) memo attached to the control and a validated-IPE evidence-and-decision package. Out of scope: testing the relying control's own operation — that belongs to the downstream SOX Key Control TOD/TOE Test, which anchors on the control's fiscal-year Control-hosted SOX testing workflow and cites this workflow's C&A package instead of re-validating. It can stand alone, but hands its validated-IPE package to SOX Key Control TOD/TOE Test instead of duplicating repeated 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.