NIST CSF 2.0
385 records. Direct records match this source; 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 · Direct
DE.AE-02 — Adverse Event Analysis: Potentially adverse events are analyzed to better understand associated activities
Adverse Event Analysis: Potentially adverse events are analyzed to better understand associated activities
control · Direct
DE.AE-03 — Adverse Event Analysis: Information is correlated from multiple sources
Adverse Event Analysis: Information is correlated from multiple sources
control · Direct
DE.AE-04 — Adverse Event Analysis: The estimated impact and scope of adverse events are understood
Adverse Event Analysis: The estimated impact and scope of adverse events are understood
control · Direct
DE.AE-06 — Adverse Event Analysis: Information on adverse events is provided to authorized staff and tools
Adverse Event Analysis: Information on adverse events is provided to authorized staff and tools
control · Direct
DE.AE-07 — Adverse Event Analysis: Cyber threat intelligence and other contextual information are integrated into the analysis
Adverse Event Analysis: Cyber threat intelligence and other contextual information are integrated into the analysis
control · Direct
DE.AE-08 — Adverse Event Analysis: Incidents are declared when adverse events meet the defined incident criteria
Adverse Event Analysis: Incidents are declared when adverse events meet the defined incident criteria
control · Direct
DE.CM-01 — Continuous Monitoring: Networks and network services are monitored to find potentially adverse events
Continuous Monitoring: Networks and network services are monitored to find potentially adverse events
control · Direct
DE.CM-02 — Continuous Monitoring: The physical environment is monitored to find potentially adverse events
Continuous Monitoring: The physical environment is monitored to find potentially adverse events
control · Direct
DE.CM-03 — Continuous Monitoring: Personnel activity and technology usage are monitored to find potentially adverse events
Continuous Monitoring: Personnel activity and technology usage are monitored to find potentially adverse events
control · Direct
DE.CM-06 — Continuous Monitoring: External service provider activities and services are monitored to find potentially adverse events
Continuous Monitoring: External service provider activities and services are monitored to find potentially adverse events
control · Direct
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 · Direct
GV.OC-01 — Organizational Context: The organizational mission is understood and informs cybersecurity risk management
Organizational Context: The organizational mission is understood and informs cybersecurity risk management
control · Direct
GV.OC-02 — Organizational Context: Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered
Organizational Context: Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered
control · Direct
GV.OC-03 — Organizational Context: Legal, regulatory, and contractual requirements regarding cybersecurity — including privacy and civil liberties obligations — are understood and managed
Organizational Context: Legal, regulatory, and contractual requirements regarding cybersecurity — including privacy and civil liberties obligations — are understood and managed
control · Direct
GV.OC-04 — Organizational Context: Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organization are understood and communicated
Organizational Context: Critical objectives, capabilities, and services that external stakeholders depend on or expect from the organization are understood and communicated
control · Direct
GV.OC-05 — Organizational Context: Outcomes, capabilities, and services that the organization depends on are understood and communicated
Organizational Context: Outcomes, capabilities, and services that the organization depends on are understood and communicated
control · Direct
GV.OV-01 — Oversight: Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction
Oversight: Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction
control · Direct
GV.OV-02 — Oversight: The cybersecurity risk management strategy is reviewed and adjusted to ensure coverage of organizational requirements and risks
Oversight: The cybersecurity risk management strategy is reviewed and adjusted to ensure coverage of organizational requirements and risks
control · Direct
GV.OV-03 — Oversight: Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed
Oversight: Organizational cybersecurity risk management performance is evaluated and reviewed for adjustments needed
control · Direct
GV.PO-01 — Policy: Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced
Policy: Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced
control · Direct
GV.PO-02 — Policy: Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission
Policy: Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission
control · Direct
GV.RM-01 — Risk Management Strategy: Risk management objectives are established and agreed to by organizational stakeholders
Risk Management Strategy: Risk management objectives are established and agreed to by organizational stakeholders
control · Direct
GV.RM-02 — Risk Management Strategy: Risk appetite and risk tolerance statements are established, communicated, and maintained
Risk Management Strategy: Risk appetite and risk tolerance statements are established, communicated, and maintained
control · Direct
GV.RM-03 — Risk Management Strategy: Cybersecurity risk management activities and outcomes are included in enterprise risk management processes
Risk Management Strategy: Cybersecurity risk management activities and outcomes are included in enterprise risk management processes
control · Direct
GV.RM-04 — Risk Management Strategy: Strategic direction that describes appropriate risk response options is established and communicated
Risk Management Strategy: Strategic direction that describes appropriate risk response options is established and communicated
control · Direct
GV.RM-05 — Risk Management Strategy: Lines of communication across the organization are established for cybersecurity risks, including risks from suppliers and other third parties
Risk Management Strategy: Lines of communication across the organization are established for cybersecurity risks, including risks from suppliers and other third parties
control · Direct
GV.RM-06 — Risk Management Strategy: A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated
Risk Management Strategy: A standardized method for calculating, documenting, categorizing, and prioritizing cybersecurity risks is established and communicated
control · Direct
GV.RM-07 — Risk Management Strategy: Strategic opportunities (i.e., positive risks) are characterized and are included in organizational cybersecurity risk discussions
Risk Management Strategy: Strategic opportunities (i.e., positive risks) are characterized and are included in organizational cybersecurity risk discussions
control · Direct
GV.RR-01 — Roles, Responsibilities, and Authorities: Organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving
Roles, Responsibilities, and Authorities: Organizational leadership is responsible and accountable for cybersecurity risk and fosters a culture that is risk-aware, ethical, and continually improving
control · Direct
GV.RR-02 — Roles, Responsibilities, and Authorities: Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced
Roles, Responsibilities, and Authorities: Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced
control · Direct
GV.RR-03 — Roles, Responsibilities, and Authorities: Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies
Roles, Responsibilities, and Authorities: Adequate resources are allocated commensurate with the cybersecurity risk strategy, roles, responsibilities, and policies
control · Direct
GV.RR-04 — Roles, Responsibilities, and Authorities: Cybersecurity is included in human resources practices
Roles, Responsibilities, and Authorities: Cybersecurity is included in human resources practices
control · Direct
GV.SC-01 — Cybersecurity Supply Chain Risk Management: A cybersecurity supply chain risk management program, strategy, objectives, policies, and processes are established and agreed to by organizational stakeholders
Cybersecurity Supply Chain Risk Management: A cybersecurity supply chain risk management program, strategy, objectives, policies, and processes are established and agreed to by organizational stakeholders
control · Direct
GV.SC-02 — Cybersecurity Supply Chain Risk Management: Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally
Cybersecurity Supply Chain Risk Management: Cybersecurity roles and responsibilities for suppliers, customers, and partners are established, communicated, and coordinated internally and externally
control · Direct
GV.SC-03 — Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes
Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management is integrated into cybersecurity and enterprise risk management, risk assessment, and improvement processes
control · Direct
GV.SC-04 — Cybersecurity Supply Chain Risk Management: Suppliers are known and prioritized by criticality
Cybersecurity Supply Chain Risk Management: Suppliers are known and prioritized by criticality
control · Direct
GV.SC-05 — Cybersecurity Supply Chain Risk Management: Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties
Cybersecurity Supply Chain Risk Management: Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties
control · Direct
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 · Direct
GV.SC-07 — Cybersecurity Supply Chain Risk Management: The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship
Cybersecurity Supply Chain Risk Management: The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship
control · Direct
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 · Direct
GV.SC-09 — Cybersecurity Supply Chain Risk Management: Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle
Cybersecurity Supply Chain Risk Management: Supply chain security practices are integrated into cybersecurity and enterprise risk management programs, and their performance is monitored throughout the technology product and service life cycle
control · Direct
GV.SC-10 — Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement
Cybersecurity Supply Chain Risk Management: Cybersecurity supply chain risk management plans include provisions for activities that occur after the conclusion of a partnership or service agreement
control · Direct
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 · Direct
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 · Direct
ID.AM-03 — Asset Management: Representations of the organization's authorized network communication and internal and external network data flows are maintained
Asset Management: Representations of the organization's authorized network communication and internal and external network data flows are maintained
control · Direct
ID.AM-04 — Asset Management: Inventories of services provided by suppliers are maintained
Asset Management: Inventories of services provided by suppliers are maintained
control · Direct
ID.AM-05 — Asset Management: Assets are prioritized based on classification, criticality, resources, and impact on the mission
Asset Management: Assets are prioritized based on classification, criticality, resources, and impact on the mission
control · Direct
ID.AM-07 — Asset Management: Inventories of data and corresponding metadata for designated data types are maintained
Asset Management: Inventories of data and corresponding metadata for designated data types are maintained
control · Direct
ID.AM-08 — Asset Management: Systems, hardware, software, services, and data are managed throughout their life cycles
Asset Management: Systems, hardware, software, services, and data are managed throughout their life cycles
control · Direct
ID.IM-01 — Improvement: Improvements are identified from evaluations
Improvement: Improvements are identified from evaluations
control · Direct
ID.IM-02 — Improvement: Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties
Improvement: Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties
control · Direct
ID.IM-03 — Improvement: Improvements are identified from execution of operational processes, procedures, and activities
Improvement: Improvements are identified from execution of operational processes, procedures, and activities
control · Direct
ID.IM-04 — Improvement: Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved
Improvement: Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved
control · Direct
ID.RA-01 — Risk Assessment: Vulnerabilities in assets are identified, validated, and recorded
Risk Assessment: Vulnerabilities in assets are identified, validated, and recorded
control · Direct
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 · Direct
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 · Direct
ID.RA-04 — Risk Assessment: Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded
Risk Assessment: Potential impacts and likelihoods of threats exploiting vulnerabilities are identified and recorded
control · Direct
ID.RA-05 — Risk Assessment: Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization
Risk Assessment: Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization
control · Direct
ID.RA-06 — Risk Assessment: Risk responses are chosen, prioritized, planned, tracked, and communicated
Risk Assessment: Risk responses are chosen, prioritized, planned, tracked, and communicated
control · Direct
ID.RA-07 — Risk Assessment: Changes and exceptions are managed, assessed for risk impact, recorded, and tracked
Risk Assessment: Changes and exceptions are managed, assessed for risk impact, recorded, and tracked
control · Direct
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 · Direct
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 · Direct
ID.RA-10 — Risk Assessment: Critical suppliers are assessed prior to acquisition
Risk Assessment: Critical suppliers are assessed prior to acquisition
control · Direct
PR.AA-01 — Identity Management, Authentication, and Access Control: Identities and credentials for authorized users, services, and hardware are managed by the organization
Identity Management, Authentication, and Access Control: Identities and credentials for authorized users, services, and hardware are managed by the organization
control · Direct
PR.AA-02 — Identity Management, Authentication, and Access Control: Identities are proofed and bound to credentials based on the context of interactions
Identity Management, Authentication, and Access Control: Identities are proofed and bound to credentials based on the context of interactions
control · Direct
PR.AA-03 — Identity Management, Authentication, and Access Control: Users, services, and hardware are authenticated
Identity Management, Authentication, and Access Control: Users, services, and hardware are authenticated
control · Direct
PR.AA-04 — Identity Management, Authentication, and Access Control: Identity assertions are protected, conveyed, and verified
Identity Management, Authentication, and Access Control: Identity assertions are protected, conveyed, and verified
control · Direct
PR.AA-05 — Identity Management, Authentication, and Access Control: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
Identity Management, Authentication, and Access Control: Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties
control · Direct
PR.AA-06 — Identity Management, Authentication, and Access Control: Physical access to assets is managed, monitored, and enforced commensurate with risk
Identity Management, Authentication, and Access Control: Physical access to assets is managed, monitored, and enforced commensurate with risk
control · Direct
PR.AT-01 — Awareness and Training: Personnel are provided with awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind
Awareness and Training: Personnel are provided with awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind
control · Direct
PR.AT-02 — Awareness and Training: Individuals in specialized roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind
Awareness and Training: Individuals in specialized roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind
control · Direct
PR.DS-01 — Data Security: The confidentiality, integrity, and availability of data-at-rest are protected
Data Security: The confidentiality, integrity, and availability of data-at-rest are protected
control · Direct
PR.DS-02 — Data Security: The confidentiality, integrity, and availability of data-in-transit are protected
Data Security: The confidentiality, integrity, and availability of data-in-transit are protected
control · Direct
PR.DS-10 — Data Security: The confidentiality, integrity, and availability of data-in-use are protected
Data Security: The confidentiality, integrity, and availability of data-in-use are protected
control · Direct
PR.DS-11 — Data Security: Backups of data are created, protected, maintained, and tested
Data Security: Backups of data are created, protected, maintained, and tested
control · Direct
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 · Direct
PR.IR-02 — Technology Infrastructure Resilience: The organization's technology assets are protected from environmental threats
Technology Infrastructure Resilience: The organization's technology assets are protected from environmental threats
control · Direct
PR.IR-03 — Technology Infrastructure Resilience: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations
Technology Infrastructure Resilience: Mechanisms are implemented to achieve resilience requirements in normal and adverse situations
control · Direct
PR.IR-04 — Technology Infrastructure Resilience: Adequate resource capacity to ensure availability is maintained
Technology Infrastructure Resilience: Adequate resource capacity to ensure availability is maintained
control · Direct
PR.PS-01 — Platform Security: Configuration management practices are established and applied
Platform Security: Configuration management practices are established and applied
control · Direct
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 · Direct
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 · Direct
PR.PS-04 — Platform Security: Log records are generated and made available for continuous monitoring
Platform Security: Log records are generated and made available for continuous monitoring
control · Direct
PR.PS-05 — Platform Security: Installation and execution of unauthorized software are prevented
Platform Security: Installation and execution of unauthorized software are prevented
control · Direct
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 · Direct
RC.CO-03 — Incident Recovery Communication: Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders
Incident Recovery Communication: Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders
control · Direct
RC.CO-04 — Incident Recovery Communication: Public updates on incident recovery are shared using approved methods and messaging
Incident Recovery Communication: Public updates on incident recovery are shared using approved methods and messaging
control · Direct
RC.RP-01 — Incident Recovery Plan Execution: The recovery portion of the incident response plan is executed once initiated from the incident response process
Incident Recovery Plan Execution: The recovery portion of the incident response plan is executed once initiated from the incident response process
control · Direct
RC.RP-02 — Incident Recovery Plan Execution: Recovery actions are selected, scoped, prioritized, and performed
Incident Recovery Plan Execution: Recovery actions are selected, scoped, prioritized, and performed
control · Direct
RC.RP-03 — Incident Recovery Plan Execution: The integrity of backups and other restoration assets is verified before using them for restoration
Incident Recovery Plan Execution: The integrity of backups and other restoration assets is verified before using them for restoration
control · Direct
RC.RP-04 — Incident Recovery Plan Execution: Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
Incident Recovery Plan Execution: Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms
control · Direct
RC.RP-05 — Incident Recovery Plan Execution: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
Incident Recovery Plan Execution: The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed
control · Direct
RC.RP-06 — Incident Recovery Plan Execution: The end of incident recovery is declared based on criteria, and incident-related documentation is completed
Incident Recovery Plan Execution: The end of incident recovery is declared based on criteria, and incident-related documentation is completed
control · Direct
RS.AN-03 — Incident Analysis: Analysis is performed to establish what has taken place during an incident and the root cause of the incident
Incident Analysis: Analysis is performed to establish what has taken place during an incident and the root cause of the incident
control · Direct
RS.AN-06 — Incident Analysis: Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved
Incident Analysis: Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved
control · Direct
RS.AN-07 — Incident Analysis: Incident data and metadata are collected, and their integrity and provenance are preserved
Incident Analysis: Incident data and metadata are collected, and their integrity and provenance are preserved
control · Direct
RS.AN-08 — Incident Analysis: An incident's magnitude is estimated and validated
Incident Analysis: An incident's magnitude is estimated and validated
control · Direct
RS.CO-02 — Incident Response Reporting and Communication: Internal and external stakeholders are notified of incidents
Incident Response Reporting and Communication: Internal and external stakeholders are notified of incidents
control · Direct
RS.CO-03 — Incident Response Reporting and Communication: Information is shared with designated internal and external stakeholders
Incident Response Reporting and Communication: Information is shared with designated internal and external stakeholders
control · Direct
RS.MA-01 — Incident Management: The incident response plan is executed in coordination with relevant third parties once an incident is declared
Incident Management: The incident response plan is executed in coordination with relevant third parties once an incident is declared
control · Direct
RS.MA-02 — Incident Management: Incident reports are triaged and validated
Incident Management: Incident reports are triaged and validated
control · Direct
RS.MA-03 — Incident Management: Incidents are categorized and prioritized
Incident Management: Incidents are categorized and prioritized
control · Direct
RS.MA-04 — Incident Management: Incidents are escalated or elevated as needed
Incident Management: Incidents are escalated or elevated as needed
control · Direct
RS.MA-05 — Incident Management: The criteria for initiating incident recovery are applied
Incident Management: The criteria for initiating incident recovery are applied
control · Direct
RS.MI-01 — Incident Mitigation: Incidents are contained
Incident Mitigation: Incidents are contained
control · Direct
RS.MI-02 — Incident Mitigation: Incidents are eradicated
Incident Mitigation: Incidents are eradicated
risk · Context
Excessive privilege and wrong assignment of access rights
Overly broad or wrongly assigned access rights, applications/services running with excessive privileges, and failure to enforce least privilege — a compromise or insider then gains broad access to systems and data.
risk · Context
Abuse of rights, forged rights, and repudiation of actions
Authorized users or administrators exploit legitimate access beyond permitted scope, fabricate or forge credentials/rights to gain privileges, and repudiate performed actions — undermining accountability and audit-trail integrity.
risk · Context
Weak account provisioning/de-registration and access review
No formal user registration/de-registration procedure and no periodic access-rights review, so orphaned or excessive accounts accumulate and access is not revoked when roles change or personnel leave.
risk · Context
Unauthorized use of equipment and unauthorized access escalation
Use of systems, networks, or devices without authorization, and users with authorized access reaching resources that exceed their authorization, potentially to exfiltrate data or conduct attacks.
risk · Context
Weak authentication and password management
Absent password policy, no MFA, credentials transmitted in clear text, and no session lock/logout on unattended workstations, making account compromise, brute-force login, and session hijacking easy.
risk · Context
GPAI transparency, systemic-risk and synthetic-content obligations
GPAI providers failing transparency/copyright/training-data obligations; systemic-risk models (>10^25 FLOPs) lacking red-teaming, incident reporting, and cybersecurity; unlabeled deepfake/synthetic content; and concentration of GPAI capability creating ecosystem single points of failure.
risk · Context
AI power concentration and erosion of societal trust
Disproportionate access to data, compute, and AI talent creates winner-take-all dynamics foreclosing competition; proliferation of AI-generated synthetic media and automated influence operations degrades the shared epistemic environment and democratic institutions.
risk · Context
AI supply-chain compromise and provider concentration
Because the organization relies on third-party pretrained models, datasets, and libraries that may carry backdoors, malicious code, or bias, and concentrates on a few external AI API providers, AI-dependent workflows are exposed to both supply-chain compromise and provider outage or insolvency, resulting in compromised model behaviour or sudden loss of AI capability.
risk · Context
Aging hardware with no periodic replacement scheme
Because maintenance routines and replacement schedules are absent, equipment is run beyond its reliable service life, so hardware fails - including correlated, pervasive disk failures from same-batch aging - resulting in outages and data loss.
risk · Context
Incomplete asset inventory and classification
No authoritative inventory of information and associated assets, missing ownership, acceptable-use, classification, labelling, or handling rules — preventing effective protection, risk assessment, and secure disposal.
risk · Context
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 · Context
Inadequate security awareness and training
Personnel lacking security awareness and training are more likely to make harmful mistakes, misconfigure systems, or be deceived — providing weak human defence and undermining every technical control. Includes insufficient privacy training.
risk · Context
No acceptable-use policy for messaging and telecoms
Because acceptable-use policies for email, messaging, and telecommunication services are absent, personnel use insecure channels without guidance, so sensitive information is inadvertently or deliberately disclosed through unsanctioned communications.
risk · Context
Phishing, spear-phishing and social engineering
Adversary counterfeits trustworthy communications (email, phone, spoofed websites) to trick individuals — including high-value executives — into revealing credentials or sensitive information, or into enabling wire-transfer/BEC fraud.
risk · Context
Missing role-based and ongoing security/privacy training
Because no role-based training program or ongoing awareness refresh exists for staff handling sensitive data or privileged systems, personnel cannot execute security procedures correctly or recognize evolving attacks, so avoidable errors and successful social-engineering compromises follow.
risk · Context
User error and mishandling of sensitive information
Authorized users make mistakes — incorrect data entry, misconfiguration, improper procedures, incorrect privilege settings, or spilling/mishandling sensitive information — causing harm to information assets without malicious intent.
risk · Context
IT resilience failure — unplanned outage, data loss, slow recovery
Critical technology infrastructure or applications experience unplanned outages, data loss, or prolonged recovery times — including failure of DR systems to activate — disrupting operations and harming stakeholders.
risk · Context
Single-site / single-region / single-supply concentration
Headquarters, data centers, or manufacturing concentrated in one region, single power feed or network path with no redundancy, and no failover — so one catastrophe or outage disables the whole service. Includes backup-facility loss destroying backups.
risk · Context
Client suitability, disclosure and fiduciary breaches
Recommending unsuitable products, failing to disclose conflicts of interest, breaching fiduciary duty, KYC failures, inadequate disclosure of fees/risks, negligent advisory activities, and product flaws causing systematic customer harm.
risk · Context
Environmental regulatory non-compliance
Unauthorized emissions or discharges, improper hazardous-waste handling, missing permits, or non-compliance with PFAS/chemical-reporting rules under EPA/RCRA/Clean Air & Water Acts — driving penalties and remediation.
risk · Context
Improper business or market practices
Losses from antitrust violations, market manipulation (spoofing, layering, front-running), benchmark/rate rigging, unlicensed business activity, and sanctions/export-control violations in the conduct of business.
risk · Context
Intellectual property loss or infringement
Patent, trade-secret, copyright, or trademark infringement claims (competitors or NPEs), loss of key IP through invalidity rulings, inadequate protection of proprietary technology, or inability to enforce own IP against infringers.
risk · Context
Litigation, investigation and enforcement exposure
Adverse judgments, class actions, contract/IP disputes, government subpoenas, DOJ/FTC/SEC investigations, consent decrees, or deferred-prosecution agreements imposing penalties, remediation, and management distraction.
risk · Context
Client selection, sponsorship and exposure-limit breaches
Failure to investigate clients per guidelines, exceeding single-counterparty exposure limits without approval, and sponsoring transactions without adequate counterparty-risk assessment or AML/CTF screening.
risk · Context
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 · Context
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 · Context
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 · Context
Credentials and sensitive data transmitted in clear text
Authentication credentials or sensitive system communications transmitted unencrypted over networks, and absence of mutual sender/receiver authentication, enable interception, credential theft, and spoofing.
risk · Context
Compromised or counterfeit certificates / certificate authority
Adversary counterfeits or compromises a certificate authority so that malware or connections appear legitimate, defeating trust in TLS and code-signing and enabling man-in-the-middle or malicious-code delivery.
risk · Context
Weak or absent encryption and key management
Sensitive data stored or transmitted without adequate encryption, or use of weak/flawed cryptography and poor key generation, storage, rotation, and destruction — enabling interception, disclosure, or tampering of data.
risk · Context
Attacks by capable, motivated threat actors
Because capable, motivated threat actors - outsiders, privileged and non-privileged insiders, organized groups, competitors, malicious partners or suppliers, and nation-states - actively target the organization's cyber resources, deliberate attacks are attempted against its systems and data, resulting in compromise, disruption, or theft when defenses are outmatched.
risk · Context
Coordinated multi-stage / APT campaigns
Adversary coordinates continuous, adaptive, multi-staged campaigns (hopping across systems, combining insider/outsider/supply-chain vectors, spreading from existing presence) to persist and progressively undermine mission/business functions.
risk · Context
Adversary reconnaissance and information gathering
Because adversaries scan perimeters, sniff exposed networks, mine open-source and public information, and surveil personnel and processes, they build a detailed map of the IT environment and its weaknesses, resulting in better-targeted, more likely-to-succeed follow-on attacks.
risk · Context
Unauthorized disclosure / breach of sensitive information
Unauthorized disclosure of information to parties not entitled to receive it, whether by insecure controls (insecurity), spillage, or authorized users induced to expose data — resulting in identity theft, economic loss, and loss of trust.
risk · Context
Data exfiltration and theft of information by attackers
Adversary (outsider, insider, nation-state, or competitor) installs malware or sniffers to locate and exfiltrate sensitive/proprietary information, or steals data by external actors — including systems-security losses from hacking.
risk · Context
Undocumented data inventory and unmapped data flows
No authoritative record of what personal data is held, where, who accesses it, and how it flows to processors/sub-processors and across borders — preventing risk assessment, DSR fulfilment, and enforcement of privacy obligations.
risk · Context
Residual data on improperly disposed or re-used media
Retrieval of recycled or discarded media, and disposal/reuse of storage without proper erasure, exposes residual sensitive information; also insecure/incomplete data deletion in multi-tenant/cloud environments.
risk · Context
Inadequate transparency, notice and deceptive privacy communications
Failure to give clear, timely notice of collection, use, retention, and sharing; misleading or dark-pattern consent flows; and failure to disclose automated decision-making — undermining meaningful consent and compounding power imbalance.
risk · Context
Physical climate risk to facilities and supply chains
Extreme weather (flooding, wildfires, hurricanes, heat stress), sea-level rise, and resource scarcity damage owned/leased facilities, disrupt supplier operations, and impair logistics beyond insurance coverage.
risk · Context
Climate transition risk — carbon pricing and stranded assets
Carbon taxes, cap-and-trade, and mandatory Scope 1-2-3 reporting increase operating costs or strand carbon-intensive assets; failure to credibly plan a net-zero transition jeopardizes access to capital and changing consumer preferences.
risk · Context
Money laundering, sanctions and financial-crime program failures
Failure to prevent money laundering or terrorist financing, file SARs/CTRs, perform adequate KYC/beneficial-ownership due diligence, screen for PEPs, or avoid processing transactions for OFAC-sanctioned parties; BSA/AML program deficiencies.
risk · Context
Ineffective ICFR / undisclosed material weakness
Because internal control over financial reporting is not maintained effectively - material weaknesses undetected or undisclosed and certifications signed despite known deficiencies - financial statements may be materially misstated and filings delayed or restated, resulting in SEC enforcement, delisting, securities-fraud liability, and loss of investor confidence.
risk · Context
Manual journal entries and management-override risk
Manual/automated journal entries posted with transposition errors, wrong account codes, or amounts; recurring entries not updated; and top-side entries used to override controls and manage earnings at period-end.
risk · Context
Revenue-recognition misstatement (fictitious, mis-timed, mis-measured)
Fictitious or channel-stuffed revenue, revenue not recorded for delivered goods, incorrect transaction-price allocation or percentage-of-completion, and principal-vs-agent gross/net errors — the highest-risk assertion cluster in the revenue cycle.
risk · Context
Segregation-of-duties conflicts in financial processes
Incompatible duties (initiate, approve, record, and custody) concentrated in one role or via broad system access enable unauthorized or fraudulent transactions to be recorded and concealed.
risk · Context
Credit and market (rate/FX) risk
Counterparty/customer default exceeding collateral, receivables concentration in deteriorating credits, and unhedged exposure to interest-rate, foreign-exchange, commodity, or equity movements causing material P&L or cash-flow volatility.
risk · Context
Liquidity, capital-structure and refinancing risk
Cash-flow shortfall from working-capital deterioration, covenant breaches accelerating debt, loss of revolving credit, or capital-market disruption; debt maturity walls and downgrades limiting refinancing at acceptable terms; insufficient capital to absorb losses.
risk · Context
External fraud — third-party theft, forgery, payment and account fraud
Third parties defraud the entity: cheque/payment-card forgery, counterfeit currency, identity theft, account takeover with stolen credentials, fraudulent loan applications, and first-party (bust-out) fraud by customers.
risk · Context
Internal fraud — asset misappropriation, embezzlement, forgery
Employees defraud the entity for financial gain: embezzlement or theft of company/client funds, fraudulent expense/payroll claims, forgery to obtain unauthorized disbursements, bribery/kickback schemes, insider trading on own account, and wilful tax evasion.
risk · Context
Inadequate board and management oversight of risk and control
Because board and management oversight of risk and control is weak - unclear tone at the top, ineffective board composition or independence, poor committee structure, and limited senior-management commitment - control priorities are not enforced and resources are withheld, so risks accumulate unmanaged and control failures go uncorrected across the entity.
risk · Context
Missing or insufficient security and privacy policies
Because documented, approved, and enforced security and privacy policies are missing and roles and duties are undefined, personnel operate without guidance on required controls and behaviours, so controls are applied inconsistently and accountability gaps leave violations undetected and unaddressed.
risk · Context
Major project / program delivery failure
Large programs — ERP implementations, digital transformations, or major capital projects — fail to deliver expected benefits on time and within budget due to poor governance, scope creep, or capability gaps.
risk · Context
Weak internal control environment enabling fraud and error
Because the internal control environment is weak - segregation of duties absent, authorization frameworks inadequate, and tone at the top poor - fraudulent and erroneous transactions can be initiated and concealed, resulting in material misstatement and financial, regulatory, and reputational loss.
risk · Context
Insufficient personnel screening and vetting
Failure to vet employees, contractors, or third parties before granting access enables insider threats or introduces compromised individuals; adversaries may deliberately place subverted individuals into (privileged) positions.
risk · Context
Missing security terms in contracts and no disciplinary process
Employment and supplier contracts omit security/confidentiality obligations, and there is no disciplinary process for security violations — removing legal recourse and the deterrent effect against repeat offenders.
risk · Context
Critical talent loss, scarcity and succession gaps
Departure of key executives or irreplaceable specialists without succession or knowledge-transfer plans, plus inability to recruit/retain scarce skills (cyber, data, AI/ML), causing loss of institutional knowledge and execution capacity. Also covers loss of key personnel disrupting operations dependent on specialist knowledge.
risk · Context
Workplace health, safety and well-being failures
Workplace accidents, occupational illness, missing PPE, OHS-regulation violations, premises-liability incidents, and burnout leading to injury claims, workers-compensation, regulatory penalties, and productivity loss.
risk · Context
Failure to detect, assess, and notify breaches on time
Failure to detect, assess, and notify affected individuals and regulators of personal-data breaches within required timeframes and content (GDPR Art.33/34, HIPAA breach rule), resulting in sanctions and compounded individual harm.
risk · Context
No or insufficient incident-response procedures
Without documented, tested incident-response procedures, breaches and failures are handled inconsistently, slowly, or ineffectively, prolonging exposure and amplifying loss.
risk · Context
Missing or insufficient logging and audit trails
Absence of logging/audit trails means unauthorized activity cannot be detected, investigated, or attributed, and adversary actions (obfuscation of intrusion detection, tampering with logs) go unnoticed.
risk · Context
No security monitoring or supervision of privileged activity
Absence of monitoring mechanisms and supervision of personnel actions (especially privileged users) allows undetected misuse, and no process exists to supervise and escalate detected security breaches.
risk · Context
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 · Context
Denial-of-service and system saturation
Simple, targeted, or distributed denial-of-service attacks, wireless jamming, and saturation of systems or networks (adversarial or excessive legitimate load) make resources unavailable to intended users.
risk · Context
Communications interception, eavesdropping and man-in-the-middle
Passive monitoring/sniffing of communications, interception of unencrypted or weakly encrypted channels, wireless interception, and man-in-the-middle attacks capture or corrupt transmitted data — including TEMPEST-type emanation capture.
risk · Context
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 · Context
Remote-work, mobile and split-tunneling exposure
Uncontrolled work outside the premises, split-tunneling, and exploitation of mobile devices/personal systems outside physical and firewall protection expose information through insecure environments and reintroduce compromised devices into the enterprise.
risk · Context
Session hijacking and unauthorized-protocol egress
Adversary hijacks established legitimate sessions (externally or internally based) and conducts attacks/exfiltration using unauthorized ports, protocols, and permitted information flows across the perimeter.
risk · Context
Core process breakdown and inability to scale
Poorly designed, undocumented, or poorly executed business processes lead to errors, rework, cost overruns, service failures, and inability to scale operations reliably; large change programs fail to deliver benefits on time and budget.
risk · Context
Trade-counterparty performance and settlement disputes
Counterparty default on OTC derivatives, settlement disputes with brokers/custodians, failure of a central counterparty, netting/close-out disputes, and margin-call miscalculations cause direct losses.
risk · Context
Client intake, documentation and account-management failures
Missing signed agreements, incomplete legal/ISDA documentation, unretained KYC/AML records, misfiled client files, unauthorized access to client accounts, and negligent loss of client assets held in custody.
risk · Context
Product and service quality failure
Outputs fail to meet specifications, customer requirements, or regulatory standards, leading to recalls, warranty claims, customer attrition, and reputational harm; product-safety incidents generate scrutiny and brand-equity erosion.
risk · Context
Physical and cyber-physical attacks on facilities and infrastructure
Adversary conducts physical attacks on facilities (arson) or supporting infrastructure (cuts power/water), or cyber-physical attacks (remotely altering HVAC), damaging systems and supporting utilities.
risk · Context
Physical damage to assets from disaster, terrorism or vandalism
Loss or damage to facilities, equipment, or physical property from natural disaster (earthquake, flood, hurricane, wildfire), terrorism, civil unrest, vandalism, utility-infrastructure damage, vehicle/aircraft collision, or environmental contamination.
risk · Context
Environmental degradation of equipment (dust, humidity, temperature, EMI)
Equipment sited without environmental controls suffers from dust, corrosion, freezing, humidity, voltage or temperature variation, and electromagnetic/thermal radiation or EMP, causing malfunction or failure.
risk · Context
Inadequate protection against fire, flood and physical hazards
Absence of fire suppression, smoke detection, flood barriers, or drainage in facilities housing information assets, and poor cabling infrastructure susceptible to damage, tapping, or accidental disconnection.
risk · Context
Inadequate physical protection and access controls
Buildings and sensitive areas lacking perimeter security, key-card/lock/mantrap controls, or supervision of visitors and cleaning/outside staff allow unauthorized physical access to equipment and media — including tailgating past physical checks.
risk · Context
Theft of equipment, media or unattended devices
Physical stealing of storage media, printouts, or computing/network equipment (including unattended laptops outside the perimeter), potentially exposing stored data. Unprotected storage locations increase exposure.
risk · Context
Cross-border personal-data transfer without safeguards
Transferring personal data to jurisdictions lacking equivalent protection without SCCs, BCRs, adequacy decisions, or other recognized mechanisms, exposing individuals and the organization to legal risk.
risk · Context
Brand and reputational crisis
Product-safety/quality failures, executive misconduct, data breaches, adverse media, or viral social-media/activist campaigns erode customer trust, investor confidence, partnerships, and brand equity — with long-term value loss exceeding near-term financial impact.
risk · Context
Stakeholder trust and social-license erosion
Gradual loss of trust and social license among customers, employees, investors, regulators, and communities — from perceived values misalignment, poor ESG/governance conduct, or repeated service failures — weakening stakeholder relationships and long-term enterprise value even absent a single acute crisis.
risk · Context
Inadequate or absent risk assessment process
No systematic process to identify, analyse, evaluate, and treat risk — including missing fraud-risk assessment and no ongoing risk monitoring — leaving material exposures unidentified and untreated before they materialise.
risk · Context
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 · Context
Malware delivery, insertion and compromise of systems
Adversary crafts and delivers known, modified, or targeted malware (via email, web, removable media, or downloadable software) and compromises system software to take control, exfiltrate data, or degrade functions.
risk · Context
Ransomware disrupting operations and data availability
Criminal groups deploy ransomware that encrypts systems and data, disrupting operations, causing losses, and demanding extortion payment — a high-impact convergence of malware, availability, and continuity risk.
risk · Context
Vulnerabilities introduced during software development
Inherent weaknesses in programming languages and development environments introduce errors and exploitable vulnerabilities into software products, and software malfunctions cause incorrect outputs, crashes, or security weaknesses.
risk · Context
Product, customer or market concentration
Revenue or gross profit concentrated in a single product line, customer, channel, or geography; loss of one major customer or an adverse regulatory change to a dominant product creates existential revenue risk.
risk · Context
Geopolitical, macroeconomic and sovereign risk
Armed conflict, political instability, sanctions, trade-policy reversals (tariffs, export bans, data-localization, forced tech transfer), expropriation/nationalization, and adverse macroeconomic cycles disrupt operations, supply chains, and cost structures.
risk · Context
Failed M&A, integration or divestiture
Acquisitions fail to achieve synergies due to cultural misalignment, IT-integration failure, or customer attrition; overpayment and hidden liabilities materialise as goodwill impairment; divestitures disrupt shared-service dependencies.
risk · Context
Strategic misalignment and execution failure
Because strategic objectives are poorly defined, internally inconsistent, or misaligned with mission and stakeholders, approved strategies cannot be executed - resource gaps and weak governance of change compound the shortfall - resulting in resource misallocation, missed objectives, and value destruction.
risk · Context
Hardware and equipment failure
Malfunction or breakdown of storage, processing, communications, sensor, controller, or display equipment (aging, resource depletion, disk errors) disrupting availability or integrity — including intermittent/degraded operation producing incorrect results.
risk · Context
Loss of essential services (power, HVAC, telecoms)
Interruption of power supply, air-conditioning/water utilities, or telecommunications — from unstable grids, single power feeds, UPS/generator failure, or carrier/fiber outages — stops operations or harms equipment and personnel.
risk · Context
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 · Context
Software and information-system failure
Failure or malfunction of operating-system, networking, or application software (defects, resource depletion, failed releases) causing loss of availability/integrity and impeding mission/business functions — including core banking/payments outages.
risk · Context
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 · Context
Critical vendor failure, insolvency or concentration
A key supplier, SaaS provider, or outsourced partner becomes insolvent, exits the market, or suffers a prolonged outage; sole-source and shared-tier concentration (multiple tier-1 vendors on a common tier-2) creates hidden single points of failure with no backup.
risk · Context
Supply-chain disruption of critical inputs
Geopolitical events, natural disasters, port congestion, or logistics failures interrupt supply of critical raw materials or components (semiconductors, rare earths); just-in-time models are exposed to demand spikes.
risk · Context
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 · Context
Third-party compliance failure creating vicarious liability
A vendor, subcontractor, or channel partner violates labor, environmental, anti-bribery (FCPA/UKBA), or data-protection rules, exposing the company to liability and reputational harm; fourth-party/N-tier dependencies are opaque.
risk · Context
Vendor/outsourcing service non-performance and disputes
Outsourced processing, IT, payroll/HR, print/mail, or sub-custodian providers fail to meet service levels, deliver defective software, make incorrect payments, or breach contractual deliverables, causing processing errors, outages, and loss.
risk · Context
Weak supplier security requirements and monitoring
Because supplier contracts omit security requirements and SLAs and third-party service delivery is not monitored, processors and sub-processors operate without equivalent, audited obligations, so third-party weaknesses and breaches propagate into the organization undetected.
risk · Context
Inadequate vulnerability scanning and pre-release testing
Software released without adequate testing, and no regular vulnerability scanning or penetration testing, leaves exploitable defects undiscovered until they manifest — or are exploited — in production.
risk · Context
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.
risk · Context
Zero-day exploitation
Adversary employs attacks that exploit as-yet-unpublicized vulnerabilities (targeted, based on reconnaissance, or nontargeted), compromising systems before any patch or signature exists.
standard · Direct
NIST CSF 2.0
NIST Cybersecurity Framework 2.0
unified · Context
UC-ACCESS-03 — Enforce least privilege, need-to-know, and segregation of duties
A documented access control policy grants access strictly on business need-to-know, with entitlements defined through roles that default to least privilege. Segregation-of-duties conflicts (e.g., request versus approve, develop versus deploy) are defined in a conflict matrix, enforced in systems, and mitigated with compensating controls where unavoidable. Role and entitlement definitions are approved by data or system owners and re-approved whenever they change.
unified · Context
UC-ACCESS-04 — Restrict privileged rights, utilities, and unauthorized software
Privileged access rights are individually authorized against a business justification, time-bound or periodically recertified, and issued on separate accounts distinct from daily-use identities. Use of utility programs capable of overriding system or application controls is restricted to authorized administrators and logged. Application allowlisting or equivalent controls prevent installation and execution of unauthorized software on managed systems.
unified · Context
UC-ACCESS-06 — Manage unique identities and identifiers end to end
Every user, service, and device is assigned a unique identifier from an authoritative source; shared or group identifiers are prohibited except under documented approval with compensating controls. Identifiers are issued through a controlled process, mapped to accountable owners, deactivated promptly when no longer needed, and not reused for a defined period.
unified · Context
UC-ACCESS-07 — Proof identities before binding credentials
The identity of users is verified through documented evidence checks proportional to the assurance level of the access requested before initial credentials are issued. The proofed identity is bound to its credentials and recorded, and re-proofing occurs on credential recovery or other high-risk changes.
unified · Context
UC-ACCESS-09 — Authenticate all users with multi-factor authentication
Every user is uniquely identified and authenticated before access, with multi-factor authentication enforced for remote access, privileged access, and access to sensitive data environments. Authentication follows secure log-on practices: credentials are validated only over protected channels, and federated identity assertions (e.g., SAML/OIDC tokens) are signed, protected, and verified. External and non-organizational users are held to the same authentication rigor, with authentication strength documented against the risk of the interaction.
unified · Context
UC-ACCESS-18 — Log and monitor system activity, capacity, and incidents
Systems generate log records that are protected and made available for continuous monitoring. Performance, capacity, and security events are monitored against thresholds, with alerts triaged and incidents identified and resolved through a tracked process. Resource use is projected and tuned to meet current and future capacity requirements.
unified · Context
UC-ACCESS-19 — Restrict physical access and maintain environmental safeguards
Physical access to facilities, data centers, and protected assets is authorized, badged, logged, monitored, and revoked on separation, commensurate with risk. Environmental protections including power conditioning and backup, fire detection and suppression, and temperature and humidity control safeguard systems, and physical access and environmental events are reviewed.
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-02 — Inventory data and document processing activities and flows
Maintain inventories of data and corresponding metadata for designated data types, together with records of processing activities capturing purposes, data categories, recipients, retention periods, and safeguards as required by applicable privacy regulation. Maintain representations of authorized network communications and internal and external data flows, such as data-flow diagrams. Review and update these records upon significant change and at least annually so management relies on complete, quality information.
unified · Context
UC-ASSET-03 — Classify, prioritize, and label information and assets
Classify information and associated assets under a documented scheme based on sensitivity, criticality, and business impact, and prioritize assets and protections accordingly. Apply labels and markings, including on physical media, that identify the classification and any distribution or handling limitations. Identify confidential information at creation or receipt and keep classifications and priorities current through periodic review.
unified · Context
UC-ASSET-05 — Inventory supplier services and assess critical suppliers
Maintain an inventory of services provided by suppliers, including the systems and data each service touches and the internal owner of the relationship. Assess critical suppliers for security and risk before acquisition or engagement, record the results, and reassess when services, dependencies, or risk profiles change.
unified · Context
UC-ASSET-07 — Manage assets through their life cycle and recover them at exit
Manage systems, hardware, software, services, and data through their full life cycles from acquisition through secure retirement, with defined ownership and handling at each stage. Recover all organizational assets from personnel and other interested parties upon termination or change of engagement, tracking issuance and verified return.
unified · Context
UC-ASSET-09 — Receive, analyze, and act on threat and vulnerability intelligence
Receive cyber threat intelligence from information-sharing forums and other sources, and identify and record internal and external threats to the organization. Operate a documented channel to receive, analyze, and respond to vulnerability disclosures from internal and external reporters. Track intelligence and disclosures to closure and feed the results into risk assessment and remediation.
unified · Context
UC-ASSET-10 — Assess and track changes and exceptions for risk impact
Manage changes and exceptions to the environment and to security requirements through a process that assesses risk impact before approval. Record each change or exception with its assessment, approver, owner, and expiry or review date, and track open items to closure.
unified · Context
UC-ASSET-11 — Improve security plans and processes from operational lessons
Identify improvements from the execution of operational processes, procedures, and activities, and track them to implementation. Establish, communicate, maintain, and improve incident response and other cybersecurity plans that affect operations, updating them after exercises, incidents, and significant organizational or technical change.
unified · Context
UC-AUDIT-17 — Follow up on findings and escalate risk acceptance
Findings, recommendations, and management action plans - including improvements identified from security tests and exercises, and those coordinated with suppliers and third parties - are tracked in a follow-up process, and implementation is confirmed through evidence-based verification before closure. When management has accepted a level of risk that may exceed the organization's risk appetite, the matter is discussed with senior management and, if unresolved, escalated to the board. Follow-up logs and escalation records are retained.
unified · Context
UC-AUDIT-22 — Review risk strategy and performance with leadership
Leadership periodically reviews the cybersecurity and risk management strategy and program performance against defined metrics, targets, and conformance requirements. Review outcomes are used to adjust strategy, direction, and program activities to ensure coverage of organizational requirements and risks. Performance and conformance monitoring follows a defined cadence with documented results and assigned follow-up actions.
unified · Context
UC-BCDR-03 — Back up data and verify restorability
Back up information, software, and system images at a frequency and scope aligned to defined recovery point objectives, protect backup copies from unauthorized access and modification, and keep copies separate from the primary environment. Verify backup integrity and restorability through periodic test restores, and verify the integrity of backups before using them for restoration.
unified · Context
UC-BCDR-04 — Provide redundant and alternate processing, storage, and telecom
Implement redundancy and alternate capability sufficient to meet availability and recovery objectives: an alternate storage site for backup media, alternate processing capability sufficiently separated from the primary site to avoid shared hazards, and diverse or alternate telecommunications services with priority-of-service provisions. Ensure alternate facilities provide security controls equivalent to the primary site and can assume operations within recovery time objectives.
unified · Context
UC-BCDR-05 — Manage capacity to meet availability requirements
Determine and monitor the processing capacity and utilization of infrastructure, data, and software against current and forecast demand, and add capacity before demand exceeds defined thresholds. Protect availability of shared resources through priority-based allocation or quotas, and alert responsible personnel when capacity thresholds are breached.
unified · Context
UC-BCDR-07 — Execute recovery plans to restore systems and operations
When disruption occurs, execute the documented recovery procedures to restore systems, applications, and data to a known operational state within recovery time objectives. Select, scope, and prioritize recovery actions based on criticality and dependencies, verify the integrity of restored assets, and confirm normal operating status before returning systems to service.
unified · Context
UC-BCDR-08 — Declare recovery complete and set post-incident norms
Define criteria for ending incident recovery and formally declare recovery complete only when those criteria are met. Complete all incident and recovery documentation, and establish post-incident operational norms that account for critical mission functions and residual cybersecurity risk.
unified · Context
UC-BCDR-09 — Communicate recovery status to stakeholders
Communicate recovery activities, progress, and estimated restoration timelines to designated internal and external stakeholders through pre-defined channels and cadences. Release public updates about incident recovery only through approved spokespersons, methods, and messaging.
unified · Context
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 · Context
UC-CONFIG-04 — Build security and privacy into software design and upkeep
Engineer security and data-protection requirements into systems and software from design onward, applying secure coding standards, pre-release security testing, and privacy-preserving defaults such as data minimization and pseudonymization. Maintain software after release by remediating identified vulnerabilities and applying security patches within risk-based timeframes. Replace or remove software that is unsupported or no longer justified by risk.
unified · Context
UC-CONFIG-06 — Verify authenticity and integrity of hardware and software
Assess the authenticity and integrity of hardware and software before acquisition and use, sourcing components from trusted suppliers. Verify digital signatures or equivalent integrity evidence on software, firmware, and updates before installation, and block or investigate components that fail verification.
unified · Context
UC-CONFIG-07 — Perform controlled, timely maintenance of systems and hardware
Schedule, approve, document, and review maintenance, repair, and replacement of systems and hardware in accordance with manufacturer specifications and organizational requirements, whether performed on site or off site. Sanitize equipment before off-site maintenance and verify security controls after maintenance is completed. Obtain maintenance support and spare parts within defined timeframes so hardware is maintained, replaced, or removed commensurate with risk.
unified · Context
UC-CRYPTO-01 — Encrypt data at rest and in transit
Sensitive and nonpublic data at rest is rendered unreadable using strong, industry-accepted encryption, or truncation/tokenization for stored account data, with storage and retention minimized to defined business need. Data in transit is protected with strong cryptography and trusted certificates over all open, public, or external networks, rejecting fallback to insecure protocols. Transmission, movement, and removal of information, including to removable media, is restricted to authorized users and processes, and the integrity of data in both states is protected. Where encryption of nonpublic information is infeasible, compensating controls are documented, approved by the CISO, and reviewed at least annually.
unified · Context
UC-CRYPTO-04 — Protect data in use from unauthorized access
Data being processed in memory or active sessions is protected against unauthorized access and exposure through techniques commensurate with risk, including process isolation, memory protections, masking of sensitive fields on display, and confidential-computing or equivalent enclave technologies for high-sensitivity workloads. Access to data in use is limited to the processing identity, and residual data is cleared from memory and temporary storage after use.
unified · Context
UC-GOV-02 — Understand organizational context and stakeholder expectations
Identify and document the organization's mission, its internal and external stakeholders and their needs and expectations, the critical objectives, capabilities, and services that stakeholders depend on, and the outcomes, capabilities, and services the organization itself depends on. Use this business context to scope and prioritize risk management activities, communicate it to those who need it, and refresh it when the business environment changes.
unified · Context
UC-GOV-03 — Identify and manage legal, regulatory, and contractual obligations
Identify, document, and keep current all legal, statutory, regulatory, and contractual requirements relevant to information security and privacy — including privacy and civil-liberties obligations — and define and assign the organization's approach to meeting each. Assess and document applicability determinations, including any regulatory exemptions claimed, and file the notices required to support those determinations. Review the obligations register at planned intervals and upon regulatory or business change.
unified · Context
UC-GOV-04 — Set tone at the top: integrity, ethics, and risk-aware culture
Leadership defines and demonstrates commitment to integrity, core ethical values, and the desired risk-aware culture through an adopted code of conduct, consistent leadership behavior, and periodic evaluation of adherence with timely remediation of deviations. Organizational leadership is responsible and accountable for cybersecurity and internal-control risk and fosters a culture that is ethical, risk-aware, and continually improving, with expectations communicated to all personnel and business partners.
unified · Context
UC-GOV-05 — Ensure board-level oversight of risk and internal control
The board of directors (or equivalent governing body), demonstrating independence from management and appropriate expertise, oversees the development and performance of internal control and the cybersecurity risk management program, approving the risk strategy and material policies. The board periodically reviews risk-management outcomes, program effectiveness, and management reporting, and directs adjustments to strategy and direction; oversight activities and decisions are documented in minutes and supporting materials.
unified · Context
UC-GOV-06 — Define security roles, responsibilities, and authorities
Establish and document organizational structures, reporting lines, and the roles, responsibilities, and authorities for information security, risk management, and internal control, with board oversight of their design. Communicate assignments to the individuals and teams concerned, keep them current through organizational and personnel change, and enforce them in practice so that ownership of each security obligation is unambiguous.
unified · Context
UC-GOV-11 — Allocate adequate resources and budget for security
Allocate and manage funding, personnel, and other resources commensurate with the organization's cybersecurity risk strategy, roles, responsibilities, and policies, ensuring security and privacy requirements are addressed in capital planning, budgeting, and investment decisions. Periodically evaluate resource allocation and utilization for adequacy and optimization, and adjust budgets as priorities and risks change.
unified · Context
UC-GOV-14 — Establish and maintain approved security policies and procedures
Establish, approve, publish, and maintain the organization's information-security policy suite as a governed whole: a top-level policy plus the topic-specific policies, each with an accountable owner, board/management approval, planned review cycles, and communication to relevant parties. Domain-specific policy content is governed by its own unified control; this objective owns the suite-level lifecycle (inventory, approval chain, review cadence, communication, exceptions).
unified · Context
UC-GOV-17 — Establish enterprise risk management strategy and appetite
Establish, document, and communicate a leadership-approved enterprise risk management strategy, including risk management objectives agreed by stakeholders, defined risk appetite and tolerance statements, and a documented risk assessment policy with procedures and a consistent methodology for identifying, analyzing, prioritizing, and responding to risk. Ensure governance activities keep risk-taking optimized within appetite, and review and update the strategy, appetite, and policy at planned intervals.
unified · Context
UC-HR-06 — Embed security and competence in HR practices
Human resources processes incorporate cybersecurity at each stage, from recruiting and onboarding through role change and separation, with defined security checkpoints. The organization defines competence requirements for roles, attracts and develops qualified personnel through training and performance evaluation, and plans for succession and contingency in security-relevant positions.
unified · Context
UC-IR-04 — Triage, categorize, and escalate reported security events
Triage every reported security event: validate that it is genuine, assess it against the agreed classification scheme, and decide whether to declare it an incident. Categorize and prioritize declared incidents by type, severity, and business impact, and escalate or elevate them to defined roles and management tiers according to documented thresholds and timeframes. Record triage decisions and their rationale in the incident system of record.
unified · Context
UC-IR-05 — Assess and validate incident scope, impact, and magnitude
For each declared or suspected incident, estimate the scope of affected systems, data, and business processes and the resulting impact, and validate those estimates as investigation proceeds. Document magnitude assessments — records affected, service disruption, and financial exposure — and update them at defined points so response priority, escalation, and notification decisions rest on current, validated figures.
unified · Context
UC-IR-06 — Respond to, contain, and eradicate declared incidents
On declaration of an incident, execute the incident response plan in coordination with internal teams and relevant third parties such as providers, law enforcement, and insurers. Contain the incident using predefined strategies for its category, eradicate the cause by removing malicious artifacts and closing exploited weaknesses, and coordinate handling with contingency and recovery activities through to resolution. Communicate response status as the plan requires and document all response actions taken, feeding lessons into response procedures.
unified · Context
UC-IR-07 — Investigate incidents and preserve evidence and records
Track and document every incident from declaration to closure in a system of record covering status, actions performed, decisions, and timeline. Collect incident data and evidence using documented procedures that preserve integrity, provenance, and chain of custody so evidence remains suitable for disciplinary and legal proceedings, and record investigation actions as they are performed. Perform analysis, including root-cause analysis, to establish what took place and why, and record the conclusions.
unified · Context
UC-IR-08 — Notify authorities and affected parties within deadlines
Maintain a notification matrix of internal stakeholders, regulators, and other external parties with triggers, deadlines, content requirements, and approved communication owners. Require personnel to report suspected incidents to the response capability within defined timeframes, notify authorities and other required external bodies within their statutory windows, and share incident information with designated internal and external stakeholders as the communications plan directs. Notify affected individuals when thresholds are met — for high-risk personal-data breaches, communicate without undue delay in clear and plain language with mitigation advice; for regulated categories of data, notify individuals, media, and regulators within the mandated statutory windows when applicable thresholds are reached, honoring notification duties owed to partner organizations. Retain evidence of every notification's timing, audience, and content.
unified · Context
UC-IR-09 — Recover from incidents using defined initiation criteria
Define objective criteria for initiating incident recovery — such as confirmed eradication, completed forensic preservation, and management authorization — and apply them before restoration begins. Identify, develop, and execute recovery activities that restore affected systems, data, and services to a known-good state, verifying integrity before return to production and confirming with business owners that normal operations have resumed.
unified · Context
UC-LOG-04 — Continuously monitor systems for anomalous activity
Operate continuous monitoring under a documented strategy that defines what is monitored, the metrics, and the frequencies — including ongoing assessment of security-control effectiveness — and report security status to defined roles on a defined cadence. Deploy monitoring across hosts, networks, and applications, at the perimeter and interior, to detect attacks, indicators of compromise, unauthorized connections, and anomalous behaviour indicative of malicious acts, natural disasters, or errors. Analyze flagged anomalies promptly to determine whether they represent security events requiring further evaluation.
unified · Context
UC-LOG-05 — Correlate and analyze events centrally with threat intel
Aggregate logs and alerts into a central analysis capability (such as a SIEM) that correlates information from multiple internal and external sources and enriches it with cyber threat intelligence and contextual information. Review and analyze collected records on a defined cadence for indications of inappropriate or unusual activity, using record-reduction and on-demand report generation that does not alter the original records. Route findings and adverse-event information to authorized staff and tools, and communicate monitoring responsibilities and results internally so accountable parties can act.
unified · Context
UC-LOG-06 — Evaluate events and declare incidents against defined criteria
Define written criteria for declaring a security incident, including thresholds that identify a reportable personal-data breach. Evaluate analyzed events against those criteria, declare incidents and initiate the response process when criteria are met, and record the assessment and rationale for every evaluated event. For reportable personal-data breaches, notify the competent regulator within the mandated statutory window with the prescribed content, and document all breaches, their effects, and remediation regardless of whether notification was required.
unified · Context
UC-LOG-07 — Monitor user sessions and personnel activity
Monitor user and administrator activity for signs of misuse: capture and review session activity for defined high-risk circumstances such as privileged or remote sessions, with legal review and any required disclosure to users, and monitor personnel technology usage against acceptable-use expectations to surface potentially adverse events. Restrict access to captured session data to authorized reviewers and involve HR and legal counsel in handling findings.
unified · Context
UC-LOG-09 — Monitor providers and exchange audit data across organizations
Define monitoring requirements for external service providers and monitor their activities, service status, and security-relevant events against contractual obligations, reviewing provider-supplied logs and reports on a defined cadence. Where audit trails cross organizational boundaries, agree methods for coordinating, exchanging, and protecting audit information with the external parties and preserve the identity context needed to trace cross-organizational actions.
unified · Context
UC-LOG-10 — Monitor the physical environment for adverse events
Monitor the physical environment of facilities hosting systems and data — using mechanisms such as camera surveillance, badge and entry logs, and environmental sensors — to detect potentially adverse physical events. Review physical-access records and environmental alerts on a defined cadence and feed anomalies into security-event analysis.
unified · 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-PHYS-03 — Protect facilities against fire, water, and environmental hazards
Design and equip facilities to protect technology assets from fire, water, temperature, humidity, and other physical and environmental threats. Deploy and independently maintain fire detection and suppression, water damage detection with accessible shutoff valves, and environmental monitoring and control at required levels. Configure alarms to notify responsible personnel automatically when protective systems activate or parameters go out of range.
unified · Context
UC-RISK-02 — Integrate risk management into enterprise processes and projects
Risk management is integrated into organizational structures, decision-making, and business activities rather than operated as a standalone silo. Cybersecurity and information security risk activities are incorporated into enterprise risk management processes, and information security risk is addressed within project management for all projects from initiation through delivery. ERM artifacts referencing cyber risk and project gate documentation with security risk sections evidence operation.
unified · Context
UC-RISK-03 — Define risk appetite, tolerance, and risk assessment criteria
The organization documents its risk framing: risk appetite and tolerance statements, assumptions, constraints, priorities, and the scope and context within which risk is managed. A standardized, structured methodology for calculating, documenting, categorizing, and prioritizing risks is defined, approved, communicated, and maintained. Risk criteria and appetite statements are reviewed periodically and after significant organizational change.
unified · Context
UC-RISK-05 — Communicate and consult with stakeholders on risk
Established lines of communication ensure risk information flows across the organization and with external stakeholders, including risks from suppliers and other third parties. Stakeholders are appropriately and inclusively involved through structured communication and consultation at each step of the risk process, and human and cultural factors are explicitly considered. Consultation records, meeting minutes, and risk communication distributions evidence operation.
unified · Context
UC-RISK-07 — Identify and analyze risks and opportunities to objectives
Risks and strategic opportunities (positive risks) are systematically identified at entity and process levels, and each identified risk is analyzed for likelihood and potential impact using the best available historical, current, and forward-looking information. Severity is assessed with consistent scales to support comparison across the risk universe. Results, sources, and analysis assumptions are recorded.
unified · Context
UC-RISK-08 — Evaluate and prioritize risks against risk criteria
Analyzed risks are evaluated against the established risk criteria to determine inherent risk and whether treatment is required. Risks are prioritized based on severity, risk appetite, and organizational context to direct treatment resources and response sequencing. Prioritization outcomes and rationale are documented and communicated to risk owners.
unified · Context
UC-RISK-09 — Select, plan, and implement risk treatments
For each risk exceeding tolerance, a response (accept, avoid, mitigate, or share/transfer) is selected consistent with the organization's strategic risk response direction. Treatment plans with owners, actions, and timelines are formulated, approved, implemented, and tracked to completion, and residual risk is re-evaluated against tolerance. Response decisions and treatment status are communicated to stakeholders.
unified · Context
UC-RISK-15 — Continually improve the risk management program
Lessons from evaluations, monitoring, and operating experience are translated into improvements to the risk management framework and process. Improvement actions are planned, assigned owners, and tracked to completion, and the framework is continually adapted to remain suitable for the organization. Improvement backlogs and completed-action evidence demonstrate operation.
unified · Context
UC-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-TPRM-01 — Operate a third-party security risk management program
Establish and operate a management-approved third-party and supply-chain risk management program with a written strategy, policies, and procedures, reviewed at defined intervals and after significant changes to the supply chain or threat landscape. Define and communicate roles and responsibilities for supplier, customer, and partner relationships, and integrate third-party and supply-chain risk into enterprise and cybersecurity risk management. Maintain a register of third-party relationships and contractual arrangements prioritized by criticality, and assess criticality, substitutability, and concentration risk before contracting. Apply risk-based due diligence, embed security requirements, audit and access rights, termination rights, and sub-outsourcing conditions in agreements, and protect organizational information processed, stored, or transmitted on external systems. Define, agree, and periodically review service agreements and supplier performance, reassess third parties on a defined cycle, operate controls to identify and address weaknesses across the relationship life cycle, and maintain documented, tested exit strategies for providers supporting critical or important functions.
unified · Context
UC-TPRM-02 — Perform risk-based due diligence before engaging vendors
Before entering a formal relationship, perform security due diligence on prospective vendors and business partners proportionate to their criticality, evaluating security posture, financial and operational risk, and supply-chain exposure, and document the acceptance decision. Use acquisition strategies, sourcing methods, and selection criteria designed to reduce supply-chain risk before contract award.
unified · Context
UC-TPRM-03 — Bind vendors to security and privacy terms by contract
Include binding security and privacy requirements in contracts and agreements with vendors, service providers, and processors before access, service delivery, or data exchange begins: required security controls, confidentiality, breach notification, audit rights, subcontractor terms, and data handling, return, and deletion obligations. Document and authorize each information exchange or system interconnection under an appropriate agreement, and review agreements periodically. Ensure agreements satisfy the contractual clause requirements mandated by applicable privacy and security regulations for the data and services involved.
unified · Context
UC-TPRM-04 — Monitor vendor performance, services, and risk
Continuously monitor third-party performance, service delivery, and security posture against contractual and risk requirements throughout the relationship. Conduct periodic reassessments and reviews, such as questionnaires, assurance reports, and audits, at a frequency based on criticality, and manage changes to supplier services. Record, prioritize, and track identified vendor risks through response and remediation.
unified · Context
UC-TPRM-05 — Include suppliers in incident notification and response
Establish agreements or contractual provisions requiring suppliers to notify the organization of security incidents and supply-chain compromises within defined timeframes. Include relevant suppliers and third parties in incident-response planning, exercises, response, and recovery activities, with coordination roles defined in advance.
unified · Context
UC-TPRM-06 — Manage secure termination and disposal at relationship end
Include termination and post-relationship provisions in supplier agreements and supply-chain risk plans: return or verified destruction of data, revocation of access and credentials, service transition, and retention of required evidence. Dispose of data, documentation, tools, and system components securely at end of life or end of relationship using defined techniques, and record each disposal.
unified · Context
UC-TRAIN-01 — Deliver security awareness training to all personnel
Provide security and privacy awareness training to all personnel as part of onboarding, at least annually thereafter, and when threats, policies, or systems change materially. Include practical exercises reflecting current threats, such as phishing simulations and social-engineering awareness, and update content based on lessons learned and emerging risks. Require timely completion as a condition of continued system access.
unified · Context
UC-TRAIN-02 — Train personnel with specialized security roles and duties
Identify roles with significant security, privacy, or elevated-risk responsibilities (e.g., administrators, developers, incident responders, senior leaders) and provide role-based training before access or duties are granted, when systems or duties change, and at least annually. Maintain a qualified security and privacy workforce through defined competencies, development plans, and recruitment and retention practices for security staff.
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-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.
workflow · Context
Cybersecurity Assurance Review
Cybersecurity Assurance Review — a CAE-owned assurance engagement that runs on the EXISTING Audit item opened from the audit plan (audit_type=it_audit, status PLANNED, lead_auditor and scope already set): the workflow instance attaches to that item and enriches it end to end, never creating a duplicate engagement record. It covers the three IIA Cybersecurity Topical Requirement domains (governance, risk management, and control activities) over the cyber estate bounded in the engagement memo (in scope: named legal entities, networks, cloud tenants, and OT/ICS where included; out of scope: areas whose assurance is documented as delivered by other engagements), testing against the NIST 800-53 Rev 5 catalog with CSF 2.0 / ISO 27001 as the aggregation frame. It originates from the audit plan (no upstream workflow) and produces the findings register (one four-Cs Issue per finding), the cyber posture summary carrying the per-domain and overall Standard 14.5 conclusions, and the approved engagement package — which it hands to the downstream Audit Report Drafting workflow.
workflow · Context
Fraud & Forensic Investigation Engagement
Fraud & Forensic Investigation Engagement as a decision-aware workflow. It runs on a dedicated Audit item (audit_type: investigation) created for this allegation at intake — the confidential case record — with the workflow instance attached to that item and its visibility restricted to the named investigation team. In scope: one specific fraud allegation, worked predication-gated and confidentially from intake through evidence preservation, forensic procedures, interviews, loss quantification, and audit-committee reporting; the named deliverables are the chain-of-custody register, the findings memorandum with its loss-quantification schedule, and the privilege-marked audit-committee fraud report. Out of scope: the enterprise fraud risk profile (owned by Fraud Risk Assessment & Anti-Override Control Review, which receives scheme intelligence from this case rather than being rerun here) and any unrelated conduct discovered in passing (which gets its own intake record). It consumes the hotline intake package from Control Responsibility Communications & Ethics Hotline when so routed, and hands each control breakdown off as an Issue item — control-gap findings to Finding Remediation & Action-Plan Monitoring and ICFR-affecting deficiencies to SOX Deficiency Remediation — rather than duplicating that work.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
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
Internal Audit Engagement Lifecycle
Internal Audit Engagement Lifecycle: run an IIA-aligned engagement on the existing Audit item (audit_type=internal) created by Audit Engagement Planning — it enriches that item and never creates a duplicate; the workflow instance attaches to the Audit item and is archived on it at close. In scope: evidence requests, fieldwork, finding evaluation, supervisory QA, conclusions per objective, and action-plan registration for the auditable entity and period fixed at planning (Audit.scope, Audit.period_start/period_end). Named deliverables: the evaluated findings register (one Issue item per finding), conclusions per objective (recorded on the Audit item as rating/opinion), and the report-ready handoff package. Out of scope: report wording (owned by Audit Report Drafting) and remediation validation (owned by Finding Remediation & Action-Plan Monitoring). It consumes the approved planning handoff package from Audit Engagement Planning and hands off to BOTH downstream workflows — Audit Report Drafting (the findings register and conclusions) and Finding Remediation & Action-Plan Monitoring (the registered action records) — rather than duplicating their work.
workflow · Context
Finding Remediation & Action-Plan Monitoring
Finding Remediation & Action-Plan Monitoring runs on the EXISTING parent Audit item — the issued engagement whose report findings are being followed up — enriching that Audit and its linked findings rather than creating a new engagement; the workflow instance attaches to that Audit item, and each report finding is an Issue item linked to it. It tracks issued-report findings and their agreed management actions from registration through evidence validation, closure, extension, risk acceptance, escalation, and committee reporting, and produces a verified disposition register and a signed final evidence-and-decision package. In scope: all open findings from the engagement plus any prior-cycle findings still open against the same auditee. Out of scope: re-performing engagement fieldwork and re-wording report findings (both belong to the upstream Audit Report Drafting workflow) and assembling the board pack (the downstream Quarterly Board & Audit-Committee GRC Reporting workflow consumes this cycle's outputs). It consumes the issued final report and findings register handed off from Audit Report Drafting and hands its verified outputs to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
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
Continuous Controls Monitoring (ISCM) Cycle
Run the continuous controls monitoring (ISCM) cycle: pull the current-period control metrics and score them against thresholds, triage degraded and failed controls, update the POA&M, report control health to governance, recalibrate the monitoring strategy, then classify the disposition and prepare, hand off, and archive the cycle package. Each interval runs as one workflow instance attached to the existing Process item that represents the ISCM / continuous-controls-monitoring program (process_type = security_process) — enrich that program record every cycle, never create a duplicate. The monitored control set is the existing Control items (Control.frequency doubles as the monitoring cadence, Control.control_owner as the accountable owner) and the POA&M is the existing Issue register (issue_type = deficiency, source = self_assessment); metric definitions and pass/degraded/fail threshold bands have no native field, so they live in the ISCM strategy document carried on the anchor Process item. The cycle produces the control-health scorecard, the reconciled POA&M, the control-health / security-status report, and the recalibrated ISCM strategy. In scope: the recurring NIST 800-137 monitoring loop — metric collection, threshold comparison, triage, POA&M maintenance, security-status reporting, and monitoring-strategy tuning for the controls under continuous monitoring. Out of scope: formal security control assessment and driving gap remediation to closure, which is owned by the downstream Security Control Assessment & POA&M Remediation workflow that consumes this cycle's handoff package. No upstream workflow feeds this one; it is triggered by the arrival of the monitoring interval.
workflow · Context
Technical Security Testing & Pentest Engagement
Runs ON an existing Audit item (audit_type: it_audit) that represents the authorized penetration-test engagement — the workflow instance attaches to that record and enriches it (scope, ratings, dates, and the assurance conclusion write back to its fields); it never creates a duplicate engagement record. In scope: authorized technical testing (reconnaissance, discovery, exploitation validation, severity rating, reporting, and retest) of the defined system boundary against its control baseline and assessment objective, with each confirmed finding recorded as an Issue linked to the anchor Audit and its affected Controls. Out of scope: any testing beyond the agreed rules of engagement, and the downstream remediation program itself — confirmed control gaps and open POA&M findings are handed to the Security Control Assessment & POA&M Remediation workflow, and the assurance conclusion to the Cybersecurity Assurance Review workflow. No upstream workflow feeds this engagement; its inputs are the anchor Audit, the in-scope system boundary (Process items), the control baseline (Control items, framework nist-800-53), the assessment objective and signed authorization, and any open Issue items (source: penetration_test / vulnerability_scan) from prior engagements.
workflow · Context
Vendor SOC 1/SOC 2 Report Review & CUEC Mapping
Reach a defensible reliance conclusion on a service organization's SOC 1/SOC 2 report. The workflow instance runs on an Audit item (audit_type: vendor_review) created for this vendor's SOC report period — enrich that item, never duplicate it; its native fields carry the report and reliance metadata (external_firm = CPA firm, opinion = service auditor's opinion, period_start/period_end = report coverage, report_date, rating = overall reliance verdict). Consumes the vendor risk handoff package from the Third-Party Vendor Risk Lifecycle workflow — the existing Vendor item, its tier, and the dependent Process items. In scope: report scope and type confirmation, the service auditor's opinion and exception analysis, complementary user entity control (CUEC) mapping, bridge/gap-period coverage, and the documented reliance decision — producing the SOC reliance memo and the reviewer-ready reliance package. Out of scope: the vendor's initial risk tiering and onboarding, and ongoing control monitoring. Hands the completed reliance package to the Continuous Controls Monitoring (ISCM) Cycle (and Third-Party ICT Vendor Regulatory Assurance) workflows.
workflow · Context
User Access Review & Recertification
Runs on the existing Control item for UC-ACCESS-02 (user access review) — with UC-ACCESS-03 linked by item relationship — enriching that Control, never creating a duplicate; each quarterly or event-triggered cycle is a workflow instance attached to it, so archived instances accumulate as the de-facto control execution log. A decision-aware workflow covering entitlement extraction, manager certification, revocation, and independent verification. Consumes at start the prior cycle's scope-change carry-forward Issues and prior signed report (both attached to the same Control) plus the period's source-of-record entitlement extracts and period-end HR roster. Produces a signed, audit-ready recertification evidence package and control-owner report as the named deliverable. In scope: SOX-significant applications, systems holding data classified Confidential or above, identity infrastructure (directory, SSO, PAM), and privileged-reach platforms, across all account populations (standard, privileged, service, shared, emergency break-glass, third-party); triggered on scheduled cadence or by event (post-incident, auditor request). Out of scope: lifecycle provisioning and the privileged-access model itself — systemic findings hand off to the Joiner-Mover-Leaver Access Lifecycle (lifecycle gaps) and Privileged Access & Authorization Model Management (privileged-model findings) workflows.
workflow · Context
Vulnerability & Patch Management Cycle
Recurring vulnerability & patch management lifecycle covering NIST SP 800-53 RA-5 (vulnerability scanning) and SI-2 (flaw remediation) and NIST CSF 2.0 ID.RA and PR.PS. Each cycle runs as one recurring instance anchored to the EXISTING vulnerability & patch management Control item (a Control with domains = vulnerability_patch_management — e.g. the UC-VULN-01 scanning control, control_owner = cycle owner); the instance enriches that Control's evidence trail rather than creating a new subject, and the instance itself is the cycle record. In scope: authenticated scanning of the confirmed asset inventory, severity-based triage against the SLA matrix, standard and emergency remediation, rescan verification, time-bound risk acceptance of residuals, metrics reporting, and cycle closure. Named deliverables: the deduplicated, enriched finding register (one vulnerability_scan Issue per finding, linked to the Control), rescan closure evidence, time-bound compensating-control-backed risk-acceptance exceptions (policy_exception Issues), and the cycle KPI & trend report. Consumed as inputs, not produced: the authoritative asset inventory / CMDB and the enterprise change-approval policy (a Policy item). The workflow is self-triggered by its own scheduled scan window (or an actively-exploited advisory) with no upstream or downstream workflow — its carry-forward package feeds the next iteration of this same cycle at intake.
workflow · Context
Business Continuity & DR Test Exercise
Run one operating cycle of an existing business continuity / disaster recovery plan-testing Control (the BC/DR test control this instance attaches to, UC-BCDR-04 "tests"): plan, execute, and evaluate a BC/DR exercise against the RTO and RPO objectives, then fold the resulting gaps back into the BC and DR plans as versioned redlines — a decision-aware workflow. It consumes as declared inputs the in-force BC and DR plans (existing Policy items), the business impact analysis (BIA), and prior after-action reports; it creates an Audit item (audit_type=operational) as the definitive exercise record, and produces named deliverables: an approved exercise package, an actual-versus-target RTO/RPO scorecard, remediation findings (Issue items), and a signed-off after-action report with an indexed evidence package. In scope: scoping, running, and evaluating one scheduled or triggered BC/DR exercise for the selected in-scope systems and business services, and folding resulting gaps back into the BC and DR plans. Out of scope: real incident response, and recovery-objective (RTO or RPO) changes to systems outside the agreed exercise scope. Standalone: no upstream or downstream workflow is required; any cross-workflow linkage — for example a related incident-response or BIA-maintenance workflow — is expressed as a declared input, not a predecessor.
workflow · Context
Security Awareness Training Campaign
Security Awareness Training Campaign as a decision-aware workflow covering curriculum, launch, completion tracking, phishing simulation, escalation of non-completers, and effectiveness reporting. It runs on the EXISTING security-awareness training Control item (framework iso-27001 / nist-800-53, domains include awareness_training, control_owner = campaign owner): each cycle is one workflow instance attached to that Control — enriching it, never creating a duplicate control — and the prior cycle's archived instance on the same Control is the baseline for content refresh and simulation trends. No upstream workflow feeds this campaign; each cycle is driven by the campaign charter (trigger, window, audience segments, inclusion/exclusion rules, mandated topics, completion target, and phishing click/report thresholds) supplied at launch, together with the HR headcount and contractor/vendor rosters and the prior campaign report. In scope: running one campaign cycle end-to-end for all in-scope staff, contractors, and third parties with system access, against the campaign charter. Out of scope: routine LMS administration outside a campaign and HR disciplinary action beyond the policy consequence ladder. The named deliverables are the campaign effectiveness report and the indexed evidence archive, presented to the security governance / management review forum. No downstream workflow consumes it; the next cycle and any interim micro-training are scheduled at close (recorded on the campaign record — AssureSwarm has no compliance-calendar surface).
workflow · Context
ISMS Internal Audit & Management Review
Runs one ISO 27001 clause 9.2 internal audit and clause 9.3 management review cycle — including clause 10.1 corrective actions — against the existing Audit item for this cycle (audit_type=internal), whose scope, lead_auditor, and period dates already carry the ISMS audit-programme entry: the workflow enriches that Audit item and its findings, never creates a duplicate audit. Upstream it consumes the Annex A control population (Control items, framework iso-27001) and the applicability decisions in the Statement of Applicability, the risk register (Risk items) and treatment plan, the prior-cycle Audit and open Issue records, and the org's ISMS policies and procedures (Policy items) as audit criteria. Named deliverables: the internal audit findings report, the clause 10.1 corrective-action records (recorded on the finding Issue items), the management review pack, and the approved clause 9.3 minutes and action register. Out of scope: the certification-body external audit and day-to-day control operation. No upstream workflow feeds this cycle and no single downstream workflow consumes its output; at close the cycle is archived on the Audit item as retained ISMS documented information, and carry-forward items re-enter the audit programme (the next PLANNED Audit item), the risk register, or the next review's inputs.
workflow · Context
Joiner-Mover-Leaver Access Lifecycle
Run one instance per HR-triggered joiner, mover, or leaver event as a decision-routed access-lifecycle control that enriches the EXISTING Control item for JML / user-access provisioning-deprovisioning (control library, domains=access_control_identity, framework nist-800-53 + iso-27001) - attach the instance to that control, never create a duplicate. Consume the authoritative HR event record from the external HR system of record (the trigger): classify the event, then provision role-based access, adjust with SoD checks on transfer, or evidence timely removal on exit, and file the named audit-ready access-lifecycle evidence package before closing. In scope: identity-provider, directory, HR-system, ERP, and connected-SaaS entitlements for the affected worker. Out of scope: HR record creation itself, physical-security badge policy, and system-owner entitlement design. The run is terminal - no upstream or downstream AssureSwarm workflow: it starts from the external HR event and ends at the archived evidence package attached to the Control item. The anchor Control links (item relationship) to the access Risk it mitigates.
workflow · Context
CSF 2.0 Profile & Maturity Assessment
Runs on an Audit item created for this assessment cycle (audit_type = readiness) — the CSF assessment engagement the workflow instance attaches to and enriches as it progresses (scope, period, rating, and report fields are written on that Audit item; every in-scope Control is linked to it so the controls-scoped profile is queryable). Build, against that boundary, a NIST CSF 2.0 Current Profile, a Target Profile, an organizational Tier rating, a subcategory gap analysis, and a CISO-ready remediation roadmap. The workflow originates on its own — scoping ingests prior CSF profiles and open POA&M (Issue) items as data, not as a named upstream handoff. In scope: rating the in-scope control set against the CSF 2.0 Core, setting target outcomes, assigning a Tier, and producing a prioritized roadmap. Out of scope: executing the remediation projects themselves and re-performing independent assurance testing. The named deliverable is the assessment package (profiles, gap analysis, Tier, posture report, roadmap, closure artifact), handed off to TWO downstream workflows that consume it rather than repeat the profiling: the Cybersecurity Assurance Review (always) and the AI Governance & Risk/Impact Assessment (only when AI systems fall inside the boundary).
workflow · Context
Information Security Program Governance Review
Standing operator workflow for the CISO's quarterly information security program governance review and its annual leg. Each cycle runs as one workflow instance attached to the existing "Information Security Program Governance" Process item (process_type: security_process, owner CISO), with the four governing Control items UC-GOV-06/09/10/15 linked to it. It is a decision-aware flow that enriches — never recreates — the senior-management-approved information security program plan (held as a Policy item) and the current role assignments every cycle, and branches into the written board report, workforce competency review, and plan reapproval when the annual interval or a significant change requires it. Named deliverables: the reapproved information security program plan (the Policy item, re-versioned and re-signed), the roles-and-authorities register, the annual written board report to the governing body, and the workforce competency review — each retained on the workflow instance. In scope: the program plan, security roles/authorities/reporting lines, the annual board report, and workforce competency for this organization; out of scope: executing the underlying protective controls and enterprise ERM governance, which are owned by their own workflows (coso-erm is referenced here only for oversight-of-design of the governance structure). There is no upstream or downstream workflow handoff — this cycle is genuinely self-contained: it starts from its own cadence trigger, consumes its own prior-cycle governance record, and seeds the next cycle at close.
workflow · Context
Privileged Access & Authorization Model Management
Standing operator workflow for the quarterly privileged-access recertification cycle, separate-account and utility-program controls, and application allowlisting, paired with role and security-attribute authorization-model maintenance and enforcement spot-testing across applications, databases, and infrastructure. Each quarterly instance runs as the operating cycle of the existing privileged-access Control item in the control library (UC-ACCESS-04, with UC-ACCESS-05 linked) — it enriches that Control's operating-effectiveness record rather than creating a new subject, and reads risk context from the linked Risk item (category cyber_security, domains access_control_identity). Consumes standing account, log, change-queue, and org-change feeds pulled live from IAM/PAM, directory, SIEM, allowlist tooling, and the HR system of record, plus the prior quarter's archived instance for its inventory register and carryover exceptions; it consumes no upstream workflow's handoff package. In scope: privileged and administrative accounts, control-overriding utility programs, the application allowlist, and the role and attribute authorization model with its enforcement points. Out of scope: standard non-privileged joiner-mover-leaver provisioning, network and perimeter controls, and application change management, each handled by its own workflow. Every exception and enforcement gap normalizes to an Issue item linked to the anchor Control, and the archived workflow instance is the cycle's evidence of record — open Issues are the cross-cycle carry-forward. Runs on a routine quarterly cadence, or out of cycle when an audit finding, incident, or major organizational change (reorg, new system, acquisition) requires it; no upstream workflow feeds it and it hands off to no single downstream workflow. Owned by the IAM Operations Lead.
workflow · Context
Cybersecurity Incident Response
Cybersecurity incident-response cycle as a decision-aware workflow spanning detection and validation, scoping, incident declaration and response-plan activation, containment with evidence preservation, eradication and recovery, POA&M updates for the control deficiencies the incident exposed, and a technical lessons-learned retrospective, closed through a disposition decision and archival. The workflow instance runs on the incident record — an Issue item (issue_type=exception, source=management_identified, severity per the org scheme) created at detection, since the schema has no native Incident type — and enriches that one record through to archival rather than creating duplicates. In scope: security events and confirmed incidents affecting the system boundary and its NIST 800-53 IR-family controls — the detection sources (logging/monitoring Control items, UC-LOG-06), affected systems (Process items, UC-ASSET-11), containment and recovery actions, forensic evidence, the deficiency Issues that become the POA&M, and their linked Risk items. Out of scope: the enterprise incident-management ticketing lifecycle and external breach-notification/legal reporting, which run in their own workflows. Where an Incident Management Lifecycle workflow is running, this cycle consumes its handoff package (initial ticket, reporter, affected systems); it hands the closed incident's control-deficiency findings — the open POA&M Issues (issue_type=deficiency) — to the Continuous Controls Monitoring (ISCM) Cycle as shared items it queries directly.
workflow · Context
Identity & Authenticator Lifecycle Administration
Standing operator workflow for identity issuance and ownership, shared-identifier exception handling, the dormancy and non-reuse sweep, identity proofing and credential binding, and the full authenticator lifecycle from verified issuance through protection, exposure scanning, and scheduled rotation or revocation. Each monthly cycle runs as a new workflow instance attached to the existing identity & authenticator lifecycle Control item (the UC-ACCESS-06/07/08 family; domains=access_control_identity, frequency=monthly) — the run enriches that standing control's evidence trail, never creating a duplicate control. It consumes no upstream workflow: its inputs are the prior cycle's own carry-forward Issue items (open corrective actions, pending shared-ID review dates, deferred rotations, each linked to the anchor Control) plus current request, source, and inventory extracts. Named deliverables: the issuance & ownership register, the dormancy/non-reuse sweep log, the shared-ID exception disposition and its compensating-control Control items, the identity-proofing evidence package with credential-binding records, the authenticator issuance/strength/default-change log, the protection/exposure-scan disposition, the rotation-and-revocation log, and the identity & authenticator lifecycle-health dashboard — all rolled into an archived, immutable operating record. Because no Identifier/Authenticator/Credential item type exists in the schema, per-identifier, per-binding, and per-authenticator records live as rows in these step-attached registers and logs; only exceptions, gaps, and carry-forwards are promoted to Issue items linked to the anchor Control, and approved shared-identifier waivers are recorded as compensating-control Control items plus a policy_exception Issue. In scope: unique-identifier issuance and ownership mapping for users, services, and devices; shared/group-identifier exceptions; the monthly dormancy and non-reuse sweep; identity proofing proportional to assurance level and credential binding; and authenticator issuance, hardening, protection, exposure remediation, rotation, and revocation across passwords, tokens, keys, and certificates. Out of scope: access authorization and entitlement reviews, joiner/mover/leaver approval routing, and privileged-session management, which are operated by their own workflows. There is no downstream handoff workflow — corrective actions and carry-forward items are tracked to closure within this cycle and seed the next monthly instance of the same control.
workflow · Context
Authentication Platform & Session Policy Operations
Monthly authentication-platform operating cycle. Anchor: this instance runs on the existing Process item for authentication-platform / session-management operations (process_type: security_process, frequency: monthly) — enrich that standing Process each cycle, never create a duplicate — with the four operated Control items UC-ACCESS-09/11/12/13 (framework tags carrying the standards mapping, domains: access_control_identity) linked to it. In scope: MFA enforcement and enrollment across remote, privileged, and sensitive-data access; secure log-on and federation-trust verification; lockout and anomalous-logon defense; session lifecycle controls (inactivity lock, automatic termination, concurrent-session limits, re-authentication for sensitive operations); and system-use, last-logon, and failed-attempt notices, across the IdP or SSO tenant, VPN or remote-access gateway, PAM tooling, and applications classified as housing sensitive data. Out of scope: identity provisioning and joiner-mover-leaver lifecycle, access certification, and privileged-access request approval, which are operated by their own workflows. There is no upstream workflow dependency: the instance is self-originating on its own initial inputs — the authentication-platform inventory (a document on the anchor Process, refreshed each cycle) and the prior-cycle operating record (the prior Workflow instance on the same Process plus its carried-forward open Issue items). The four operating areas run in parallel and reconverge at the platform-posture disposition. Named deliverables: the MFA enforcement-coverage register, the authentication-posture memo, the lockout-and-anomaly log, the session-policy compliance matrix, the banner-and-notice verification record, the platform-health dashboard and readiness summary, and the corrective-action register — each attached to its step, with every gap raised as a self_assessment Issue linked to the Control it degrades. There is no downstream handoff: this terminal recurring cycle seeds its own successor via carry-forward Issue items at close.
workflow · Context
Data Encryption & In-Use Protection Operations
Standing operator workflow for the quarterly encryption sweep across data at rest, in transit, and in use, including CISO-approved compensating controls where encryption is infeasible, with a dashboarded readiness classification and corrective-action tracking. Each quarterly instance runs against — and enriches — the existing Control item for the data-encryption / in-use-protection control (domains cryptography_key_management + data_protection_privacy, quarterly frequency, control_owner set); it never creates a duplicate control. It consumes the prior cycle's carry-forward — the still-open corrective-action Issue items and the active compensating-control Control items already linked to that anchor Control (there is no upstream handoff package). Named deliverables: the sensitivity-classified inventory register; the at-rest, in-transit, movement-control, and data-in-use findings registers; the CISO-approved compensating-control register; the program-health dashboard; the corrective-action register; and the archived operating record. In scope: every data store, transmission channel, and removable-media pathway that holds or moves sensitive or account data, plus high-sensitivity workloads that process data in use. Out of scope: key and certificate inventory and rotation, which are reviewed under the separate key-management program. Terminal by design: no downstream workflow consumes this cycle's output — open corrective actions and compensating controls carry forward as explicit inputs to the next quarterly cycle.
workflow · Context
Facility Access Administration & Monitoring
Standing monthly operator workflow anchored to the existing **Facility Access Administration** Process item (process_type: security_process), with the operated Control items UC-PHYS-01, UC-PHYS-02, and UC-ACCESS-19 (control_category: physical, frequency: monthly) linked to it; each cycle runs as a fresh workflow instance and its reconciliation packages, decision forms, and Issue items attach to that instance. It covers credential authorization, entry control and visitor logging, key/badge custody and revocation — plus the monthly surveillance, access-log, and environmental-safeguards review with facilities, including the data-center and protected-asset access confirmation. In scope: authorization, issuance, and periodic re-justification of physical credentials; entry-control and visitor-escort enforcement; key/combination/badge custody, rotation, and revocation; and the monthly surveillance, access-log, visitor-record, and environmental-safeguards review across all facilities, perimeters, and secure areas including the data center and other protected-asset locations. Out of scope: logical/system access provisioning and full incident-response investigation — a confirmed intrusion or data-center compromise is handed off to the incident-response process. No upstream workflow feeds this capability; it runs on its own monthly cadence and on personnel-change and reported-anomaly triggers, and terminates at close-and-archive (the run itself is the retained audit trail — no other downstream workflow consumes the cycle package). Control references: NIST 800-53 PE-2/PE-3/PE-6/PE-8, ISO 27001 A.7.1–A.7.4/A.7.6.
workflow · Context
Environmental & Utility Systems Maintenance
Standing operator workflow for the monthly environmental and utility systems preventive-maintenance calendar — fire/water/environmental protection, emergency power and lighting, protected cabling, and electromagnetic shielding — producing the single maintenance-and-inspection log required as evidence. Anchor: each monthly cycle runs as a new workflow instance attached to the existing umbrella physical/environmental-maintenance Control item in the control library (control_category=physical, frequency=monthly, framework nist-800-53|iso-27001|nist-csf-2), with the specific UC-PHYS-03/05/06/07 Control items linked — the run enriches that Control's execution history, never creates a duplicate control. Consumes its inputs directly with no feeder workflow: the PM calendar entry, the fire/water/power/lighting/cabling/shielding asset inventories, and the independent maintenance vendor's service tickets and test records (the vendor is a Vendor item in the third-party register; its tickets attach as step evidence). The prior cycle's archived export and its still-open deficiency Issues (linked to the anchor Control) are the only carry-forward channel. In scope: the physical environmental and utility protection systems for the in-scope facilities and rooms (fire detection and suppression, water-damage detection and shutoff valves, temperature/humidity monitoring, UPS and generators, emergency lighting and power shutoffs, protected cabling and wiring closets, and electromagnetic shielding). Out of scope: logical access, network security, and the building's base construction. There is no downstream workflow: this standing cycle drains to its own retained archive and seeds next month's cycle with the corrective-action Issues left open.
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
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
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
Identity Assurance Review
This review runs on an Audit engagement item created for the review cycle (audit_type: it_audit; scope: the identity assurance boundary) — the workflow instance attaches to that Audit, and the five in-scope UC-ACCESS Control items (UC-ACCESS-07/08/09/11/12) link to it. It is self-originating: no upstream workflow feeds it — it starts from the review trigger, the governing controls, and the collected evidence. Review the IAL, AAL, and FAL assurance requirements against the current identity proofing, authentication, and federation controls for the in-scope systems, then remediate, document, and hand off open gaps. It produces the target-level register, the current-state control inventory, the scored gap register, the per-control assurance determination memo, and the compiled assurance review package; each open gap is recorded as an Issue (POA&M) item linked to its UC-ACCESS Control and the anchor Audit. In scope: NIST SP 800-63 identity assurance levels for the systems named in the locked workplan. Out of scope: broader access provisioning, joiner-mover-leaver lifecycle, and privileged-access certification. Hands off the assurance determination and any open POA&M items to the Security Control Assessment and POA&M Remediation workflow.
workflow · Context
Security Monitoring & Detection Operations
Each weekly cycle is a recurring instance attached to the existing continuous security-monitoring Control item (domains: logging_monitoring_detection, control_type: detective, frequency: weekly) — the cycle enriches that standing Control with its operating record, never creating a duplicate control. It consumes the prior cycle's carry-forward (unresolved queue Issues, open watchlist entries, open corrective actions) and the documented continuous-monitoring strategy (a Policy item linked to the Control), and produces named deliverables: the deployment coverage-and-effectiveness assessment, the enriched central SIEM analysis queue, the maintained detection watchlist, and the signed cycle security-status report. In scope: verifying monitoring deployment and effectiveness, working the central SIEM threat-intel analysis queue, triaging flagged anomalies, maintaining the detection watchlist, reporting security status to the defined roles, and verifying continuous protection-service health and tuning across hosts, networks, and applications at both the perimeter and the interior. Out of scope: incident containment, eradication, and recovery — confirmed security events are handed off mid-cycle to the Security Incident Response workflow rather than duplicated here.
workflow · Context
User Activity & External Exposure Monitoring
Monthly operator cycle for the standing user-activity and external-exposure monitoring control (UC-LOG-07/UC-LOG-11) — a detective, monthly-frequency Control that already exists in the control library. Each cycle runs as one workflow instance attached to that existing Control (enrich it — never create a duplicate control); the accountable owner and cadence come from Control.control_owner and Control.frequency=monthly. The instance runs the restricted privileged/remote session and acceptable-use review alongside the external open-source and dark-web exposure sweep, then converges every confirmed finding from both halves — each recorded as an Issue item linked to the anchor Control — into one consolidated restricted case log (XLSX) for security-event evaluation. Consumes upstream: no workflow feeds it — session capture and the exposure sweep are the two parallel entry points; each cycle draws on the standing monitoring program's authorized-reviewer roster, the acceptable-use policy and employee-monitoring disclosure notice (Policy items), the external search-set markers, and the prior cycle's carry-forward Issues. Named deliverables: the personnel-activity and exposure disposition decisions, the HR/legal referral and takedown Issues, the cycle-health dashboard, and the consolidated restricted case log. Downstream handoff: confirmed findings hand into the security-event evaluation queue — an informal handoff recorded as a reference on each case-log entry and in each Issue.description, since the graph has no terminal handoff node. In scope: privileged/remote session review, personnel acceptable-use monitoring, and the external open-source/dark-web exposure sweep for one monthly cycle. Out of scope: the automated SIEM alerting pipeline and the downstream security-event evaluation itself.
workflow · Context
Network & Provider Service Monitoring
Each monthly run attaches to the EXISTING network & provider monitoring Control item (UC-LOG-08/UC-LOG-09, frequency = monthly; framework = iso-27001 | nist-csf-2 | nist-800-53) — enrich that Control's evidence trail, never create a duplicate control. The cycle keeps network devices hardened and controlled, network-service documentation (including outsourced services) current, delivered services monitored for conformance, and external providers reviewed against their contractual obligations, feeding every deviation into a single owned remediation log — Issue items linked to the anchor Control — and producing a signed monthly monitoring record archived under retention. In scope: in-scope network devices and services, external service providers (the Vendor register) and their contracts, cross-organizational audit-trail exchange arrangements, and the deviations they produce. Out of scope: incident response and investigation for a provider-reported security event, which is tracked in its own incident case rather than in this monitoring cycle. Consumes no upstream workflow — self-originating, triggered by its own monthly cadence, a newly onboarded network service or provider, or a carried-forward deviation requiring follow-up; the previous instance hands off its still-open remediation Issues (linked to the same Control) as this cycle's carry-forward inputs. Terminal: it hands off to nothing downstream — closure seeds its own next cycle.
workflow · Context
Physical Environment Monitoring Review
Standing operator workflow for the monthly physical-environment monitoring review across facilities hosting systems and data — badge and entry logs, camera surveillance coverage and footage, and environmental sensor alerts. Each cycle runs as a recurring workflow instance attached to the existing UC-LOG-10 Control item (control_type=detective, control_category=physical, frequency=monthly, framework=nist-csf-2, domains include physical_environmental_security and logging_monitoring_detection) — it enriches that Control's execution history and never creates a duplicate control. In scope: physical-access, surveillance, and environmental monitoring of the in-scope facilities and the systems and data they host. Out of scope: logical-access review and the downstream analysis and remediation of confirmed events, which are handed off to the security-event analysis workflow. Runs on a routine monthly cadence (or out-of-cycle after a triggering incident) with no upstream workflow feeding it — it originates from the anchor Control, its prior-cycle instance, and the prior cycle's still-open Issue items. Consolidates findings into a de-duplicated physical-event register, packages every confirmed adverse physical event as a security-event case handed off to the security-event analysis workflow, and tracks monitoring coverage gaps to closure as owned corrective-action Issues. Implements NIST CSF 2.0 continuous detection monitoring (control UC-LOG-10).
workflow · Context
Resilience & Failover Readiness Verification
Standing quarterly operator workflow that verifies alternate storage, alternate processing, and diverse telecommunications capability (UC-BCDR-04) and validates the safe-mode, alternate-communications, and alternate-security-mechanism design configured on critical systems (UC-BCDR-11). Each quarterly instance runs against the EXISTING UC-BCDR-04 alternate-capability Control item in the Control library (frequency quarterly), with the UC-BCDR-11 degraded-mode Control item linked as the second in-scope control — it enriches the evidence trail on those existing controls, never creating a duplicate control. Self-originating: it consumes no upstream workflow handoff, reading the two governing Control items (control_id UC-BCDR-04 and UC-BCDR-11), the prior quarter's archived readiness instance, and the open corrective-action Issues carried forward on those controls; all operational reference data (backup schedule, alternate-site media/replication log, site records, telecom inventory, system design specs and configs) enters as PBC uploads on the verifying step, since none of it is item-typed. In scope: confirming that this alternate capability and degraded-mode design remain current, hazard-separated, secured to primary-site parity, and ready to assume operations within RTO. Out of scope: the live failover exercise that actually cuts over to the alternate site, run separately by the assure-line DR test workflow that consumes the readiness state this workflow maintains. Named deliverables: six verification memos (storage-site, processing-capability, telecom, safe-mode, alternate-communications, alternate-security), a readiness dashboard and a signed readiness summary, and a corrective-action register — every gap converts into an owned corrective-action Issue (issue_type: deficiency, source: self_assessment) linked to the impaired Control, with any recovery-time-impacting gap escalated immediately rather than held for end-of-cycle closure. Downstream handoff: the archived readiness summary and dashboard serve as the readiness-state package the assure-line DR test workflow reads (no terminal handoff node exists yet — see the closure step).
workflow · Context
IT Operations & Capacity Management Cycle
Standing operator workflow for the weekly IT operations and capacity management cycle. It runs on the EXISTING **Process** item "IT Operations & Capacity Management" (process_type: operational, process_owner: IT operations manager, frequency: weekly): each weekly cycle is a new workflow instance attached to that Process — the Process is enriched, never recreated — with the operated **Control** items (job-scheduling, infrastructure-monitoring, and capacity controls; frequency: weekly) linked to it via a Control ↔ Process relationship. The instance executes and reconciles daily job scheduling, processing, infrastructure monitoring, and facility management against documented procedure, then assesses capacity and utilization against forecast demand, triggers capacity additions and priority-allocation safeguards ahead of threshold breach, and produces the named evidence set: the weekly operations review minutes, the consolidated exception log, and the capacity-and-utilization report (plus a recurring capacity-and-utilization dashboard). In scope: daily job scheduling, processing, infrastructure monitoring, and facility management for the operator's named in-scope systems and facilities, plus the weekly capacity and utilization review of infrastructure, data, and software against forecast demand. Out of scope: incident response, change management, and disaster-recovery testing, which run as their own workflows; this cycle raises corrective actions and capacity-addition requests (tracked as Issue items) that feed change management in substance but models no explicit handoff node — it is a terminal, self-originating operate-line cycle that does not itself execute infrastructure changes. No upstream workflow feeds it: its inputs are the operator's own job schedules, monitoring and facility feeds, the governing operating-procedure and capacity-threshold and quota **Policy** items, and the prior cycle's carryover **Issue** items (created when the signed weekly operations review closes the cycle) that arrive as tracked inputs — and the cycle seeds its own next-cycle carryover the same way.
workflow · Context
ISMS Risk Assessment & Treatment Cycle
Perform an ISO 27005 information security risk assessment and treatment cycle for a defined ISMS scope. The recurring cycle instance attaches to the existing Process item (process_type=security_process) that represents the ISMS scope — enrich that item, never create a duplicate; the risk register it produces is the set of Risk items the run creates and updates. The cycle: establish context and risk criteria, identify information security risks, analyze and evaluate them against the criteria, select treatment options, draft the risk treatment plan, obtain residual-risk acceptance, and retain the documented information. In scope: risk identification through treatment planning and residual-risk acceptance for the ISMS boundary. Out of scope: the Statement of Applicability control-applicability determination and control operating-effectiveness testing, which are handled downstream. This workflow has no upstream workflow — its boundary and inventory are initial inputs: the in-scope business processes are existing Process items, while the asset/information inventory and risk criteria are uploaded documents (no native Asset type). It produces the named deliverables — the current risk register (Risk items), the Risk Treatment Plan (RTP), and the SoA inputs — handed off to the ISO 27001 SoA Review & Controls Assessment workflow.
workflow · Context
Secure SDLC Phase-Gate Program
Operate the secure SDLC phase-gate program as a modular, decision-aware workflow where the accountable control owner chairs the intake, requirements, design, and build/release gates end to end. Each recurring operating cycle runs as a new workflow instance attached to the existing secure-SDLC phase-gate Control item (domains = secure_development_sdlc; framework = nist-800-53 / iso-27001 / cobit-2019 / nist-csf-2) — that Control already exists in the library, so the instance enriches it with this cycle's gate evidence rather than creating a duplicate control. In scope: chairing those four security-integrated lifecycle gates for every development initiative due this cycle, remediating held or blocked initiatives, and monitoring the process itself; it is self-initiating and consumes no upstream workflow package, and it seeds its own next cycle. Out of scope and distinct from it: the independent SDLC gate review's release-milestone verification, and the release-security-gate's technical testing practice.
workflow · Context
Onboarding & Access Provisioning
Runs on the existing personnel item. Provision a joiner access from an approved role profile, evidence each grant, and approve the provisioning record that ITGC access testing samples. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ISO 27001 SoA Review & Controls Assessment
Review the ISO 27001 Statement of Applicability and assess the controls behind it. Each run attaches to an Audit item created for the review cycle (audit_type = compliance, e.g. "ISO 27001 SoA Review 2026-H2"), which accumulates the scope, the per-control test instances, the assessment package, the approval, and the rating. The workflow locks the assessment workplan, reconciles every Annex A control's applicable/excluded decision and justification against the current risk treatment plan, verifies implementation evidence, assesses the sampled controls for design and operating effectiveness, routes deficiencies to owners, and approves and publishes the version-controlled Statement of Applicability (SoA) — then classifies the disposition and prepares, approves, hands off, and archives the review package. In scope: reconciling and assessing the SoA's Annex A control applicability decisions and their implementation for the ISMS in scope, and publishing the approved SoA version. It consumes the ISMS Risk Assessment & Treatment Cycle's handoff package (the current risk register, the risk treatment decisions, and the required-controls determination) and hands its named deliverable — the approved, version-controlled published SoA and the assessment package — off to the downstream ISO 27001 Certification Readiness workflow. Out of scope: the enterprise risk assessment and treatment decisions that determine which controls are required (owned upstream by the ISMS Risk Assessment & Treatment Cycle) and the certification audit preparation that follows (owned by the downstream ISO 27001 Certification Readiness workflow, which consumes this review's approved package). The trigger is the scheduled SoA review interval or a material change to scope, risk, or the control environment.
workflow · Context
Transfer & Access Modification
Runs on the existing personnel item. Modify a mover access for a new role, remove entitlements the prior role no longer justifies, and approve the modification record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Backup & Recovery Testing
Runs on the existing system item. Test recoverability for a system by performing an actual restoration and measuring the result against recovery objectives. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Privileged Access Review
Runs on the existing system item. Review privileged, service, and emergency accounts on a system for continued business justification, supporting activity, and compensating monitoring. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Security Control Assessment & POA&M Remediation
Run this assessment on the EXISTING Audit item for the engagement (audit_type: it_audit or compliance) — enrich that record, never create a duplicate: Audit.scope carries the authorization boundary and Audit.period_start/period_end the assessment window. Consumes, from the upstream SSP-development / system-categorization effort, the approved System Security Plan (SSP), the FIPS 199 system categorization, and the tailored NIST 800-53 baseline (existing Control items, framework: nist-800-53). Assess each in-scope control with 800-53A examine/interview/test methods, record satisfied / other-than-satisfied determinations, open a POA&M Issue for every gap, re-validate remediation, and issue the Security Assessment Report (SAR). In scope: control assessment, determinations, the POA&M lifecycle, and the SAR for the authorization boundary agreed at kickoff. Out of scope: the authorization (ATO) decision itself and the steady-state continuous-monitoring cadence. On completion, the frozen SAR and POA&M package are handed to the NIST RMF System Authorization (ATO) Cycle.
workflow · Context
Control Remediation Retest and Closure
Runs on the existing control item. Verify remediation readiness, independently retest the changed control, evaluate sustained results, and approve a supported closure decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ISO 27001 Stage 1 ISMS Documentation Review
Certification-body Stage 1 review of the ISMS against ISO/IEC 27001:2022 clauses 4–10: context and leadership, planning and support, operation, and performance evaluation with improvement - walking each clause group against the governing documents and the operating processes that carry it, and concluding Stage 2 readiness with dual sign-off. Stage 1 documentation and readiness review for ISO/IEC 27001:2022 clauses 4–10, conducted under the engagement methodology. It informs Stage 2 planning and does not issue a certification decision. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
ISO 27001 Stage 2 Annex A Controls Audit
Attach to the existing Audit engagement, owned by Internal Audit, using its approved Statement of Applicability, risk treatment plan, scope, review period and operating evidence; produce the Stage 2 Annex A Controls Audit report, four signed theme conclusions and finding register for the engagement and remediation owners. Apply the approved Statement of Applicability to ISO/IEC 27001:2022 Annex A.5.1–A.5.37, A.6.1–A.6.8, A.7.1–A.7.14 and A.8.1–A.8.34; document each exclusion and assess direct and inherited responsibilities. This Annex A assessment contributes to the engagement and does not independently establish full ISMS conformity or issue certification. Stage 1 and readiness remain separate workflows; any certification decision remains with the authorized certification body.
workflow · Context
SOC 2 Availability Assessment
Design-readiness review of the SOC 2 availability series: capacity management, environmental protections with backup and recovery infrastructure, and recovery plan testing (A1.1–A1.3). Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Confidentiality Assessment
Design-readiness review of the SOC 2 confidentiality series: identification and maintenance of confidential information and its secure disposal at end of life (C1.1–C1.2). Design-readiness assessment limited to the listed SOC 2 criteria. Evidence may include operating examples to assess the design; this module does not provide a SOC 2 Type II opinion. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
SOC 2 Type II Interim Testing
Interim fieldwork for the Type II examination: cycle walkthroughs, design assessment against the Trust Services Criteria, the first operating-effectiveness testing wave over the agreed interim evidence window, and exception triage feeding remediation and retest planning before the period closes. Interim SOC 2 Type II fieldwork for the listed control selections and agreed interim window. Later-period testing and the service auditor's independent opinion remain outside this module. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
Employee Onboarding
Run on an existing personnel item using signed engagement, screening references and an approved role profile. Produce an Onboarding Readiness Package with IT access evidence for HR, the manager and subsequent access reviews.
workflow · Context
GCP Physical and Environmental Subservice Reliance
Evaluate GCP assurance-report scope, physical and environmental controls, exceptions and user responsibilities; record a bounded reliance decision rather than claiming to operate provider facilities. This customer-side review relies on relevant independent reports, disclosed provider information and customer implementation evidence. It does not operate or certify GCP facility access or environmental safeguards. Preserve each report's permitted-use restrictions.
workflow · Context
System ITGC Operation
Operate and evidence the IT general controls on a system: authentication and password configuration, access provisioning and deprovisioning, the periodic user access review, change management (testing, sign-off, logs), and subservice SOC report reliance.
workflow · Context
Annual Policy Review
Runs on the existing policy item. Canonical annual policy review: establish scope, obtain the policy owner and policy team sign-offs, record any required change path, and approve a documented review outcome and next review date. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Policy Change
Runs on the existing policy item. Canonical policy-change governance: scope and propose a controlled change, obtain policy-team approval, publish only the approved version, and close with a traceable document and communication record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Risk Assessment and Treatment Review
Runs on the existing risk item. Assess a risk against current context and evidence, select a supported treatment response, and approve a traceable review record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOC 2 Reporting and Management Assertion
Reporting close for the Type II examination: drafting and validating the system description under the carve-out method, preparing the management assertion, reviewing complementary user entity controls and subservice reliance, and the dual-approval close of the examination file at the agreed period end. Management-owned SOC 2 Type II reporting support: system description, management assertion, CUECs, subservice reliance, and auditee file closure. The independent service auditor retains responsibility for examination conclusions and the CPA opinion. Attach this workflow to the existing SOC 2 evidence or reporting process item; retain evidence and conclusions on its workflow steps.
workflow · Context
System and Third-Party Risk Review
Runs on the existing system item. Review system and provider dependencies, assess current risk and control evidence, select response actions, and approve the review record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Vendor Risk Assessment and Disposition
Runs on one existing System with vendor=true. Uses the supplier record, contracts, assurance/CUECs, access and continuity evidence to produce a reviewed vendor risk assessment and authorized disposition for the business/risk owner and readiness evidence consumers. Two checkpoints retain expert challenge and the owner’s choice of conditions, treatment and monitoring; executor work is recorded in step results and documents, with no collection forms or runtime branches.
workflow · Context
Quarterly Board & Audit-Committee GRC Reporting
Runs on the existing standing "Board & Audit-Committee GRC Reporting" governance Process item (process_type=business_process, frequency=quarterly): one workflow instance per quarter attaches to that Process and enriches it (the Process is not created here), and each closed instance is the prior-quarter baseline for the next run. The named deliverable is the quarterly board & audit-committee GRC pack (six-domain narrative deck, Word + PDF, redaction-cleared). It compiles that pack across six domains — risk profile, control health, open issues, regulatory deadlines, audit-plan progress, and SOX posture — computed over one quarter window. In scope: aggregating and synthesizing existing GRC records (Risk, Control, Issue, Audit, and Control-hosted SOX testing workflows) into a board-level narrative, obtaining executive and committee approval, and archiving the decision and action register. Out of scope: performing the underlying risk assessments, audits, or control tests themselves. Consumes two upstream handoff packages: the Enterprise Risk Assessment & Portfolio Oversight Cycle package (risk register, residual scores, appetite positions) and the Audit Report Drafting & Regulatory Compliance Attestation Cycle package (audit-plan status, issued reports, attestation status); there is no downstream workflow — the closed package feeds the next quarterly run of this workflow.
workflow · Context
Risk Appetite Definition & Board Reporting
Define enterprise risk appetite statements, tolerances, and KRIs, secure executive and board approval, monitor actuals against tolerances, and report the appetite position to the board. Runs as a standalone recurring instance per appetite cycle (typically annual): appetite spans the whole Risk register rather than a single item, so the register, tolerance and KRI matrix, monitoring workbook, and reporting pack attach to the workflow instance's steps as the versioned documents of record, with the existing Risk items as the linked reference data and KRI breaches recorded as Issue items (issue_type: exception, linked to their Risk). In scope: appetite-statement definition, tolerance and KRI design, executive validation, board approval, ongoing monitoring, and ERM board reporting. Out of scope: the enterprise-wide risk identification and scoring that produces the risk universe, and the assembly of the full quarterly board deck. Consumes the risk-assessment handoff package from the Enterprise Risk Assessment & Portfolio Oversight Cycle (the risk universe as Risk items plus inherent and residual ratings) rather than re-deriving it, and hands the board-approved appetite package to the Quarterly Board & Audit-Committee GRC Reporting workflow.
workflow · Context
Risk Register Intake
Intake one newly identified risk into the enterprise register. The instance creates a new Risk item at the first step and attaches to that Risk item for the whole run — every rating, control link, and disposition enriches that single record. It consumes the initial risk identification (no upstream workflow) plus existing Control items, Policy items, and evidence carried on Issue, Audit, and Control-hosted SOX testing workflows, and produces the named deliverable: a review-ready risk intake package attached to the Risk item. On completion it hands that package to the Enterprise Risk Register Lifecycle workflow for ongoing monitoring. In scope: intake and initial assessment of one new risk. Out of scope: portfolio-level aggregation, periodic re-assessment, and risk-treatment project execution, which the Enterprise Risk Register Lifecycle workflow owns.
workflow · Context
Third-Party Vendor Risk Lifecycle
Operate the third-party vendor risk lifecycle end to end: scope and tier the vendor population, gather and analyze assurance evidence (SOC reports and CUECs, plus C-SCRM controls), embed contractual protections, enroll ongoing monitoring, and reach a governed disposition and approval. The vendor register IS the set of Vendor items — tiered by criticality (tier) and data exposure (data_classification), owned (business_owner, risk_owner), and driven by reassessment_cadence with last/next assessment dates and monitoring_status; each assessment cycle runs as one workflow instance over that register. In scope: vendor and supplier third-party risk assessment, onboarding controls, and periodic reassessment. Out of scope: procurement sourcing and commercial negotiation, and the deeper fieldwork of a Third-Party Vendor Assurance Engagement, to which the approved package is handed off. This workflow is self-initiating and consumes no upstream workflow package.
workflow · Context
Policy Exception & Risk Acceptance
Policy Exception & Risk Acceptance as a decision-aware workflow. It carries a waiver from request and justification through risk assessment, compensating controls, time-bound approval, registration with expiry, and re-review so no exception outlives its rationale. The exception IS an Issue item (issue_type: policy_exception) — the workflow runs on it, and the exception register is simply the set of those Issues, queryable by their filterable exception_expiry_date. The affected policy is a Policy item the Issue links to; a granted acceptance also sets treatment: accept on the linked Risk item. In scope: time-bound exceptions/waivers to an existing policy that are risk-accepted for a bounded window. Out of scope: permanent policy-change proposals, which route to the Policy Lifecycle Management workflow (the Policy item's revision process) rather than this waiver workflow. No upstream or downstream workflow feeds or consumes this one; the exception request is the initial input, and recurring-exception patterns are compiled as feedback onto the affected Policy items at close.
workflow · Context
IT Governance Objective Review (COBIT)
Periodic review of selected COBIT 2019 governance and management objectives, run per cycle on an Audit item (audit_type: it_audit; scope = the in-scope objectives; period_start/period_end = the assessment cycle) that the workflow instance attaches to and archives at close. Each in-scope COBIT objective is a Process item (process_type: it_general_control) linked to that Audit, and the review produces named deliverables against it: an evidence register and pre-scored capability sheet, a signed capability profile, a gap table with the benchmark decision, a committed improvement roadmap of Issue initiatives, and the governance board report and dashboard. In scope: the COBIT 2019 objectives selected for this cycle, each with a justified 0-5 target capability level, a named accountable owner, and the review cadence; out of scope: objectives explicitly excluded with recorded rationale. Self-originating: its scope sheet and target profile are supplied as workflow inputs, and it hands off to no distinct downstream workflow — the carry-forward improvement Issues and the archived instance seed its own next cycle.
workflow · Context
Risk & Resilience Framework Governance
Risk & Resilience Framework Governance as a decision-aware workflow. The instance runs on the "Enterprise Risk Management Framework" Process item (process_type: business_process, process_owner = the framework owner, frequency: annual) - created on the first cycle at "Design core ERM framework" and enriched every cycle thereafter, never duplicated; that Process item is the governance register entry, and each governance cycle runs as a workflow instance attached to it, so the at-least-annual cadence is provable from one item's instance history. Working from the organization's context and the ISO 31000 / COSO ERM / DORA reference models - no upstream workflow package feeds it, because this workflow establishes the governance layer - it establishes or refreshes the enterprise risk management framework, extends it for ICT operational resilience and regulated technologies, secures management-body approval and budget, drives implementation across the organization, and runs the at-least-annual review, filling the governance layer the risk-cycle workflows run inside but never establish. The named deliverable is the approved risk & resilience framework package (core ERM design + ICT operational-resilience (DORA) extension + any regulated-technology lifecycle extension), archived at close as durable governance evidence. In scope: the enterprise risk framework, its always-in-scope ICT operational-resilience (DORA) extension, and any regulated-technology (e.g. high-risk AI) extensions to be evaluated. Out of scope: executing the individual risk-cycle workflows (identify / assess / treat / monitor) that run inside this framework - this workflow governs them but does not perform them, and consumes no upstream workflow package. Downstream, the archived framework enables those risk-cycle workflows, which reference it as their governing baseline (the relationship is real but not modeled as a node).
workflow · Context
Board Risk & Internal Control Oversight Cycle
Board Risk & Internal Control Oversight Cycle as a decision-aware workflow: the governance office verifies board independence and expertise, compiles the board risk & internal-control oversight pack, routes the at-least-annual governance-framework effectiveness evaluation, facilitates the independent board's approval of the risk strategy and material policies, captures and minutes the directed adjustments, and launches and tracks them as an owned open directives register. It is standalone: the governing body and the governance framework are not Studio item types, so there is no natural item anchor — each cycle runs as a fresh recurring workflow instance and its deliverables attach to the run's own steps. The named deliverables are the composition-and-independence summary, the board risk & internal-control oversight pack, the annual governance-and-management-framework effectiveness evaluation when in scope, the adopted board/committee minutes, and the board directives-and-adjustments register (one Issue item per directive, linked across cycles). The risk strategy and material policies the board approves are Policy items (approved_by, version, next_review_date); board directives, approval conditions, and framework adjustments are Issue items (issue_type: observation, source: management_identified). In scope: a single named governing body's quarterly (or specially convened) risk and internal-control oversight meeting and, where the annual clock or a substantial-change trigger applies, that cycle's enterprise governance and management framework effectiveness evaluation. Out of scope: the day-to-day first- and second-line control operation, testing, and assurance that feed the pack — no workflow hands into this cycle, and the board's directives flow onward into control-remediation and policy-update execution as prose, not a wired downstream template.
workflow · Context
Code of Conduct & Workforce Accountability Cycle
Code of Conduct & Workforce Accountability Cycle as a decision-aware workflow that runs on an existing ethics Process item ("Ethics & Code of Conduct Program", process_type: business_process, frequency: annual): each annual cycle is a workflow instance attached to that Process, and the archived instances on it ARE the ethics register - version history plus the open-deviation log. The code of conduct and the rules of behavior are Policy items (policy_type: policy and procedure) enriched each cycle - never recreated - and the tone-at-the-top and acknowledgment Controls (UC-GOV-04, UC-GOV-07) are linked to the Process via item relationships. The cycle reissues the code and rules of behavior, secures leadership adoption, communicates expectations to personnel and business partners, gates access on acknowledgment, and evaluates adherence - routing violations through the documented disciplinary process and remediating deviations timely, with deviations and violations recorded as Issue items carrying the full remediation lifecycle. Named deliverables: the reissued code of conduct and rules of behavior (Policy items plus redline/change summary), the leadership adoption decision, the acknowledgment coverage report with access-gating evidence, the deviation and violation inventory (Issues), the disciplinary and remediation outcomes, and the archived self-contained cycle evidence package. In scope: one annual accountability cycle (a full reissue or an update-driven re-acknowledgment) covering all in-scope personnel and the business-partner populations bound by the code. Out of scope: the ethics-hotline intake that feeds reported concerns - an input, not a step here. No upstream workflow is required to start the cycle; it is triggered by its annual cadence or by a material change to the code or rules of behavior. Downstream, the operational access-provisioning system consumes this cycle's acknowledgment gate - the workflow's terminal handoff - before it grants access.
workflow · Context
Technology Investment & Project Risk Governance
Technology Investment & Project Risk Governance as a decision-aware checkpoint graph, run as a recurring workflow instance attached to the existing Process item for the technology-investment / portfolio-governance process (process_type: business_process) — each quarterly board cycle enriches that standing process record rather than creating a new one. In the cycle the investment board refreshes its criteria, scores and prioritizes the technology and innovation portfolio, routes the annual capital-planning leg that allocates security funding to the risk strategy, monitors in-flight value and reprioritizes or terminates where value is not realized, and enforces security-risk sections in every project gate with ERM-linked artifacts. In scope: the quarterly technology investment-board review (always), the annual capital-planning and security-budget leg (when the funding and staffing envelope must be set or re-planned this cycle), and every project stage gate falling due. Out of scope: individual project execution and delivery mechanics and day-to-day security operations. The cycle consumes the ERM cyber-risk register (Risk items, category: cyber_security) and the approved program business cases as standing inputs, and produces a board decision record and evidence pack as its named deliverable. There is no downstream workflow hand-off, so cross-references are recorded as linked records (Issue ↔ Risk) rather than routed onward; the scored portfolio, in-flight programs, and stage-gated projects have no native item type and live as step documents.
workflow · Context
Strategic Context & Objectives Alignment Cycle
Strategic Context & Objectives Alignment Cycle as a decision-aware workflow. Anchor: this recurring governance cycle runs on and enriches the existing "Strategic Planning & Objectives Alignment" Process item (process_type business_process, annual frequency) that represents the strategy-refresh process itself; where no such convention item is seeded it runs standalone with every output attached to the workflow instance. No upstream workflow feeds this cycle — it is the top of the governance chain and its own trigger, run annually or on an event-driven change such as an acquisition, a new market or regulation, a material risk-profile shift, or a significant incident; its only prior-cycle input is this workflow's own previous run, archived at close-and-archive. It refreshes the mission statement and stakeholder register, builds a bidirectional objectives-and-dependency map, communicates that context to risk-scoping owners, realigns and cascades strategy into a published and monitored roadmap, and closes by documenting mission-essential business processes as Process items with their information-protection needs as the approved basis for risk-assessment scoping. Named deliverables: the refreshed mission statement (DOCX) and stakeholder register (XLSX), the objectives-and-dependency map, the published context package and change summary, the strategy realign-or-reaffirm decision, the realigned enterprise and technology strategy (realign branch), the cascaded objectives and published roadmap, the mission-essential Process definitions, and the archived cycle record. In scope: the mission and stakeholder context refresh, strategy realignment and objective cascade, and the mission-essential process and risk-scoping definitions. Out of scope: executing the risk assessment itself. Downstream handoff: the exported cycle record and the approved mission-essential Process items are the scoping basis consumed by the Enterprise risk-assessment cycle.
workflow · Context
Enterprise Risk Treatment Operations Cycle
Enterprise Risk Treatment Operations Cycle as a decision-aware workflow: it runs the documented risk methodology each cycle - identification and analysis of risks and opportunities, evaluation and prioritization against risk criteria, treatment selection and tracking for risks exceeding tolerance with residual re-evaluation, and risk-register and portfolio reporting to management and the board - triggering dynamic reassessment when internal or external change shifts the risk profile. This cycle has no anchor item of its own: the enterprise risk register it maintains IS the Risk item population, and the workflow instance is the cycle record and durable audit trail. In scope: entity-level and process-level risk across the enterprise, explicitly including cybersecurity, privacy, and financial-reporting risk alongside operational and strategic risk and opportunity. Out of scope: detailed control design and testing, which downstream control workflows own - a mitigate or share/transfer plan that creates or strengthens a control hands that work off to those workflows, which anchor on the affected Control items. This cycle has no upstream workflow feeding it; its starting inputs are the documented methodology, the consistent likelihood/impact scoring scales, the board-approved risk criteria and appetite/tolerance statements, and the risk-acceptance delegation matrix - all carried as Policy items - plus the existing control, insurance and transfer information (Control items and step documents) and the prior cycle's Risk register. Named deliverables: the maintained enterprise risk register (the Risk items), the prioritized risk heat-map dashboard, and the management and board portfolio report package.
workflow · Context
Risk Communication, Reporting & Performance Review
Risk Communication, Reporting & Performance Review as a decision-aware workflow that runs each quarter or on an out-of-cycle significant matter. Because none of the eight Studio item types represents the ERM reporting cycle itself, the workflow instance IS the durable record: its named deliverables - the tiered internal and external risk, control and performance reporting package, the event-driven report on a significant matter, the management-signed risk-and-control performance-review pack, and the tracked improvement actions - attach to its steps, its item-level writes land on the existing Risk, Control, and Issue items (improvement actions are tracked as Issues with source: self_assessment); control-testing results are read from SOX testing workflows hosted directly on the relevant Controls; and the risk-management framework is read as its Policy item (policy_type: charter) for the evaluation baseline and the suppliers and third parties consulted as their Vendor items. In scope: stakeholder consultation across every risk-process step (identification, assessment, response, monitoring) including suppliers and third parties; the cadenced internal and external reporting package; event-driven reporting on significant matters; the periodic review of risk-management and internal-control performance against the framework's design intent with accountable management; and converting lessons into owned, tracked improvement actions. Out of scope: running the underlying risk assessments, control testing, or business-performance measurement themselves - this workflow consumes their results as inputs. It starts on its own trigger (the quarterly cadence or a significant event) and has no upstream feeder workflow and no named downstream handoff workflow; each run's close-and-archive leaves the stakeholder, risk, and improvement registers current - the informal handoff both to the next cycle of this workflow and to the downstream risk-assessment and control-testing workflows whose results this cycle consumes.
workflow · Context
Supplier Service Registry & Critical Supplier Assessment
Supplier Service Registry & Critical Supplier Assessment as a modular, decision-aware workflow. Each cycle runs on an Audit item created for the cycle (audit_type = vendor_review) — a vendor-review engagement the workflow instance attaches to — while the supplier service register itself lives as Vendor items that are enriched as services onboard, change, or exit, never recreated each cycle. It reconciles the register against the organization's own supplier, procurement, and billing records, maps the systems and data each service touches and its internal relationship owner, classifies critical suppliers, and runs a security and risk assessment before acquisition or engagement, triggering reassessment when services, dependencies, or risk profiles change. Named deliverables: the reconciled supplier service register (the Vendor items), the supplier criticality classifications, the critical-supplier security and risk assessment memo with risk rating (its material third-party exposure recorded as third_party Risk items and its control gaps as finding Issues), the engagement decision, and the scheduled reassessments. In scope: maintaining the supplier service register and performing pre-acquisition and pre-engagement security and risk assessments of critical suppliers. Out of scope: ongoing SLA and contract-performance management, procurement sourcing and negotiation, and enterprise-level risk aggregation. Self-originating — no upstream workflow feeds this cycle; it is opened by a scheduled register review, a new supplier acquisition or engagement, a service onboarding/change/exit event, or a reassessment trigger. It hands off to no named downstream workflow (contract and SLA management being out of scope); an engage decision's conditions are carried forward as finding Issues and in the decision rationale so they remain actionable.
workflow · Context
Vendor Due Diligence & Contracting Gate
Vendor Due Diligence & Contracting Gate as a modular, decision-aware workflow. Anchor: the vendor's register entry — the Vendor item (slug: vendor). For a net-new engagement the gate creates the Vendor item and populates its tier, data_classification, business_owner, and risk_owner; for a renewal it enriches the existing Vendor item rather than duplicating it (enrich, never recreate). This is the first-line pre-contract gate the vendor-management office runs for every new engagement or renewal - tiering criticality, running proportionate due diligence into the vendor due-diligence report, documenting the risk-acceptance decision and any risk-reducing sourcing conditions, binding the contract to required security, privacy, and regulatory clauses, authorizing the specific information exchange before access begins, and - where personal data is involved - obtaining the signed written privacy commitments and scheduling compliance monitoring and incident-response routing. In scope: pre-contract due diligence, risk acceptance, and contract execution for one vendor engagement, ending with the Vendor item enrolled in monitoring (Vendor.monitoring_status = enrolled). There is no upstream workflow — the engagement trigger (a new prospective vendor or a renewal) is its own entry point. Downstream handoff: the archived gate record exported at close is the handoff package the ongoing third-party risk monitoring / vendor oversight lifecycle picks up to sustain the scheduled compliance checks and incident routing; that linkage is a prose handoff of live controls on the same Vendor item, not a triggered downstream node.
workflow · Context
Third-Party Risk Program & Vendor Oversight Cycle
A standing quarterly cycle the vendor-management office runs as control owner. The workflow instance is a recurring run attached to the EXISTING Process item "Third-Party / Vendor Risk Management" (process_type: operational, process_owner: Vendor Risk Program Lead, frequency: quarterly), linked to the Control items for the unified controls it operates (UC-TPRM-01/04/05/08) — it enriches that standing program, never recreating it. It consumes no upstream workflow handoff: each run is self-feeding, drawing its criteria and prior state from the program's own standing artifacts — the SCRM plan, third-party risk policy, and program strategy held as Policy items; the criticality-tiered Vendor register (Vendor items); and the prior cycle instance's step documents (the DORA Article 28(3) register of information and the ICT concentration-risk view). In scope: reaffirming or revising the governing Policy items; re-tiering the Vendor register; refreshing the DORA Article 28(3) register of information and the concentration-risk view (a dashboard over the Vendor items); verifying critical-provider exit strategies; executing this cycle's tier-based reassessments and driving findings to tracked third-party Risk items (remediation or risk-committee escalation); confirming external and cloud service provider oversight; and verifying critical suppliers carry live incident-notification coverage. Named deliverables: the refreshed criticality-tiered Vendor register, the updated DORA Article 28(3) register of information, the recomputed ICT concentration-risk view, the exit-readiness summary, this cycle's tracked Risk items, and the archived cycle evidence package on the workflow instance. Terminal at close-and-archive with no downstream handoff — open or escalated vendor risks persist as Risk items in the risk register. Out of scope and handled by separate workflows: the continuous monitor-line vendor lifecycle and the per-engagement due-diligence gate for onboarding a new vendor.
workflow · Context
Enterprise Risk Assessment & Portfolio Oversight Cycle
Second-line ERM oversight cycle. Each run is anchored to a cycle Audit item created for the period (audit_type: operational, scope = the assessment boundary, period_start/period_end = the cycle window, report_date = the approval date); the workflow instance attaches to it as the durable audit trail, and the enterprise Risk items are the register it assesses and updates in place. Establish the assessment context (scope, criteria, appetite, scoring calibration), identify risks, score inherent and residual severity, select responses, publish the portfolio view, and route the package through disposition and governance approval. In scope: enterprise-level risk identification, assessment, response selection, and portfolio reporting for the current cycle. Out of scope: defining the board-approved risk appetite statement itself and preparing the board reporting deck, which are handled by downstream workflows. Consumes the prior-cycle risk-register handoff package (the existing Risk items plus the linked register document) from the Enterprise Risk Register Lifecycle workflow, and hands its named deliverables — the residual portfolio view (dashboard), the risk-movement narrative, and the approved assessment package — to the Risk Appetite Definition & Board Reporting and Quarterly Board & Audit-Committee GRC Reporting workflows.
workflow · Context
Vendor Offboarding & Secure Termination
Vendor Offboarding & Secure Termination as a decision-aware workflow triggered on a relationship termination. It runs on the vendor's existing Vendor register item - the offboarding enriches that record, it never creates a duplicate: the run marks the Vendor `monitoring_status: exited` and stamps `contract_end_date`, and where the vendor's risk is registered it links to the existing third-party Risk item (`category: third_party`). In scope: executing one vendor's contractual exit end to end - inventorying the vendor's access, data, and dedicated components; containing access immediately on for-cause exits; transitioning each service to its successor; revoking every credential; verifying data return or destruction; disposing of internal-side components using defined techniques; and retaining the post-relationship evidence. Out of scope: the underlying contract-termination or renewal business decision and any separately-governed affiliate contracts. Initial inputs are the termination trigger and effective date, the vendor's contractual exit provisions (master agreement, data processing addendum, exit plan) - which also carry the data-disposition and evidence-retention clauses consumed downstream - and the existing Vendor register item with its risk tier; there is no upstream workflow. The named deliverable is the retained, audit-standing termination evidence package assembled at compile-termination-evidence-and-retain; the workflow is terminal - close-and-archive exports the run and hands off nothing downstream.
workflow · Context
Risk & Control Self-Assessment (RCSA) Program
Risk & Control Self-Assessment (RCSA) Program as a modular, decision-aware workflow. Each wave runs on its own Audit item — created per wave (audit_type: operational; period_start/period_end = the wave window; report_date = the risk-committee date) — with the workflow instance attached to that item and the wave's questionnaires, attested returns, and calibration record kept inside the run. Each wave rebuilds the assessment universe from the existing Process, Risk, and Control items and their owners (enriching them, never recreating them), issues rating questionnaires to named control and process owners, collects attested self-assessments with structured exception capture, chases completeness, subjects the results to second-line challenge and calibration, aggregates a residual-risk view across units, updates the risk register's residual ratings, and routes self-identified issues to remediation and exceptions to time-bound acceptance before the results reach the risk committee. In scope: first-line self-assessment of in-scope business units and shared functions against their own risks and controls. Out of scope: independent testing/audit of those controls, and the remediation and formal risk-acceptance of what the wave surfaces, which are handed off downstream to the Finding Remediation & Action-Plan Monitoring (deficiencies), Policy Exception & Risk Acceptance (risk-acceptances/waivers), and Quarterly Board & Audit-Committee GRC Reporting (the wave report) workflows.
workflow · Context
Regulatory Exam & External Audit Management
Manage a live regulator examination or external audit end to end — from notification intake through request fulfillment, QC’d evidence release, fieldwork support, preliminary-findings response, and commitment closure. Runs on an Audit engagement item created per exam (audit_type = regulatory_exam, or external_attestation for an external audit); the workflow instance attaches to that Audit anchor, and preliminary findings and their corrective-action commitments become linked Issue items. No upstream workflow feeds this — it is triggered by the exam or audit notification itself. In scope: coordinating examiner requests, controlled evidence release, and management responses for a single exam or audit engagement. Out of scope: remediating the underlying control gaps — the findings and committed corrective actions hand off to Finding Remediation & Action-Plan Monitoring — and standing up new obligations surfaced by the exam, which hand off to Regulatory Horizon Scanning & Triage and Regulatory Obligation Implementation.
workflow · Context
Emerging Risk & Horizon Scan
Runs on the existing risk item. Scan the forward horizon for signals of an emerging exposure, assess plausibility and velocity, and decide whether it enters the register or stays on the watchlist. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Risk Appetite & Tolerance Calibration
Runs on the existing risk item. Set or recalibrate the appetite statement and tolerance thresholds for a risk, test the current position against them, and approve the escalation record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ERM Risk Identification & Register Refresh
Runs on the existing risk item. Run a periodic enterprise risk identification cycle, consolidate candidate risks, and approve the resulting register changes. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Enterprise Risk Register Lifecycle
Enterprise Risk Register Lifecycle as a decision-aware workflow. This is a standalone recurring instance (quarterly or annual) that runs against the existing Risk item population — the enterprise risk register itself — enriching those Risk items in place rather than recreating a register: per-risk results are written onto the individual Risk items, and cycle-level deliverables attach to the workflow instance's steps. In scope: maintaining the register across the confirmed entities, business units, and risk-taxonomy categories for this cycle — intake and deduplication of new risks, Three-Lines ownership, control and assurance mapping, KRIs, periodic review and escalation, and retirement. Out of scope: any entity, unit, or category not named in this cycle's confirmed scope. It consumes the candidate-risk handoff package from the upstream Risk Register Intake workflow and hands its maintained register, residual positions, and escalations to two downstream workflows — Enterprise Risk Assessment & Portfolio Oversight Cycle (the maintained register, the concentration and correlation flags, and the residual positions) and Risk Appetite Definition & Board Reporting (the above-appetite entries, the escalations, and the acceptances) — rather than duplicating repeated work.
workflow · Context
ESG-Related Risk Materiality & Integration
ESG-Related Risk Materiality & Integration as a decision-aware workflow. Each cycle runs on the existing portfolio-level ESG Risk item (a Risk with category: esg — e.g. "ESG / sustainability risk — enterprise"): it enriches that umbrella entry and the ESG-tagged slice of the Risk register (Risk items tagged category: esg / taxonomies: esg_sustainability) rather than recreating them, and fans per-topic detail out onto the individual Risk items it creates or updates for each impact, risk, and opportunity (IRO). In scope: assessing ESG-related risks across the confirmed environmental, social, and governance topics, entities, and value-chain boundary for this cycle — defining the ESG risk universe (impacts, risks, opportunities), engaging affected stakeholders and information users, assessing double materiality and prioritizing the material topics, mapping controls and management responses, defining KRIs and disclosure metrics, and assembling disclosure inputs. Its named deliverables are the double-materiality assessment (the ranked material topic set with a materiality matrix), the control/response and assurance mapping, the disclosure metrics and leading KRIs, and the framework-mapped disclosure index (ESRS/CSRD, ISSB S1/S2, GRI, SEC climate). Out of scope: any ESG topic, entity, or business unit not named in this cycle's confirmed scope, and the drafting of the external sustainability report itself. It consumes the enterprise risk portfolio and residual positions from the upstream Enterprise Risk Assessment & Portfolio Oversight Cycle and hands its material ESG topics, KRIs, and disclosure inputs to the downstream Quarterly Board & Audit-Committee GRC Reporting workflow rather than duplicating repeated work.
workflow · Context
Incident Management Lifecycle
Run the enterprise incident management lifecycle on a single governed incident record — an Issue item created at intake that every step enriches (there is no separate Incident type; the workflow instance anchors to that Issue). Open the record, analyze scope and impact, anchor the regulatory and remediation notification clocks to the detection date, contain/eradicate/recover, execute severity-based notifications, run lessons-learned and CAPA, classify the disposition, then prepare, hand off, and archive the governance package. Named deliverables: the scope-and-impact assessment, the root-cause analysis, the owned CAPA / remediation action plan, and the final evidence-and-decision governance package. In scope: operational and security incidents from detection through closure, including regulatory-notification clock management and corrective/preventive actions. Upstream: the incident originates on detection itself, but for a security-category incident this workflow consumes the containment-and-forensics handoff package produced by the Cybersecurity Incident Response workflow (linked in at the eradicate-and-recover step) rather than re-running SOC triage. Out of scope: real-time SOC triage and containment mechanics (owned by that Cybersecurity Incident Response workflow) and board-level reporting — the final governance package is handed off to the Quarterly Board & Audit-Committee GRC Reporting workflow, which reports the outcome without re-investigating.
workflow · Context
Policy Lifecycle Management
Run one policy through its full lifecycle, anchored to a Policy item in the policy library — created at authoring for a net-new policy, enriched in place on each refresh cycle (never duplicated). In scope: authoring and control/authority linkage, stakeholder review, formal approval, publication and workforce attestation, acknowledgement tracking, disposition, and scheduled alignment refresh. Consumes read-only upstream: the enterprise risk assessment (Risk items), control design (Control items), and obligation mapping — this workflow neither produces nor edits them. Produces four named deliverables: the published policy version, a frozen workforce attestation completion record, a section-by-section alignment verdict, and a single approval-ready policy package. Out of scope: enterprise risk assessment, control design, and obligation mapping. The approved policy package is handed off to the Regulatory Compliance Attestation Cycle, which runs the recurring regulatory attestation; the acknowledgement campaign launched here is the one-time publication attestation and is explicitly flagged in the handoff as not-to-be-repeated downstream.
workflow · Context
Privacy Breach Assessment & Notification
Personal-data breach response, anchored on a breach-register Issue item created for the breach (issue_type: exception, source: management_identified, identified_date = the awareness timestamp); the workflow instance attaches to that Issue and the breach register is the queryable set of these Issues. Consumes the Incident Management Lifecycle workflow's handoff package (incident record, containment status, investigation timeline) and drives it from handoff to closure: a frozen, dated exposure inventory; a per-jurisdiction notifiability determination against GDPR Article 33, US state (California/CCPA included), and HIPAA clocks; regulator and data-subject notifications with milestone tracking; processor coordination against the processor's Vendor record and DPA; remediation and support Issue items; the Article 33(5) breach-register entry; and a post-breach review that hands off to the DPIA / Privacy Impact Assessment workflow for each affected processing activity. In scope: the notifiability judgment and notification execution downstream of the incident handoff; out of scope: incident containment and forensics, which stay with incident response.
workflow · Context
Requirement Applicability & Control Mapping
Runs on the existing requirement item. Interpret a requirement, determine supported applicability, map obligations to controls and evidence, and approve the mapping record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Regulatory Change Intake & Impact Assessment
Runs on the existing requirement item. Validate a new or amended external obligation against its authoritative source, determine applicability, and assess the impact on controls, policies, processes and systems. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Obligation Implementation & Adoption
Runs on the existing requirement item. Deliver the control, policy and process changes an obligation requires, validate readiness evidence, and approve the adoption record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
EU AI Act Obligation Impact Analysis
EU AI Act Obligation Impact Analysis runs on a compliance Audit item created at intake (`audit_type: compliance`, `scope` = the fixed entities/AI-systems/markets boundary) — the "impact-analysis item" the whole run enriches and closes. It parses in-scope EU AI Act provisions, classifies affected AI use cases by operator role and risk tier, crosswalks obligations to existing Control items, rates conformity gaps as Issue items, and routes high-risk gaps to the AIMS (ISO/IEC 42001 AI management system). Consumes the horizon-scanning handoff package from Regulatory Horizon Scanning & Triage. Named deliverables: the locked workplan, the obligation register (the durable run-to-run workbook), the per-use-case classification set, the obligation-to-control crosswalk, the ranked conformity-exposure list, and the version-pinned final analysis package. Hands its approved gap-and-action package to Regulatory Obligation Implementation. In scope: obligation parsing, use-case classification, control crosswalk, and gap rating for the entities, AI systems, and markets fixed at intake. Out of scope: implementing remediations, performing conformity assessments, and running fundamental-rights impact assessments (FRIAs) — FRIAs route to the AI Governance & Risk/Impact Assessment module.
workflow · Context
Compliance Monitoring & Attestation
Runs on the existing requirement item. Refresh evidence for an obligation on its review cycle, test continued conformance, and record the owner attestation with any exceptions. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Regulatory Horizon Scanning & Triage
Regulatory Horizon Scanning & Triage as a modular, decision-aware workflow. Each cycle runs on an Audit item created for the scan window — `audit_type` = compliance, titled "Regulatory Horizon Scanning — <period>", with `period_start`/`period_end` set to the detection window; the workflow instance attaches to that Audit and is archived against it at close. It can stand alone, but is designed to exchange handoff packages with related workflows instead of duplicating repeated work. In scope: detecting and summarizing regulator publications, routing them to the authority-source register, applicability screening against the compliance profile, entity profile, and activity inventory, owner assignment, and queueing. Out of scope: obligation mapping, gap and impact analysis, and implementation — those belong to the downstream Regulatory Impact Analysis & Obligation Mapping workflow, which consumes this workflow's named deliverables: the prioritized impact-analysis intake queue and the cycle evidence package. There is no upstream workflow and no prior handoff to consume; this is the sensing edge of the regulatory-change chain, and its standing inputs are the monitored feed list, the prior cycle's cursor, the authority-source register, and the Policy items that cite those authorities.
workflow · Context
Regulatory Impact Analysis & Obligation Mapping
Regulatory Impact Analysis & Obligation Mapping runs on a compliance Audit engagement record — an Audit item created per triggering instrument (audit_type=compliance) whose scope holds the locked scope statement and to which every gap Issue, risk acceptance, and the workflow instance attach. It consumes two upstream inputs: the triage handoff package from Regulatory Horizon Scanning & Triage (instrument, canonical citation, publication and effective dates, triage disposition) and the canonical instrument text itself — the Official Journal or regulator-register version, the authoritative source the whole analysis cites. It parses that instrument into obligations, maps them to the existing Policy and Control library, classifies and rates gaps, and reconciles the obligation register. Named deliverables: the cited regulatory impact note, the obligation inventory, the authority-to-policy crosswalk, the classified and rated gap Issues, the versioned obligation register, and the final evidence and decision package. In scope: obligation analysis, crosswalk, gap classification, exposure rating, and register reconciliation for the in-scope entities, products, and jurisdictions. Out of scope: remediation build-out (handed off to Regulatory Obligation Implementation) and re-prioritizing the instrument (owned by Regulatory Horizon Scanning & Triage). Confirmed gaps and their action plans hand off to Regulatory Obligation Implementation.
workflow · Context
Regulatory Obligation Implementation
Implement a new or changed regulatory obligation end to end on the Audit item created for this implementation (audit_type = compliance or readiness): its scope names the obligation and authority, its period_end holds the effective (compliance-by) date, and the workflow instance attaches to it. There is no native Regulation type, so the regulator, region, and obligation summary live in the anchor Audit.description with the operative source text uploaded to the gap-analysis step. The work — gap analysis, policy updates (Policy items), control design (Control items), process operationalization (a Process item), and coverage validation — enriches that Audit rather than creating a parallel record. In scope are the legal entities, products, systems, and vendor relationships (Vendor items) the obligation touches; entities and processing below the regulation's applicability thresholds are out of scope. This workflow consumes the obligation map handed off from Regulatory Impact Analysis & Obligation Mapping and hands its named deliverable — a validated coverage package (the gap list, the drafted policies and controls, the operationalized process, and the validation run) — to the Regulatory Compliance Attestation Cycle.
workflow · Context
Third-Party ICT Vendor Regulatory Assurance
Third-Party ICT Vendor Regulatory Assurance as a decision-aware workflow. Each cycle runs on its own Audit engagement item (audit_type = vendor_review) created at kickoff, with Audit.scope set to the in-scope legal entities, regimes, and vendor population; every workpaper, decision form, and gap attaches to that instance. In scope: ICT third-party service providers — including intra-group ICT providers — assessed against DORA, NIS2, and US interagency/FFIEC third-party expectations; out of scope: non-ICT vendors, which stay with the general vendor lifecycle. It consumes the arrangement-level inventory, tiering, and due-diligence handoff package from Third-Party Vendor Risk Lifecycle (whose provider records are the Vendor items); refers vendor SOC 1/SOC 2 reports carrying real reliance to the Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow and folds back its reliance conclusions; and produces a provision-cited, severity-rated gap register (Issue items linked to the anchor Audit and the affected Control/Vendor records) plus a qualified final assurance package. It hands the validated obligation statuses to the Regulatory Compliance Attestation Cycle, exchanging handoff packages with related workflows instead of duplicating repeated work.
workflow · Context
Annual ICFR Scoping & Risk Assessment
Runs on the fiscal year’s existing SOX Audit, using financial balances, prior-year RCM and deficiency history, business changes, and the approved IA plan. Produces the Fiscal Year Audit Scope Memo, Risk & Control Matrix, approved workplan, kickoff records and recipient-specific annual communications for process walkthroughs and control testing.
workflow · Context
Production Operations & Processing Integrity Cycle
Runs on the existing Process item for production/IT operations (process_type: it_general_control, frequency: daily — e.g. "Production Batch Operations & Processing Integrity"): one recurring instance per daily bridge/shift attaches to and enriches that Process, never creating a duplicate, and is archived against it at close. It operates the unified controls UC-ACCESS-17/18/20 (Control items, framework containing soc1|nist-csf-2|iso-27001) and consumes the prior cycle's carry-forward Issue items (open incidents, aged exceptions, backup gaps, tuning actions) as its opening population. A decision-aware workflow covering authorized batch execution and monitoring, failure and incident resolution, backup and restore-test verification, performance/capacity/security event monitoring with capacity tuning, and daily data-processing integrity through interface reconciliation and authorized-only output distribution. In scope: the authorized batch, interface, and report population, monitoring thresholds, and the backup and restore-test calendar for the daily processing bridge with weekly capacity and restore-test reviews layered in. Out of scope: application change management and access provisioning, handled by their own ITGC workflows — suspected change-control bypasses and access findings are cross-referred to those owners. No upstream or downstream workflow feeds this cycle; the certified-and-filed evidence step seeds the next run of this same cycle with carry-forward Issue items linked to the Process.
workflow · Context
Year-End Deficiency Aggregation & Severity Evaluation
Year-End Deficiency Aggregation & Severity Evaluation as a modular, decision-aware workflow. The instance runs against the existing fiscal-year ICFR assessment engagement — the Audit item with audit_type=sox_testing whose period_end is fiscal year end — enriching it rather than creating a duplicate: the frozen register snapshot and the full evaluation memo trail attach to its steps, and the overall ICFR conclusion lands on that Audit item (rating/opinion/report_date). It closes the gap between per-deficiency handling and the portfolio view: it freezes the register, reconciles it to every failed test, aggregates related deficiencies, concludes control deficiency versus significant deficiency versus material weakness, and hands conclusions to certification support, remediation, and audit-committee reporting instead of duplicating their work. The named deliverables are the year-end deficiency-evaluation memo (carrying the overall ICFR conclusion) and the countersigned final severity schedule. In scope: freezing and severity-evaluating the year-end deficiency population as of the fiscal-year-end assessment date, kept live through the 10-K filing date under a late-arrival rule. Out of scope, handed off rather than duplicated: fixing the deficiencies (SOX Deficiency Remediation) and reporting them to the board (Quarterly Board & Audit-Committee GRC Reporting). Severity thresholds and the contributing-test population are consumed from the Annual ICFR Scoping & Risk Assessment, SOX Key Control TOD/TOE Test, and SOX ITGC Testing runs — the deficiency register itself is the Issue population (issue_type deficiency, escalating to significant_deficiency and material_weakness as this workflow finalizes).
workflow · Context
FSLI Significance Assessment
Runs on the existing fsli item. Assess quantitative and qualitative significance for a financial statement line item and approve its scoped assertions, locations, and process dependencies. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOX Deficiency Remediation
SOX Deficiency Remediation carries one control deficiency's full lifecycle — grade, root cause, remediation, validation, and closure. The workflow runs on the deficiency **Issue item** it opens at grading — `issue_type` set to the exact SOX grade (deficiency / significant_deficiency / material_weakness) and `severity` on the mapped AssureSwarm scale — linked to the affected Control(s), the source Control-hosted SOX testing workflow (template kind: sox-testing), and the current-year SOX audit (Audit, `audit_type: sox_testing`); the remediation actions and the validation retest live as steps on this Issue's own workflow. In scope: a single deficiency triggered by a failed test or unresolved exception. It **consumes** the concluded, reviewed failed-test workpaper handoff package owned upstream (SOX Key Control TOD/TOE Test and SOX ITGC Testing) and **hands off** the closed-or-carried deficiency outcome — with its intact severity history and any triggered communication obligations — to Quarterly Board & Audit-Committee GRC Reporting, which aggregates the full deficiency population into the period's ICFR conclusion and audit-committee materials. It exchanges handoff packages with those related workflows rather than duplicating their work.
workflow · Context
SOX ITGC Testing
SOX ITGC Testing as a modular, decision-aware workflow. It runs on the existing Audit engagement item for this ITGC cycle (audit_type: sox_testing, period_start/period_end = the test period) — enrich that item, never create a duplicate — while per-control operating-effectiveness results live on Control-hosted SOX testing workflows, one created per in-scope ITGC control per Workflow.customFields.sox.fiscalYear, each hosted directly on the Control under test. It consumes the ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment, produces the reperformable final ITGC testing package as its named deliverable, and hands the deficiencies off to SOX Deficiency Remediation. In scope: the operating-effectiveness conclusion on the ITGCs protecting in-scope financial systems, reached by referencing the controls-owned NIST 800-53 catalog and its test scripts — not by rebuilding procedures. Out of scope, owned by related workflows: scoping of significant accounts and applications (Annual ICFR Scoping & Risk Assessment), deep completeness-and-accuracy validation of system-generated populations (SOX IPE Validation), and remediation of what fails (SOX Deficiency Remediation, the downstream handoff). It can stand alone, but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.
workflow · Context
SOX Scoping Decision
Runs on the existing Process item for the one business process under decision — it enriches that Process item and the Control and Risk items in its RCM, never creating a duplicate. Determine whether the process is SOX-relevant and, if so, scope its key controls — otherwise document the exclusion. Consumes the Annual ICFR Scoping & Risk Assessment handoff package (accepted materiality set, scoping thresholds, aggregation floor). Named deliverables: the assessment worksheet, the SOX-relevance determination memo, the resulting Risk & Control Matrix (RCM) scope (Control and Risk items with live links), and the exclusion memo — compiled into a signed scoping decision package. Hands that signed package off to the downstream SOX Process Walkthrough for the in-scope slice, or routes a full exclusion into the annual monitoring/refresh cycle. Out of scope: entity-level materiality, significant accounts, and fraud-risk assessment, which are owned by the upstream Annual ICFR Scoping & Risk Assessment, and process understanding and control verification, which are owned by the downstream SOX Process Walkthrough.