Secure Configuration & Change Management
271 records. Direct records match this topic; context records explain their connections.
Read the first JSON page · Data retrieval guide
Mappings may provide partial coverage. Read mapping properties, residual requirements and source notes before relying on a connection.
control · Context
B008 — Protect AI system deployment environment
Protect AI system deployment environment
control · Context
E011 — Record processing locations
Record processing locations
control · Context
BAI02 — Managed Requirements Definition
Managed Requirements Definition
control · Context
BAI03 — Managed Solutions Identification and Build
Managed Solutions Identification and Build
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
MEA03 — Managed Compliance With External Requirements
Managed Compliance With External Requirements
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-Art45 — Information and intelligence sharing arrangements
Information and intelligence sharing arrangements
control · Context
AIA-Art15 — Accuracy, robustness and cybersecurity (high-risk)
Accuracy, robustness and cybersecurity (high-risk)
control · Context
GDPR-Art25 — Data protection by design and by default
Data protection by design and by default
control · Context
A.5.10 — Acceptable use of information and other associated assets
Acceptable use of information and other associated assets
control · Context
A.5.21 — Managing information security in the ICT supply chain
Managing information security in the ICT supply chain
control · Context
A.5.32 — Intellectual property rights
Intellectual property rights
control · Context
A.5.9 — Inventory of information and other associated assets
Inventory of information and other associated assets
control · Context
A.7.10 — Storage media
Storage media
control · Context
A.7.14 — Secure disposal or re-use of equipment
Secure disposal or re-use of equipment
control · Context
A.7.9 — Security of assets off-premises
Security of assets off-premises
control · Context
A.8.1 — User endpoint devices
User endpoint devices
control · Context
A.8.19 — Installation of software on operational systems
Installation of software on operational systems
control · Context
A.8.20 — Networks security
Networks security
control · Context
A.8.21 — Security of network services
Security of network services
control · Context
A.8.22 — Segregation of networks
Segregation of networks
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.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.7 — Protection against malware
Protection against malware
control · Context
A.8.8 — Management of technical vulnerabilities
Management of technical vulnerabilities
control · Context
A.8.9 — Configuration management
Configuration management
control · Context
AC-20 — Use of External Systems
Use of External Systems
control · Context
CA-8 — Penetration Testing
Penetration Testing
control · Context
CM-10 — Software Usage Restrictions
Software Usage Restrictions
control · Context
CM-11 — User-installed Software
User-installed Software
control · Context
CM-12 — Information Location
Information Location
control · Context
CM-13 — Data Action Mapping
Data Action Mapping
control · Context
CM-14 — Signed Components
Signed Components
control · Context
CM-2 — Baseline Configuration
Baseline Configuration
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-6 — Configuration Settings
Configuration Settings
control · Context
CM-7 — Least Functionality
Least Functionality
control · Context
CM-8 — System Component Inventory
System Component Inventory
control · Context
CM-9 — Configuration Management Plan
Configuration Management Plan
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
MP-2 — Media Access
Media Access
control · Context
MP-6 — Media Sanitization
Media Sanitization
control · Context
MP-7 — Media Use
Media Use
control · Context
PM-5 — System Inventory
System Inventory
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-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
SC-2 — Separation of System and User Functionality
Separation of System and User Functionality
control · Context
SC-24 — Fail in Known State
Fail in Known State
control · Context
SC-25 — Thin Nodes
Thin Nodes
control · Context
SC-29 — Heterogeneity
Heterogeneity
control · Context
SC-3 — Security Function Isolation
Security Function Isolation
control · Context
SC-31 — Covert Channel Analysis
Covert Channel Analysis
control · Context
SC-32 — System Partitioning
System Partitioning
control · Context
SC-36 — Distributed Processing and Storage
Distributed Processing and Storage
control · Context
SC-39 — Process Isolation
Process Isolation
control · Context
SC-4 — Information in Shared System Resources
Information in Shared System Resources
control · Context
SC-47 — Alternate Communications Paths
Alternate Communications Paths
control · Context
SC-5 — Denial-of-service Protection
Denial-of-service Protection
control · Context
SC-7 — Boundary Protection
Boundary Protection
control · Context
SI-11 — Error Handling
Error Handling
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-2 — Flaw Remediation
Flaw Remediation
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-10 — Inspection of Systems or Components
Inspection of Systems or Components
control · Context
SR-11 — Component Authenticity
Component Authenticity
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-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.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-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.AM-01 — Asset Management: Inventories of hardware managed by the organization are maintained
Asset Management: Inventories of hardware managed by the organization are maintained
control · Context
ID.AM-02 — Asset Management: Inventories of software, services, and systems managed by the organization are maintained
Asset Management: Inventories of software, services, and systems managed by the organization are maintained
control · Context
ID.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.IR-01 — Technology Infrastructure Resilience: Networks and environments are protected from unauthorized logical access and usage
Technology Infrastructure Resilience: Networks and environments are protected from unauthorized logical access and usage
control · Context
PR.PS-01 — Platform Security: Configuration management practices are established and applied
Platform Security: Configuration management practices are established and applied
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
500.5 — Vulnerability management (penetration testing and scanning)
Vulnerability management (penetration testing and scanning)
control · Context
PCI-Req1 — Install and maintain network security controls
Install and maintain network security controls
control · Context
PCI-Req11 — Test security of systems and networks regularly
Test security of systems and networks regularly
control · Context
PCI-Req2 — Apply secure configurations to all system components
Apply secure configurations to all system components
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
PCI-Req9 — Restrict physical access to cardholder data
Restrict physical access to cardholder data
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
CC6.1 — The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity's objectives.
control · Context
CC6.5 — The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished and is no longer required to meet the entity's objectives.
The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished and is no longer required to meet the entity's objectives.
control · Context
CC6.6 — The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
control · Context
CC6.8 — The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity's objectives.
The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity's objectives.
control · Context
CC7.1 — To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.
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
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.
risk · Direct
Uncontrolled copying to removable media / unmanaged software installs
Absence of controls over copying data to removable devices, and users freely downloading/installing untested or unlicensed software, expands the attack surface and introduces malicious or unlicensed code into the environment.
risk · Direct
Internet-exposed or misconfigured systems
Adversary gains access through the Internet to systems not authorized for Internet connectivity or that do not meet configuration requirements, and exploits attacks over unauthorized ports, protocols, and services.
risk · Direct
Poor configuration management and insecure baseline drift
Without documented, enforced baseline configurations and change control, systems drift into insecure states, contain unauthorized changes, or expose unnecessary network services, expanding attack surface.
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
Cloud multi-tenancy isolation and data-scavenging exploits
Adversary exploits multi-tenancy in a cloud environment to observe organizational processes, violates isolation mechanisms, or scavenges data used and deleted by cloud processes, compromising confidentiality and availability.
risk · Direct
Poor network architecture and unprotected public connections
Because externally-facing connections lack perimeter controls (firewalls, DMZ) and the network lacks segmentation, redundancy, and defense-in-depth, attackers can breach the boundary and move laterally and single points of failure go unmitigated, resulting in intrusion, data exfiltration, and outage.
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
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
Use of unlicensed, counterfeit or pirated software
Fraudulent copying of software and deployment of pirated/counterfeit software (unlicensed or inadequately controlled) that may lack security patches or contain malicious code — a legal and security exposure.
risk · Direct
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
Exploitation of known, unpatched vulnerabilities
Use of software with publicly known, unpatched flaws (CVEs) that adversaries readily exploit — including recently discovered vulnerabilities exploited before mitigations are in place, and internal-system vulnerability exploitation.
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 · Direct
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-ASSET-01 — Maintain a complete inventory of systems, hardware, and software
Maintain a documented inventory of all hardware, software, systems, and services, recording owner, location, and the attributes needed for accountability and security management. Update the inventory as part of component installation, removal, and change, and reconcile it at least quarterly to correct discrepancies. Include every in-scope component so the inventory serves as the authoritative record of protected information assets for audit and compliance scoping.
unified · Context
UC-ASSET-04 — Control storage media through use, storage, and destruction
Restrict access to and use of removable and other storage media to authorized personnel and approved media types, and physically secure media commensurate with the classification of the data it holds. Sanitize or destroy media and equipment containing storage using approved techniques before disposal, reuse, or release from control, and verify that data can no longer be read or recovered before protections are discontinued. Retain records of media use, movement, sanitization, and destruction.
unified · Context
UC-ASSET-06 — Govern acceptable use of endpoints, off-site, and external systems
Define, communicate, and require acknowledgment of acceptable-use rules for information and associated assets. Protect user endpoint devices with enforced safeguards such as encryption, screen locking, and centralized management, and protect organizational assets used off premises against loss, theft, and observation. Permit use of or connection to external systems only under established terms and conditions consistent with the trust relationship, including restrictions on processing organizational information and on portable storage.
unified · Context
UC-ASSET-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-AUDIT-24 — Manage compliance with external legal and regulatory requirements
The organization identifies applicable external legal, regulatory, and contractual requirements - including intellectual property rights and software licensing obligations - and maintains them in a compliance register with assigned owners. Compliance with these requirements is evaluated on a defined cadence, confirmed through documented reviews, and non-compliance is remediated with status reported to management. The register and evaluation results are retained as evidence.
unified · Context
UC-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 · Direct
UC-CONFIG-01 — Harden systems to approved secure configuration baselines
Establish, document, and maintain current baseline configurations and mandatory secure settings for all system components, including network security controls, aligned to accepted industry hardening standards. Configure systems for least functionality by disabling or restricting unnecessary ports, protocols, services, and functions. Monitor deployed configurations for deviations from baseline and for changes that introduce vulnerabilities, remediating drift as findings, and reassess baselines periodically and upon significant change.
unified · Direct
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 · Direct
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 · Direct
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 · Direct
UC-CONFIG-05 — Permit only authorized software installation and use
Restrict installation of software on operational systems to authorized personnel installing approved software from trusted sources, and govern user-installed software through explicit policy and technical enforcement such as allowlisting. Combine these restrictions with anti-malware controls that prevent or detect and act upon unauthorized or malicious software. Track software installation and use to comply with contract terms and license entitlements.
unified · Direct
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 · Direct
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 · Direct
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 · Direct
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 · Direct
UC-CONFIG-10 — Map where information resides and how data is processed
Identify and document the location of information and the specific system components on which it is processed and stored, including designated data types such as personally identifiable information. Develop and maintain a map of system data actions covering collection, processing, storage, and transmission, and update location and mapping documentation upon change.
unified · Context
UC-LOG-08 — Secure and monitor networks and network services
Secure and actively manage networks and network services: document the security features, service levels, and management responsibilities of all network services (including outsourced ones), harden and control network devices, and monitor delivered network services for conformance with the documented security features and service levels, addressing deviations.
unified · Context
UC-NET-01 — Segment networks and defend the external boundary
Segment networks into zones based on trust level, sensitivity, and function, and mediate all traffic at managed interfaces (firewalls, gateways, proxies) with deny-by-default rules at the external boundary and key internal boundaries. Monitor and control communications crossing each boundary to protect against threats originating outside the system boundary, and review segmentation and rule sets periodically.
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-05 — Prevent leakage via shared resources and covert channels
Prevent unauthorized or unintended information transfer through shared system resources by clearing, sanitizing, or isolating resources between users and processes. Analyze the system for covert storage and timing channels, estimate their bandwidth, and reduce or eliminate identified channels that exceed acceptable thresholds.
unified · Context
UC-NET-08 — Maintain communications availability under attack and failure
Protect network services against denial-of-service events through capacity management, rate limiting, filtering, or upstream DoS-mitigation services. Ensure components fail to a known, secure state while preserving essential state information, and maintain alternate communications paths so operations can continue if primary channels degrade or fail.
unified · Context
UC-NET-09 — Reduce attack surface through resilient architecture
Architect infrastructure to resist attack and localize failures: deploy minimal-functionality (thin) nodes where feasible, employ heterogeneity in key technologies to avoid common-mode compromise, and distribute processing and storage across multiple physical locations or components. Review these architecture decisions against current threats periodically.
unified · Context
UC-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 · Context
UC-SDLC-03 — Define and approve security requirements for applications
Elicit, analyze, document, and approve functional and non-functional requirements, including application security requirements such as authentication, authorization, input and output handling, logging, and data protection, before solution design and build, assessing feasibility and alternative options. Manage requirement changes and requirements risk, and obtain stakeholder and management approval of the final requirements.
unified · Context
UC-SDLC-04 — Engineer systems with secure architecture and design
Design and build systems using established secure architecture and engineering principles: least privilege, defense in depth, isolation of execution domains (process and memory separation), fail-safe defaults, and attack-surface minimization, applied from concept through implementation. Require developers to produce and maintain a security architecture description consistent with the enterprise architecture. Engineer solutions to remain accurate, robust, and resilient against errors, faults, and adversarial manipulation.
unified · Context
UC-SDLC-06 — Maintain configuration control over systems and code
Maintain configuration management over solution components throughout development and operation: identify configuration items, establish and protect baselines for code, dependencies, and build settings, record and verify configuration information, and review deviations. Require developers to track the integrity of changes to configuration items, implement only approved changes, and track and resolve resulting security flaws.
unified · Context
UC-SDLC-07 — Approve, test, and accept changes before production release
Evaluate, prioritize, and authorize all IT changes, including emergency changes, before implementation, with documented impact and risk assessment. Establish acceptance criteria, perform acceptance testing in an environment representative of production, obtain business and IT approval, and promote releases through a controlled, auditable transition with fallback plans and post-implementation review.
unified · Context
UC-SDLC-08 — Maintain current system documentation and knowledge
Obtain, produce, and maintain current administrator and user documentation for systems, covering secure configuration, use, and maintenance, and protect and distribute it to authorized roles. Keep development and operational knowledge validated, current, and available to the personnel who need it.
unified · Context
UC-SDLC-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 · Context
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 · Context
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 · Context
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 · 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-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-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.
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
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
IT Asset Inventory & Classification Upkeep
Standing operator workflow for the quarterly IT asset inventory reconciliation and the information and asset classification and labeling review. Anchor: each quarterly run is a workflow instance attached to the EXISTING Control item for the IT asset inventory & classification control (domains asset_management_inventory, frequency quarterly, framework including nist-800-53 / iso-27001 — e.g. control_id CM-8 / UC-ASSET-01) as its operating and execution record; enrich that Control, never create a duplicate. In scope: reconciling the authoritative hardware, software, systems, and services inventory against network, endpoint, cloud, and SaaS discovery scans and change records for the in-scope business units, and reviewing the classification, priority, and labeling of information and associated assets including physical media. Out of scope: the remediation engineering behind a decommission or security investigation (handed to those owners) and the downstream security-scoping processes that consume this cycle's outputs. Upstream: no upstream workflow — the cycle runs on the org's live inventory and discovery systems (external ITAM/CMDB, scanners, change/ticketing) plus the prior run's carry-forward Issue items linked to the anchor Control. Converges on two named deliverables — a signed reconciliation record and an updated classification register with an exported extract; that packaged, dual-signed record is the de-facto handoff package that downstream security-scoping processes consume (there is no named downstream workflow).
workflow · Context
Endpoint, Media & Information Handling Custody
Standing monthly operator desk for endpoint, media, and information-handling custody. The workflow instance is the monthly operating cycle attached to the EXISTING Control item for this custody control (control_id UC-ASSET-04/06/08 and UC-NET-12, Control.frequency monthly, Control.framework spanning nist-800-53, iso-27001, soc2, pci-dss) — each cycle enriches that standing Control rather than creating a new one. In scope: fleet endpoint safeguard and acceptable-use verification, off-premises and external-system use, port/I/O/sensor and collaboration-device restriction, removable-media authorization/custody/sanitization/destruction, and the information-transfer rulebook and agreements across electronic, physical-courier, and verbal channels. Out of scope: identity/access provisioning and network-perimeter engineering, which run under their own controls. No upstream workflow feeds this desk — the prior cycle's close-and-archive export is the carry-forward input that seeds each run (the fleet inventory, media custody register, and transfer rulebook are its own standing inputs). Named deliverables: the fleet-safeguard exception list, the endpoint-posture and custody-cycle disposition decisions, the removable-media authorization log and custody register, sanitization verification evidence and retained destruction certificates, the transfer-rule status, and two corrective-action registers backed by Issue items. Endpoint, media, and transfer streams run in parallel and reconverge at two decision checkpoints that route exceptions to tracked corrective action; terminal by design — it hands off to nothing but its own next monthly cycle.
workflow · Context
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
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
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
Network & Provider Service Monitoring
Each monthly run attaches to the EXISTING network & provider monitoring Control item (UC-LOG-08/UC-LOG-09, frequency = monthly; framework = iso-27001 | nist-csf-2 | nist-800-53) — enrich that Control's evidence trail, never create a duplicate control. The cycle keeps network devices hardened and controlled, network-service documentation (including outsourced services) current, delivered services monitored for conformance, and external providers reviewed against their contractual obligations, feeding every deviation into a single owned remediation log — Issue items linked to the anchor Control — and producing a signed monthly monitoring record archived under retention. In scope: in-scope network devices and services, external service providers (the Vendor register) and their contracts, cross-organizational audit-trail exchange arrangements, and the deviations they produce. Out of scope: incident response and investigation for a provider-reported security event, which is tracked in its own incident case rather than in this monitoring cycle. Consumes no upstream workflow — self-originating, triggered by its own monthly cadence, a newly onboarded network service or provider, or a carried-forward deviation requiring follow-up; the previous instance hands off its still-open remediation Issues (linked to the same Control) as this cycle's carry-forward inputs. Terminal: it hands off to nothing downstream — closure seeds its own next cycle.
workflow · Context
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
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
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
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 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
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
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
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
Regulatory Exam & External Audit Management
Manage a live regulator examination or external audit end to end — from notification intake through request fulfillment, QC’d evidence release, fieldwork support, preliminary-findings response, and commitment closure. Runs on an Audit engagement item created per exam (audit_type = regulatory_exam, or external_attestation for an external audit); the workflow instance attaches to that Audit anchor, and preliminary findings and their corrective-action commitments become linked Issue items. No upstream workflow feeds this — it is triggered by the exam or audit notification itself. In scope: coordinating examiner requests, controlled evidence release, and management responses for a single exam or audit engagement. Out of scope: remediating the underlying control gaps — the findings and committed corrective actions hand off to Finding Remediation & Action-Plan Monitoring — and standing up new obligations surfaced by the exam, which hand off to Regulatory Horizon Scanning & Triage and Regulatory Obligation Implementation.
workflow · Context
Policy Lifecycle Management
Run one policy through its full lifecycle, anchored to a Policy item in the policy library — created at authoring for a net-new policy, enriched in place on each refresh cycle (never duplicated). In scope: authoring and control/authority linkage, stakeholder review, formal approval, publication and workforce attestation, acknowledgement tracking, disposition, and scheduled alignment refresh. Consumes read-only upstream: the enterprise risk assessment (Risk items), control design (Control items), and obligation mapping — this workflow neither produces nor edits them. Produces four named deliverables: the published policy version, a frozen workforce attestation completion record, a section-by-section alignment verdict, and a single approval-ready policy package. Out of scope: enterprise risk assessment, control design, and obligation mapping. The approved policy package is handed off to the Regulatory Compliance Attestation Cycle, which runs the recurring regulatory attestation; the acknowledgement campaign launched here is the one-time publication attestation and is explicitly flagged in the handoff as not-to-be-repeated downstream.
workflow · Context
Regulatory Compliance Attestation Cycle
Regulatory Compliance Attestation Cycle: runs on and enriches the existing Audit item created for this authority and reporting period (audit_type = compliance or regulatory_exam; scope = certification boundary; period_start/period_end = the reporting period) — that Audit item is the attestation record the cycle updates throughout, never a duplicate. Over the cycle: compile evidence for the authority source across the reporting period, validate and resolve evidence gaps, produce the five-section regulatory attestation package, route certifying-officer certification, and archive the package. In scope: the legal entities, products, geographies, and systems named in the certification boundary for that authority and period. Consumes the implemented, owned, control-mapped obligation baseline as the handoff package from the Regulatory Obligation Implementation workflow (the implementations themselves are the Control items whose framework multiselect includes this authority, linked to the anchor Audit). Out of scope: obligations under other authorities, entities outside the certification boundary, and the obligation-to-control implementation itself. Hands the certification outcome, exception register, action plans, and accepted risks off to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Legal & Regulatory Compliance Register Evaluation
Runs the compliance office's recurring register-evaluation cycle as a compliance-review engagement: the workflow instance attaches to an Audit item created per cycle (audit_type: compliance, period_start/period_end bounding the evaluation period, lead_auditor = the compliance officer), and every gap, management directive, and result produced this cycle links back to that Audit. A decision-aware cycle that refreshes the register of applicable legal, regulatory, and contractual requirements — including intellectual-property and software-licensing obligations — confirms ownership, schedules and performs documented compliance evaluations on each requirement's defined cadence, remediates non-compliance, reports status to management, and retains the register and results as evidence. Consumes upstream: between-cycle regulatory change flows in as a data feed from the Regulatory Horizon Scanning & Triage workflow, swept at the register-refresh entry point (a feed, not a formal handoff package). Named deliverables: the dated register of record, the period evaluation schedule, the evaluation results register, the compliance determination, the exposure-ranked remediation set (Issues linked to the cycle Audit), the compliance status report and dashboard, and the retained cycle evidence set. Hands off downstream: obligations that need standing up route to the Regulatory Obligation Implementation workflow — named in prose at close-and-archive, with no handoff package produced here. In scope: the legal, regulatory, and contractual requirements already in the compliance register that fall due for evaluation this period — cadence-due, overdue, or event-triggered. Out of scope: standing up brand-new obligations. The cycle scope — register population, the due subset including overdue catch-ups, and the period boundaries — is set at the register-refresh entry point.
workflow · Context
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
Regulatory Impact Analysis & Obligation Mapping
Regulatory Impact Analysis & Obligation Mapping runs on a compliance Audit engagement record — an Audit item created per triggering instrument (audit_type=compliance) whose scope holds the locked scope statement and to which every gap Issue, risk acceptance, and the workflow instance attach. It consumes two upstream inputs: the triage handoff package from Regulatory Horizon Scanning & Triage (instrument, canonical citation, publication and effective dates, triage disposition) and the canonical instrument text itself — the Official Journal or regulator-register version, the authoritative source the whole analysis cites. It parses that instrument into obligations, maps them to the existing Policy and Control library, classifies and rates gaps, and reconciles the obligation register. Named deliverables: the cited regulatory impact note, the obligation inventory, the authority-to-policy crosswalk, the classified and rated gap Issues, the versioned obligation register, and the final evidence and decision package. In scope: obligation analysis, crosswalk, gap classification, exposure rating, and register reconciliation for the in-scope entities, products, and jurisdictions. Out of scope: remediation build-out (handed off to Regulatory Obligation Implementation) and re-prioritizing the instrument (owned by Regulatory Horizon Scanning & Triage). Confirmed gaps and their action plans hand off to Regulatory Obligation Implementation.
workflow · Context
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
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.