Secure Development (SDLC) & Application Security
423 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
A006 — Prevent PII leakage
Prevent PII leakage
control · Context
B001 — Third-party testing of adversarial robustness
Third-party testing of adversarial robustness
control · Context
B002 — Detect adversarial input
Detect adversarial input
control · Context
B004 — Prevent AI endpoint scraping
Prevent AI endpoint scraping
control · Context
B005 — Implement real-time input filtering
Implement real-time input filtering
control · Context
B006 — Prevent unauthorized AI agent actions
Prevent unauthorized AI agent actions
control · Context
B008 — Protect AI system deployment environment
Protect AI system deployment environment
control · Context
B010 — Promote secure patterns in generated code
Promote secure patterns in generated code
control · Context
C002 — Conduct pre-deployment testing
Conduct pre-deployment testing
control · Context
C010 — Third-party testing for harmful outputs
Third-party testing for harmful outputs
control · Context
C011 — Third-party testing for out-of-scope outputs
Third-party testing for out-of-scope outputs
control · Context
C012 — Third-party testing for customer-defined risk
Third-party testing for customer-defined risk
control · Context
D002 — Third-party testing for hallucinations
Third-party testing for hallucinations
control · Context
D003 — Restrict unsafe tool calls
Restrict unsafe tool calls
control · Context
D004 — Third-party testing of tool calls
Third-party testing of tool calls
control · Context
E006 — Conduct vendor due diligence
Conduct vendor due diligence
control · Context
E012 — Document regulatory compliance
Document regulatory compliance
control · Context
E013 — Implement quality management system
Implement quality management system
control · Context
E017 — Document system transparency policy
Document system transparency policy
control · Context
CCPA-1798.106 — Right to correct inaccurate personal information
Right to correct inaccurate personal information
control · Context
APO09 — Managed Service Agreements
Managed Service Agreements
control · Context
APO10 — Managed Vendors
Managed Vendors
control · Context
BAI01 — Managed Programs
Managed Programs
control · Context
BAI02 — Managed Requirements Definition
Managed Requirements Definition
control · Context
BAI03 — Managed Solutions Identification and Build
Managed Solutions Identification and Build
control · Context
BAI04 — Managed Availability and Capacity
Managed Availability and Capacity
control · Context
BAI05 — Managed Organizational Change
Managed Organizational Change
control · Context
BAI06 — Managed IT Changes
Managed IT Changes
control · Context
BAI07 — Managed IT Change Acceptance and Transitioning
Managed IT Change Acceptance and Transitioning
control · Context
BAI08 — Managed Knowledge
Managed Knowledge
control · Context
BAI09 — Managed Assets
Managed Assets
control · Context
BAI10 — Managed Configuration
Managed Configuration
control · Context
BAI11 — Managed Projects
Managed Projects
control · Context
DSS01 — Managed Operations
Managed Operations
control · Context
DSS02 — Managed Service Requests and Incidents
Managed Service Requests and Incidents
control · Context
DSS03 — Managed Problems
Managed Problems
control · Context
P12 — The organization deploys control activities through policies that establish what is expected and procedures that put policies into action.
The organization deploys control activities through policies that establish what is expected and procedures that put policies into action.
control · Context
DORA-Art17-23 — ICT-related incident management, classification and reporting
ICT-related incident management, classification and reporting
control · Context
DORA-Art28-44 — Managing of ICT third-party risk
Managing of ICT third-party risk
control · Context
DORA-Art45 — Information and intelligence sharing arrangements
Information and intelligence sharing arrangements
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-Art15 — Accuracy, robustness and cybersecurity (high-risk)
Accuracy, robustness and cybersecurity (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-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-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-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
GDPR-Art25 — Data protection by design and by default
Data protection by design and by default
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.514 — De-identification of PHI and limited data sets
De-identification of PHI and limited data sets
control · Context
HIPAA-164.526 — Individual right to amend PHI
Individual right to amend PHI
control · Context
A.5.19 — Information security in supplier relationships
Information security in supplier relationships
control · Context
A.5.21 — Managing information security in the ICT supply chain
Managing information security in the ICT supply chain
control · Context
A.5.23 — Information security for use of cloud services
Information security for use of cloud services
control · Context
A.5.26 — Response to information security incidents
Response to information security incidents
control · Context
A.8.11 — Data masking
Data masking
control · Context
A.8.13 — Information backup
Information backup
control · Context
A.8.23 — Web filtering
Web filtering
control · Context
A.8.25 — Secure development life cycle
Secure development life cycle
control · Context
A.8.26 — Application security requirements
Application security requirements
control · Context
A.8.27 — Secure system architecture and engineering principles
Secure system architecture and engineering principles
control · Context
A.8.28 — Secure coding
Secure coding
control · Context
A.8.29 — Security testing in development and acceptance
Security testing in development and acceptance
control · Context
A.8.30 — Outsourced development
Outsourced development
control · Context
A.8.31 — Separation of development, test and production environments
Separation of development, test and production environments
control · Context
A.8.32 — Change management
Change management
control · Context
A.8.33 — Test information
Test information
control · Context
A.8.34 — Protection of information systems during audit testing
Protection of information systems during audit testing
control · Context
A.8.7 — Protection against malware
Protection against malware
control · Context
A.8.8 — Management of technical vulnerabilities
Management of technical vulnerabilities
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.4.2 — Resource documentation
Resource documentation
control · Context
A.4.3 — Data resources
Data resources
control · Context
A.4.4 — Tooling resources
Tooling resources
control · Context
A.4.5 — System and computing resources
System and computing resources
control · Context
A.6.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.7 — AI system technical documentation
AI system technical documentation
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
NIS2-Art21d — Supply chain security
Supply chain security
control · Context
CA-8 — Penetration Testing
Penetration Testing
control · Context
CM-14 — Signed Components
Signed Components
control · Context
CM-3 — Configuration Change Control
Configuration Change Control
control · Context
CM-4 — Impact Analyses
Impact Analyses
control · Context
CM-5 — Access Restrictions for Change
Access Restrictions for Change
control · Context
CM-9 — Configuration Management Plan
Configuration Management Plan
control · Context
CP-10 — System Recovery and Reconstitution
System Recovery and Reconstitution
control · Context
CP-11 — Alternate Communications Protocols
Alternate Communications Protocols
control · Context
CP-12 — Safe Mode
Safe Mode
control · Context
CP-13 — Alternative Security Mechanisms
Alternative Security Mechanisms
control · Context
CP-9 — System Backup
System Backup
control · Context
IR-4 — Incident Handling
Incident Handling
control · Context
MA-2 — Controlled Maintenance
Controlled Maintenance
control · Context
MA-3 — Maintenance Tools
Maintenance Tools
control · Context
MA-4 — Nonlocal Maintenance
Nonlocal Maintenance
control · Context
MA-5 — Maintenance Personnel
Maintenance Personnel
control · Context
MA-6 — Timely Maintenance
Timely Maintenance
control · Context
MA-7 — Field Maintenance
Field Maintenance
control · Context
PM-17 — Protecting Controlled Unclassified Information on External Systems
Protecting Controlled Unclassified Information on External Systems
control · Context
PM-30 — Supply Chain Risk Management Strategy
Supply Chain Risk Management Strategy
control · Context
PT-3 — Personally Identifiable Information Processing Purposes
Personally Identifiable Information Processing Purposes
control · Context
RA-5 — Vulnerability Monitoring and Scanning
Vulnerability Monitoring and Scanning
control · Context
SA-10 — Developer Configuration Management
Developer Configuration Management
control · Context
SA-11 — Developer Testing and Evaluation
Developer Testing and Evaluation
control · Context
SA-15 — Development Process, Standards, and Tools
Development Process, Standards, and Tools
control · Context
SA-16 — Developer-provided Training
Developer-provided Training
control · Context
SA-17 — Developer Security and Privacy Architecture and Design
Developer Security and Privacy Architecture and Design
control · Context
SA-2 — Allocation of Resources
Allocation of Resources
control · Context
SA-20 — Customized Development of Critical Components
Customized Development of Critical Components
control · Context
SA-21 — Developer Screening
Developer Screening
control · Context
SA-22 — Unsupported System Components
Unsupported System Components
control · Context
SA-23 — Specialization
Specialization
control · Context
SA-3 — System Development Life Cycle
System Development Life Cycle
control · Context
SA-5 — System Documentation
System Documentation
control · Context
SA-8 — Security and Privacy Engineering Principles
Security and Privacy Engineering Principles
control · Context
SA-9 — External System Services
External System Services
control · Context
SC-15 — Collaborative Computing Devices and Applications
Collaborative Computing Devices and Applications
control · Context
SC-16 — Transmission of Security and Privacy Attributes
Transmission of Security and Privacy Attributes
control · Context
SC-18 — Mobile Code
Mobile Code
control · Context
SC-2 — Separation of System and User Functionality
Separation of System and User Functionality
control · Context
SC-20 — Secure Name/Address Resolution Service (Authoritative Source)
Secure Name/Address Resolution Service (Authoritative Source)
control · Context
SC-21 — Secure Name/Address Resolution Service (Recursive or Caching Resolver)
Secure Name/Address Resolution Service (Recursive or Caching Resolver)
control · Context
SC-22 — Architecture and Provisioning for Name/Address Resolution Service
Architecture and Provisioning for Name/Address Resolution Service
control · Context
SC-26 — Decoys
Decoys
control · Context
SC-3 — Security Function Isolation
Security Function Isolation
control · Context
SC-32 — System Partitioning
System Partitioning
control · Context
SC-34 — Non-modifiable Executable Programs
Non-modifiable Executable Programs
control · Context
SC-35 — External Malicious Code Identification
External Malicious Code Identification
control · Context
SC-39 — Process Isolation
Process Isolation
control · Context
SC-41 — Port and I/O Device Access
Port and I/O Device Access
control · Context
SC-42 — Sensor Capability and Data
Sensor Capability and Data
control · Context
SC-43 — Usage Restrictions
Usage Restrictions
control · Context
SC-44 — Detonation Chambers
Detonation Chambers
control · Context
SC-45 — System Time Synchronization
System Time Synchronization
control · Context
SC-46 — Cross Domain Policy Enforcement
Cross Domain Policy Enforcement
control · Context
SC-48 — Sensor Relocation
Sensor Relocation
control · Context
SC-49 — Hardware-enforced Separation and Policy Enforcement
Hardware-enforced Separation and Policy Enforcement
control · Context
SC-50 — Software-enforced Separation and Policy Enforcement
Software-enforced Separation and Policy Enforcement
control · Context
SC-51 — Hardware-based Protection
Hardware-based Protection
control · Context
SC-6 — Resource Availability
Resource Availability
control · Context
SI-10 — Information Input Validation
Information Input Validation
control · Context
SI-11 — Error Handling
Error Handling
control · Context
SI-13 — Predictable Failure Prevention
Predictable Failure Prevention
control · Context
SI-14 — Non-persistence
Non-persistence
control · Context
SI-15 — Information Output Filtering
Information Output Filtering
control · Context
SI-16 — Memory Protection
Memory Protection
control · Context
SI-17 — Fail-safe Procedures
Fail-safe Procedures
control · Context
SI-18 — Personally Identifiable Information Quality Operations
Personally Identifiable Information Quality Operations
control · Context
SI-19 — De-identification
De-identification
control · Context
SI-2 — Flaw Remediation
Flaw Remediation
control · Context
SI-20 — Tainting
Tainting
control · Context
SI-21 — Information Refresh
Information Refresh
control · Context
SI-22 — Information Diversity
Information Diversity
control · Context
SI-23 — Information Fragmentation
Information Fragmentation
control · Context
SI-3 — Malicious Code Protection
Malicious Code Protection
control · Context
SI-5 — Security Alerts, Advisories, and Directives
Security Alerts, Advisories, and Directives
control · Context
SI-6 — Security and Privacy Function Verification
Security and Privacy Function Verification
control · Context
SI-7 — Software, Firmware, and Information Integrity
Software, Firmware, and Information Integrity
control · Context
SI-8 — Spam Protection
Spam Protection
control · Context
SR-1 — Policy and Procedures
Policy and Procedures
control · Context
SR-10 — Inspection of Systems or Components
Inspection of Systems or Components
control · Context
SR-11 — Component Authenticity
Component Authenticity
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-4 — Provenance
Provenance
control · Context
SR-5 — Acquisition Strategies, Tools, and Methods
Acquisition Strategies, Tools, and Methods
control · Context
SR-7 — Supply Chain Operations Security
Supply Chain Operations Security
control · Context
SR-8 — Notification Agreements
Notification Agreements
control · Context
SR-9 — Tamper Resistance and Detection
Tamper Resistance and Detection
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-06 — Prompt-injection prevention and limits on resulting harm
The paper explicitly asks which controls help prevent direct and indirect prompt injection and which controls can limit its impact after an injection succeeds.
control · Context
NIST-AGI-07 — Prompt provenance and data-flow tracking
The proposed project explores tracking the provenance of user prompts and input data so that risk assessments and policies can take those sources into account when deciding whether an agent may act.
control · Context
NIST-TEVV-01 — Define evaluation objectives, context, and measurements
The framework starts with organizational goals and the system's operational context, then constructs measurement concepts, test events, and tools that address those objectives.
control · Context
NIST-TEVV-02 — Run evaluations and examine results and limitations
The framework applies the selected tests and synthesizes their results into evidence about system performance, while interrogating the measurements and what the findings support.
control · Context
NIST-TEVV-03 — Evaluate AI systems in realistic operating settings
The draft discusses testing in settings that better reflect real use, including interactions with users and the operating environment, to complement model tests and benchmarks.
control · Context
NIST-TEVV-05 — Test direct and indirect prompt injection
Appendix B includes integrity tests for direct and indirect prompt injection, poisoning, obfuscated inputs, and retrieval weaknesses that could alter intended outputs or outcomes.
control · Context
NIST-TEVV-06 — Test agent tool misuse and unauthorized external actions
Appendix B includes tests for misuse of connected tools and external actions, including unsafe tool selection, excessive agency, unauthorized action attempts, and harmful task execution.
control · Context
DE.AE-04 — Adverse Event Analysis: The estimated impact and scope of adverse events are understood
Adverse Event Analysis: The estimated impact and scope of adverse events are understood
control · Context
DE.CM-09 — Continuous Monitoring: Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events
Continuous Monitoring: Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events
control · Context
GV.SC-01 — Cybersecurity Supply Chain Risk Management: A cybersecurity supply chain risk management program, strategy, objectives, policies, and processes are established and agreed to by organizational stakeholders
Cybersecurity Supply Chain Risk Management: A cybersecurity supply chain risk management program, strategy, objectives, policies, and processes are established and agreed to by organizational stakeholders
control · Context
GV.SC-02 — Cybersecurity Supply Chain Risk Management: Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally
Cybersecurity Supply Chain Risk Management: Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally
control · Context
GV.SC-03 — Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes
Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes
control · Context
GV.SC-04 — Cybersecurity Supply Chain Risk Management: Suppliers are known and prioritized by criticality
Cybersecurity Supply Chain Risk Management: Suppliers are known and prioritized by criticality
control · Context
GV.SC-06 — Cybersecurity Supply Chain Risk Management: Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships
Cybersecurity Supply Chain Risk Management: Planning and due diligence are performed to reduce risks before entering into formal supplier or other third-party relationships
control · Context
GV.SC-08 — Cybersecurity Supply Chain Risk Management: Relevant suppliers and other third parties are included in incident planning, response, and recovery activities
Cybersecurity Supply Chain Risk Management: Relevant suppliers and other third parties are included in incident planning, response, and recovery activities
control · Context
ID.RA-01 — Risk Assessment: Vulnerabilities in assets are identified, validated, and recorded
Risk Assessment: Vulnerabilities in assets are identified, validated, and recorded
control · Context
ID.RA-02 — Risk Assessment: Cyber threat intelligence is received from information sharing forums and sources
Risk Assessment: Cyber threat intelligence is received from information sharing forums and sources
control · Context
ID.RA-03 — Risk Assessment: Internal and external threats to the organization are identified and recorded
Risk Assessment: Internal and external threats to the organization are identified and recorded
control · Context
ID.RA-08 — Risk Assessment: Processes for receiving, analyzing, and responding to vulnerability disclosures are established
Risk Assessment: Processes for receiving, analyzing, and responding to vulnerability disclosures are established
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.DS-11 — Data Security: Backups of data are created, protected, maintained, and tested
Data Security: Backups of data are created, protected, maintained, and tested
control · Context
PR.IR-04 — Technology Infrastructure Resilience: Adequate resource capacity to ensure availability is maintained
Technology Infrastructure Resilience: Adequate resource capacity to ensure availability is maintained
control · Context
PR.PS-02 — Platform Security: Software is maintained, replaced, and removed commensurate with risk
Platform Security: Software is maintained, replaced, and removed commensurate with risk
control · Context
PR.PS-03 — Platform Security: Hardware is maintained, replaced, and removed commensurate with risk
Platform Security: Hardware is maintained, replaced, and removed commensurate with risk
control · Context
PR.PS-06 — Platform Security: Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle
Platform Security: Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle
control · Context
RC.RP-01 — Incident Recovery Plan Execution: The recovery portion of the incident response plan is executed once initiated from the incident response process
Incident Recovery Plan Execution: The recovery portion of the incident response plan is executed once initiated from the incident response process
control · Context
RC.RP-02 — Incident Recovery Plan Execution: Recovery actions are selected, scoped, prioritized, and performed
Incident Recovery Plan Execution: Recovery actions are selected, scoped, prioritized, and performed
control · Context
RC.RP-03 — Incident Recovery Plan Execution: The integrity of backups and other restoration assets is verified before using them for restoration
Incident Recovery Plan Execution: The integrity of backups and other restoration assets is verified before using them for restoration
control · Context
RC.RP-05 — Incident Recovery Plan Execution: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
Incident Recovery Plan Execution: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
control · Context
RS.AN-08 — Incident Analysis: An incident's magnitude is estimated and validated
Incident Analysis: An incident's magnitude is estimated and validated
control · Context
RS.MA-01 — Incident Management: The incident response plan is executed in coordination with relevant third parties once an incident is declared
Incident Management: The incident response plan is executed in coordination with relevant third parties once an incident is declared
control · Context
RS.MA-05 — Incident Management: The criteria for initiating incident recovery are applied
Incident Management: The criteria for initiating incident recovery are applied
control · Context
RS.MI-01 — Incident Mitigation: Incidents are contained
Incident Mitigation: Incidents are contained
control · Context
RS.MI-02 — Incident Mitigation: Incidents are eradicated
Incident Mitigation: Incidents are eradicated
control · Context
500.11 — Third-party service provider security policy
Third-party service provider security policy
control · Context
500.5 — Vulnerability management (penetration testing and scanning)
Vulnerability management (penetration testing and scanning)
control · Context
PCI-Req11 — Test security of systems and networks regularly
Test security of systems and networks regularly
control · Context
PCI-Req5 — Protect all systems and networks from malicious software
Protect all systems and networks from malicious software
control · Context
PCI-Req6 — Develop and maintain secure systems and software
Develop and maintain secure systems and software
control · Context
SOC1-2 — Change management — controls provide reasonable assurance that changes to applications and infrastructure are authorized, tested, approved, and migrated to production appropriately.
Change management — controls provide reasonable assurance that changes to applications and infrastructure are authorized, tested, approved, and migrated to production appropriately.
control · Context
SOC1-3 — Program development / SDLC — controls provide reasonable assurance that new systems and applications are developed, tested, approved, and implemented in accordance with management's intent.
Program development / SDLC — controls provide reasonable assurance that new systems and applications are developed, tested, approved, and implemented in accordance with management's intent.
control · Context
SOC1-4 — Computer operations / job scheduling — controls provide reasonable assurance that production batch jobs and scheduled processing are appropriately defined, executed, monitored, and that exceptions/failures are identified and resolved.
Computer operations / job scheduling — controls provide reasonable assurance that production batch jobs and scheduled processing are appropriately defined, executed, monitored, and that exceptions/failures are identified and resolved.
control · Context
SOC1-5 — Backup and recovery — controls provide reasonable assurance that data is backed up, retained, and recoverable, and that restoration is tested.
Backup and recovery — controls provide reasonable assurance that data is backed up, retained, and recoverable, and that restoration is tested.
control · Context
A1.1 — The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.
The entity maintains, monitors, and evaluates current processing capacity and use of system components (infrastructure, data, and software) to manage capacity demand and to enable the implementation of additional capacity to help meet its objectives.
control · Context
A1.2 — The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.
The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.
control · Context
CC7.4 — The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.
The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.
control · Context
CC7.5 — The entity identifies, develops, and implements activities to recover from identified security incidents.
The entity identifies, develops, and implements activities to recover from identified security incidents.
control · Context
CC8.1 — The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its objectives.
The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures to meet its 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
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
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
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
ITGC-CM — Program change management — changes to applications, databases, and infrastructure are requested, authorized, tested, approved, and migrated to production by appropriate personnel with segregation between development and production.
Program change management — changes to applications, databases, and infrastructure are requested, authorized, tested, approved, and migrated to production by appropriate personnel with segregation between development and production.
control · Context
ITGC-DEV — Program development / SDLC — new systems and significant implementations are designed, developed, tested, approved, and converted/migrated in accordance with management's specifications.
Program development / SDLC — new systems and significant implementations are designed, developed, tested, approved, and converted/migrated in accordance with management's specifications.
control · Context
ITGC-OPS — Computer operations — job scheduling and batch processing, backup and recovery, incident/problem management, and monitoring of system processing and availability.
Computer operations — job scheduling and batch processing, backup and recovery, incident/problem management, and monitoring of system processing and availability.
risk · Direct
Adversarial attacks, data poisoning and prompt injection
Data-poisoning corrupts training data and embeds backdoors; adversarial evasion, prompt injection, and jailbreaks fool deployed models at inference; model extraction steals proprietary weights/logic — enabling harmful or policy-violating outputs.
risk · Direct
Emergent behaviour and unsafe AI system integration
Large-scale or multi-model pipelines exhibit emergent capabilities/failures not present in any component and not predictable from component testing; integration with legacy systems introduces interface mismatches and configuration errors.
risk · Direct
Insecure AI-generated code and hallucinated or typosquatted dependencies
Code-generating AI produces insecure defaults (injection-prone queries, weak authentication and session handling, unsafe logging) or specifies non-existent, hallucinated, or typosquatted packages that attackers pre-register, introducing vulnerabilities and malicious dependencies into production software.
risk · Direct
AI supply-chain compromise and provider concentration
Because the organization relies on third-party pretrained models, datasets, and libraries that may carry backdoors, malicious code, or bias, and concentrates on a few external AI API providers, AI-dependent workflows are exposed to both supply-chain compromise and provider outage or insolvency, resulting in compromised model behaviour or sudden loss of AI capability.
risk · Direct
Absent or weak change-control procedures
Changes to systems, software, hardware, or configurations without formal approval and testing (including unauthorized or poorly tested hardware/config changes) introduce new vulnerabilities, instability, or failed releases.
risk · Direct
Corruption or integrity loss of critical data
Intentional or accidental alteration, deletion, defacement, or injection of false-but-believable data into systems (including web defacement and data from untrustworthy sources) renders data inaccurate and erodes confidence in it.
risk · Direct
Acceptance of data from untrustworthy sources
Injection or acceptance of data from untrusted or malicious sources (including position-detection/tracking data) causes incorrect processing or decisions and can seed downstream integrity loss.
risk · Direct
Product design and model errors
Defective product design, errors in model or pricing assumptions embedded in products, and failure to investigate customer complaints cause systematic customer harm and mis-selling losses.
risk · Direct
Absence of privacy-by-design and default
Because systems and products are built without embedding privacy controls at the architecture level, privacy protections are bolted on after launch rather than applied by default, so personal data is over-collected and exposed and costly manual remediation is required.
risk · Direct
Applications running with excessive privilege / insecure design
Applications or services running under privileged accounts, opening unnecessary network connections, or lacking secure-by-design architecture mean a single compromise grants broad system access and expands attack surface.
risk · Direct
Malware delivery, insertion and compromise of systems
Adversary crafts and delivers known, modified, or targeted malware (via email, web, removable media, or downloadable software) and compromises system software to take control, exfiltrate data, or degrade functions.
risk · Direct
Ransomware disrupting operations and data availability
Criminal groups deploy ransomware that encrypts systems and data, disrupting operations, causing losses, and demanding extortion payment — a high-impact convergence of malware, availability, and continuity risk.
risk · Direct
Vulnerabilities introduced during software development
Inherent weaknesses in programming languages and development environments introduce errors and exploitable vulnerabilities into software products, and software malfunctions cause incorrect outputs, crashes, or security weaknesses.
risk · Direct
Loss of system maintainability
Loss of the ability to maintain, update, or repair information systems due to missing documentation, tools, skills, or unversioned software — leaving systems unpatchable and increasingly fragile over time.
risk · Direct
Software and information-system failure
Failure or malfunction of operating-system, networking, or application software (defects, resource depletion, failed releases) causing loss of availability/integrity and impeding mission/business functions — including core banking/payments outages.
risk · Direct
Malicious supply-chain injection of tampered hardware/software
Adversary creates false-front suppliers or intercepts the supply chain to insert counterfeit or tampered hardware, corrupted software/firmware, or malicious components into products and information systems.
risk · Direct
Inadequate vulnerability scanning and pre-release testing
Software released without adequate testing, and no regular vulnerability scanning or penetration testing, leaves exploitable defects undiscovered until they manifest — or are exploited — in production.
risk · Direct
Zero-day exploitation
Adversary employs attacks that exploit as-yet-unpublicized vulnerabilities (targeted, based on reconnaissance, or nontargeted), compromising systems before any patch or signature exists.
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
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-16 — Authorize, test, and approve changes and development
Changes to applications and infrastructure, and new system development, follow a documented lifecycle: authorized request, risk-assessed design, testing in non-production environments, documented approval, and controlled migration to production by personnel independent of development. Emergency changes are ratified retrospectively, and evidence of each gate is retained.
unified · Context
UC-ACCESS-17 — Execute, monitor, and recover production processing
Production batch jobs and scheduled processing are defined, authorized, and monitored, with failures and exceptions logged, tracked, and resolved in a timely manner. Data is backed up on a defined schedule with protected, retained copies, and restoration is periodically tested to confirm recoverability within objectives.
unified · Context
UC-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-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-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-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-18 — Defend AI interfaces against adversarial input, injection, and endpoint abuse
Protect the inference and agent interfaces of AI systems with layered input defenses: screen prompts, uploaded content, retrieved data, and tool results for prompt-injection and jailbreak patterns before they reach the model or trigger actions; detect and alert on adversarial-input campaigns; and rate-limit, authenticate, and monitor endpoints to prevent scraping, model extraction, and resource-exhaustion abuse. Tune detections from evaluation findings and retain filter configurations and detection logs as evidence.
unified · Context
UC-AI-19 — Constrain agent actions and tool use to authorized scope
Bound what autonomous agents may do: allow-list the tools, connectors, and actions each agent may invoke; scope its permissions to the task, user, and context; require human approval for irreversible, high-value, or out-of-policy actions; execute agent-generated code only in isolated sandboxes; and scan agent configuration artifacts such as hooks, skills, and rules for injected instructions. Log every tool call with its authorization decision and review denied and escalated calls.
unified · Context
UC-AI-21 — Commission independent third-party AI evaluations on a quarterly cadence
Engage an independent evaluator at least quarterly to test each in-scope AI system against its defined risk categories: adversarial robustness and jailbreak resistance, harmful and out-of-scope outputs, agent-specific high-risk outputs, hallucination rates, and unsafe or unauthorized tool calls. Fix the test scope and pass thresholds in advance, track every finding to remediation and retest, and retain evaluator reports, methodologies, and remediation evidence.
unified · Context
UC-AI-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-AI-25 — Guide code-generating systems toward secure patterns and safe dependencies
Configure code-generating AI systems with secure-by-default guidance: steer generated code toward parameterized queries and safe frameworks for common vulnerability classes, established authentication and authorization libraries, secure session and cookie settings, input validation and safe error handling, and logging that excludes secrets; require pinned, verified dependency specifications so hallucinated or typosquatted packages are not introduced; and test the guidance against a vulnerability benchmark on change. Retain system-prompt and policy configurations and benchmark results as evidence.
unified · Context
UC-ASSET-09 — Receive, analyze, and act on threat and vulnerability intelligence
Receive cyber threat intelligence from information-sharing forums and other sources, and identify and record internal and external threats to the organization. Operate a documented channel to receive, analyze, and respond to vulnerability disclosures from internal and external reporters. Track intelligence and disclosures to closure and feed the results into risk assessment and remediation.
unified · Context
UC-ASSET-12 — Operate scheduled processing, backup, and availability monitoring
Schedule and monitor batch jobs and system processing, investigating and resolving failures through documented incident and problem management. Perform and verify data backups and periodically test recovery capability. Monitor system processing and availability against defined service expectations, with documented follow-up on deviations.
unified · Context
UC-BCDR-03 — Back up data and verify restorability
Back up information, software, and system images at a frequency and scope aligned to defined recovery point objectives, protect backup copies from unauthorized access and modification, and keep copies separate from the primary environment. Verify backup integrity and restorability through periodic test restores, and verify the integrity of backups before using them for restoration.
unified · Context
UC-BCDR-05 — Manage capacity to meet availability requirements
Determine and monitor the processing capacity and utilization of infrastructure, data, and software against current and forecast demand, and add capacity before demand exceeds defined thresholds. Protect availability of shared resources through priority-based allocation or quotas, and alert responsible personnel when capacity thresholds are breached.
unified · Context
UC-BCDR-06 — Resolve operational incidents and eliminate root causes
Log, classify, and prioritize operational and security incidents and service requests, respond within defined service levels, and escalate by severity until service is restored. Classify and report major ICT incidents to regulators, customers, and affected parties within required timeframes. Perform root-cause analysis of significant and recurring incidents, and track underlying problems through to permanent resolution.
unified · Context
UC-BCDR-07 — Execute recovery plans to restore systems and operations
When disruption occurs, execute the documented recovery procedures to restore systems, applications, and data to a known operational state within recovery time objectives. Select, scope, and prioritize recovery actions based on criticality and dependencies, verify the integrity of restored assets, and confirm normal operating status before returning systems to service.
unified · Context
UC-BCDR-11 — Sustain operations via safe modes and alternate mechanisms
Design critical systems to continue operating safely when primary capabilities fail: enter a defined safe mode of operation that restricts functions when specified conditions are detected, switch to alternate communications protocols to maintain continuity, and employ alternative security mechanisms when primary security safeguards are unavailable.
unified · Context
UC-BCDR-12 — Operate IT services according to defined procedures
Execute day-to-day IT operations, including job scheduling, processing, infrastructure monitoring, and facility management, according to documented operating procedures. Monitor operations against expected outcomes, record exceptions, and correct deviations to sustain reliable service delivery.
unified · Context
UC-BCDR-16 — Participate in cyber threat intelligence sharing
Establish arrangements to exchange cyber threat information and intelligence, such as indicators of compromise, tactics, and alerts, with trusted communities of peers and authorities. Operate the exchange under agreements that protect sensitive business information and comply with data protection requirements.
unified · Context
UC-CONFIG-02 — Authorize, test, and approve changes before production
Manage changes to applications, databases, infrastructure, configurations, and procedures through a documented process in which changes are requested, analyzed for security and risk impact, authorized, tested, approved, and implemented by appropriate personnel. Require migration to production to be performed by individuals independent of development, and retain records evidencing each step. Define rollback plans and an emergency-change path with retrospective review and approval.
unified · Context
UC-CONFIG-03 — Separate environments and protect production data in testing
Separate development, test, and production environments, and enforce physical and logical access restrictions so only authorized personnel can make changes to production systems. Select, protect, and manage information used for testing, anonymizing or masking production data before use in non-production environments and removing it when testing completes.
unified · Context
UC-CONFIG-04 — Build security and privacy into software design and upkeep
Engineer security and data-protection requirements into systems and software from design onward, applying secure coding standards, pre-release security testing, and privacy-preserving defaults such as data minimization and pseudonymization. Maintain software after release by remediating identified vulnerabilities and applying security patches within risk-based timeframes. Replace or remove software that is unsupported or no longer justified by risk.
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-CONFIG-07 — Perform controlled, timely maintenance of systems and hardware
Schedule, approve, document, and review maintenance, repair, and replacement of systems and hardware in accordance with manufacturer specifications and organizational requirements, whether performed on site or off site. Sanitize equipment before off-site maintenance and verify security controls after maintenance is completed. Obtain maintenance support and spare parts within defined timeframes so hardware is maintained, replaced, or removed commensurate with risk.
unified · Context
UC-CONFIG-08 — Control maintenance tools, personnel, and remote sessions
Approve, inspect, and control maintenance tools and media brought into facilities, checking them for improper modification and malicious code. Authorize and supervise maintenance personnel against a current list of approved individuals, with escorts for those lacking required access authorizations. Require nonlocal maintenance sessions to use approved connections and strong authentication, record the session, and terminate connections when maintenance is complete.
unified · Context
UC-CONFIG-09 — Document configuration management policy, plan, and procedures
Develop, document, and implement a configuration management plan defining roles, responsibilities, processes, and procedures for identifying, managing, and protecting configuration items throughout the system development life cycle. Deploy these expectations through approved policies and actionable procedures, review them periodically, and update them when the environment or organization changes.
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-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-12 — De-identify, mask, or pseudonymize personal data
Apply masking, pseudonymization, or de-identification when full identifiers are not required, following policy and the applicable legal standard (e.g., expert determination or safe-harbor methods, limited data sets under agreement). Protect the keys and mappings that could re-identify data, and prohibit re-identification attempts.
unified · Context
UC-IR-05 — Assess and validate incident scope, impact, and magnitude
For each declared or suspected incident, estimate the scope of affected systems, data, and business processes and the resulting impact, and validate those estimates as investigation proceeds. Document magnitude assessments — records affected, service disruption, and financial exposure — and update them at defined points so response priority, escalation, and notification decisions rest on current, validated figures.
unified · Context
UC-IR-06 — Respond to, contain, and eradicate declared incidents
On declaration of an incident, execute the incident response plan in coordination with internal teams and relevant third parties such as providers, law enforcement, and insurers. Contain the incident using predefined strategies for its category, eradicate the cause by removing malicious artifacts and closing exploited weaknesses, and coordinate handling with contingency and recovery activities through to resolution. Communicate response status as the plan requires and document all response actions taken, feeding lessons into response procedures.
unified · Context
UC-IR-09 — Recover from incidents using defined initiation criteria
Define objective criteria for initiating incident recovery — such as confirmed eradication, completed forensic preservation, and management authorization — and apply them before restoration begins. Identify, develop, and execute recovery activities that restore affected systems, data, and services to a known-good state, verifying integrity before return to production and confirming with business owners that normal operations have resumed.
unified · Context
UC-NET-04 — Isolate system, user, and security functions
Separate user functionality, including user-interface services, from system-management functionality, and isolate security functions from non-security functions using partitioning, virtualization, or separate physical or logical components. Partition the system so components of differing sensitivity reside in separate domains, limiting the blast radius of a compromise.
unified · Context
UC-NET-06 — Enforce separation with hardware and software mechanisms
Employ hardware-enforced and software-enforced separation mechanisms to isolate critical security functions and enforce policy between execution domains. Use hardware-based protections such as write-protected or read-only memory, and load and execute key programs from hardware-enforced non-modifiable media so critical code cannot be altered at runtime.
unified · Context
UC-NET-07 — Secure name resolution and time services
Provide authoritative name-resolution service with origin authentication and integrity verification (e.g., DNSSEC), and perform data-origin authentication and integrity validation in recursive or caching resolvers. Architect name-resolution services to be fault tolerant and to enforce internal and external role separation, and synchronize system clocks to authoritative time sources so events can be correlated reliably.
unified · Context
UC-NET-10 — Deploy deception and dynamic detection capabilities
Deploy decoy components (honeypots or honeynets) and honeyclient capabilities to attract, detect, and analyze malicious activity and externally hosted malicious code without exposing production assets. Detonate suspicious files, URLs, and code in isolated sandbox environments before delivery to users, and relocate or reposition detection sensors as threat conditions change.
unified · Context
UC-NET-12 — Restrict communication-capable devices, ports, and sensors
Prohibit remote activation of collaborative computing devices (cameras, microphones, shared whiteboards) except where explicitly authorized, and give people present an explicit indication of use. Physically or logically disable unneeded connection ports and input/output devices, and restrict on-board sensor capability and the use of sensor-collected data. Define, authorize, and enforce documented usage restrictions for components subject to them.
unified · Context
UC-NET-13 — Control mobile code and web content
Define acceptable and unacceptable mobile-code technologies, and authorize, monitor, and control mobile code so unauthorized active content cannot execute in browsers, documents, or email. Filter access to external websites by category and reputation to reduce exposure to malicious content, and log enforcement actions.
unified · Context
UC-NET-14 — Enforce policy on cross-domain information exchange
Associate security and privacy attributes (labels) with information exchanged between systems and preserve them in transmission so receiving systems can enforce handling policy. Enforce mandatory information-exchange policy at cross-domain interconnection points so only authorized data types and flow directions are permitted between security domains.
unified · Direct
UC-SDLC-01 — Follow a secure development lifecycle with approval gates
Define and follow a documented development lifecycle with security integrated into every phase from requirements through design, build, test, and release, including defined security activities, secure development standards and tooling, and management approval gates. Ensure new systems and significant changes are designed, developed, tested, and approved in accordance with management's specifications before migration to production. Monitor adherence to and performance of the secure development process.
unified · Direct
UC-SDLC-02 — Plan and resource development programs and projects
Manage development initiatives as governed programs and projects with defined scope, stakeholders, benefits, milestones, and risk management through delivery. Identify information security requirements during planning and allocate the resources and budget needed to fulfill them as an explicit line item.
unified · Direct
UC-SDLC-03 — Define and approve security requirements for applications
Elicit, analyze, document, and approve functional and non-functional requirements, including application security requirements such as authentication, authorization, input and output handling, logging, and data protection, before solution design and build, assessing feasibility and alternative options. Manage requirement changes and requirements risk, and obtain stakeholder and management approval of the final requirements.
unified · Direct
UC-SDLC-04 — Engineer systems with secure architecture and design
Design and build systems using established secure architecture and engineering principles: least privilege, defense in depth, isolation of execution domains (process and memory separation), fail-safe defaults, and attack-surface minimization, applied from concept through implementation. Require developers to produce and maintain a security architecture description consistent with the enterprise architecture. Engineer solutions to remain accurate, robust, and resilient against errors, faults, and adversarial manipulation.
unified · Direct
UC-SDLC-05 — Enforce secure coding and input validation standards
Establish and enforce secure coding standards for in-house and reused code, covering common weakness classes and secure use of components. Validate all information inputs for syntax, semantics, type, length, and range at trust boundaries, rejecting or safely encoding unsafe input. Verify adherence through code review and static analysis before release.
unified · Direct
UC-SDLC-06 — Maintain configuration control over systems and code
Maintain configuration management over solution components throughout development and operation: identify configuration items, establish and protect baselines for code, dependencies, and build settings, record and verify configuration information, and review deviations. Require developers to track the integrity of changes to configuration items, implement only approved changes, and track and resolve resulting security flaws.
unified · Direct
UC-SDLC-07 — Approve, test, and accept changes before production release
Evaluate, prioritize, and authorize all IT changes, including emergency changes, before implementation, with documented impact and risk assessment. Establish acceptance criteria, perform acceptance testing in an environment representative of production, obtain business and IT approval, and promote releases through a controlled, auditable transition with fallback plans and post-implementation review.
unified · Direct
UC-SDLC-08 — Maintain current system documentation and knowledge
Obtain, produce, and maintain current administrator and user documentation for systems, covering secure configuration, use, and maintenance, and protect and distribute it to authorized roles. Keep development and operational knowledge validated, current, and available to the personnel who need it.
unified · Direct
UC-SDLC-09 — Prepare and train users for new and changed systems
Plan and manage the organizational side of new and changed systems: communicate impacts, prepare business and IT stakeholders, and sustain adoption after go-live. Require system developers to provide role-appropriate training and training materials for administrators, users, and security personnel before deployment.
unified · Direct
UC-SDLC-10 — Oversee outsourced development and vet developers
Direct, monitor, and review outsourced and third-party development: contractually define secure-development requirements, intellectual property ownership, and audit rights, review deliverables against requirements, and obtain evidence of security testing. Screen developers of critical systems against defined criteria before granting them access to development environments.
unified · Direct
UC-SDLC-11 — Apply specialized development to critical components
Identify components critical to security or mission and, where commercial items cannot meet requirements, use customized or specialized development, such as reimplementation, custom variants, or context-specific augmentation, to reduce supply-chain and assurance risk. Document the rationale and assurance evidence for each specialized component.
unified · Direct
UC-SDLC-12 — Manage solution assets and retire unsupported components
Manage application and infrastructure assets through their life cycle: maintain an accurate record of solution assets, ownership, and licensing, and optimize their use and cost. Identify system components approaching end of support and replace or upgrade them, or apply documented compensating controls with explicit risk acceptance, before support lapses.
unified · Direct
UC-SDLC-13 — Plan solution availability and capacity
Plan, monitor, and manage the availability and capacity of solutions and services against current and forecast business requirements. Assess the impact of demand changes, address projected shortfalls through corrective plans, and validate that agreed availability and capacity targets are met.
unified · Direct
UC-SDLC-14 — Protect production systems during audit testing
Plan and agree audit and assurance testing of operational systems between the tester and appropriate management before testing begins: define and approve scope, limit testers to read-only access where possible or use isolated copies, schedule tests to minimize disruption, and monitor and log all audit access.
unified · Context
UC-TPRM-01 — Operate a third-party security risk management program
Establish and operate a management-approved third-party and supply-chain risk management program with a written strategy, policies, and procedures, reviewed at defined intervals and after significant changes to the supply chain or threat landscape. Define and communicate roles and responsibilities for supplier, customer, and partner relationships, and integrate third-party and supply-chain risk into enterprise and cybersecurity risk management. Maintain a register of third-party relationships and contractual arrangements prioritized by criticality, and assess criticality, substitutability, and concentration risk before contracting. Apply risk-based due diligence, embed security requirements, audit and access rights, termination rights, and sub-outsourcing conditions in agreements, and protect organizational information processed, stored, or transmitted on external systems. Define, agree, and periodically review service agreements and supplier performance, reassess third parties on a defined cycle, operate controls to identify and address weaknesses across the relationship life cycle, and maintain documented, tested exit strategies for providers supporting critical or important functions.
unified · Context
UC-TPRM-02 — Perform risk-based due diligence before engaging vendors
Before entering a formal relationship, perform security due diligence on prospective vendors and business partners proportionate to their criticality, evaluating security posture, financial and operational risk, and supply-chain exposure, and document the acceptance decision. Use acquisition strategies, sourcing methods, and selection criteria designed to reduce supply-chain risk before contract award.
unified · Context
UC-TPRM-05 — Include suppliers in incident notification and response
Establish agreements or contractual provisions requiring suppliers to notify the organization of security incidents and supply-chain compromises within defined timeframes. Include relevant suppliers and third parties in incident-response planning, exercises, response, and recovery activities, with coordination roles defined in advance.
unified · Context
UC-TPRM-07 — Verify component authenticity, provenance, and integrity
Document and maintain the provenance of critical systems, components, and data through the supply chain, for example with bills of materials and chain-of-custody records. Apply anti-tamper and anti-counterfeit measures: tamper-resistant and tamper-evident packaging and design, inspection of systems and components at receipt and on indication of tampering, and verification of component authenticity with training and reporting of suspected counterfeits.
unified · Context
UC-TPRM-08 — Govern security of external and cloud service use
Define and enforce processes for acquiring, using, managing, and exiting external system services and cloud services in line with the organization's information security requirements. Require external providers to comply with those requirements, define oversight roles and responsibilities on both sides, agree service and exit terms, and monitor provider compliance on an ongoing basis.
unified · Context
UC-TPRM-09 — Protect supply chain information through OPSEC
Apply operations security safeguards to supply-chain activities: identify sensitive information about suppliers, shipments, configurations, and delivery schedules, protect it from collection by adversaries, and limit its disclosure to parties with a validated need to know.
unified · Context
UC-VULN-01 — Scan for vulnerabilities and track advisories on a defined cadence
Run authenticated vulnerability scans across all in-scope systems and applications on a defined cadence — at least quarterly and after significant changes — using tools whose vulnerability feeds are kept current. Subscribe to security advisories and directives from authoritative sources, assess their applicability, and disseminate them to system owners with required actions and completion dates. Validate and record every finding in a central register with severity ratings, and track findings to closure within severity-based timeframes. Share scan results and advisory status with designated security and management roles.
unified · Context
UC-VULN-02 — Test security through independent penetration exercises
Commission penetration tests of systems, applications, and networks at least annually and after material changes, performed by qualified testers independent of the target's operation and governed by documented rules of engagement. Include both internal and external testing perspectives, validate the exploitability of identified weaknesses, and report results to accountable management. Track corrective actions from each exercise to verified closure, and use the results as a separate evaluation of whether security controls are present and functioning.
unified · Context
UC-VULN-03 — Remediate identified flaws within defined timeframes
Identify, evaluate, and install security-relevant software and firmware updates within documented, risk-based timeframes (for example, critical flaws within 15 days and high-severity within 30). Test patches for effectiveness and side effects before production deployment, use central patch-management tooling to measure coverage, and verify remediation by rescan or configuration check. Document time-bound compensating measures or formal risk acceptance for any flaw that cannot be corrected on schedule.
unified · Context
UC-VULN-04 — Test software security during development and acceptance
Require developers and project teams to perform security testing throughout development and at acceptance, including a documented test plan, static and dynamic analysis appropriate to the technology, and retained evidence of test execution and results. Define security acceptance criteria for new systems and major upgrades, and remediate weaknesses found before release into production.
unified · Context
UC-VULN-05 — Block malware, spam, and phishing across all systems
Deploy centrally managed anti-malware protection on all system components commonly affected by malicious software, with real-time and periodic scanning, automatic signature and engine updates, and tamper protection so users cannot disable or alter it. Quarantine or block detected code, alert responders, and log all detections; periodically re-evaluate components deemed not commonly affected. Filter email and web channels for spam and phishing at entry and exit points, and support the technical controls with user awareness on malware and phishing.
unified · Context
UC-VULN-06 — Verify software, firmware, and information integrity
Employ integrity-verification mechanisms — file-integrity monitoring, cryptographic hash or signature validation, and secure or measured boot where supported — to detect unauthorized changes to software, firmware, and critical information, alerting designated personnel on detection. Verify the correct operation of security and privacy functions at startup, on demand, and on a defined schedule, and act on failures or anomalies. Continuously monitor computing hardware, software, and runtime environments so unexpected changes surface as potentially adverse events for analysis.
unified · Context
UC-VULN-07 — Harden runtime error handling, output filtering, and memory
Build and configure software so that failures and outputs cannot be weaponized: handle errors gracefully, generating only the minimum information needed for correction and revealing no sensitive data in messages or logs. Validate and filter information output from applications so it matches expected content and format before release to users or downstream systems. Enable hardware- and OS-level memory protections such as data-execution prevention and address-space layout randomization on all supporting systems.
unified · Context
UC-VULN-08 — Engineer systems to fail predictably and safely
Determine mean time to failure for components whose failure could compromise security or availability, and replace or refresh them within predicted tolerances before failure occurs. Define and implement fail-safe procedures so that on detected failure conditions systems enter a known safe state — preserving security protections, alerting designated personnel, and preventing unsafe continuation of operations.
unified · Context
UC-VULN-09 — Employ non-persistence and information-resilience techniques
Reduce the attack surface available to persistent adversaries by provisioning selected components and services non-persistently and refreshing them from known-good, trusted sources at defined intervals or on demand. Refresh designated information at defined frequencies to purge stale or potentially corrupted data, source critical information from diverse suppliers or paths, and fragment designated high-value information across separate systems so no single compromise exposes or destroys it.
unified · Context
UC-VULN-11 — Embed taint mechanisms to detect data exfiltration
Embed covert taint mechanisms — such as beacon files, honeytokens, or watermarked records — into organizational systems and datasets so that exfiltration, improper modification, or unauthorized use of data can be detected. Monitor for taint activations, alert the security team when they fire, and periodically test that the mechanisms remain functional.
workflow · Context
Cybersecurity Assurance Review
Cybersecurity Assurance Review — a CAE-owned assurance engagement that runs on the EXISTING Audit item opened from the audit plan (audit_type=it_audit, status PLANNED, lead_auditor and scope already set): the workflow instance attaches to that item and enriches it end to end, never creating a duplicate engagement record. It covers the three IIA Cybersecurity Topical Requirement domains (governance, risk management, and control activities) over the cyber estate bounded in the engagement memo (in scope: named legal entities, networks, cloud tenants, and OT/ICS where included; out of scope: areas whose assurance is documented as delivered by other engagements), testing against the NIST 800-53 Rev 5 catalog with CSF 2.0 / ISO 27001 as the aggregation frame. It originates from the audit plan (no upstream workflow) and produces the findings register (one four-Cs Issue per finding), the cyber posture summary carrying the per-domain and overall Standard 14.5 conclusions, and the approved engagement package — which it hands to the downstream Audit Report Drafting workflow.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
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
Third-Party Vendor Assurance Engagement
Runs on the existing Audit item for this engagement (audit_type=vendor_review) — the workflow enriches that already-planned engagement record, it never creates a duplicate — consuming the confirmed scope, criteria, and calendar handed off from Audit Engagement Planning. An IA-led third-party vendor assurance engagement that concludes on the design and operating effectiveness of the organization’s TPRM program — governance, risk tiering, vendor control-environment reliance, monitoring, exclusions, and reporting. Vendors under test are the existing Vendor items, each finding is an Issue item, and the named deliverable is a reperformable engagement workpaper package. In scope: assuring the program (IA evaluates management’s third-party risk management; it does not operate it). Out of scope: operating the vendor lifecycle (onboarding, tier refresh, remediation), which belongs to the second-line Third-Party Vendor Risk Lifecycle workflow; deep single-report SOC work, which can be delegated to the reusable Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow; and ICT arrangements caught by regulatory regimes, which route to Third-Party ICT Vendor Regulatory Assurance. Findings and the engagement conclusion exit through Audit Report Drafting, and action plans route to Finding Remediation & Action-Plan Monitoring.
workflow · Context
Technical Security Testing & Pentest Engagement
Runs ON an existing Audit item (audit_type: it_audit) that represents the authorized penetration-test engagement — the workflow instance attaches to that record and enriches it (scope, ratings, dates, and the assurance conclusion write back to its fields); it never creates a duplicate engagement record. In scope: authorized technical testing (reconnaissance, discovery, exploitation validation, severity rating, reporting, and retest) of the defined system boundary against its control baseline and assessment objective, with each confirmed finding recorded as an Issue linked to the anchor Audit and its affected Controls. Out of scope: any testing beyond the agreed rules of engagement, and the downstream remediation program itself — confirmed control gaps and open POA&M findings are handed to the Security Control Assessment & POA&M Remediation workflow, and the assurance conclusion to the Cybersecurity Assurance Review workflow. No upstream workflow feeds this engagement; its inputs are the anchor Audit, the in-scope system boundary (Process items), the control baseline (Control items, framework nist-800-53), the assessment objective and signed authorization, and any open Issue items (source: penetration_test / vulnerability_scan) from prior engagements.
workflow · Context
Vulnerability & Patch Management Cycle
Recurring vulnerability & patch management lifecycle covering NIST SP 800-53 RA-5 (vulnerability scanning) and SI-2 (flaw remediation) and NIST CSF 2.0 ID.RA and PR.PS. Each cycle runs as one recurring instance anchored to the EXISTING vulnerability & patch management Control item (a Control with domains = vulnerability_patch_management — e.g. the UC-VULN-01 scanning control, control_owner = cycle owner); the instance enriches that Control's evidence trail rather than creating a new subject, and the instance itself is the cycle record. In scope: authenticated scanning of the confirmed asset inventory, severity-based triage against the SLA matrix, standard and emergency remediation, rescan verification, time-bound risk acceptance of residuals, metrics reporting, and cycle closure. Named deliverables: the deduplicated, enriched finding register (one vulnerability_scan Issue per finding, linked to the Control), rescan closure evidence, time-bound compensating-control-backed risk-acceptance exceptions (policy_exception Issues), and the cycle KPI & trend report. Consumed as inputs, not produced: the authoritative asset inventory / CMDB and the enterprise change-approval policy (a Policy item). The workflow is self-triggered by its own scheduled scan window (or an actively-exploited advisory) with no upstream or downstream workflow — its carry-forward package feeds the next iteration of this same cycle at intake.
workflow · Context
Business Continuity & DR Test Exercise
Run one operating cycle of an existing business continuity / disaster recovery plan-testing Control (the BC/DR test control this instance attaches to, UC-BCDR-04 "tests"): plan, execute, and evaluate a BC/DR exercise against the RTO and RPO objectives, then fold the resulting gaps back into the BC and DR plans as versioned redlines — a decision-aware workflow. It consumes as declared inputs the in-force BC and DR plans (existing Policy items), the business impact analysis (BIA), and prior after-action reports; it creates an Audit item (audit_type=operational) as the definitive exercise record, and produces named deliverables: an approved exercise package, an actual-versus-target RTO/RPO scorecard, remediation findings (Issue items), and a signed-off after-action report with an indexed evidence package. In scope: scoping, running, and evaluating one scheduled or triggered BC/DR exercise for the selected in-scope systems and business services, and folding resulting gaps back into the BC and DR plans. Out of scope: real incident response, and recovery-objective (RTO or RPO) changes to systems outside the agreed exercise scope. Standalone: no upstream or downstream workflow is required; any cross-workflow linkage — for example a related incident-response or BIA-maintenance workflow — is expressed as a declared input, not a predecessor.
workflow · Context
CSF 2.0 Profile & Maturity Assessment
Runs on an Audit item created for this assessment cycle (audit_type = readiness) — the CSF assessment engagement the workflow instance attaches to and enriches as it progresses (scope, period, rating, and report fields are written on that Audit item; every in-scope Control is linked to it so the controls-scoped profile is queryable). Build, against that boundary, a NIST CSF 2.0 Current Profile, a Target Profile, an organizational Tier rating, a subcategory gap analysis, and a CISO-ready remediation roadmap. The workflow originates on its own — scoping ingests prior CSF profiles and open POA&M (Issue) items as data, not as a named upstream handoff. In scope: rating the in-scope control set against the CSF 2.0 Core, setting target outcomes, assigning a Tier, and producing a prioritized roadmap. Out of scope: executing the remediation projects themselves and re-performing independent assurance testing. The named deliverable is the assessment package (profiles, gap analysis, Tier, posture report, roadmap, closure artifact), handed off to TWO downstream workflows that consume it rather than repeat the profiling: the Cybersecurity Assurance Review (always) and the AI Governance & Risk/Impact Assessment (only when AI systems fall inside the boundary).
workflow · Context
Threat Intelligence & Insider Threat Program
Runs on the existing Process item "Threat Intelligence & Insider Threat Program" (process_type=security_process, process_owner = program lead) — a long-lived program record related to the Control items it operates (UC-RISK-17, UC-BCDR-16, UC-GOV-37); each cycle is one recurring workflow instance attached to that Process, enriching the standing program rather than creating a new one. Decision-aware, covering NIST SP 800-53 PM-12, PM-16, and RA-10 and NIST CSF 2.0 ID.RA and DE.CM. In scope: cyclic intake and curation of threat intelligence into a validated intake register and intel cards, governed internal dissemination and TLP-marked outbound sharing packages, intel-driven threat hunts (producing the hunt summary) and any resulting investigation record, and privacy-guarded review of insider-threat indicators with a governed board disposition and a restricted insider case file, closing with a program-effectiveness report and a reperformable cycle archive. No upstream workflow feeds it; the only cross-run input is the prior cycle's carry-forward package (the carry-forward document from the previous instance's program-effectiveness report step, which closes each cycle), and each cycle emits the next one. Out of scope and handed off only in prose (no terminal handoff node): incident-response execution (the incident-response process, once an incident is declared at open-investigation) and HR/legal employment actions (owned by those functions within an insider case). Each cycle's intel-and-hunt track and its insider-threat track start in parallel from their own inputs.
workflow · Context
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
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
IT Availability & Resilient Failure Operations
Standing operator workflow for the monthly IT availability and resilient-failure-operations cycle: batch and processing monitoring with incident and problem resolution, backup and restore verification, availability-to-SLA tracking, network capacity and DoS-mitigation posture, fail-secure and alternate-communications readiness, and the mean-time-to-failure replacement queue with verified fail-safe procedures, as a decision-aware flow that escalates an urgent reliability gap immediately and rolls routine findings into a single end-of-cycle corrective-action log. Each monthly instance runs against the EXISTING Control item for this IT-availability and resilient-failure-operations control (frequency: monthly; framework: nist-800-53 + sox; domains: business_continuity_disaster_recovery, network_communications_security, incident_management_response) — it enriches that standing control with the cycle's evidence rather than creating a new record: per-stream evidence attaches as documents on the workflow instance's steps, operational failures and gaps become Issue items linked to that Control, and the named deliverable is the signed monthly control record (the classify-cycle-disposition form plus its disposition summary), backed by the monitoring roll-up, incident-and-problem log, backup-and-restore summary, availability dashboard, capacity and fail-secure verification records, and the corrective-action register. In scope: the in-scope batch jobs and system processing, network services and communications paths, and components tracked for mean-time-to-failure named in the operating brief, measured against their defined availability and processing service expectations; out of scope: application change management, access provisioning, and physical-environment controls, which are operated by their own workflows. This is a standing monthly cycle with no upstream workflow dependency and no downstream handoff — its inputs are the organization's own scheduler and monitoring feeds, backup history, capacity telemetry, and asset/MTTF inventory; its archived record seeds the next monthly instance of the same control.
workflow · Context
Change & Release Management (CAB)
Change & Release Management (CAB) as a decision-aware workflow that runs one recurring weekly instance against the EXISTING change-management ITGC Control item in the control library (domains: secure_configuration_change_management; mapped via Control.framework to nist-800-53, cobit-2019, iso-27001, and soc1, alongside the related UC-CONFIG-02/03, UC-ACCESS-16, and UC-SDLC-06/07/08/09 controls) — it enriches that control's operating evidence each cycle, it does not create the control. Upstream it consumes the open change-request queue and the emergency-change log exported from the ticketing system, plus the prior cycle's closure export as its carry-forward backlog. It covers change intake, security and risk impact analysis, environment segregation and configuration-baseline control, acceptance testing, the single CAB authorization gate, the emergency-change path, and controlled deployment with rollback and post-implementation verification — producing the prioritized CAB agenda and authorization packet, per-change risk-assessment memos, the environment-and-baseline verification memo, acceptance-testing summaries, the deployment-and-verification record, and the archived per-cycle evidence set. In scope: application, database, infrastructure, configuration, and procedure changes across development, test, and production environments. Out of scope: authoring the change itself — this workflow governs authorization and release, not development of the underlying code or configuration. Studio ships no native Change Request item type, so per-change records live as lines in step documents and in the workflow instance rather than as items. This is a terminal workflow with no downstream handoff: closure archives the cycle evidence set in place under retention, and the next cycle's intake reads this instance's closure export as its carry-forward source.
workflow · Context
Secure Baseline & Integrity Drift Management
Standing monthly operator workflow for the secure-baseline and integrity-drift cycle: maintain and approve hardening baselines and least-functionality settings against accepted industry standards, run configuration-compliance scanning and remediate drift as findings, triage file-integrity, hash/signature, and secure-boot alerts while verifying security functions self-test correctly, and keep the configuration management plan current annually or after significant environment change. In scope: system components and network security controls governed by CM-2/CM-6/CM-7/CM-9 and SI-6/SI-7 (ISO 27001 A.8.9, PCI DSS Req.1/Req.2, NIST CSF PR.PS-01/DE.CM-09). Out of scope: incident containment and response — unexplained changes are escalated as potentially adverse events to the detect-to-respond incident-analysis practice rather than contained here. Anchor: each monthly run is a recurring workflow instance attached to the EXISTING secure-configuration Control item (the CM-2/CM-6/CM-7 hardening-baseline control — domains=secure_configuration_change_management, frequency=monthly, framework nist-800-53/pci-dss/iso-27001); the cycle enriches that standing Control and never creates a new one. No upstream workflow feeds this cycle — it is self-seeding: its inputs are the prior instance's archived operating record, the approved hardening-baseline standards (Policy items linked to the Control), the open drift/integrity backlog and baseline-reassessment carry-forward (Issue items linked to the anchor Control), and the CM-plan review calendar. Named deliverables: the approved hardening-baseline standards and least-functionality list, the configuration-compliance scan-result register, the integrity-alert and self-test register, drift and corrective-action findings (Issue items linked to the Control), the reviewed configuration management plan (Policy item), the cycle-health dashboard and readiness summary, and the signed, archived cycle operating record. The only cross-workflow handoff is the adverse-event escalation package handed to the detect-to-respond incident-analysis practice.
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
Malware, Email & Web Content Defense Operations
Standing operator workflow for anti-malware coverage, detection handling, spam and phishing filtering, and mobile-code and website-content control, run on a monthly cadence by the security operations malware defense lead. Each monthly run is a new workflow instance attached to the existing Process item "Malware, Email & Web Content Defense Operations" (process_type: security_process, frequency: monthly), with Item relationships to the Control items it operates — UC-VULN-05 (malicious code protection) and UC-NET-13 (mobile code) in the control library (framework: nist-800-53, iso-27001, pci-dss). In scope: every system component commonly affected by malicious software, the email and web filtering entry and exit points, the mobile-code technologies in use, and website category and reputation filtering. Out of scope: endpoint patching and vulnerability remediation, incident response beyond first-line quarantine and alerting, and network firewall rule management. No upstream workflow feeds it: the monthly scope, the in-scope component and channel list, the accountable owners, and the prior-cycle carryover — the previous instance's open Issue items and step documents — are its own initial inputs. It produces the coverage reconciliation report, the detection-and-response log, the mobile-code authorization list, the tuned email/web and website-content filtering packages, a capability-health dashboard, a signed readiness classification, and a corrective-action register. It is terminal by design: rather than hand off to a downstream workflow, the close-and-archive step preserves the signed operating record under retention and loops carry-forward Issue items into the next monthly cycle.
workflow · Context
Deception, Honeytoken & OPSEC Concealment Operations
Standing quarterly operator workflow that runs against the EXISTING deception/OPSEC concealment Control in the control library (control_type: detective, framework: nist-800-53, frequency: quarterly, mapped to UC-NET-10/UC-VULN-11/UC-NET-11) — each quarter's instance enriches that Control's operating history and is archived as its audit trail, never creating a duplicate control. In scope: deploy and reposition honeypot/honeynet decoys and honeyclient sandbox detonation ahead of user delivery, seed/monitor/functionally-test honeytoken/beacon/watermark taint mechanisms across systems and datasets, and run the OPSEC process that identifies critical operational information (Risk items), analyzes adversary collection paths, and deploys concealment and misdirection countermeasures (Control items) on the cycle's designated systems, segments, and datasets. Originates on its own: the four operating streams (OPSEC, decoys, sandbox, taint) are parallel entry points fed by the organization's own asset, threat-intel, and inventory data — no upstream workflow feeds it. Named deliverables: the isolation-verified deception estate (deployment/repositioning plan + isolation-verification record), sandbox pipeline test results, the seeded taint-mechanism placement inventory, the OPSEC critical-information register with countermeasure register, the cycle detections timeline, and the program-health readiness dashboard. Out of scope: incident containment and eradication — confirmed activations are handed to the incident-response workflow with a preserved chain-of-custody evidence package (that handoff fires only on the activations-detected branch), rather than contained here.
workflow · Context
Secure Development & Release Security Gate
Each run attaches as a workflow instance to the existing Control item for the secure-development/release-security-gate control (domains: secure_development_sdlc + vulnerability_patch_management) — enrich that Control, never create a duplicate; release runs and the quarterly checkpoint are separate instances on the same anchor Control. This workflow originates on its own artifacts (the release candidate, design artifacts, and the standing portfolio registers) and receives no upstream handoff package. Decision-aware: it branches on trigger type. In scope — for a release or major upgrade entering development, run security-and-privacy-by-design engineering, security test-plan execution, and runtime-hardening verification as parallel evidence streams, then resolve the release security disposition and assemble the release security evidence package with its acceptance-criteria index; for the quarterly portfolio checkpoint, run the vulnerability, patch, and end-of-life software review, publish the portfolio-health dashboard, and log corrective actions. Out of scope — the final production go/no-go, which the separate SDLC gate review workflow owns using the evidence package this workflow hands off to it. The release track and the quarterly track never force each other's steps.
workflow · Context
Controlled Hardware & System Maintenance
Standing operator workflow for the hardware and system maintenance desk, anchored on the existing Process item "Hardware & System Maintenance" (process_type: it_general_control, process_owner: the maintenance coordinator, frequency: monthly): each monthly cycle runs as one workflow instance on that Process — enrich the standing Process, never create a duplicate desk. It schedules and approves maintenance, repair, and replacement, routes execution across on-site, off-site, and nonlocal (remote) sessions with the right tool, personnel, and connection controls, and verifies security controls after every completion. The governing requirements are the linked Control items UC-CONFIG-07 and UC-CONFIG-08 (framework nist-800-53, nist-csf-2; MA family). In scope: scheduling, approval, execution, and post-work verification of maintenance, repair, and replacement for in-scope hardware and systems across on-site, off-site, and nonlocal sessions, plus support/spare-parts tracking and end-of-life disposition. Out of scope: procurement of net-new assets and software patch/change management, which run in their own workflows. No upstream workflow feeds this desk; it consumes its own maintenance queue, open work requests, the asset/hardware register export (there is no native Asset item type — the register is uploaded at the first step), and manufacturer maintenance schedules, and it seeds its own next cycle at close. Named deliverables: an approved maintenance schedule (XLSX), per-mode execution-evidence logs, a post-maintenance security-control verification report, a support/spare-parts disposition status, a maintenance-desk health dashboard, and a closure record — with exceptions, control drift, and gaps promoted to Issue items and a corrective-action register. Downstream, end-of-life "remove from service" dispositions hand off to the equipment-disposal / media-destruction workflow, and any out-of-scope drift found during post-maintenance verification hands off to the incident or change-management workflow.
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
Secure Connectivity & Network Trust Services Operation
Standing operator workflow for remote/wireless/mobile access re-authorization, session trusted-channel and termination verification, and DNSSEC/name-resolution and time-service assurance, as a decision-aware quarterly cycle that contains rogue access before continuing and routes gaps to tracked corrective action. Each quarterly instance attaches to the existing standing Process item (process_type: security_process, frequency: quarterly) for Secure Connectivity & Network Trust Services — it enriches that Process cycle-over-cycle, never creating a duplicate — and that Process is related to the existing Control items UC-NET-02, UC-NET-03, and UC-NET-07 the cycle operates. In scope: remote-access methods, wireless networks, and organization-controlled mobile devices; systems hosting security-relevant sessions; authoritative DNS zones, recursive and caching resolvers, and authoritative time sources. Out of scope: endpoint hardening and identity/credential lifecycle beyond out-of-band key delivery. The cycle runs on its own quarterly trigger and consumes no upstream workflow handoff package; it produces the re-authorization register, the sweep and containment logs, the session-trust and name-resolution/time assurance records, the connectivity trust-posture dashboard and summary, and a corrective-action register — closing into an internal carry-forward that seeds the next quarterly instance (no handoff to a distinct downstream workflow).
workflow · Context
Platform Isolation & Separation Enforcement
Platform Isolation & Separation Enforcement as a decision-aware operator workflow. Each semiannual run attaches to the existing platform-isolation Control item — UC-NET-04 (framework nist-800-53, family SC, frequency semi_annual, control_owner = security architect), with sibling Controls UC-NET-05 and UC-NET-06 linked — enriching that standing control with a fresh cycle of evidence rather than creating any new anchor; consecutive instances stack on the same Control as its cycle history. Three verification streams run in parallel — user/system-management/security function and sensitivity-domain separation, shared-resource sanitization and covert-channel bandwidth reduction, and hardware- and software-enforced separation-mechanism integrity — and converge into a single posture review and closure. It consumes the prior cycle's still-open findings (Issue items carried forward on the anchor Control) plus live platform telemetry, and produces named deliverables: the function-and-domain separation matrix, the shared-resource sanitization report, the covert-channel analysis report, the hardware/software-mechanism verification report, a consolidated isolation-posture dashboard and evidence summary, and a signed cycle closure record. In scope: the semiannual verification and corrective-action closure of platform isolation across all in-scope platform components. Out of scope: the platform-engineering re-architecture behind a fix (tracked here as corrective-action Issues, executed by platform engineering) and boundary/network-protection controls owned by their own cycle. No upstream workflow feeds this cycle; its only handoff is downstream to its own next run — open corrective actions are left as OPEN Issue items on the anchor Control and arrive as explicit inputs to the next semiannual instance.
workflow · Context
Resilient Architecture & Non-Persistence Operations
Standing operator workflow that runs each quarter against the existing NIST 800-53 resilient-architecture / non-persistence Control item in the control library (framework=nist-800-53, SI/SC family covering SI-14, SI-21, SI-22, SI-23, SC-25, SC-29, SC-36, frequency=quarterly, control_owner = Infrastructure Architecture Lead); the recurring instance attaches to and enriches that Control — it never creates a new control. In scope: non-persistent provisioning and information refresh, diverse sourcing and fragmentation of high-value data, and the resilient-architecture review of thin nodes, technology heterogeneity, and distributed processing and storage against current threats. It consumes no upstream workflow handoff; its inputs are the standing non-persistence and resilient-architecture inventories — the critical-information suppliers adopt the native Vendor type, while the infrastructure components, information stores, and fragmentation entries have no native item type and are held as register documents on the anchor Control — plus any open carryover Issue items from the prior cycle. Named deliverables: the refresh-and-attestation log, the sourcing-diversity and fragmentation-verification report, the thin-node / heterogeneity / distribution assessments, the combined resilience-posture dashboard and posture-review summary, and the adjustment-action register; exceptions, drift, and gaps normalize into Issue items linked to the Control. Out of scope: incident response itself — a suspected refresh-source compromise is contained and escalated to the incident-response team (an escalation, not a workflow handoff) — and application-layer change management. This is a terminal recurring cycle: close-and-archive exports the run as the durable operating record and seeds the next quarter's inputs.
workflow · Context
Resilience & Failover Readiness Verification
Standing quarterly operator workflow that verifies alternate storage, alternate processing, and diverse telecommunications capability (UC-BCDR-04) and validates the safe-mode, alternate-communications, and alternate-security-mechanism design configured on critical systems (UC-BCDR-11). Each quarterly instance runs against the EXISTING UC-BCDR-04 alternate-capability Control item in the Control library (frequency quarterly), with the UC-BCDR-11 degraded-mode Control item linked as the second in-scope control — it enriches the evidence trail on those existing controls, never creating a duplicate control. Self-originating: it consumes no upstream workflow handoff, reading the two governing Control items (control_id UC-BCDR-04 and UC-BCDR-11), the prior quarter's archived readiness instance, and the open corrective-action Issues carried forward on those controls; all operational reference data (backup schedule, alternate-site media/replication log, site records, telecom inventory, system design specs and configs) enters as PBC uploads on the verifying step, since none of it is item-typed. In scope: confirming that this alternate capability and degraded-mode design remain current, hazard-separated, secured to primary-site parity, and ready to assume operations within RTO. Out of scope: the live failover exercise that actually cuts over to the alternate site, run separately by the assure-line DR test workflow that consumes the readiness state this workflow maintains. Named deliverables: six verification memos (storage-site, processing-capability, telecom, safe-mode, alternate-communications, alternate-security), a readiness dashboard and a signed readiness summary, and a corrective-action register — every gap converts into an owned corrective-action Issue (issue_type: deficiency, source: self_assessment) linked to the impaired Control, with any recovery-time-impacting gap escalated immediately rather than held for end-of-cycle closure. Downstream handoff: the archived readiness summary and dashboard serve as the readiness-state package the assure-line DR test workflow reads (no terminal handoff node exists yet — see the closure step).
workflow · Context
IT Operations & Capacity Management Cycle
Standing operator workflow for the weekly IT operations and capacity management cycle. It runs on the EXISTING **Process** item "IT Operations & Capacity Management" (process_type: operational, process_owner: IT operations manager, frequency: weekly): each weekly cycle is a new workflow instance attached to that Process — the Process is enriched, never recreated — with the operated **Control** items (job-scheduling, infrastructure-monitoring, and capacity controls; frequency: weekly) linked to it via a Control ↔ Process relationship. The instance executes and reconciles daily job scheduling, processing, infrastructure monitoring, and facility management against documented procedure, then assesses capacity and utilization against forecast demand, triggers capacity additions and priority-allocation safeguards ahead of threshold breach, and produces the named evidence set: the weekly operations review minutes, the consolidated exception log, and the capacity-and-utilization report (plus a recurring capacity-and-utilization dashboard). In scope: daily job scheduling, processing, infrastructure monitoring, and facility management for the operator's named in-scope systems and facilities, plus the weekly capacity and utilization review of infrastructure, data, and software against forecast demand. Out of scope: incident response, change management, and disaster-recovery testing, which run as their own workflows; this cycle raises corrective actions and capacity-addition requests (tracked as Issue items) that feed change management in substance but models no explicit handoff node — it is a terminal, self-originating operate-line cycle that does not itself execute infrastructure changes. No upstream workflow feeds it: its inputs are the operator's own job schedules, monitoring and facility feeds, the governing operating-procedure and capacity-threshold and quota **Policy** items, and the prior cycle's carryover **Issue** items (created when the signed weekly operations review closes the cycle) that arrive as tracked inputs — and the cycle seeds its own next-cycle carryover the same way.
workflow · Context
Supply-Chain Integrity & OPSEC Operations
Standing monthly operator workflow run against the existing supply-chain integrity Control item (UC-TPRM-07, frequency=monthly, domains=third_party_supply_chain_risk), with the OPSEC need-to-know Control (UC-TPRM-09) linked as the second in-scope control — enrich these existing Control items, never recreate them; the workflow instance attaches to the anchor Control as the durable operating record. Two concurrent workstreams. In scope: receipt-time tamper-evidence and authenticity inspection of critical systems and components, provenance and chain-of-custody upkeep, suspected-counterfeit disposition (each raised as a finding Issue linked to the anchor Control and the implicated Vendor) with inspector-training refresh where a lapse is found, and the OPSEC need-to-know review of the sensitive supply-chain information register with remediation of any overexposure. Named deliverables: the authenticated provenance and chain-of-custody register, the counterfeit-disposition cases, the OPSEC exposure-review worksheet, and the confirmed need-to-know-restricted disclosure footprint. No upstream workflow feeds this cycle — its inputs are the period's own receiving log and the sensitive supply-chain information register. This is a terminal standing control: procurement and vendor onboarding, contract-level third-party risk assessment, and facility physical security are out of scope, each handled by its own workflow; a substantiated counterfeit or compromised supplier is escalated to the third-party/vendor risk workflow rather than resolved here.
workflow · Context
Secure SDLC Phase-Gate Program
Operate the secure SDLC phase-gate program as a modular, decision-aware workflow where the accountable control owner chairs the intake, requirements, design, and build/release gates end to end. Each recurring operating cycle runs as a new workflow instance attached to the existing secure-SDLC phase-gate Control item (domains = secure_development_sdlc; framework = nist-800-53 / iso-27001 / cobit-2019 / nist-csf-2) — that Control already exists in the library, so the instance enriches it with this cycle's gate evidence rather than creating a duplicate control. In scope: chairing those four security-integrated lifecycle gates for every development initiative due this cycle, remediating held or blocked initiatives, and monitoring the process itself; it is self-initiating and consumes no upstream workflow package, and it seeds its own next cycle. Out of scope and distinct from it: the independent SDLC gate review's release-milestone verification, and the release-security-gate's technical testing practice.
workflow · Context
Outsourced & Critical-Component Development Oversight
Quarterly outsourced- and critical-component development oversight, run as a recurring operating cycle against the EXISTING Control item for outsourced/critical-component secure development (UC-SDLC-10 / UC-SDLC-11; domains secure_development_sdlc + third_party_supply_chain_risk; NIST 800-53 SA-20/SA-21/SA-23, ISO 27001 A.8.30) — the workflow enriches that Control, it never creates a duplicate. Each quarter it inventories the active outsourced/third-party development engagements (enriching the Vendor register), verifies contract secure-development / IP-ownership / audit-rights terms, traces deliverables to requirements with security-test evidence on file, screens critical-system developers before access, refreshes the register of components critical to security or mission, and re-tests the specialized-development rationale and assurance evidence. It consumes the prior cycle's carry-forward Issue items (open corrective actions, contract renewals, components due for rationale review) and the archived prior workflow instance's registers; every gap it surfaces becomes an Issue linked to the anchor Control, giving one queryable corrective-action population. In scope: active outsourced and third-party development engagements and the register of components critical to security or mission; out of scope: internal-only development with no third-party contributor and general procurement risk unrelated to development. Self-terminating: no downstream workflow consumes this cycle's output — corrective actions are tracked to closure within this workflow and carried forward to the next quarter.
workflow · Context
Technology Lifecycle & Capacity Review
Standing operator workflow for the quarterly solution-asset lifecycle review and the availability/capacity planning cycle, from asset reconciliation and end-of-support disposition through capacity monitoring, corrective planning, and prior-period target validation. Each quarterly run is a recurring workflow instance attached to the EXISTING technology-lifecycle-and-capacity-management Control item (UC-SDLC-12/13; frequency = quarterly; control_owner = the IT control owner) — the instance enriches that standing Control and its linked records, never a fresh duplicate; the governing COBIT 2019 / NIST 800-53 mapping rides on Control.framework. In scope: the in-scope solutions, applications, and supporting infrastructure components (the services they run are Process items) with named owners, and the services carrying agreed availability and capacity (SLA/SLO) targets. Out of scope: the projects that execute an approved replacement or upgrade (each tracked externally as its own project item) and live incident response for availability outages. Named deliverables: the reconciled solution-asset register and optimization actions, the ranked end-of-support exposure list and disposition, funded replacement/upgrade plans (Issue items) and compensating-control records (Control items) with signed risk acceptances (policy_exception Issues carrying exception_expiry_date, on treatment: accept Risks), the capacity/availability dashboard and corrective plans, and the validated prior-period target package. No upstream workflow feeds this cycle and there is no separate downstream workflow to hand off to — the still-open replacement/upgrade plans, capacity corrective plans, and risk-acceptance expiries (their existing Issue and Risk items, linked to the anchor Control) carry forward as explicit inputs to the next quarterly run of this same workflow.
workflow · Context
AI Guardrail Configuration & Agent Permission Review
Each monthly or release-triggered instance runs against the existing Control item for AI guardrail configuration and agent permission review (framework aiuc-1 + iso-42001 + eu-ai-act; frequency monthly and per release; control_owner AI Platform Security Lead) — the run enriches that Control's execution history and is its evidence of operation, never a duplicate. The decision-aware cycle confirms the in-scope agent population and baseline; reviews input defenses and endpoint limits, tool allow-lists, permissions and sandboxing, output filters and grounding, misuse refusals, secrets redaction, and secure-code-generation defaults; decides on agent permission scope and on guardrail drift with a remediation branch for each; and consolidates the results into a signed guardrail attestation with cycle metrics and owned actions, booking every residual gap as an Issue (source: management_identified) linked to the anchor Control. In scope: every production AI agent and inference endpoint, its guardrail configuration, tool-call and detection logs, and configuration artifacts. Out of scope: model development, pre-deployment evaluation, and vendor AI due diligence, which have their own workflows. The cycle hands off only to its next instance through the carry-forward Issues that the guardrail attestation step links to the anchor Control.
workflow · Context
Quarterly Third-Party AI Evaluation Cycle
Each quarterly instance runs against the existing Control item for independent third-party AI evaluation (framework aiuc-1 + iso-42001 + eu-ai-act; domains ai_governance; frequency quarterly; control_owner AI Product Lead) — the run enriches that Control's execution history and is its evidence of operation, it never creates a duplicate Control; the one record it does create is a per-quarter Audit item (audit_type: it_audit) for the evaluator engagement. The decision-aware cycle confirms the quarter's in-scope systems and risk taxonomy, engages an independent evaluator with the test plan, categories, and pass thresholds fixed in advance, provisions contained test access, triages every finding by category and severity against the tested control, routes failed thresholds through remediation and evaluator retest, gates acceptance of the evaluator report, publishes the accepted evidence (trust-portal summary, customer-facing attestation, evidence register), and tunes guardrails from the findings. In scope: every in-scope AI system and agent under the AIUC-1 program and its six mandatory third-party test categories (B001 adversarial robustness, C010 harmful outputs, C011 out-of-scope outputs, C012 agent-specific risk, D002 hallucinations, D004 tool calls). Out of scope: internal red-teaming, pre-release model evaluation, and vendor AI due diligence, which run in their own workflows. It hands off only to the next quarterly run of itself, seeding it with the open carry-forward finding Issues that the publish-evidence-and-tune-guardrails step links to the anchor Control.
workflow · Context
ISO 27001 SoA Review & Controls Assessment
Review the ISO 27001 Statement of Applicability and assess the controls behind it. Each run attaches to an Audit item created for the review cycle (audit_type = compliance, e.g. "ISO 27001 SoA Review 2026-H2"), which accumulates the scope, the per-control test instances, the assessment package, the approval, and the rating. The workflow locks the assessment workplan, reconciles every Annex A control's applicable/excluded decision and justification against the current risk treatment plan, verifies implementation evidence, assesses the sampled controls for design and operating effectiveness, routes deficiencies to owners, and approves and publishes the version-controlled Statement of Applicability (SoA) — then classifies the disposition and prepares, approves, hands off, and archives the review package. In scope: reconciling and assessing the SoA's Annex A control applicability decisions and their implementation for the ISMS in scope, and publishing the approved SoA version. It consumes the ISMS Risk Assessment & Treatment Cycle's handoff package (the current risk register, the risk treatment decisions, and the required-controls determination) and hands its named deliverable — the approved, version-controlled published SoA and the assessment package — off to the downstream ISO 27001 Certification Readiness workflow. Out of scope: the enterprise risk assessment and treatment decisions that determine which controls are required (owned upstream by the ISMS Risk Assessment & Treatment Cycle) and the certification audit preparation that follows (owned by the downstream ISO 27001 Certification Readiness workflow, which consumes this review's approved package). The trigger is the scheduled SoA review interval or a material change to scope, risk, or the control environment.
workflow · Context
Backup & Recovery Testing
Runs on the existing system item. Test recoverability for a system by performing an actual restoration and measuring the result against recovery objectives. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Job Scheduling & Batch Monitoring
Runs on the existing system item. Review scheduled job execution for a system over a period, evidencing failure detection, escalation, and resolution. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Change Request, Approval & Migration
Runs on the existing system item. Move a system change from request through independent testing and approval to production migration, evidencing developer-migrator segregation. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Emergency Change
Runs on the existing system item. Record an emergency change that bypassed normal change control, evidence the elevated access used, and retrospectively test whether the bypass was justified. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
New System Implementation (SDLC)
Runs on the existing system item. Take a new system from control requirements through testing and acceptance to an evidenced go-live readiness decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Incident & Problem Management
Runs on the existing system item. Record an incident on a system, evidence containment against response targets, and determine root cause with preventive action. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Security Control Assessment & POA&M Remediation
Run this assessment on the EXISTING Audit item for the engagement (audit_type: it_audit or compliance) — enrich that record, never create a duplicate: Audit.scope carries the authorization boundary and Audit.period_start/period_end the assessment window. Consumes, from the upstream SSP-development / system-categorization effort, the approved System Security Plan (SSP), the FIPS 199 system categorization, and the tailored NIST 800-53 baseline (existing Control items, framework: nist-800-53). Assess each in-scope control with 800-53A examine/interview/test methods, record satisfied / other-than-satisfied determinations, open a POA&M Issue for every gap, re-validate remediation, and issue the Security Assessment Report (SAR). In scope: control assessment, determinations, the POA&M lifecycle, and the SAR for the authorization boundary agreed at kickoff. Out of scope: the authorization (ATO) decision itself and the steady-state continuous-monitoring cadence. On completion, the frozen SAR and POA&M package are handed to the NIST RMF System Authorization (ATO) Cycle.
workflow · Context
ISO 27001 Stage 1 ISMS Documentation Review
Certification-body Stage 1 review of the ISMS against ISO/IEC 27001:2022 clauses 4–10: context and leadership, planning and support, operation, and performance evaluation with improvement - walking each clause group against the governing documents and the operating processes that carry it, and concluding Stage 2 readiness with dual sign-off. Stage 1 documentation and readiness review for ISO/IEC 27001:2022 clauses 4–10, conducted under the engagement methodology. It informs Stage 2 planning and does not issue a certification decision. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
ISO 27001 Stage 2 Annex A Controls Audit
Attach to the existing Audit engagement, owned by Internal Audit, using its approved Statement of Applicability, risk treatment plan, scope, review period and operating evidence; produce the Stage 2 Annex A Controls Audit report, four signed theme conclusions and finding register for the engagement and remediation owners. Apply the approved Statement of Applicability to ISO/IEC 27001:2022 Annex A.5.1–A.5.37, A.6.1–A.6.8, A.7.1–A.7.14 and A.8.1–A.8.34; document each exclusion and assess direct and inherited responsibilities. This Annex A assessment contributes to the engagement and does not independently establish full ISMS conformity or issue certification. Stage 1 and readiness remain separate workflows; any certification decision remains with the authorized certification body.
workflow · Context
SOC 2 Availability Assessment
Design-readiness review of the SOC 2 availability series: capacity management, environmental protections with backup and recovery infrastructure, and recovery plan testing (A1.1–A1.3). Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Privacy Criteria Assessment
Design-readiness review of the full SOC 2 privacy series: notice and choice, collection through disposal, data subject access and disclosure, and data quality with dispute monitoring (P1.1–P8.1), concluded with dual sign-off on the criteria-bearing final assessment. Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Type II Interim Testing
Interim fieldwork for the Type II examination: cycle walkthroughs, design assessment against the Trust Services Criteria, the first operating-effectiveness testing wave over the agreed interim evidence window, and exception triage feeding remediation and retest planning before the period closes. Interim SOC 2 Type II fieldwork for the listed control selections and agreed interim window. Later-period testing and the service auditor's independent opinion remain outside this module. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
GCP Physical and Environmental Subservice Reliance
Evaluate GCP assurance-report scope, physical and environmental controls, exceptions and user responsibilities; record a bounded reliance decision rather than claiming to operate provider facilities. This customer-side review relies on relevant independent reports, disclosed provider information and customer implementation evidence. It does not operate or certify GCP facility access or environmental safeguards. Preserve each report's permitted-use restrictions.
workflow · Context
System ITGC Operation
Operate and evidence the IT general controls on a system: authentication and password configuration, access provisioning and deprovisioning, the periodic user access review, change management (testing, sign-off, logs), and subservice SOC report reliance.
workflow · Context
SOC 2 Reporting and Management Assertion
Reporting close for the Type II examination: drafting and validating the system description under the carve-out method, preparing the management assertion, reviewing complementary user entity controls and subservice reliance, and the dual-approval close of the examination file at the agreed period end. Management-owned SOC 2 Type II reporting support: system description, management assertion, CUECs, subservice reliance, and auditee file closure. The independent service auditor retains responsibility for examination conclusions and the CPA opinion. Attach this workflow to the existing SOC 2 evidence or reporting process item; retain evidence and conclusions on its workflow steps.
workflow · Context
System and Third-Party Risk Review
Runs on the existing system item. Review system and provider dependencies, assess current risk and control evidence, select response actions, and approve the review record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Vendor Risk Assessment and Disposition
Runs on one existing System with vendor=true. Uses the supplier record, contracts, assurance/CUECs, access and continuity evidence to produce a reviewed vendor risk assessment and authorized disposition for the business/risk owner and readiness evidence consumers. Two checkpoints retain expert challenge and the owner’s choice of conditions, treatment and monitoring; executor work is recorded in step results and documents, with no collection forms or runtime branches.
workflow · Context
ISO/IEC 42001 AI Management System Internal Audit
An independent internal-audit cycle for the AI management system: set scope and criteria, test governance, risk, documentation, operations, value-chain controls, and reporting, then issue findings and an evidence-backed conclusion. The audit supports management improvement and assurance; it does not certify conformity.
workflow · Context
AI Governance & Risk/Impact Assessment
Assess a single AI system end to end under ISO/IEC 42001 (AIMS) and the NIST AI RMF: govern and register the system, map context and risks, measure risks and impacts, manage treatment, produce transparency artifacts, and authorize deployment with monitoring. The instance attaches to an Audit item created for this assessment cycle (audit_type compliance, or advisory for a pre-deployment review); because Studio has no native AI System type, the system under assessment is named in that Audit's scope and its lifecycle/EU-AI-Act detail lives in the scoping memo and step documents. In scope: one named AI system or use case and its lifecycle risk posture. Out of scope: enterprise-wide AI policy authoring and detailed EU AI Act legal obligation mapping, which are consumed as an input handoff package from the EU AI Act Obligation Impact Analysis workflow. The named deliverable is the approved AI assessment package (executive summary plus recommended governance decision), backed by the AI risk register (Risk items, category ai_governance), the model/system card and AI impact-assessment record, and a deployment authorization with live drift/fairness monitoring; approved outputs hand off to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Third-Party Vendor Risk Lifecycle
Operate the third-party vendor risk lifecycle end to end: scope and tier the vendor population, gather and analyze assurance evidence (SOC reports and CUECs, plus C-SCRM controls), embed contractual protections, enroll ongoing monitoring, and reach a governed disposition and approval. The vendor register IS the set of Vendor items — tiered by criticality (tier) and data exposure (data_classification), owned (business_owner, risk_owner), and driven by reassessment_cadence with last/next assessment dates and monitoring_status; each assessment cycle runs as one workflow instance over that register. In scope: vendor and supplier third-party risk assessment, onboarding controls, and periodic reassessment. Out of scope: procurement sourcing and commercial negotiation, and the deeper fieldwork of a Third-Party Vendor Assurance Engagement, to which the approved package is handed off. This workflow is self-initiating and consumes no upstream workflow package.
workflow · Context
IT Governance Objective Review (COBIT)
Periodic review of selected COBIT 2019 governance and management objectives, run per cycle on an Audit item (audit_type: it_audit; scope = the in-scope objectives; period_start/period_end = the assessment cycle) that the workflow instance attaches to and archives at close. Each in-scope COBIT objective is a Process item (process_type: it_general_control) linked to that Audit, and the review produces named deliverables against it: an evidence register and pre-scored capability sheet, a signed capability profile, a gap table with the benchmark decision, a committed improvement roadmap of Issue initiatives, and the governance board report and dashboard. In scope: the COBIT 2019 objectives selected for this cycle, each with a justified 0-5 target capability level, a named accountable owner, and the review cadence; out of scope: objectives explicitly excluded with recorded rationale. Self-originating: its scope sheet and target profile are supplied as workflow inputs, and it hands off to no distinct downstream workflow — the carry-forward improvement Issues and the archived instance seed its own next cycle.
workflow · Context
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
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
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
Incident Management Lifecycle
Run the enterprise incident management lifecycle on a single governed incident record — an Issue item created at intake that every step enriches (there is no separate Incident type; the workflow instance anchors to that Issue). Open the record, analyze scope and impact, anchor the regulatory and remediation notification clocks to the detection date, contain/eradicate/recover, execute severity-based notifications, run lessons-learned and CAPA, classify the disposition, then prepare, hand off, and archive the governance package. Named deliverables: the scope-and-impact assessment, the root-cause analysis, the owned CAPA / remediation action plan, and the final evidence-and-decision governance package. In scope: operational and security incidents from detection through closure, including regulatory-notification clock management and corrective/preventive actions. Upstream: the incident originates on detection itself, but for a security-category incident this workflow consumes the containment-and-forensics handoff package produced by the Cybersecurity Incident Response workflow (linked in at the eradicate-and-recover step) rather than re-running SOC triage. Out of scope: real-time SOC triage and containment mechanics (owned by that Cybersecurity Incident Response workflow) and board-level reporting — the final governance package is handed off to the Quarterly Board & Audit-Committee GRC Reporting workflow, which reports the outcome without re-investigating.
workflow · Context
Policy Lifecycle Management
Run one policy through its full lifecycle, anchored to a Policy item in the policy library — created at authoring for a net-new policy, enriched in place on each refresh cycle (never duplicated). In scope: authoring and control/authority linkage, stakeholder review, formal approval, publication and workforce attestation, acknowledgement tracking, disposition, and scheduled alignment refresh. Consumes read-only upstream: the enterprise risk assessment (Risk items), control design (Control items), and obligation mapping — this workflow neither produces nor edits them. Produces four named deliverables: the published policy version, a frozen workforce attestation completion record, a section-by-section alignment verdict, and a single approval-ready policy package. Out of scope: enterprise risk assessment, control design, and obligation mapping. The approved policy package is handed off to the Regulatory Compliance Attestation Cycle, which runs the recurring regulatory attestation; the acknowledgement campaign launched here is the one-time publication attestation and is explicitly flagged in the handoff as not-to-be-repeated downstream.
workflow · Context
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
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
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
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
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
Production Operations & Processing Integrity Cycle
Runs on the existing Process item for production/IT operations (process_type: it_general_control, frequency: daily — e.g. "Production Batch Operations & Processing Integrity"): one recurring instance per daily bridge/shift attaches to and enriches that Process, never creating a duplicate, and is archived against it at close. It operates the unified controls UC-ACCESS-17/18/20 (Control items, framework containing soc1|nist-csf-2|iso-27001) and consumes the prior cycle's carry-forward Issue items (open incidents, aged exceptions, backup gaps, tuning actions) as its opening population. A decision-aware workflow covering authorized batch execution and monitoring, failure and incident resolution, backup and restore-test verification, performance/capacity/security event monitoring with capacity tuning, and daily data-processing integrity through interface reconciliation and authorized-only output distribution. In scope: the authorized batch, interface, and report population, monitoring thresholds, and the backup and restore-test calendar for the daily processing bridge with weekly capacity and restore-test reviews layered in. Out of scope: application change management and access provisioning, handled by their own ITGC workflows — suspected change-control bypasses and access findings are cross-referred to those owners. No upstream or downstream workflow feeds this cycle; the certified-and-filed evidence step seeds the next run of this same cycle with carry-forward Issue items linked to the Process.
workflow · Context
SOX ITGC Testing
SOX ITGC Testing as a modular, decision-aware workflow. It runs on the existing Audit engagement item for this ITGC cycle (audit_type: sox_testing, period_start/period_end = the test period) — enrich that item, never create a duplicate — while per-control operating-effectiveness results live on Control-hosted SOX testing workflows, one created per in-scope ITGC control per Workflow.customFields.sox.fiscalYear, each hosted directly on the Control under test. It consumes the ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment, produces the reperformable final ITGC testing package as its named deliverable, and hands the deficiencies off to SOX Deficiency Remediation. In scope: the operating-effectiveness conclusion on the ITGCs protecting in-scope financial systems, reached by referencing the controls-owned NIST 800-53 catalog and its test scripts — not by rebuilding procedures. Out of scope, owned by related workflows: scoping of significant accounts and applications (Annual ICFR Scoping & Risk Assessment), deep completeness-and-accuracy validation of system-generated populations (SOX IPE Validation), and remediation of what fails (SOX Deficiency Remediation, the downstream handoff). It can stand alone, but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.