Compliance, Audit & Assurance
801 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
A003 — Limit AI agent data access
Limit AI agent data access
control · Context
A004 — Protect IP & trade secrets
Protect IP & trade secrets
control · Context
A005 — Prevent cross-customer data exposure
Prevent cross-customer data exposure
control · Context
A007 — Prevent IP violations
Prevent IP violations
control · Context
B007 — Enforce user access privileges to AI systems
Enforce user access privileges to AI systems
control · Context
B009 — Limit output over-exposure
Limit output over-exposure
control · Context
C001 — Define AI risk taxonomy
Define AI risk taxonomy
control · Context
C002 — Conduct pre-deployment testing
Conduct pre-deployment testing
control · Context
C003 — Prevent harmful outputs
Prevent harmful outputs
control · Context
C004 — Prevent out-of-scope outputs
Prevent out-of-scope outputs
control · Context
C005 — Prevent agent-specific high risk outputs
Prevent agent-specific high risk outputs
control · Context
C006 — Prevent output vulnerabilities
Prevent output vulnerabilities
control · Context
C007 — Flag high risk outputs for human review
Flag high risk outputs for human review
control · Context
C008 — Monitor AI risk categories
Monitor AI risk categories
control · Context
C009 — Enable real-time feedback and intervention
Enable real-time feedback and intervention
control · Context
D001 — Prevent hallucinated outputs
Prevent hallucinated outputs
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.100 — Notice at collection and consumer right to know
Notice at collection and consumer right to know
control · Context
CCPA-1798.105 — Right to delete personal information
Right to delete personal information
control · Context
CCPA-1798.106 — Right to correct inaccurate personal information
Right to correct inaccurate personal information
control · Context
CCPA-1798.110-115 — Rights to access and disclosure of personal information collected, sold, or shared
Rights to access and disclosure of personal information collected, sold, or shared
control · Context
CCPA-1798.120-121 — Right to opt out of sale/sharing and to limit use of sensitive personal information
Right to opt out of sale/sharing and to limit use of sensitive personal information
control · Context
CCPA-1798.125 — Non-discrimination and financial-incentive requirements
Non-discrimination and financial-incentive requirements
control · Context
CCPA-1798.130-135 — Request-handling mechanics, verification, and opt-out link requirements
Request-handling mechanics, verification, and opt-out link requirements
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
APO06 — Managed Budget and Costs
Managed Budget and Costs
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
APO14 — Managed Data
Managed Data
control · Context
DSS06 — Managed Business Process Controls
Managed Business Process Controls
control · Context
EDM01 — Ensured Governance Framework Setting and Maintenance
Ensured Governance Framework Setting and Maintenance
control · Context
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
E13 — Implements Risk Responses
Implements Risk Responses
control · Context
E15 — Assesses Substantial Change
Assesses Substantial Change
control · Context
E18 — Leverages Information and Technology
Leverages Information and Technology
control · Context
E19 — Communicates Risk Information
Communicates Risk Information
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
E7 — Defines Risk Appetite
Defines Risk Appetite
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
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
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
GDPR-Art12-14 — Transparency and information to data subjects
Transparency and information to data subjects
control · Context
GDPR-Art15-22 — Data subject rights (access, rectification, erasure, portability, objection, automated decisions)
Data subject rights (access, rectification, erasure, portability, objection, automated decisions)
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-Art32 — Security of processing
Security of processing
control · Context
GDPR-Art34 — Communication of a breach to the data subject
Communication of a breach to the data subject
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-Art44-49 — International transfers of personal data
International transfers of personal data
control · Context
GDPR-Art5 — Principles relating to processing of personal data
Principles relating to processing of personal data
control · Context
GDPR-Art6 — Lawfulness of processing
Lawfulness of processing
control · Context
GDPR-Art7 — Conditions for consent
Conditions for consent
control · Context
GDPR-Art9 — Processing of special categories of data
Processing of special categories of data
control · Context
HIPAA-164.312(a) — Technical access control for ePHI (unique user ID, emergency access, automatic logoff, encryption/decryption)
Technical access control for ePHI (unique user ID, emergency access, automatic logoff, encryption/decryption)
control · Context
HIPAA-164.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
HIPAA-164.400-414 — Breach notification to individuals, media, and HHS (incl. business-associate duties)
Breach notification to individuals, media, and HHS (incl. business-associate duties)
control · Context
HIPAA-164.502 — Uses and disclosures of PHI (permitted/required uses, minimum necessary)
Uses and disclosures of PHI (permitted/required uses, minimum necessary)
control · Context
HIPAA-164.508 — Authorizations required for other uses and disclosures of PHI
Authorizations required for other uses and disclosures of PHI
control · Context
HIPAA-164.520 — Notice of privacy practices for PHI
Notice of privacy practices for PHI
control · Context
HIPAA-164.524 — Individual right of access to PHI
Individual right of access to PHI
control · Context
HIPAA-164.526 — Individual right to amend PHI
Individual right to amend PHI
control · Context
Principle 1 — Demonstrate Integrity
Demonstrate Integrity
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 14 — Conduct Engagement Work
Conduct Engagement Work
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 4 — Exercise Due Professional Care
Exercise Due Professional Care
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 1.1 — Honesty and Professional Courage
Honesty and Professional Courage
control · Context
Std 1.2 — Organization's Ethical Expectations
Organization's Ethical Expectations
control · Context
Std 1.3 — Legal and Ethical Behavior
Legal and Ethical Behavior
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.1 — Gathering Information for Analyses and Evaluation
Gathering Information for Analyses and Evaluation
control · Context
Std 14.2 — Analyses and Potential Engagement Findings
Analyses and Potential Engagement Findings
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 4.1 — Conformance with the Global Internal Audit Standards
Conformance with the Global Internal Audit Standards
control · Context
Std 4.2 — Due Professional Care
Due Professional Care
control · Context
Std 4.3 — Professional Skepticism
Professional Skepticism
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-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-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.10 — Acceptable use of information and other associated assets
Acceptable use of information and other associated assets
control · Context
A.5.12 — Classification of information
Classification of information
control · Context
A.5.13 — Labelling of information
Labelling of information
control · Context
A.5.14 — Information transfer
Information transfer
control · Context
A.5.15 — Access control
Access control
control · Context
A.5.18 — Access rights
Access rights
control · Context
A.5.19 — Information security in supplier relationships
Information security in supplier relationships
control · Context
A.5.22 — Monitoring, review and change management of supplier services
Monitoring, review and change management of supplier services
control · Context
A.5.24 — Information security incident management planning and preparation
Information security incident management planning and preparation
control · Context
A.5.25 — Assessment and decision on information security events
Assessment and decision on information security events
control · Context
A.5.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.33 — Protection of records
Protection of records
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.9 — Inventory of information and other associated assets
Inventory of information and other associated assets
control · Context
A.6.8 — Information security event reporting
Information security event reporting
control · Context
A.7.9 — Security of assets off-premises
Security of assets off-premises
control · Context
A.8.1 — User endpoint devices
User endpoint devices
control · Context
A.8.10 — Information deletion
Information deletion
control · Context
A.8.12 — Data leakage prevention
Data leakage prevention
control · Context
A.8.18 — Use of privileged utility programs
Use of privileged utility programs
control · Context
A.8.19 — Installation of software on operational systems
Installation of software on operational systems
control · Context
A.8.2 — Privileged access rights
Privileged access rights
control · Context
A.8.3 — Information access restriction
Information access restriction
control · Context
A.8.4 — Access to source code
Access to source code
control · Context
31000-P2 — Structured and comprehensive
Structured and comprehensive
control · Context
31000-P5 — Dynamic
Dynamic
control · Context
31000-P6 — Best available information
Best available information
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-PR6 — Risk treatment
Risk treatment
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.4 — AI system verification and validation
AI system verification and validation
control · Context
A.6.2.5 — AI system deployment
AI system deployment
control · Context
A.6.2.6 — AI system operation and monitoring
AI system operation and monitoring
control · Context
A.6.2.7 — AI system technical documentation
AI system technical documentation
control · Context
A.6.2.8 — AI system recording of event logs
AI system recording of event logs
control · Context
A.7.2 — Data for development and enhancement of AI systems
Data for development and enhancement of AI systems
control · Context
A.7.3 — Acquisition of data
Acquisition of data
control · Context
A.7.4 — Data quality for AI systems
Data quality for AI systems
control · Context
A.7.5 — Data provenance
Data provenance
control · Context
A.7.6 — Data preparation
Data preparation
control · Context
A.8.2 — System documentation and information for users
System documentation and information for users
control · Context
A.8.3 — External reporting
External reporting
control · Context
A.8.4 — Communication of incidents
Communication of incidents
control · Context
A.8.5 — Information for interested parties
Information for interested parties
control · Context
A.9.2 — Processes for responsible use of AI systems
Processes for responsible use of AI systems
control · Context
A.9.3 — Objectives for responsible use of AI systems
Objectives for responsible use of AI systems
control · Context
A.9.4 — Intended use of the AI system
Intended use of the AI system
control · Context
NIS2-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-Art21d — Supply chain security
Supply chain security
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-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-16 — Security and Privacy Attributes
Security and Privacy Attributes
control · Context
AC-20 — Use of External Systems
Use of External Systems
control · Context
AC-24 — Access Control Decisions
Access Control Decisions
control · Context
AC-25 — Reference Monitor
Reference Monitor
control · Context
AC-3 — Access Enforcement
Access Enforcement
control · Context
AC-4 — Information Flow Enforcement
Information Flow Enforcement
control · Context
AC-5 — Separation of Duties
Separation of Duties
control · Context
AC-6 — Least Privilege
Least Privilege
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-6 — Authorization
Authorization
control · Context
CA-9 — Internal System Connections
Internal System Connections
control · Context
CM-10 — Software Usage Restrictions
Software Usage Restrictions
control · Context
CM-11 — User-installed Software
User-installed Software
control · Context
CM-14 — Signed Components
Signed Components
control · Context
CM-8 — System Component Inventory
System Component Inventory
control · Context
IR-6 — Incident Reporting
Incident Reporting
control · Context
IR-7 — Incident Response Assistance
Incident Response Assistance
control · Context
IR-8 — Incident Response Plan
Incident Response Plan
control · Context
IR-9 — Information Spillage Response
Information Spillage Response
control · Context
MP-1 — Policy and Procedures
Policy and Procedures
control · Context
MP-3 — Media Marking
Media Marking
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-9 — Central Management
Central Management
control · Context
PM-10 — Authorization Process
Authorization Process
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-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-32 — Purposing
Purposing
control · Context
PM-5 — System Inventory
System Inventory
control · Context
PM-6 — Measures of Performance
Measures of Performance
control · Context
PM-9 — Risk Management Strategy
Risk Management Strategy
control · Context
PT-1 — Policy and Procedures
Policy and Procedures
control · Context
PT-2 — Authority to Process Personally Identifiable Information
Authority to Process Personally Identifiable Information
control · Context
PT-3 — Personally Identifiable Information Processing Purposes
Personally Identifiable Information Processing Purposes
control · Context
PT-4 — Consent
Consent
control · Context
PT-5 — Privacy Notice
Privacy Notice
control · Context
PT-6 — System of Records Notice
System of Records Notice
control · Context
PT-7 — Specific Categories of Personally Identifiable Information
Specific Categories of Personally Identifiable Information
control · Context
PT-8 — Computer Matching Requirements
Computer Matching Requirements
control · Context
RA-1 — Policy and Procedures
Policy and Procedures
control · Context
RA-7 — Risk Response
Risk Response
control · Context
RA-8 — Privacy Impact Assessments
Privacy Impact Assessments
control · Context
SA-4 — Acquisition Process
Acquisition Process
control · Context
SI-12 — Information Management and Retention
Information Management and Retention
control · Context
SI-18 — Personally Identifiable Information Quality Operations
Personally Identifiable Information Quality Operations
control · Context
SR-1 — Policy and Procedures
Policy and Procedures
control · Context
SR-2 — Supply Chain Risk Management Plan
Supply Chain Risk Management Plan
control · Context
SR-3 — Supply Chain Controls and Processes
Supply Chain Controls and Processes
control · Context
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
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-07 — Prompt provenance and data-flow tracking
The proposed project explores tracking the provenance of user prompts and input data so that risk assessments and policies can take those sources into account when deciding whether an agent may act.
control · Context
NIST-TEVV-01 — Define evaluation objectives, context, and measurements
The framework starts with organizational goals and the system's operational context, then constructs measurement concepts, test events, and tools that address those objectives.
control · Context
NIST-TEVV-02 — Run evaluations and examine results and limitations
The framework applies the selected tests and synthesizes their results into evidence about system performance, while interrogating the measurements and what the findings support.
control · Context
NIST-TEVV-03 — Evaluate AI systems in realistic operating settings
The draft discusses testing in settings that better reflect real use, including interactions with users and the operating environment, to complement model tests and benchmarks.
control · Context
NIST-TEVV-04 — Test for disclosure of confidential information
Appendix B includes confidentiality attacks that test whether an AI system reveals confidential information or internal functionality, including user information and system-prompt leakage.
control · Context
DE.AE-04 — Adverse Event Analysis: The estimated impact and scope of adverse events are understood
Adverse Event Analysis: The estimated impact and scope of adverse events are understood
control · Context
GV.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.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-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-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-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-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
ID.AM-01 — Asset Management: Inventories of hardware managed by the organization are maintained
Asset Management: Inventories of hardware managed by the organization are maintained
control · Context
ID.AM-02 — Asset Management: Inventories of software, services, and systems managed by the organization are maintained
Asset Management: Inventories of software, services, and systems managed by the organization are maintained
control · Context
ID.AM-05 — Asset Management: Assets are prioritized based on classification, criticality, resources, and impact on the mission
Asset Management: Assets are prioritized based on classification, criticality, resources, and impact on the mission
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-06 — Risk Assessment: Risk responses are chosen, prioritized, planned, tracked, and communicated
Risk Assessment: Risk responses are chosen, prioritized, planned, tracked, and communicated
control · Context
ID.RA-09 — Risk Assessment: The authenticity and integrity of hardware and software are assessed prior to acquisition and use
Risk Assessment: The authenticity and integrity of hardware and software are assessed prior to acquisition and use
control · Context
PR.AA-05 — Identity Management, Authentication, and Access Control: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
Identity Management, Authentication, and Access Control: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
control · Context
PR.PS-05 — Platform Security: Installation and execution of unauthorized software are prevented
Platform Security: Installation and execution of unauthorized software are prevented
control · Context
RS.AN-08 — Incident Analysis: An incident's magnitude is estimated and validated
Incident Analysis: An incident's magnitude is estimated and validated
control · Context
RS.CO-02 — Incident Response Reporting and Communication: Internal and external stakeholders are notified of incidents
Incident Response Reporting and Communication: Internal and external stakeholders are notified of incidents
control · Context
RS.CO-03 — Incident Response Reporting and Communication: Information is shared with designated internal and external stakeholders
Incident Response Reporting and Communication: Information is shared with designated internal and external stakeholders
control · Context
RS.MA-02 — Incident Management: Incident reports are triaged and validated
Incident Management: Incident reports are triaged and validated
control · Context
RS.MA-03 — Incident Management: Incidents are categorized and prioritized
Incident Management: Incidents are categorized and prioritized
control · Context
RS.MA-04 — Incident Management: Incidents are escalated or elevated as needed
Incident Management: Incidents are escalated or elevated as needed
control · Context
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.3 — Cybersecurity policy
Cybersecurity policy
control · Context
500.4 — Chief Information Security Officer (CISO)
Chief Information Security Officer (CISO)
control · Context
500.7 — Access privileges and management
Access privileges and management
control · Context
PCI-Req12 — Support information security with organizational policies and programs
Support information security with organizational policies and programs
control · Context
PCI-Req7 — Restrict access to system components and cardholder data by business need to know
Restrict access to system components and cardholder data by business need to know
control · Context
SOC1-12 — Vendor / subservice organization management — controls provide reasonable assurance that subservice organizations relevant to user entities' ICFR are appropriately managed and monitored.
Vendor / subservice organization management — controls provide reasonable assurance that subservice organizations relevant to user entities' ICFR are appropriately managed and monitored.
control · Context
SOC1-6 — Data transmission / interface controls — controls provide reasonable assurance that data transmitted to and from the system and across interfaces is complete, accurate, authorized, and timely.
Data transmission / interface controls — controls provide reasonable assurance that data transmitted to and from the system and across interfaces is complete, accurate, authorized, and timely.
control · Context
SOC1-7 — Data input — controls provide reasonable assurance that transactions and data input into the system are complete, accurate, and authorized.
Data input — controls provide reasonable assurance that transactions and data input into the system are complete, accurate, and authorized.
control · Context
SOC1-8 — Data processing — controls provide reasonable assurance that transactions are processed completely, accurately, and in the proper period.
Data processing — controls provide reasonable assurance that transactions are processed completely, accurately, and in the proper period.
control · Context
SOC1-9 — Data output / reporting — controls provide reasonable assurance that output and reports provided to user entities are complete, accurate, and distributed only to authorized recipients.
Data output / reporting — controls provide reasonable assurance that output and reports provided to user entities are complete, accurate, and distributed only to authorized recipients.
control · Context
C1.1 — The entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality.
The entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality.
control · Context
C1.2 — The entity disposes of confidential information to meet the entity's objectives related to confidentiality.
The entity disposes of confidential information to meet the entity's objectives related to confidentiality.
control · Context
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.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.1 — The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.
The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.
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.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
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
CC6.1 — The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
control · Context
CC6.3 — The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity's objectives.
The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity's objectives.
control · Context
CC6.8 — The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity's objectives.
The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity's objectives.
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
P1.1 — The entity provides notice to data subjects about its privacy practices to meet the entity's objectives related to privacy. The notice is updated and communicated to data subjects in a timely manner for changes to the entity's privacy practices, including changes in the use of personal information, to meet the entity's objectives related to privacy.
The entity provides notice to data subjects about its privacy practices to meet the entity's objectives related to privacy. The notice is updated and communicated to data subjects in a timely manner for changes to the entity's privacy practices, including changes in the use of personal information, to meet the entity's objectives related to privacy.
control · Context
P2.1 — The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information to the data subjects and the consequences, if any, of each choice. Explicit consent for the collection, use, retention, disclosure, and disposal of personal information is obtained from data subjects or other authorized persons, if required. Such consent is obtained only for the intended purpose of the information to meet the entity's objectives related to privacy. The entity's basis for determining implicit consent for the collection, use, retention, disclosure, and disposal of personal information is documented.
The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information to the data subjects and the consequences, if any, of each choice. Explicit consent for the collection, use, retention, disclosure, and disposal of personal information is obtained from data subjects or other authorized persons, if required. Such consent is obtained only for the intended purpose of the information to meet the entity's objectives related to privacy. The entity's basis for determining implicit consent for the collection, use, retention, disclosure, and disposal of personal information is documented.
control · Context
P3.1 — Personal information is collected consistent with the entity's objectives related to privacy.
Personal information is collected consistent with the entity's objectives related to privacy.
control · Context
P3.2 — For information requiring explicit consent, the entity communicates the need for such consent, as well as the consequences of a failure to provide consent for the request for personal information, and obtains the consent prior to the collection of the information to meet the entity's objectives related to privacy.
For information requiring explicit consent, the entity communicates the need for such consent, as well as the consequences of a failure to provide consent for the request for personal information, and obtains the consent prior to the collection of the information to meet the entity's objectives related to privacy.
control · Context
P4.1 — The entity limits the use of personal information to the purposes identified in the entity's objectives related to privacy.
The entity limits the use of personal information to the purposes identified in the entity's objectives related to privacy.
control · Context
P4.2 — The entity retains personal information consistent with the entity's objectives related to privacy.
The entity retains personal information consistent with the entity's objectives related to privacy.
control · Context
P4.3 — The entity securely disposes of personal information to meet the entity's objectives related to privacy.
The entity securely disposes of personal information to meet the entity's objectives related to privacy.
control · Context
P5.1 — The entity grants identified and authenticated data subjects the ability to access their stored personal information for review and, upon request, provides physical or electronic copies of that information to data subjects to meet the entity's objectives related to privacy. If access is denied, data subjects are informed of the denial and reason for such denial, as required, to meet the entity's objectives related to privacy.
The entity grants identified and authenticated data subjects the ability to access their stored personal information for review and, upon request, provides physical or electronic copies of that information to data subjects to meet the entity's objectives related to privacy. If access is denied, data subjects are informed of the denial and reason for such denial, as required, to meet the entity's objectives related to privacy.
control · Context
P5.2 — The entity corrects, amends, or appends personal information based on information provided by data subjects and communicates such information to third parties, as committed or required, to meet the entity's objectives related to privacy. If a request for correction is denied, data subjects are informed of the denial and reason for such denial to meet the entity's objectives related to privacy.
The entity corrects, amends, or appends personal information based on information provided by data subjects and communicates such information to third parties, as committed or required, to meet the entity's objectives related to privacy. If a request for correction is denied, data subjects are informed of the denial and reason for such denial to meet the entity's objectives related to privacy.
control · Context
P6.1 — The entity discloses personal information to third parties with the explicit consent of data subjects, and such consent is obtained prior to disclosure to meet the entity's objectives related to privacy.
The entity discloses personal information to third parties with the explicit consent of data subjects, and such consent is obtained prior to disclosure to meet the entity's objectives related to privacy.
control · Context
P6.2 — The entity creates and retains a complete, accurate, and timely record of authorized disclosures of personal information to meet the entity's objectives related to privacy.
The entity creates and retains a complete, accurate, and timely record of authorized disclosures of personal information to meet the entity's objectives related to privacy.
control · Context
P6.3 — The entity creates and retains a complete, accurate, and timely record of detected or reported unauthorized disclosures (including breaches) of personal information to meet the entity's objectives related to privacy.
The entity creates and retains a complete, accurate, and timely record of detected or reported unauthorized disclosures (including breaches) of personal information to meet the entity's objectives related to privacy.
control · Context
P6.4 — The entity obtains privacy commitments from vendors and other third parties who have access to personal information to meet the entity's objectives related to privacy. The entity assesses those parties' compliance on a periodic and as-needed basis and takes corrective action, if necessary.
The entity obtains privacy commitments from vendors and other third parties who have access to personal information to meet the entity's objectives related to privacy. The entity assesses those parties' compliance on a periodic and as-needed basis and takes corrective action, if necessary.
control · Context
P6.5 — The entity obtains commitments from vendors and other third parties with access to personal information to notify the entity in the event of actual or suspected unauthorized disclosures of personal information. Such notifications are reported to appropriate personnel and acted on in accordance with established incident response procedures to meet the entity's objectives related to privacy.
The entity obtains commitments from vendors and other third parties with access to personal information to notify the entity in the event of actual or suspected unauthorized disclosures of personal information. Such notifications are reported to appropriate personnel and acted on in accordance with established incident response procedures to meet the entity's objectives related to privacy.
control · Context
P6.6 — The entity provides notification of breaches and incidents to affected data subjects, regulators, and others to meet the entity's objectives related to privacy.
The entity provides notification of breaches and incidents to affected data subjects, regulators, and others to meet the entity's objectives related to privacy.
control · Context
P6.7 — The entity provides data subjects with an accounting of the personal information held and disclosure of the data subjects' personal information, upon the data subjects' request, to meet the entity's objectives related to privacy.
The entity provides data subjects with an accounting of the personal information held and disclosure of the data subjects' personal information, upon the data subjects' request, to meet the entity's objectives related to privacy.
control · Context
P7.1 — The entity collects and maintains accurate, up-to-date, complete, and relevant personal information to meet the entity's objectives related to privacy.
The entity collects and maintains accurate, up-to-date, complete, and relevant personal information to meet the entity's objectives related to privacy.
control · Context
P8.1 — The entity implements a process for receiving, addressing, resolving, and communicating the resolution of inquiries, complaints, and disputes from data subjects and others and periodically monitors compliance to meet the entity's objectives related to privacy. Corrections and other necessary actions related to identified deficiencies are made or taken in a timely manner.
The entity implements a process for receiving, addressing, resolving, and communicating the resolution of inquiries, complaints, and disputes from data subjects and others and periodically monitors compliance to meet the entity's objectives related to privacy. Corrections and other necessary actions related to identified deficiencies are made or taken in a timely manner.
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.2 — The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity's objectives.
The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting to meet the entity's objectives.
control · Context
PI1.4 — The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity's objectives.
The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity's objectives.
control · Context
PI1.5 — The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity's objectives.
The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet the entity's objectives.
control · Context
ELC-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-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-PERFR — Period-End Financial Reporting Process — controls over the close process, consolidation, journal entries, estimates, and preparation of financial statements and disclosures.
Period-End Financial Reporting Process — controls over the close process, consolidation, journal entries, estimates, and preparation of financial statements and disclosures.
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-INPUT — Input controls — edit/validation checks, completeness checks, and field/format controls that ensure data entered into systems is complete, accurate, and valid.
Input controls — edit/validation checks, completeness checks, and field/format controls that ensure data entered into systems is complete, accurate, and valid.
control · Context
PLC-INTF — Interface controls — controls ensuring data transferred between systems and across interfaces is complete, accurate, and processed only once (reconciliation of record counts/control totals, error handling).
Interface controls — controls ensuring data transferred between systems and across interfaces is complete, accurate, and processed only once (reconciliation of record counts/control totals, error handling).
control · Context
PLC-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-MRC — Management review controls — reviews of financial information, account analyses, budget-to-actual variances, estimates, and reconciliations performed at an appropriate level of precision with documented investigation and resolution of items.
Management review controls — reviews of financial information, account analyses, budget-to-actual variances, estimates, and reconciliations performed at an appropriate level of precision with documented investigation and resolution of items.
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
Harmful AI bias and discrimination against protected groups
Models encode/amplify historical bias, producing allocative harm (biased hiring/lending/housing/benefits), representational harm (stereotyping), and evaluation bias masking disparate subgroup performance — systematically disadvantaging protected groups.
risk · Direct
GPAI transparency, systemic-risk and synthetic-content obligations
GPAI providers failing transparency/copyright/training-data obligations; systemic-risk models (>10^25 FLOPs) lacking red-teaming, incident reporting, and cybersecurity; unlabeled deepfake/synthetic content; and concentration of GPAI capability creating ecosystem single points of failure.
risk · Direct
Rights harm from biometric-identification AI
Because remote biometric identification, categorization, or emotion-recognition systems (EU AI Act Annex III(1)) are deployed without conformity assessment, data governance, human oversight, accuracy/robustness controls, or a fundamental-rights impact assessment, they can misidentify, misclassify, or surveil individuals, resulting in wrongful treatment, discrimination, and rights violations.
risk · Direct
Public-safety harm from AI in critical infrastructure
Because AI acting as a safety component in critical digital infrastructure, road traffic, or utilities (Annex III(2)) operates without the required risk management, robustness, and human oversight, it can fail or behave unsafely, resulting in service disruption and threats to public safety and continuity.
risk · Direct
Unfair exclusion by AI in education and training
Because AI determining access, admission, assessment, or proctoring in education and vocational training (Annex III(3)) operates without bias controls, transparency, human oversight, or fundamental-rights safeguards, learners can be scored or excluded unfairly, resulting in denial of educational opportunity and discrimination.
risk · Direct
Discriminatory outcomes from AI in employment
Because AI used for recruitment, selection, promotion, task allocation, or worker monitoring (Annex III(4)) operates without bias mitigation, worker transparency, human oversight, or a data-protection impact assessment, it can decide about workers on biased or opaque grounds, resulting in discriminatory or unfair employment outcomes.
risk · Direct
Unlawful denial of essential services by AI
Because AI evaluating eligibility for public benefits, creditworthiness, or insurance risk and pricing (Annex III(5)) operates without fairness, explainability, human oversight, or the required conformity controls, it can wrongly deny or misprice essential services, resulting in unlawful exclusion and consumer harm.
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
Rights violations from AI in law enforcement
Because AI for individual risk assessment, evidence evaluation, profiling, or predictive policing (Annex III(6)) operates without strict accuracy, human oversight, logging, and fundamental-rights safeguards, it can drive wrongful enforcement action, resulting in unjust detention, profiling harm, and rights violations.
risk · Direct
Wrongful denial by AI in migration and border control
Because AI for migration, asylum, or visa risk assessment and border-control screening (Annex III(7)) operates without the required accuracy, human oversight, and fundamental-rights protections, it can misjudge individuals, resulting in wrongful denial of entry or status and discrimination.
risk · Direct
Deployment of prohibited AI practices (EU AI Act Art.5)
Use of prohibited AI: subliminal/manipulative techniques, social scoring, untargeted facial-image scraping, real-time/post remote biometric identification for law enforcement, sensitive-attribute biometric categorization, and emotion recognition in work/education settings.
risk · Direct
Client suitability, disclosure and fiduciary breaches
Recommending unsuitable products, failing to disclose conflicts of interest, breaching fiduciary duty, KYC failures, inadequate disclosure of fees/risks, negligent advisory activities, and product flaws causing systematic customer harm.
risk · Direct
Environmental regulatory non-compliance
Unauthorized emissions or discharges, improper hazardous-waste handling, missing permits, or non-compliance with PFAS/chemical-reporting rules under EPA/RCRA/Clean Air & Water Acts — driving penalties and remediation.
risk · Direct
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
Intellectual property loss or infringement
Patent, trade-secret, copyright, or trademark infringement claims (competitors or NPEs), loss of key IP through invalidity rulings, inadequate protection of proprietary technology, or inability to enforce own IP against infringers.
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
Adverse regulatory or policy change
Changes in law, regulation, tax policy, or government programs materially alter the entity’s cost structure, competitive dynamics, or permissible business practices, requiring costly adaptation.
risk · Direct
Sector regulatory non-compliance (financial, healthcare, trade)
Non-compliance with sector regimes — banking prudential rules, consumer-lending laws, payment-network rules, healthcare (FDA/HIPAA/CMS, Anti-Kickback/Stark, False Claims), export controls (EAR/ITAR), antitrust, and environmental/labor rules — triggering fines, sanctions, or loss of license.
risk · Direct
Client selection, sponsorship and exposure-limit breaches
Failure to investigate clients per guidelines, exceeding single-counterparty exposure limits without approval, and sponsoring transactions without adequate counterparty-risk assessment or AML/CTF screening.
risk · Direct
Privacy-program non-compliance (GDPR, CCPA, state laws)
Failure to honour data-subject rights (access, deletion, portability, restriction) on time, missing lawful-basis/consent documentation, defective consent mechanisms, invalid cross-border transfer mechanisms, or inadequate notices — driving fines and private rights of action.
risk · Direct
Unlawful retention or premature deletion of records
Retaining personal data beyond necessity/mandated schedules (privacy and breach risk) or deleting records before required retention periods (litigation-hold, regulatory, tax risk); records-management policy not enforced technically.
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
Social and human-rights failures in operations and supply chain
Failure to respect human rights — forced or child labour, discrimination, unsafe conditions — in operations and supply chains, resulting in legal liability, boycotts, and ESG rating downgrades.
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
Data-quality and IPE integrity failures in reporting
Poor data lineage, inconsistent master-data definitions, or uncontrolled data transformation (weak IPE completeness/accuracy) cause management decisions and regulatory reports to rest on inaccurate or incomplete data.
risk · Direct
Financial-statement fraud and management override
Intentional misstatement through fictitious revenue, phantom inventory/assets, ghost-employee payroll, or management override of controls — inflating results and deceiving investors and regulators.
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
Presentation and disclosure deficiencies
Debt misclassified as long-term, gross/net revenue errors, operating/non-operating misclassification, faulty segment reporting, undisclosed related-party transactions, unstated accounting-policy changes, going-concern and contingent-liability disclosure failures.
risk · Direct
Revenue-recognition misstatement (fictitious, mis-timed, mis-measured)
Fictitious or channel-stuffed revenue, revenue not recorded for delivered goods, incorrect transaction-price allocation or percentage-of-completion, and principal-vs-agent gross/net errors — the highest-risk assertion cluster in the revenue cycle.
risk · Direct
Segregation-of-duties conflicts in financial processes
Incompatible duties (initiate, approve, record, and custody) concentrated in one role or via broad system access enable unauthorized or fraudulent transactions to be recorded and concealed.
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
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
Employment-practice and labor-law violations
Wrongful termination, wage-and-hour and overtime violations, benefit disputes, worker misclassification, whistleblower-protection breaches, and labor grievances/strike action causing litigation and operational loss.
risk · Direct
Failure to detect, assess, and notify breaches on time
Failure to detect, assess, and notify affected individuals and regulators of personal-data breaches within required timeframes and content (GDPR Art.33/34, HIPAA breach rule), resulting in sanctions and compounded individual harm.
risk · Direct
Negligent advisory activities and breach of duty of care
Losses from disputes over M&A, structuring, financial-planning, or hedging advice where the firm has a duty of care — including failure to advise clients of material risks in recommended transactions.
risk · Direct
Failed or inaccurate mandatory regulatory reporting
Late or inaccurate regulatory transaction reporting, missed regulatory-return deadlines, inaccurate risk reporting to management, and errors in suspicious-activity reporting — breaching disclosure obligations to regulators and stakeholders.
risk · Direct
Cross-border personal-data transfer without safeguards
Transferring personal data to jurisdictions lacking equivalent protection without SCCs, BCRs, adequacy decisions, or other recognized mechanisms, exposing individuals and the organization to legal risk.
risk · Direct
Securities-law and SEC-reporting non-compliance
Public-company reporting failures: late or restated SEC filings, disclosure-control deficiencies, and securities-fraud exposure distinct from the underlying ICFR weakness — triggering enforcement and delisting risk.
risk · Direct
Illegal processing of personal or sensitive data
Processing personal or sensitive data without legal authority, consent, or in violation of regulatory requirements — a data-protection breach with legal, privacy, and reputational consequences.
risk · Direct
Use of unlicensed, counterfeit or pirated software
Fraudulent copying of software and deployment of pirated/counterfeit software (unlicensed or inadequately controlled) that may lack security patches or contain malicious code — a legal and security exposure.
risk · Direct
Third-party compliance failure creating vicarious liability
A vendor, subcontractor, or channel partner violates labor, environmental, anti-bribery (FCPA/UKBA), or data-protection rules, exposing the company to liability and reputational harm; fourth-party/N-tier dependencies are opaque.
standard · Context
AIUC-1 (Jul 2026)
AIUC-1 — AI agent security, safety and reliability standard (requirement level)
standard · Context
CCPA/CPRA
CCPA/CPRA — California Consumer Privacy
standard · Context
COBIT 2019
COBIT 2019 Governance & Management Objectives
standard · Context
COSO ERM 2017
COSO ERM – Integrating with Strategy and Performance (2017)
standard · Context
COSO IC 2013
COSO Internal Control – Integrated Framework (2013)
standard · Context
EU DORA
EU DORA — Digital Operational Resilience Act
standard · Context
EU AI Act
EU AI Act — principal obligation areas (Chapters II, III, V and IX)
standard · Context
EU GDPR
EU GDPR — General Data Protection Regulation
standard · Context
HIPAA
HIPAA — Security, Privacy & Breach Notification
standard · Context
IIA 2024 Standards
IIA 2024 Global Internal Audit Standards
standard · Context
The Role of the Internal Audit Function in Enterprise Risk Management
The Role of the Internal Audit Function in Enterprise Risk Management
standard · Context
Three Lines Model: Assurance and Advice in Support of Effective Governance
Three Lines Model: Assurance and Advice in Support of Effective Governance
standard · Context
ISO/IEC 27001:2022
ISO/IEC 27001:2022 Annex A
standard · Context
ISO 31000:2018
ISO 31000:2018 Risk Management (principles/framework/process)
standard · Context
ISO/IEC 42001:2023 (AI)
ISO/IEC 42001:2023 Annex A (AI Management System)
standard · Context
EU NIS2
EU NIS2 Directive
standard · Context
NIST SP 800-53 Rev5
NIST SP 800-53 Rev 5 — Security and Privacy Controls
standard · Context
NIST Agent Identity (draft, Feb 2026)
NIST NCCoE: Software and AI Agent Identity and Authorization
standard · Context
NIST TEVV-Athlon (draft, Aug 2026)
NIST AI 200-2: TEVV-Athlon Framework for Evaluating AI Systems
standard · Context
NIST CSF 2.0
NIST Cybersecurity Framework 2.0
standard · Context
NYDFS Part 500
NYDFS Part 500 — NY Cybersecurity Regulation
standard · Context
PCI DSS v4.0.1
PCI DSS v4.0.1
standard · Context
SOC 1
SOC 1 (SSAE 18 / ISAE 3402) — service-org ICFR control objectives
standard · Context
SOC 2 (TSC)
AICPA SOC 2 Trust Services Criteria (2017, rev. 2022)
standard · Context
SOX / PCAOB (ICFR)
SOX 404 / PCAOB AS 2201 — ICFR control taxonomy
unified · Context
UC-ACCESS-02 — Review user access rights periodically
All user and privileged access rights are reviewed at least annually, and more frequently for high-risk systems, by system or data owners who confirm each entitlement remains limited to business need. Unnecessary accounts and excess privileges identified in reviews are disabled or removed within a defined SLA. Completed reviews and remediation evidence are retained.
unified · Context
UC-ACCESS-03 — Enforce least privilege, need-to-know, and segregation of duties
A documented access control policy grants access strictly on business need-to-know, with entitlements defined through roles that default to least privilege. Segregation-of-duties conflicts (e.g., request versus approve, develop versus deploy) are defined in a conflict matrix, enforced in systems, and mitigated with compensating controls where unavoidable. Role and entitlement definitions are approved by data or system owners and re-approved whenever they change.
unified · Context
UC-ACCESS-04 — Restrict privileged rights, utilities, and unauthorized software
Privileged access rights are individually authorized against a business justification, time-bound or periodically recertified, and issued on separate accounts distinct from daily-use identities. Use of utility programs capable of overriding system or application controls is restricted to authorized administrators and logged. Application allowlisting or equivalent controls prevent installation and execution of unauthorized software on managed systems.
unified · Context
UC-ACCESS-05 — Enforce approved authorizations for information and functions
Systems mediate every access attempt through a tamper-resistant, always-invoked enforcement mechanism that applies approved authorizations before granting access to information or functions. Restrictions use roles and security attributes bound to data and subjects, limiting access to sensitive information, source code, and administrative functions to explicitly authorized identities. Enforcement rules are applied consistently across applications, databases, and infrastructure and are tested for effectiveness.
unified · Context
UC-ACCESS-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-20 — Ensure complete, accurate, and authorized data processing
Transactions and data entering the system are validated for completeness, accuracy, and authorization through edit checks, batch totals, and exception queues. Interfaces and transmissions between systems are controlled with reconciliation, error handling, and timeliness checks, and processing applies complete and accurate logic in the proper period. Outputs and reports are validated and distributed only to authorized recipients.
unified · Context
UC-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-07 — Verify, validate, and control AI deployment and changes
Verify and validate each AI system against its requirements and responsible-AI objectives, documenting test plans, acceptance criteria, and results before release approval. Gate deployment on a documented deployment plan and sign-off confirming requirements are met. Route updates, retraining, and other changes through the same assessment and approval process, including impact reassessment where relevant, and retain verification records and deployment and change approvals.
unified · Context
UC-AI-08 — Log and monitor AI system behavior in operation
Ensure AI systems automatically record event logs that enable traceability of operation over the system's lifetime, including events relevant to identifying risk situations and substantial modification. Retain logs for at least the mandated regulatory minimum, or longer where required. Monitor deployed systems against defined performance and behavior metrics with alerting and escalation for anomalies and drift, and retain logs and monitoring reviews as evidence.
unified · Context
UC-AI-09 — Govern AI data quality, provenance, and preparation
Govern training, validation, and test data under documented data-management practices covering acquisition, selection, provenance recording, and preparation activities such as labelling, cleaning, and enrichment. Apply and record quality criteria appropriate to the intended purpose, including relevance, representativeness, and, to the best extent possible, completeness and freedom from errors, and examine datasets for biases with mitigation of those likely to affect health, safety, or fundamental rights. Retain data documentation and provenance records for each AI system.
unified · Context
UC-AI-10 — Meet transparency obligations for AI systems
Provide users, deployers, and other interested parties with documentation and instructions for each AI system describing its intended purpose, capabilities, limitations, performance characteristics, and required human-oversight measures. Disclose when people are interacting with an AI system, and mark AI-generated or manipulated content, including deepfakes, in a machine-readable and clearly perceptible way where required. Keep transparency materials current with system changes and retain distribution evidence.
unified · Context
UC-AI-11 — Operate AI concern, incident, and external reporting channels
Operate channels through which personnel and other stakeholders can report concerns about the organization's role in developing or using AI systems, with documented triage and follow-up. Define and execute procedures for communicating AI incidents to affected users and interested parties, and for making required reports to regulators and other external bodies within mandated timeframes. Retain concern reports, incident communications, and resolution records as evidence.
unified · Context
UC-AI-12 — Enforce responsible and lawful use of AI systems
Define objectives and documented processes for responsible use of AI systems, and ensure each system is used only in accordance with its intended use and accompanying documentation. Screen proposed and existing uses against legal prohibitions on unacceptable practices — such as manipulative techniques, social scoring, and untargeted facial-image scraping — and block or discontinue prohibited uses. Retain use approvals and screening records.
unified · Context
UC-AI-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-20 — Prevent harmful, out-of-scope, hallucinated, and over-exposed AI outputs
Filter and shape every AI output before release: block or transform content that matches the system's harmful-output taxonomy, keep responses within the declared scope and capabilities, detect agent-specific high-risk outputs and route them to defined responses by severity, ground factual claims in cited sources and verify them to limit hallucination, withhold system prompts, internal data, and other over-exposed information, and sanitize outputs consumed by downstream systems so they cannot carry executable or injected payloads. Measure filter effectiveness and retain configurations, block logs, and review samples as evidence.
unified · Context
UC-AI-24 — Operate an AI quality management system
Establish and maintain a documented quality management system for AI products covering quality objectives and responsibilities; documented design, development, testing, and release procedures; change management; data management procedures; issue tracking and corrective action; stakeholder and regulator communication procedures; and record keeping. Review the system periodically for effectiveness and continual improvement, and retain the quality manual, procedures, review records, and corrective-action logs as evidence.
unified · Context
UC-ASSET-01 — Maintain a complete inventory of systems, hardware, and software
Maintain a documented inventory of all hardware, software, systems, and services, recording owner, location, and the attributes needed for accountability and security management. Update the inventory as part of component installation, removal, and change, and reconcile it at least quarterly to correct discrepancies. Include every in-scope component so the inventory serves as the authoritative record of protected information assets for audit and compliance scoping.
unified · Context
UC-ASSET-03 — Classify, prioritize, and label information and assets
Classify information and associated assets under a documented scheme based on sensitivity, criticality, and business impact, and prioritize assets and protections accordingly. Apply labels and markings, including on physical media, that identify the classification and any distribution or handling limitations. Identify confidential information at creation or receipt and keep classifications and priorities current through periodic review.
unified · Context
UC-ASSET-06 — Govern acceptable use of endpoints, off-site, and external systems
Define, communicate, and require acknowledgment of acceptable-use rules for information and associated assets. Protect user endpoint devices with enforced safeguards such as encryption, screen locking, and centralized management, and protect organizational assets used off premises against loss, theft, and observation. Permit use of or connection to external systems only under established terms and conditions consistent with the trust relationship, including restrictions on processing organizational information and on portable storage.
unified · Context
UC-ASSET-08 — Transfer information securely under defined rules and agreements
Establish rules, procedures, and agreements that protect information transferred within the organization and with external parties, covering electronic transfer, physical media in transit, and verbal disclosure. Require safeguards proportionate to classification, such as encryption in transit and tracked courier services, and bind external recipients through transfer agreements.
unified · Direct
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 · Direct
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 · Direct
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 · Direct
UC-AUDIT-04 — Uphold integrity and ethical conduct in internal auditing
Internal auditors demonstrate integrity in their work and professional relationships: they act honestly, exhibit professional courage by communicating truthfully even when uncomfortable, comply with applicable laws and the organization's ethical expectations, and encourage ethical behavior across the organization. Ethics expectations are acknowledged by audit staff annually and deviations are addressed and documented.
unified · Direct
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 · Direct
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 · Direct
UC-AUDIT-07 — Exercise due professional care and professional skepticism
Internal auditors exercise due professional care by conforming with applicable professional internal auditing standards and by assessing the nature, circumstances, and requirements of each engagement, including the interests of stakeholders and the relative complexity and significance of the work. Auditors apply professional skepticism, critically assessing the reliability and sufficiency of information before relying on it. Conformance is confirmed through supervisory and quality reviews.
unified · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
UC-AUDIT-13 — Gather and analyze evidence to develop engagement findings
Auditors gather information that is relevant, reliable, and sufficient to support analyses and evaluations, applying appropriate analytical methods and tools. Deviations between the established criteria and the observed condition are analyzed and assessed for significance and developed into potential findings documenting condition, criteria, cause, and effect. Evidence and analyses are captured in workpapers.
unified · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
UC-AUDIT-23 — Coordinate independent assurance reviews across providers
The organization plans and obtains independent reviews of its approach to managing and implementing information security - including people, processes, and technologies - at planned intervals, after significant changes, and where required by applicable law or regulation. Before relying on another provider's work, each reliance decision assesses and records the provider's independence and objectivity, competence and methodology rigor, evidence quality and reperformance capability, and recency against the covered risk's cadence, together with the resulting reliance level and rationale. Assurance activities are coordinated across internal and external providers to ensure coverage, minimize duplication, and support reliance on others' work. Material reliance limitations, assurance gaps, and duplication remain visible to management and the board. Results are reported to management and the board and drive corrective actions.
unified · Direct
UC-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 · Direct
UC-AUDIT-25 — Maintain quality records and information for internal control
The organization obtains or generates and uses relevant, quality information to support the functioning of internal control, with defined expectations for accuracy, completeness, and timeliness. Records are protected against loss, destruction, falsification, and unauthorized access or release, and are retained and disposed of in accordance with retention schedules aligned to legal, regulatory, contractual, and business requirements.
unified · Direct
UC-AUDIT-26 — Authorize systems and internal connections before operation
A senior accountable official formally authorizes each system to operate before production use, based on the assessed security and privacy risk to organizational operations, assets, and individuals, and reauthorizes on a defined frequency or after significant change. Internal system connections are authorized prior to establishment and documented, including interface characteristics, security and privacy requirements, and the information communicated. Authorization decisions and connection documentation are retained.
unified · Direct
UC-AUDIT-27 — Govern expanded internal audit ERM responsibilities
Any ERM, compliance, risk-management, or other second-line responsibility assigned to the internal audit function or chief audit executive is classified as assurance, advisory, administrative, supervisory, or operational; justified and documented in the internal audit charter or a board-approved appendix; and approved by the board with the associated independence and objectivity risks. Internal audit does not select or own risk responses or other management decisions. Expanded responsibilities are time-bounded with a transition plan when intended to be temporary, and actual or perceived impairments are disclosed to the board. Internal auditors do not provide assurance over an activity they designed, operated, managed, or supervised during the preceding 12 months; another suitably qualified and independent party provides assurance for affected areas. Safeguards, alternative assurance, and transition status are reviewed periodically.
unified · Context
UC-BCDR-14 — Embed control activities in business processes
Define and operate control activities embedded within key business processes - input, processing, and output controls, segregation of duties and levels of authority, error and exception handling, and traceability of transactions - so that information processed remains complete, accurate, and valid.
unified · Context
UC-CONFIG-05 — Permit only authorized software installation and use
Restrict installation of software on operational systems to authorized personnel installing approved software from trusted sources, and govern user-installed software through explicit policy and technical enforcement such as allowlisting. Combine these restrictions with anti-malware controls that prevent or detect and act upon unauthorized or malicious software. Track software installation and use to comply with contract terms and license entitlements.
unified · Context
UC-CONFIG-06 — Verify authenticity and integrity of hardware and software
Assess the authenticity and integrity of hardware and software before acquisition and use, sourcing components from trusted suppliers. Verify digital signatures or equivalent integrity evidence on software, firmware, and updates before installation, and block or investigate components that fail verification.
unified · Context
UC-DATA-01 — Process personal data only under a documented lawful basis
Identify and document the lawful basis and organizational authority for each personal-data processing activity before data is collected or processed. Record the basis (e.g., consent, contract, legal obligation, legitimate interest) in the processing register and collect personal data only for those documented purposes. Review the register at least annually and whenever processing changes.
unified · Context
UC-DATA-02 — Obtain and honor consent for collection, use, and disclosure
Where consent or authorization is the basis for collecting, using, retaining, disclosing, selling, or sharing personal data, present the available choices and their consequences clearly and capture freely given, specific, informed consent before the data is collected or disclosed. Maintain auditable consent records, honor withdrawal and opt-out requests (including opt-out of sale/sharing and limits on sensitive-data use) as easily as consent was given, and use compliant authorization forms where required. Document the basis for any implied consent relied upon.
unified · Context
UC-DATA-03 — Limit personal-data use to stated purposes and minimum necessary
Identify and document the specific purposes for which personal data is processed, and restrict use and disclosure to those purposes or documented compatible ones. Apply the minimum-necessary standard so only the least data required is used, disclosed, or requested for each purpose. Obtain new authority or consent before processing for any new purpose.
unified · Context
UC-DATA-04 — Restrict processing of special categories of personal data
Inventory all processing of special categories of personal data (e.g., health, biometric, genetic, race or ethnicity, religion, sexual orientation) and prohibit such processing unless a documented legal exception or explicit consent applies. Apply heightened safeguards to this data and record the exception relied upon for each processing activity.
unified · Context
UC-DATA-05 — Provide privacy notices and transparency to data subjects
Publish and maintain privacy notices that describe, in clear and plain language, the categories of personal data collected, purposes, lawful bases, recipients, retention periods, and data-subject rights, and deliver them at or before the point of collection. Update and re-communicate notices in a timely manner when practices change, and publish any legally required registrations such as system-of-records notices. Retain dated notice versions as evidence.
unified · Context
UC-DATA-06 — Provide data subjects access to their personal data
Operate a mechanism for identified and authenticated individuals to obtain confirmation of processing and a copy of their personal data, including the categories collected, sold, shared, or disclosed and the categories of recipients, within statutory deadlines. Where access is denied, inform the individual of the denial, the reason, and any recourse. Log all requests and responses as evidence.
unified · Context
UC-DATA-07 — Keep personal data accurate and honor correction requests
Maintain personal data that is accurate, complete, up to date, and relevant for its intended use, with periodic data-quality checks. Provide a process for individuals to request correction or amendment, execute or formally deny each request within statutory deadlines with stated reasons, and communicate corrections to third parties to whom the data was disclosed.
unified · Context
UC-DATA-08 — Execute deletion and other rights requests within deadlines
Operate a verified rights-request process with designated intake channels, identity verification, and statutory response clocks that executes data-subject rights including erasure/deletion, portability, restriction, objection, and rights related to automated decision-making, and directs service providers to do the same. Do not discriminate or retaliate against individuals for exercising rights, and disclose the material terms of any financial-incentive program with opt-in consent. Track every request end-to-end as evidence.
unified · Context
UC-DATA-09 — Retain personal and confidential data per schedule, then destroy it
Maintain an approved retention schedule for personal and confidential information tied to documented legal and business requirements, and retain data no longer than the schedule permits. When retention ends, delete or irreversibly destroy the information wherever it resides, including in external services, using methods that prevent reconstruction, and record disposal actions as evidence.
unified · Context
UC-DATA-11 — Control data flows, leakage, and cross-border transfers
Enforce approved authorizations for information flows within and between systems using technical flow-control mechanisms, and deploy data-leakage-prevention measures on systems and channels that could exfiltrate sensitive data. Transfer personal data across borders only under a valid transfer mechanism (adequacy decision, standard contractual clauses, binding corporate rules, or a documented derogation), with the transfer risk assessed and the safeguard recorded.
unified · Context
UC-DATA-14 — Maintain and provide an accounting of disclosures
Record every authorized disclosure of personal information - recipient, date, data categories, and purpose - completely, accurately, and in a timely manner. Upon a verified request, provide the data subject an accounting of the personal information held and its disclosures within the required timeframe.
unified · Context
UC-DATA-15 — Record and notify unauthorized disclosures of personal data
Log every detected or reported unauthorized disclosure or breach of personal information in a complete, accurate, and timely register. Notify affected data subjects, regulators, and other required parties within the applicable statutory windows, and retain the notifications and supporting analysis as evidence.
unified · Context
UC-DATA-16 — Bind third parties handling personal data to privacy commitments
Before granting vendors or other third parties access to personal information, obtain written privacy commitments covering permitted use, safeguards, and notification of actual or suspected unauthorized disclosures. Assess their compliance periodically and as needed, route their breach notifications into the incident-response process, and take corrective action or terminate access when commitments are not met.
unified · Context
UC-DATA-17 — Resolve privacy inquiries, complaints, and disputes
Operate a documented channel for receiving, tracking, addressing, and resolving privacy inquiries, complaints, and disputes from data subjects and other parties. Communicate resolutions to the complainant, make corrections for identified deficiencies in a timely manner, and monitor complaint trends for systemic issues.
unified · Context
UC-DATA-18 — Govern automated matching of PII under formal agreements
Enter formal agreements before participating in automated matching of personal data between organizations or systems, specifying the purpose, data elements, and verification procedures. Provide any required notice, independently verify matched information before taking adverse action against an individual, and retain agreements and verification records as evidence.
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-02 — Review financial results and the period-end close
Execute the period-end close under a documented close calendar and checklist covering consolidation, journal entries, significant estimates, and preparation of financial statements and disclosures, with sign-off on each step. Perform management reviews of financial results, including account analyses, budget-to-actual and period-over-period variances, estimates, and reconciliations, at a defined precision threshold, documenting the investigation and resolution of items exceeding it. Retain review evidence identifying the reviewer, items challenged, and outcomes.
unified · Context
UC-FIN-03 — Perform and review account reconciliations
Perform account and subledger-to-general-ledger reconciliations for in-scope accounts on a defined frequency, verifying the completeness and accuracy of balances. Require independent, timely review and approval of each reconciliation, and age, track, and resolve reconciling items within defined thresholds. Retain completed reconciliations, approvals, and resolution evidence.
unified · Context
UC-FIN-04 — Authorize transactions with attributable approvals
Require transactions, journal entries, and master-data or configuration changes to be reviewed and approved by authorized personnel in accordance with the delegation-of-authority matrix before they are recorded or executed. Capture approvals in systems under unique authenticated user accounts with tamper-evident audit trails that irrefutably bind each approval to the individual who performed it, so that approval actions cannot be repudiated. Evidence includes the delegation-of-authority matrix, approval workflow configurations, and approval audit trails.
unified · Context
UC-FIN-05 — Segregate incompatible financial duties
Divide incompatible duties, including authorization, recording, custody of assets, and reconciliation, among different individuals across financial processes so that no one person can both perpetrate and conceal an error or fraud. Enforce the segregation through role design and system access, maintain a documented segregation-of-duties conflict matrix, and review conflicts periodically with documented mitigating controls where segregation is impracticable.
unified · Context
UC-FIN-06 — Validate completeness and accuracy of system inputs
Implement input controls over data entered into financial systems, including edit and validation checks, required-field and format controls, completeness checks, and rejection or suspense handling of invalid entries, so that inputs are complete, accurate, and valid. Define these controls in documented policies and procedures over system inputs and retest their configuration on change. Evidence includes configuration baselines, validation rules, and rejected-input handling records.
unified · Context
UC-FIN-08 — Control interface transfers and output delivery
Control data transferred between systems and delivered as output so that it is complete, accurate, timely, and processed only once, using record counts, control totals, or hash checks reconciled at each interface with automated error handling and alerting for failures. Deliver or make output available in accordance with documented specifications, and investigate and resolve interface or delivery failures timely. Evidence includes the interface inventory, reconciliation results, and failure-resolution logs.
unified · Context
UC-FIN-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 · Context
UC-GOV-01 — Establish and maintain the enterprise governance framework
Design, implement, and maintain an enterprise governance system for information and technology that sets direction, decision rights, and accountability, together with a supporting management framework (organizational structures, policies, processes, and culture) that puts governance direction into operation. Evaluate the effectiveness of the governance and management framework periodically and adjust it as the enterprise context, strategy, and regulatory environment change.
unified · Context
UC-GOV-03 — Identify and manage legal, regulatory, and contractual obligations
Identify, document, and keep current all legal, statutory, regulatory, and contractual requirements relevant to information security and privacy — including privacy and civil-liberties obligations — and define and assign the organization's approach to meeting each. Assess and document applicability determinations, including any regulatory exemptions claimed, and file the notices required to support those determinations. Review the obligations register at planned intervals and upon regulatory or business change.
unified · Context
UC-GOV-04 — Set tone at the top: integrity, ethics, and risk-aware culture
Leadership defines and demonstrates commitment to integrity, core ethical values, and the desired risk-aware culture through an adopted code of conduct, consistent leadership behavior, and periodic evaluation of adherence with timely remediation of deviations. Organizational leadership is responsible and accountable for cybersecurity and internal-control risk and fosters a culture that is ethical, risk-aware, and continually improving, with expectations communicated to all personnel and business partners.
unified · Context
UC-GOV-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 · Context
UC-GOV-07 — Hold individuals accountable for control responsibilities
Management requires all personnel to apply information security in accordance with established policies and procedures and holds individuals accountable for their internal control responsibilities. Accountability is enforced through defined expectations, documented rules of behavior acknowledged before access is granted and re-acknowledged when updated, performance measures and incentives, and disciplinary consequences for violations.
unified · Context
UC-GOV-08 — Segregate conflicting duties and areas of responsibility
Identify duties and areas of responsibility that conflict — such as requesting versus approving access, development versus production deployment, or initiating versus approving transactions — and segregate them among different individuals or roles. Where segregation is impracticable, apply and document compensating controls such as enhanced monitoring, logging, or independent review.
unified · Context
UC-GOV-09 — Appoint accountable security leadership (CISO)
Designate a qualified senior leader (e.g., a Chief Information Security Officer) with organization-wide responsibility, accountability, authority, and resources to develop, implement, and enforce the information security program, and designate accountable leadership roles for the risk management program. The security leader reports in writing on the program, material cybersecurity risks, and remediation plans to the board or equivalent governing body at least annually.
unified · Context
UC-GOV-11 — Allocate adequate resources and budget for security
Allocate and manage funding, personnel, and other resources commensurate with the organization's cybersecurity risk strategy, roles, responsibilities, and policies, ensuring security and privacy requirements are addressed in capital planning, budgeting, and investment decisions. Periodically evaluate resource allocation and utilization for adequacy and optimization, and adjust budgets as priorities and risks change.
unified · Context
UC-GOV-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 · Context
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 · Context
UC-GOV-17 — Establish enterprise risk management strategy and appetite
Establish, document, and communicate a leadership-approved enterprise risk management strategy, including risk management objectives agreed by stakeholders, defined risk appetite and tolerance statements, and a documented risk assessment policy with procedures and a consistent methodology for identifying, analyzing, prioritizing, and responding to risk. Ensure governance activities keep risk-taking optimized within appetite, and review and update the strategy, appetite, and policy at planned intervals.
unified · Context
UC-GOV-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 · Context
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 · Context
UC-GOV-21 — Communicate and report risk and control information
Establish channels, responsibilities, and cadences to communicate risk, control, and performance information internally at all levels — including objectives and internal control responsibilities — and with external stakeholders, business partners, and the technology function. Leverage information systems to capture, process, and deliver this reporting, and report on risk, culture, and performance to stakeholders at defined intervals and on significant events.
unified · Context
UC-GOV-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 · Context
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 · Context
UC-GOV-24 — Notify regulators of incidents and file required certifications
Maintain documented procedures to notify supervisory and regulatory bodies of reportable cybersecurity events within mandated regulatory timelines, including any staged early-warning, detailed-notification, and final-report deadlines, and to submit required periodic compliance certifications and filings. Handle regulatory submissions and related materials confidentially, and retain evidence of all notifications, certifications, and supporting records.
unified · Context
UC-GOV-25 — Operate a privacy program with accountable leadership
Establish and maintain a privacy program and program plan defining the technical and organisational measures by which the organization ensures, and is able to demonstrate, compliance with privacy requirements. Designate a qualified, appropriately independent privacy leader (a Data Protection Officer where required) with defined tasks, adequate resources, and direct reporting to the highest level of management. Disseminate privacy program information to the workforce and the public, and report on privacy posture and program effectiveness at defined intervals.
unified · Context
UC-GOV-26 — Enforce personal-data processing principles and minimization
Adopt and enforce policies and procedures requiring that personal data is processed lawfully, fairly, and transparently; collected for specified, explicit purposes; limited to what is necessary; kept accurate through defined quality-management checks and correction procedures; stored no longer than needed; and protected — with accountability demonstrable through documentation. Minimize or use de-identified personally identifiable information in testing, training, and research, applying documented techniques where full data is not required.
unified · Context
UC-GOV-27 — Manage privacy complaints and account for disclosures
Implement a process to receive, track, and resolve privacy-related complaints, concerns, and questions from individuals within defined response times, including escalation paths and feedback to complainants. Maintain an accurate accounting of disclosures of personal information — including date, nature, purpose, and recipient — retained for the required period and made available to the individuals concerned upon request.
unified · Context
UC-GOV-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 · Context
UC-IR-01 — Maintain an approved incident response plan
Maintain a written incident response plan that defines the mission and scope of the response capability, incident definitions and severity structure, roles, responsibilities, and communication paths, and how the capability coordinates with business continuity and third parties. Have the plan approved by designated management, distribute it to named response personnel, and review and update it on a defined frequency and after significant incidents or organizational changes, protecting it from unauthorized disclosure and modification.
unified · Context
UC-IR-03 — Provide channels to report events and obtain response help
Operate well-known channels — such as a monitored mailbox, hotline, or service portal — through which all personnel can and are directed to report observed or suspected security events as quickly as possible. Provide an incident response support resource, integral to the response capability, that offers advice and assistance to users on reporting and on handling suspected events. Acknowledge every report and route it into triage.
unified · Context
UC-IR-04 — Triage, categorize, and escalate reported security events
Triage every reported security event: validate that it is genuine, assess it against the agreed classification scheme, and decide whether to declare it an incident. Categorize and prioritize declared incidents by type, severity, and business impact, and escalate or elevate them to defined roles and management tiers according to documented thresholds and timeframes. Record triage decisions and their rationale in the incident system of record.
unified · Context
UC-IR-05 — Assess and validate incident scope, impact, and magnitude
For each declared or suspected incident, estimate the scope of affected systems, data, and business processes and the resulting impact, and validate those estimates as investigation proceeds. Document magnitude assessments — records affected, service disruption, and financial exposure — and update them at defined points so response priority, escalation, and notification decisions rest on current, validated figures.
unified · Context
UC-IR-08 — Notify authorities and affected parties within deadlines
Maintain a notification matrix of internal stakeholders, regulators, and other external parties with triggers, deadlines, content requirements, and approved communication owners. Require personnel to report suspected incidents to the response capability within defined timeframes, notify authorities and other required external bodies within their statutory windows, and share incident information with designated internal and external stakeholders as the communications plan directs. Notify affected individuals when thresholds are met — for high-risk personal-data breaches, communicate without undue delay in clear and plain language with mitigation advice; for regulated categories of data, notify individuals, media, and regulators within the mandated statutory windows when applicable thresholds are reached, honoring notification duties owed to partner organizations. Retain evidence of every notification's timing, audience, and content.
unified · Context
UC-IR-11 — Respond to information spillage with defined procedures
Maintain and execute a documented procedure for responding to information spillage — sensitive or regulated information landing on systems not authorized to hold it. On discovery, identify the information and the extent of contamination, alert designated personnel without amplifying exposure, isolate and eradicate the spilled information from affected systems and backups, and assess any obligations triggered by the exposure. Provide procedures and training for personnel exposed to spilled information and document each spill response.
unified · Context
UC-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-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-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-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-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.
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
ISO 27001 Certification Readiness
Runs on the existing audit item. Assess ISO/IEC 27001 certification readiness across ISMS scope, clauses, risk treatment, Annex A applicability, internal assurance, gaps, and audit-entry governance. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Process Narrative & Walkthrough
Runs on the existing process item. Document an end-to-end process, corroborate the narrative through a representative walkthrough, and approve a traceable current-state record. 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
ITGC Change & Provisioning Testing
Runs ON a control item (a change-management or access-provisioning ITGC). Validates the change and provisioning populations for the period, draws reproducible samples, tests each sampled ticket against the control attributes (approval before migration, segregation of developer and migrator, approval before access, access matches the requested profile), records design and operating conclusions on the control, and raises every exception as an issue.
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
User Access Review & Recertification
Runs on the existing Control item for UC-ACCESS-02 (user access review) — with UC-ACCESS-03 linked by item relationship — enriching that Control, never creating a duplicate; each quarterly or event-triggered cycle is a workflow instance attached to it, so archived instances accumulate as the de-facto control execution log. A decision-aware workflow covering entitlement extraction, manager certification, revocation, and independent verification. Consumes at start the prior cycle's scope-change carry-forward Issues and prior signed report (both attached to the same Control) plus the period's source-of-record entitlement extracts and period-end HR roster. Produces a signed, audit-ready recertification evidence package and control-owner report as the named deliverable. In scope: SOX-significant applications, systems holding data classified Confidential or above, identity infrastructure (directory, SSO, PAM), and privileged-reach platforms, across all account populations (standard, privileged, service, shared, emergency break-glass, third-party); triggered on scheduled cadence or by event (post-incident, auditor request). Out of scope: lifecycle provisioning and the privileged-access model itself — systemic findings hand off to the Joiner-Mover-Leaver Access Lifecycle (lifecycle gaps) and Privileged Access & Authorization Model Management (privileged-model findings) 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
Data Retention & Secure Disposal
Each cycle runs as a workflow instance attached to the existing data-retention-and-secure-disposal Control item in the control library (UC-DATA-09/UC-DATA-10) — enrich that Control with this run's evidence, never create a duplicate control. A decision-aware cycle covering expired-data identification, disposition approval, verifiable disposal, media sanitization, evidence assembly, and stakeholder reporting. In scope: identifying and disposing of data whose retention has expired across in-scope stores (databases, file shares, document repositories, email archives, backup sets, and physical media) governed by the approved retention schedule. Out of scope: authoring the retention schedule itself — it is consumed as a standing input (the retention Policy item and its attached schedule), not produced here — and any data under an active legal or audit hold, which is fenced off from disposal. No upstream workflow feeds this cycle; it is triggered by the disposal calendar, a storage threshold, a system decommission, or a data-subject erasure request. It produces a signed disposition list, a disposal evidence package (job logs, hash manifests, chain-of-custody records, and certificates of destruction), a cycle dashboard, and an approved cycle report mapped to ISO 27001 A.8.10/A.7.10, NIST SP 800-53 SI-12/MP-6, and GDPR Article 5(1)(e). Downstream it hands nothing to another workflow: open exceptions, deferrals, and accepted gaps carry forward as Issue items in the risk/issue register, and schedule-maintenance gaps are forwarded to the retention-schedule owner as a closure notice.
workflow · Context
Incident Reporting Channels & Spillage Response
Standing operator workflow that runs on the existing Control item for the incident-reporting and information-spillage control (UC-IR-03; framework nist-800-53 | iso-27001 | nis2, domains incident_management_response) — one recurring workflow instance per operating cycle attaches to and enriches that Control item, never a duplicate. It consumes the prior cycle's carry-forward from the same Control: the last-sweep timestamp from the previous instance's close-and-archive record, plus the still-open corrective-action and obligation Issues linked to the Control. In scope: intake acknowledgment and triage routing across the monitored mailbox, hotline, and service portal; spillage containment/eradication and obligation assessment; and maintenance of the authorities and special-interest-group (SIG) contact register — spanning NIST 800-53 IR-6, IR-7, IR-9, and PM-15; ISO 27001 A.6.8, A.5.5, A.5.6; and NIS2 reporting duties. Named deliverables: the deduplicated intake register and acknowledgment log, the batch routing decision, the spill case with verified eradication, the obligation assessment and exposed-personnel training evidence, the refreshed authority/SIG contact register, the capability-health dashboard, the corrective-action register, and the archived operating record. Out of scope: full containment, investigation, and forensic response for genuine security events — those are handed off to the detect-to-respond workflow (via the route_to_incident_triage routing decision plus the linked intake Issues) rather than duplicated here.
workflow · Context
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
Privileged Access & Authorization Model Management
Standing operator workflow for the quarterly privileged-access recertification cycle, separate-account and utility-program controls, and application allowlisting, paired with role and security-attribute authorization-model maintenance and enforcement spot-testing across applications, databases, and infrastructure. Each quarterly instance runs as the operating cycle of the existing privileged-access Control item in the control library (UC-ACCESS-04, with UC-ACCESS-05 linked) — it enriches that Control's operating-effectiveness record rather than creating a new subject, and reads risk context from the linked Risk item (category cyber_security, domains access_control_identity). Consumes standing account, log, change-queue, and org-change feeds pulled live from IAM/PAM, directory, SIEM, allowlist tooling, and the HR system of record, plus the prior quarter's archived instance for its inventory register and carryover exceptions; it consumes no upstream workflow's handoff package. In scope: privileged and administrative accounts, control-overriding utility programs, the application allowlist, and the role and attribute authorization model with its enforcement points. Out of scope: standard non-privileged joiner-mover-leaver provisioning, network and perimeter controls, and application change management, each handled by its own workflow. Every exception and enforcement gap normalizes to an Issue item linked to the anchor Control, and the archived workflow instance is the cycle's evidence of record — open Issues are the cross-cycle carry-forward. Runs on a routine quarterly cadence, or out of cycle when an audit finding, incident, or major organizational change (reorg, new system, acquisition) requires it; no upstream workflow feeds it and it hands off to no single downstream workflow. Owned by the IAM Operations Lead.
workflow · Context
Cybersecurity Incident Response
Cybersecurity incident-response cycle as a decision-aware workflow spanning detection and validation, scoping, incident declaration and response-plan activation, containment with evidence preservation, eradication and recovery, POA&M updates for the control deficiencies the incident exposed, and a technical lessons-learned retrospective, closed through a disposition decision and archival. The workflow instance runs on the incident record — an Issue item (issue_type=exception, source=management_identified, severity per the org scheme) created at detection, since the schema has no native Incident type — and enriches that one record through to archival rather than creating duplicates. In scope: security events and confirmed incidents affecting the system boundary and its NIST 800-53 IR-family controls — the detection sources (logging/monitoring Control items, UC-LOG-06), affected systems (Process items, UC-ASSET-11), containment and recovery actions, forensic evidence, the deficiency Issues that become the POA&M, and their linked Risk items. Out of scope: the enterprise incident-management ticketing lifecycle and external breach-notification/legal reporting, which run in their own workflows. Where an Incident Management Lifecycle workflow is running, this cycle consumes its handoff package (initial ticket, reporter, affected systems); it hands the closed incident's control-deficiency findings — the open POA&M Issues (issue_type=deficiency) — to the Continuous Controls Monitoring (ISCM) Cycle as shared items it queries directly.
workflow · Context
IT Asset Inventory & Classification Upkeep
Standing operator workflow for the quarterly IT asset inventory reconciliation and the information and asset classification and labeling review. Anchor: each quarterly run is a workflow instance attached to the EXISTING Control item for the IT asset inventory & classification control (domains asset_management_inventory, frequency quarterly, framework including nist-800-53 / iso-27001 — e.g. control_id CM-8 / UC-ASSET-01) as its operating and execution record; enrich that Control, never create a duplicate. In scope: reconciling the authoritative hardware, software, systems, and services inventory against network, endpoint, cloud, and SaaS discovery scans and change records for the in-scope business units, and reviewing the classification, priority, and labeling of information and associated assets including physical media. Out of scope: the remediation engineering behind a decommission or security investigation (handed to those owners) and the downstream security-scoping processes that consume this cycle's outputs. Upstream: no upstream workflow — the cycle runs on the org's live inventory and discovery systems (external ITAM/CMDB, scanners, change/ticketing) plus the prior run's carry-forward Issue items linked to the anchor Control. Converges on two named deliverables — a signed reconciliation record and an updated classification register with an exported extract; that packaged, dual-signed record is the de-facto handoff package that downstream security-scoping processes consume (there is no named downstream workflow).
workflow · Context
Endpoint, Media & Information Handling Custody
Standing monthly operator desk for endpoint, media, and information-handling custody. The workflow instance is the monthly operating cycle attached to the EXISTING Control item for this custody control (control_id UC-ASSET-04/06/08 and UC-NET-12, Control.frequency monthly, Control.framework spanning nist-800-53, iso-27001, soc2, pci-dss) — each cycle enriches that standing Control rather than creating a new one. In scope: fleet endpoint safeguard and acceptable-use verification, off-premises and external-system use, port/I/O/sensor and collaboration-device restriction, removable-media authorization/custody/sanitization/destruction, and the information-transfer rulebook and agreements across electronic, physical-courier, and verbal channels. Out of scope: identity/access provisioning and network-perimeter engineering, which run under their own controls. No upstream workflow feeds this desk — the prior cycle's close-and-archive export is the carry-forward input that seeds each run (the fleet inventory, media custody register, and transfer rulebook are its own standing inputs). Named deliverables: the fleet-safeguard exception list, the endpoint-posture and custody-cycle disposition decisions, the removable-media authorization log and custody register, sanitization verification evidence and retained destruction certificates, the transfer-rule status, and two corrective-action registers backed by Issue items. Endpoint, media, and transfer streams run in parallel and reconverge at two decision checkpoints that route exceptions to tracked corrective action; terminal by design — it hands off to nothing but its own next monthly cycle.
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
Authorized Software & Component Integrity Control
Authorized Software & Component Integrity Control run as a decision-aware monthly cycle that enriches the existing "Authorized Software & Component Integrity" Control item in the control library (control_id UC-CONFIG-05/UC-CONFIG-06, frequency monthly, domains secure_configuration_change_management + third_party_supply_chain_risk) — each run is a workflow instance attached to that Control item, never a newly created control. It originates on its own (parallel entry threads consuming the cycle's own software-inventory, catalog/allowlist, install-rights, supplier-intake, and telemetry feeds) and also carries forward the prior cycle's still-open Issue items linked to the same Control. In scope: reconciling installed software across the in-scope endpoints, servers, and system images against the approved catalog and technical allowlist (the discrepancy register), triaging unauthorized installations to catalog-update / removal / escalation, verifying installation rights stay restricted to the authorized-installer roster from trusted sources (the install-rights and trusted-source exception list), tracking usage against license entitlements (the license-position report), and verifying supplier trust and signature integrity for every component acquired this cycle (the component verification register). Named deliverables — the discrepancy register, triage dispositions, catalog/allowlist change record, per-host removal evidence, install-rights and trusted-source exception list, component verification register, blocked-component investigation findings, and license-position report — are archived as the signed monthly cycle record on the workflow instance. Out of scope: incident containment and forensics — any suspected-malicious component is handed off, evidence intact, to the incident-response workflow, which owns that containment; this control cycle does not duplicate it.
workflow · Context
Network Segmentation & Boundary Rule Management
Network Segmentation & Boundary Rule Management as a decision-aware operator workflow covering trust-zone maintenance, gated rule-change implementation, boundary threat monitoring, the quarterly segmentation and rule-set review, and cross-domain exchange-policy enforcement. This cycle runs on the EXISTING boundary-protection Control item (domains network_communications_security; framework NIST 800-53, NIST CSF 2.0, ISO 27001, SOC 2; frequency quarterly; the boundary control owner as control_owner) — each quarterly run is one workflow instance attached to and enriching that Control, never a new control record. In scope: the trust-zone model, the managed interfaces (firewalls, gateways, proxies) mediating traffic between zones, the external boundary and key internal boundaries, and the cross-domain interconnection points, all under a deny-by-default baseline (NIST 800-53 SC-7, SC-16, SC-46; NIST CSF 2.0 PR.IR-01; ISO 27001 A.8.22; SOC 2 CC6.6). No upstream workflow feeds this cycle; it self-seeds from its own prior-cycle carry-forward — open corrective-action Issue items linked to the Control plus the prior run's closure record and archived rule-change record log. Named deliverables: the reconciled trust-zone model, the verified rule-change record log, the boundary threat-monitoring summary, the cross-domain exchange-policy enforcement report, the quarterly segmentation & rule-set review report, the boundary-posture dashboard, and corrective-action Issues linked to the Control. Downstream, it hands off only to its own next cycle via the carry-forward closure record; a confirmed intrusion is escalated to the incident-response workflow (out of scope), as are host/endpoint controls.
workflow · Context
Incident Response Readiness Program
Standing operator workflow that runs against the EXISTING incident-response Control item — UC-IR-01 (domains=incident_management_response, frequency=annual) — with the training-and-testing Control UC-IR-02 linked to the same instance; both carry framework=[nist-800-53, iso-27001], and those governing standards drive the plan's required elements. It maintains and approves the written IR plan (a Policy item, policy_type=procedure, framework=[nist-800-53, iso-27001], review_frequency=annual, whose governed redline attaches to the item), distributes and protects it to named responders, delivers role-based training, runs the scheduled capability test (an Audit item, audit_type=readiness, linked back to the two Controls), and feeds exercise and training gaps back into the plan and training program as corrective-action Issue items (source=self_assessment). Named deliverables: the redlined IR plan on its Policy item, the exercise after-action report, the IR readiness dashboard, and the routed corrective-action register (Issue items). In scope: the IR plan's required elements (mission and scope, incident definitions and severity structure, roles and responsibilities, communication paths, and business-continuity/third-party coordination), the named-responder and leadership training population, and the scheduled capability test. Out of scope: live incident handling itself — this workflow builds and tests readiness, it does not run the response to an active incident. It runs on an annual cadence and off-cycle whenever a significant incident or a material organizational/system change occurs; no upstream workflow feeds it and it hands off to no downstream workflow — identified gaps re-enter this same workflow as corrective-action Issues.
workflow · Context
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
Onboarding & Access Provisioning
Runs on the existing personnel item. Provision a joiner access from an approved role profile, evidence each grant, and approve the provisioning record that ITGC access testing samples. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
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
Transfer & Access Modification
Runs on the existing personnel item. Modify a mover access for a new role, remove entitlements the prior role no longer justifies, and approve the modification record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Periodic User Access Review
Runs on the existing system item. Run a periodic entitlement recertification for a system, evidence reviewer decisions, and confirm that required revocations were executed. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Data Conversion & Migration
Runs on the existing system item. Convert data into a target system with evidenced completeness and accuracy reconciliation between source and target. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
End-User Computing Inventory & Validation
Runs on the existing system item. Inventory the spreadsheets and end-user tools feeding reporting for a system, and test their access, change, and integrity controls. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
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
Privileged Access Review
Runs on the existing system item. Review privileged, service, and emergency accounts on a system for continued business justification, supporting activity, and compensating monitoring. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Security Control Assessment & POA&M Remediation
Run this assessment on the EXISTING Audit item for the engagement (audit_type: it_audit or compliance) — enrich that record, never create a duplicate: Audit.scope carries the authorization boundary and Audit.period_start/period_end the assessment window. Consumes, from the upstream SSP-development / system-categorization effort, the approved System Security Plan (SSP), the FIPS 199 system categorization, and the tailored NIST 800-53 baseline (existing Control items, framework: nist-800-53). Assess each in-scope control with 800-53A examine/interview/test methods, record satisfied / other-than-satisfied determinations, open a POA&M Issue for every gap, re-validate remediation, and issue the Security Assessment Report (SAR). In scope: control assessment, determinations, the POA&M lifecycle, and the SAR for the authorization boundary agreed at kickoff. Out of scope: the authorization (ATO) decision itself and the steady-state continuous-monitoring cadence. On completion, the frozen SAR and POA&M package are handed to the NIST RMF System Authorization (ATO) Cycle.
workflow · Context
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 Confidentiality Assessment
Design-readiness review of the SOC 2 confidentiality series: identification and maintenance of confidential information and its secure disposal at end of life (C1.1–C1.2). Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Privacy Criteria Assessment
Design-readiness review of the full SOC 2 privacy series: notice and choice, collection through disposal, data subject access and disclosure, and data quality with dispute monitoring (P1.1–P8.1), concluded with dual sign-off on the criteria-bearing final assessment. Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 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
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
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
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
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
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
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
Enterprise GRC Platform Integration Bridge
Runs on a Process item created at kickoff (process_type = it_general_control, process_owner = the integration owner, frequency = the sync cadence) that represents the bridge as an operated, auditable IT process — the workflow instance attaches to and enriches that Process item, never a duplicate. Bridges an external enterprise GRC platform (e.g., RSA Archer, ServiceNow GRC, Workday, AuditBoard) with AssureSwarm: define field and ID mappings, run the initial migration or provisioning (which creates Risk / Control / Issue / Audit / Policy items and Control-hosted testing workflows for imported control-test records), operate a monitored bidirectional scheduled sync, resolve conflicts, and confirm system-of-record agreement. This workflow originates the integration project — it consumes no upstream handoff. In scope: mapping design, initial load, ongoing sync operation and health monitoring, conflict resolution, and system-of-record sign-off. Out of scope: standing up the external GRC platform itself, and the downstream assurance analysis. The named deliverable is a version-stamped final bridge package (evidence index, executive summary, authoritative per-field system-of-record coverage table, open-items list), handed to the Combined Assurance Mapping workflow, which consumes it rather than re-deriving the record inventory.
workflow · Context
Policy Lifecycle Management
Run one policy through its full lifecycle, anchored to a Policy item in the policy library — created at authoring for a net-new policy, enriched in place on each refresh cycle (never duplicated). In scope: authoring and control/authority linkage, stakeholder review, formal approval, publication and workforce attestation, acknowledgement tracking, disposition, and scheduled alignment refresh. Consumes read-only upstream: the enterprise risk assessment (Risk items), control design (Control items), and obligation mapping — this workflow neither produces nor edits them. Produces four named deliverables: the published policy version, a frozen workforce attestation completion record, a section-by-section alignment verdict, and a single approval-ready policy package. Out of scope: enterprise risk assessment, control design, and obligation mapping. The approved policy package is handed off to the Regulatory Compliance Attestation Cycle, which runs the recurring regulatory attestation; the acknowledgement campaign launched here is the one-time publication attestation and is explicitly flagged in the handoff as not-to-be-repeated downstream.
workflow · Context
Regulatory Compliance Attestation Cycle
Regulatory Compliance Attestation Cycle: runs on and enriches the existing Audit item created for this authority and reporting period (audit_type = compliance or regulatory_exam; scope = certification boundary; period_start/period_end = the reporting period) — that Audit item is the attestation record the cycle updates throughout, never a duplicate. Over the cycle: compile evidence for the authority source across the reporting period, validate and resolve evidence gaps, produce the five-section regulatory attestation package, route certifying-officer certification, and archive the package. In scope: the legal entities, products, geographies, and systems named in the certification boundary for that authority and period. Consumes the implemented, owned, control-mapped obligation baseline as the handoff package from the Regulatory Obligation Implementation workflow (the implementations themselves are the Control items whose framework multiselect includes this authority, linked to the anchor Audit). Out of scope: obligations under other authorities, entities outside the certification boundary, and the obligation-to-control implementation itself. Hands the certification outcome, exception register, action plans, and accepted risks off to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Personal Data Quality & De-identification
Personal Data Quality & De-identification runs as a recurring operate cycle attached to the existing Control for personal-data quality & de-identification (framework gdpr/hipaa/ccpa/nist-800-53, domain data_protection_privacy): each period is a workflow instance that enriches that Control's operating record — never a new Control. The cycle consumes the data map / RoPA, the data-quality ruleset and retention schedule (Policy items), the individual correction-request queue, the disclosure log and the recipient/processor Vendor register, and the de-identification policy; it checks PII accuracy, relevance, timeliness, and completeness, corrects or deletes failing records and notifies downstream recipients under GDPR Art. 19, adjudicates individual correction requests within statutory deadlines, and de-identifies datasets that do not require full identifiers. It produces the exception register (exception Issue items), the corrected-and-deleted set, the recipient correction/deletion notices, and the de-identification and residual-risk reports; systemic findings hand off to the internal privacy backlog as Issue items. This is a terminal operate cycle — the archived, regulator-ready cycle record is the deliverable, not a handoff package for a named downstream workflow.
workflow · Context
Privacy Safeguards & Notice Management
Privacy Safeguards & Notice Management as a decision-aware cycle that runs as a workflow instance attached to the standing "Privacy Program" Process item (process_type: business_process, process_owner: the privacy officer) — one archived instance per period is the cycle file. Each run refreshes the privacy requirements inventory, confirms PII-protection accountability over the PII stores (modeled as processing-activity Process items), verifies administrative, technical, and physical safeguards against data volume and sensitivity (the safeguard set is the Control items with control_category administrative|technical|physical and framework gdpr|ccpa|hipaa protecting each store), remediates gaps as tracked Issues, and authors, publishes, and version-retains the privacy notices and registrations (modeled as Policy items) kept accurate to actual processing. In scope: the periodic privacy program cycle over the confirmed PII stores, their safeguard control set, and the published notice and registration population; every run reconciles the affected notices to actual processing — a cycle that skips notice reconciliation is a different workflow. No upstream or downstream workflow feeds or consumes this cycle; its inputs are the organization's own privacy program records, and open remediation, treatment expiries, and deferred drift carry forward as open Issues that seed the next cycle's intake.
workflow · Context
Legal & Regulatory Compliance Register Evaluation
Runs the compliance office's recurring register-evaluation cycle as a compliance-review engagement: the workflow instance attaches to an Audit item created per cycle (audit_type: compliance, period_start/period_end bounding the evaluation period, lead_auditor = the compliance officer), and every gap, management directive, and result produced this cycle links back to that Audit. A decision-aware cycle that refreshes the register of applicable legal, regulatory, and contractual requirements — including intellectual-property and software-licensing obligations — confirms ownership, schedules and performs documented compliance evaluations on each requirement's defined cadence, remediates non-compliance, reports status to management, and retains the register and results as evidence. Consumes upstream: between-cycle regulatory change flows in as a data feed from the Regulatory Horizon Scanning & Triage workflow, swept at the register-refresh entry point (a feed, not a formal handoff package). Named deliverables: the dated register of record, the period evaluation schedule, the evaluation results register, the compliance determination, the exposure-ranked remediation set (Issues linked to the cycle Audit), the compliance status report and dashboard, and the retained cycle evidence set. Hands off downstream: obligations that need standing up route to the Regulatory Obligation Implementation workflow — named in prose at close-and-archive, with no handoff package produced here. In scope: the legal, regulatory, and contractual requirements already in the compliance register that fall due for evaluation this period — cadence-due, overdue, or event-triggered. Out of scope: standing up brand-new obligations. The cycle scope — register population, the due subset including overdue catch-ups, and the period boundaries — is set at the register-refresh entry point.
workflow · Context
AI System Development, Data & Deployment Gate
Runs as a standalone per-release gate cycle — one workflow instance per new AI system or substantial modification. The schema has no native AI System item type, so the instance links (Item relationship) to the existing Control items it operates (UC-AI-04/05/06/07/09; framework eu-ai-act|iso-42001, domains ai_governance) and to the ai_governance Risk it mitigates, and all cycle evidence attaches to its steps. It consumes the AI system inventory profile and the enterprise responsible-AI objectives (Policy items) upstream; the release board then approves those objectives and the per-system requirements before build, governs training, validation, and test data with bias mitigation, executes the pre-deployment impact assessment and EU AI Act risk classification, applies the high-risk conformity obligations where they trigger, assembles Annex IV-grade technical documentation, and records verification-and-validation results and the deployment sign-off. Named deliverables: the risk-classification decision, the pre-deployment impact-assessment report, the Annex IV technical-documentation package, the verification-and-validation report, and the recorded sign-off. Retraining and substantial changes re-enter the same gate as a fresh instance (a self-loop, no downstream handoff).
workflow · Context
AI Transparency & Value-Chain Communications
Each quarterly instance runs against the existing "AI Transparency & Value-Chain Communications" Process item (process_type: business_process, frequency: quarterly), enriching it rather than recreating it, and links to the existing Control items UC-AI-10 and UC-AI-14 (framework: iso-42001 + eu-ai-act, domains: ai_governance) that the cycle executes. A recurring operate cycle that keeps AI system documentation, interaction disclosures, and content marking current with system changes, retains distribution evidence, evaluates AI suppliers (Vendor items) against responsible-AI requirements, and reviews customer needs and communications; the transparency policy and content-marking standard it enforces are Policy items. It consumes no upstream handoff package (a self-originating quarterly cadence) and terminates in no downstream workflow — systemic findings and carry-forwards land as Issue items in the AI governance backlog. In scope: every AI system in production or customer-facing use and every AI supplier providing an AI system, model component, training data, or inference service; out of scope: risk-classification and conformity assessment itself — purpose or risk-class drift is routed to the EU AI Act Impact Analysis workflow (as an observation Issue referencing it) rather than resolved in this cycle.
workflow · Context
GPAI Model Provider Compliance Cycle
Recurring operate cycle that fulfills Article 53 general-purpose AI model provider duties every release and quarterly refresh, and layers in Article 55 systemic-risk duties for models designated as posing systemic risk. The cycle runs as one Workflow instance on the existing Process item "GPAI model governance / provider compliance" (process_type: business_process, process_owner: Head of Model Governance) — enriched each cycle, never recreated — and links to the Control item implementing UC-AI-15. It consumes the prior cycle's archived instance on the same Process anchor (the per-model scope/exemption register and the prior version-of-record documentation carry forward), and produces the archived, authority-producible provider-obligation cycle record as its named deliverable. Note: the Studio catalog has no AI-Model item type, so per-model artifacts — scope, open-source-exemption determination, documentation and pack versions, publication records — live as version-stamped step documents and on the Workflow instance rather than on a model item, with the per-model scope register carried as a document on the anchor Process item. In scope: every general-purpose AI model this provider places on the EU market, scoped per model to Article 53 alone or Article 53 plus Article 55, with per-model provider-status and Article 53(2) open-source-exemption determinations carried on that scope register. Out of scope: the downstream integrator's own AI-system risk-class obligations, which each deployer operates separately; there is no named downstream workflow this cycle hands off to.
workflow · Context
Privacy Breach Assessment & Notification
Personal-data breach response, anchored on a breach-register Issue item created for the breach (issue_type: exception, source: management_identified, identified_date = the awareness timestamp); the workflow instance attaches to that Issue and the breach register is the queryable set of these Issues. Consumes the Incident Management Lifecycle workflow's handoff package (incident record, containment status, investigation timeline) and drives it from handoff to closure: a frozen, dated exposure inventory; a per-jurisdiction notifiability determination against GDPR Article 33, US state (California/CCPA included), and HIPAA clocks; regulator and data-subject notifications with milestone tracking; processor coordination against the processor's Vendor record and DPA; remediation and support Issue items; the Article 33(5) breach-register entry; and a post-breach review that hands off to the DPIA / Privacy Impact Assessment workflow for each affected processing activity. In scope: the notifiability judgment and notification execution downstream of the incident handoff; out of scope: incident containment and forensics, which stay with incident response.
workflow · Context
Requirement Applicability & Control Mapping
Runs on the existing requirement item. Interpret a requirement, determine supported applicability, map obligations to controls and evidence, and approve the mapping record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Regulatory Change Intake & Impact Assessment
Runs on the existing requirement item. Validate a new or amended external obligation against its authoritative source, determine applicability, and assess the impact on controls, policies, processes and systems. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Obligation Implementation & Adoption
Runs on the existing requirement item. Deliver the control, policy and process changes an obligation requires, validate readiness evidence, and approve the adoption record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
EU AI Act Obligation Impact Analysis
EU AI Act Obligation Impact Analysis runs on a compliance Audit item created at intake (`audit_type: compliance`, `scope` = the fixed entities/AI-systems/markets boundary) — the "impact-analysis item" the whole run enriches and closes. It parses in-scope EU AI Act provisions, classifies affected AI use cases by operator role and risk tier, crosswalks obligations to existing Control items, rates conformity gaps as Issue items, and routes high-risk gaps to the AIMS (ISO/IEC 42001 AI management system). Consumes the horizon-scanning handoff package from Regulatory Horizon Scanning & Triage. Named deliverables: the locked workplan, the obligation register (the durable run-to-run workbook), the per-use-case classification set, the obligation-to-control crosswalk, the ranked conformity-exposure list, and the version-pinned final analysis package. Hands its approved gap-and-action package to Regulatory Obligation Implementation. In scope: obligation parsing, use-case classification, control crosswalk, and gap rating for the entities, AI systems, and markets fixed at intake. Out of scope: implementing remediations, performing conformity assessments, and running fundamental-rights impact assessments (FRIAs) — FRIAs route to the AI Governance & Risk/Impact Assessment module.
workflow · Context
Compliance Monitoring & Attestation
Runs on the existing requirement item. Refresh evidence for an obligation on its review cycle, test continued conformance, and record the owner attestation with any exceptions. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Regulatory Horizon Scanning & Triage
Regulatory Horizon Scanning & Triage as a modular, decision-aware workflow. Each cycle runs on an Audit item created for the scan window — `audit_type` = compliance, titled "Regulatory Horizon Scanning — <period>", with `period_start`/`period_end` set to the detection window; the workflow instance attaches to that Audit and is archived against it at close. It can stand alone, but is designed to exchange handoff packages with related workflows instead of duplicating repeated work. In scope: detecting and summarizing regulator publications, routing them to the authority-source register, applicability screening against the compliance profile, entity profile, and activity inventory, owner assignment, and queueing. Out of scope: obligation mapping, gap and impact analysis, and implementation — those belong to the downstream Regulatory Impact Analysis & Obligation Mapping workflow, which consumes this workflow's named deliverables: the prioritized impact-analysis intake queue and the cycle evidence package. There is no upstream workflow and no prior handoff to consume; this is the sensing edge of the regulatory-change chain, and its standing inputs are the monitored feed list, the prior cycle's cursor, the authority-source register, and the Policy items that cite those authorities.
workflow · Context
Regulatory Impact Analysis & Obligation Mapping
Regulatory Impact Analysis & Obligation Mapping runs on a compliance Audit engagement record — an Audit item created per triggering instrument (audit_type=compliance) whose scope holds the locked scope statement and to which every gap Issue, risk acceptance, and the workflow instance attach. It consumes two upstream inputs: the triage handoff package from Regulatory Horizon Scanning & Triage (instrument, canonical citation, publication and effective dates, triage disposition) and the canonical instrument text itself — the Official Journal or regulator-register version, the authoritative source the whole analysis cites. It parses that instrument into obligations, maps them to the existing Policy and Control library, classifies and rates gaps, and reconciles the obligation register. Named deliverables: the cited regulatory impact note, the obligation inventory, the authority-to-policy crosswalk, the classified and rated gap Issues, the versioned obligation register, and the final evidence and decision package. In scope: obligation analysis, crosswalk, gap classification, exposure rating, and register reconciliation for the in-scope entities, products, and jurisdictions. Out of scope: remediation build-out (handed off to Regulatory Obligation Implementation) and re-prioritizing the instrument (owned by Regulatory Horizon Scanning & Triage). Confirmed gaps and their action plans hand off to Regulatory Obligation Implementation.
workflow · Context
Regulatory Obligation Implementation
Implement a new or changed regulatory obligation end to end on the Audit item created for this implementation (audit_type = compliance or readiness): its scope names the obligation and authority, its period_end holds the effective (compliance-by) date, and the workflow instance attaches to it. There is no native Regulation type, so the regulator, region, and obligation summary live in the anchor Audit.description with the operative source text uploaded to the gap-analysis step. The work — gap analysis, policy updates (Policy items), control design (Control items), process operationalization (a Process item), and coverage validation — enriches that Audit rather than creating a parallel record. In scope are the legal entities, products, systems, and vendor relationships (Vendor items) the obligation touches; entities and processing below the regulation's applicability thresholds are out of scope. This workflow consumes the obligation map handed off from Regulatory Impact Analysis & Obligation Mapping and hands its named deliverable — a validated coverage package (the gap list, the drafted policies and controls, the operationalized process, and the validation run) — to the Regulatory Compliance Attestation Cycle.
workflow · Context
Third-Party ICT Vendor Regulatory Assurance
Third-Party ICT Vendor Regulatory Assurance as a decision-aware workflow. Each cycle runs on its own Audit engagement item (audit_type = vendor_review) created at kickoff, with Audit.scope set to the in-scope legal entities, regimes, and vendor population; every workpaper, decision form, and gap attaches to that instance. In scope: ICT third-party service providers — including intra-group ICT providers — assessed against DORA, NIS2, and US interagency/FFIEC third-party expectations; out of scope: non-ICT vendors, which stay with the general vendor lifecycle. It consumes the arrangement-level inventory, tiering, and due-diligence handoff package from Third-Party Vendor Risk Lifecycle (whose provider records are the Vendor items); refers vendor SOC 1/SOC 2 reports carrying real reliance to the Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow and folds back its reliance conclusions; and produces a provision-cited, severity-rated gap register (Issue items linked to the anchor Audit and the affected Control/Vendor records) plus a qualified final assurance package. It hands the validated obligation statuses to the Regulatory Compliance Attestation Cycle, exchanging handoff packages with related workflows instead of duplicating repeated work.
workflow · Context
DSAR Fulfillment (Access & Deletion Requests)
DSAR Fulfillment (Access & Deletion Requests) as a modular, decision-aware workflow that verifies identity, locates and reviews personal data, applies exemptions, and delivers the response inside the statutory deadline. The workflow runs against the EXISTING "DSAR / Data-Subject Request Handling" Process item (process_type: business_process) — enrich it, never recreate it: one workflow instance per inbound request, and the instance itself is the DSAR register entry (there is no native DSAR/privacy-request item type; the register is the set of these instances). In scope: a single inbound data-subject access or deletion request under GDPR, CCPA/CPRA, or HIPAA, with the statutory clock started at receipt, carried from identity verification through data compilation, exemption review, delivery, and archival, with any correction or portability elements handled inline. It consumes the inbound request and identity artifacts uploaded at the first step, the data map / record of processing activities, the exemption playbook and retention schedule (Policy items with the governing documents attached), and the processor register (Vendor items, category: data_processing). Named deliverables: the access disclosure set or deletion certificate, the exemption log and redlined package, the reasoned rejection notice on the failed-verification path, the delivery evidence and completion-metrics record, systemic-finding Issue items routed to the privacy program, and the archived DSAR case file — the exported workflow record. Out of scope: unrelated privacy processes such as breach notification and privacy impact assessments, which run as their own workflows; this workflow takes no upstream handoff and produces no downstream workflow handoff.
workflow · Context
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
Financial Controls Policy & Segregation-of-Duties Governance
Financial controls policy and segregation-of-duties governance as a decision-aware workflow covering annual policy-suite reapproval and communication, quarterly SoD conflict-matrix refresh, role and system-access conflict screening, mitigating-control documentation, and owner-assignment confirmation, closed out with a control-indexed certified evidence package. Each run is one workflow instance on the existing Process item "Financial Controls Policy & SoD Governance" (process_type: financial_reporting, quarterly cadence), enriching — never recreating — the financial-control Policy suite (entity-wide ITGC and period-end financial reporting oversight policies held as Policy items) and the existing Control items UC-FIN-01 and UC-FIN-05 that the cycle operates. In scope: reapproval and communication of the Policy suite and segregation-of-duties screening across the in-scope entities, finance systems, and personnel, with the cycle running either annual policy reapproval plus the quarterly SoD review or the quarterly SoD review alone; out of scope: access provisioning and remediation execution themselves. As a standing governance control it takes no upstream workflow feed and runs on its own annual/quarterly cadence, but it hands off the remediation and deficiency Issues it raises — elimination-path access conflicts and recorded deficiencies — to the access-management and deficiency-evaluation processes that execute them.
workflow · Context
Financial Systems Transaction Integrity Monitoring
Each cycle runs as a workflow instance attached to the EXISTING financial-reporting Process item (process_type=financial_reporting) that represents financial-systems transaction processing; the four unified controls it operates (UC-FIN-06 through UC-FIN-09) are EXISTING Control items linked to that Process — enrich them, never recreate them. A decision-aware workflow covering input-control queue clearance and configuration revalidation, automated-processing exception disposition and configuration-change approval, interface reconciliation and failure resolution, and system-generated report validation and baselining. It consumes the prior cycle's carry-forward open items (Issue items created when that cycle's evidence package was certified and closed, linked to their Control) as this cycle's scope. In scope each cycle: every in-scope input control, automated processing control, interface, and relied-upon standard report for the cycle window, with change-flagged items retested and prior-cycle carryovers carried forward. The named deliverable is the control-indexed cycle evidence package with the owner's signed certification statement. There is no downstream workflow — the workflow is terminal and self-seeding: the open items this cycle discloses become carry-forward Issue items that seed the next run of this same cycle on the same Process.
workflow · Context
Physical Asset Custody & Count Program
Physical-asset custody and count program as a decision-aware workflow that operates control UC-FIN-10 (physical asset custody & count) each cycle. The instance attaches to the EXISTING UC-FIN-10 Control item — a preventive, physical control run on the standing count calendar — enriching that control's operating history each cycle rather than creating a new record; every variance, custody exception, storage gap, deficiency, and carry-forward it raises is an Issue linked back to that Control. It covers count-package preparation, blind physical count and inspection, book reconciliation, custody-log authorization review, storage and retention verification, and certified, audit-ready evidence archival. In scope each cycle: cash funds (petty cash, tills, vault), negotiable instruments on hand, and physical accounting records under retention, counted against the standing count calendar. It consumes no upstream workflow and hands off to none; cross-cycle continuity is item-based — this cycle's carry-forward Issue items become the next cycle's scoping inputs — so there is no handoff package.
workflow · Context
Production Operations & Processing Integrity Cycle
Runs on the existing Process item for production/IT operations (process_type: it_general_control, frequency: daily — e.g. "Production Batch Operations & Processing Integrity"): one recurring instance per daily bridge/shift attaches to and enriches that Process, never creating a duplicate, and is archived against it at close. It operates the unified controls UC-ACCESS-17/18/20 (Control items, framework containing soc1|nist-csf-2|iso-27001) and consumes the prior cycle's carry-forward Issue items (open incidents, aged exceptions, backup gaps, tuning actions) as its opening population. A decision-aware workflow covering authorized batch execution and monitoring, failure and incident resolution, backup and restore-test verification, performance/capacity/security event monitoring with capacity tuning, and daily data-processing integrity through interface reconciliation and authorized-only output distribution. In scope: the authorized batch, interface, and report population, monitoring thresholds, and the backup and restore-test calendar for the daily processing bridge with weekly capacity and restore-test reviews layered in. Out of scope: application change management and access provisioning, handled by their own ITGC workflows — suspected change-control bypasses and access findings are cross-referred to those owners. No upstream or downstream workflow feeds this cycle; the certified-and-filed evidence step seeds the next run of this same cycle with carry-forward Issue items linked to the Process.
workflow · Context
Year-End Deficiency Aggregation & Severity Evaluation
Year-End Deficiency Aggregation & Severity Evaluation as a modular, decision-aware workflow. The instance runs against the existing fiscal-year ICFR assessment engagement — the Audit item with audit_type=sox_testing whose period_end is fiscal year end — enriching it rather than creating a duplicate: the frozen register snapshot and the full evaluation memo trail attach to its steps, and the overall ICFR conclusion lands on that Audit item (rating/opinion/report_date). It closes the gap between per-deficiency handling and the portfolio view: it freezes the register, reconciles it to every failed test, aggregates related deficiencies, concludes control deficiency versus significant deficiency versus material weakness, and hands conclusions to certification support, remediation, and audit-committee reporting instead of duplicating their work. The named deliverables are the year-end deficiency-evaluation memo (carrying the overall ICFR conclusion) and the countersigned final severity schedule. In scope: freezing and severity-evaluating the year-end deficiency population as of the fiscal-year-end assessment date, kept live through the 10-K filing date under a late-arrival rule. Out of scope, handed off rather than duplicated: fixing the deficiencies (SOX Deficiency Remediation) and reporting them to the board (Quarterly Board & Audit-Committee GRC Reporting). Severity thresholds and the contributing-test population are consumed from the Annual ICFR Scoping & Risk Assessment, SOX Key Control TOD/TOE Test, and SOX ITGC Testing runs — the deficiency register itself is the Issue population (issue_type deficiency, escalating to significant_deficiency and material_weakness as this workflow finalizes).
workflow · Context
Quarterly 302/906 Sub-Certification Cascade
Quarterly 302/906 sub-certification as a modular, decision-aware workflow: it maintains the certifier hierarchy, refreshes the questionnaire for new systems, reorgs, known control issues, and pending deficiencies, launches the tiered cascade, tracks completion and cures gaps at the cutoff, triages exceptions and qualifications with escalation to the disclosure committee where material, summarizes the population for principal-officer 302/906 sign-off, and archives the certification evidence with the period's support. The instance runs against a campaign-record Audit item created for the quarter (audit_type: compliance; period_start/period_end = the quarter; scope = the in-scope entity and process population), enriching that one record — every questionnaire form, certification register, decision form, dashboard, and attestation package hangs off it and the run's own instance is the audit trail. It consumes the in-scope Process items (each carrying its process_owner) and the open deficiency Issue log, originates on its own recurring quarterly cadence with no upstream handoff, and hands its deficiencies downstream as linked Issue items into the SOX Deficiency Remediation, Year-End Deficiency Aggregation & Severity Evaluation, and Quarterly Board & Audit-Committee GRC Reporting workflows. In scope: the quarter's in-scope entities and processes per the current consolidation scope, from process-owner sub-certification through principal-officer 302/906 sign-off and archival, back-planned from the SEC filing date. Out of scope: the officers' external SEC filing mechanics, and the deficiency, year-end aggregation, and board reporting handled by the downstream SOX Deficiency Remediation, Year-End Deficiency Aggregation & Severity Evaluation, and Quarterly Board & Audit-Committee GRC Reporting workflows this cascade routes into.
workflow · Context
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
External Audit Support & PBC
Runs on the existing audit item. Govern external-audit PBC requests from intake and preparation through quality review, secure delivery, clarification, and complete request closure. 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.