COBIT 2019
208 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
APO01 — Managed I&T Management Framework
Managed I&T Management Framework
control · Direct
APO02 — Managed Strategy
Managed Strategy
control · Direct
APO03 — Managed Enterprise Architecture
Managed Enterprise Architecture
control · Direct
APO04 — Managed Innovation
Managed Innovation
control · Direct
APO05 — Managed Portfolio
Managed Portfolio
control · Direct
APO06 — Managed Budget and Costs
Managed Budget and Costs
control · Direct
APO07 — Managed Human Resources
Managed Human Resources
control · Direct
APO08 — Managed Relationships
Managed Relationships
control · Direct
APO09 — Managed Service Agreements
Managed Service Agreements
control · Direct
APO10 — Managed Vendors
Managed Vendors
control · Direct
APO11 — Managed Quality
Managed Quality
control · Direct
APO12 — Managed Risk
Managed Risk
control · Direct
APO13 — Managed Security
Managed Security
control · Direct
APO14 — Managed Data
Managed Data
control · Direct
BAI01 — Managed Programs
Managed Programs
control · Direct
BAI02 — Managed Requirements Definition
Managed Requirements Definition
control · Direct
BAI03 — Managed Solutions Identification and Build
Managed Solutions Identification and Build
control · Direct
BAI04 — Managed Availability and Capacity
Managed Availability and Capacity
control · Direct
BAI05 — Managed Organizational Change
Managed Organizational Change
control · Direct
BAI06 — Managed IT Changes
Managed IT Changes
control · Direct
BAI07 — Managed IT Change Acceptance and Transitioning
Managed IT Change Acceptance and Transitioning
control · Direct
BAI08 — Managed Knowledge
Managed Knowledge
control · Direct
BAI09 — Managed Assets
Managed Assets
control · Direct
BAI10 — Managed Configuration
Managed Configuration
control · Direct
BAI11 — Managed Projects
Managed Projects
control · Direct
DSS01 — Managed Operations
Managed Operations
control · Direct
DSS02 — Managed Service Requests and Incidents
Managed Service Requests and Incidents
control · Direct
DSS03 — Managed Problems
Managed Problems
control · Direct
DSS04 — Managed Continuity
Managed Continuity
control · Direct
DSS05 — Managed Security Services
Managed Security Services
control · Direct
DSS06 — Managed Business Process Controls
Managed Business Process Controls
control · Direct
EDM01 — Ensured Governance Framework Setting and Maintenance
Ensured Governance Framework Setting and Maintenance
control · Direct
EDM02 — Ensured Benefits Delivery
Ensured Benefits Delivery
control · Direct
EDM03 — Ensured Risk Optimization
Ensured Risk Optimization
control · Direct
EDM04 — Ensured Resource Optimization
Ensured Resource Optimization
control · Direct
EDM05 — Ensured Stakeholder Engagement
Ensured Stakeholder Engagement
control · Direct
MEA01 — Managed Performance and Conformance Monitoring
Managed Performance and Conformance Monitoring
control · Direct
MEA02 — Managed System of Internal Control
Managed System of Internal Control
control · Direct
MEA03 — Managed Compliance With External Requirements
Managed Compliance With External Requirements
control · Direct
MEA04 — Managed Assurance
Managed Assurance
risk · Context
Adversarial attacks, data poisoning and prompt injection
Data-poisoning corrupts training data and embeds backdoors; adversarial evasion, prompt injection, and jailbreaks fool deployed models at inference; model extraction steals proprietary weights/logic — enabling harmful or policy-violating outputs.
risk · Context
Emergent behaviour and unsafe AI system integration
Large-scale or multi-model pipelines exhibit emergent capabilities/failures not present in any component and not predictable from component testing; integration with legacy systems introduces interface mismatches and configuration errors.
risk · 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
Public-safety harm from AI in critical infrastructure
Because AI acting as a safety component in critical digital infrastructure, road traffic, or utilities (Annex III(2)) operates without the required risk management, robustness, and human oversight, it can fail or behave unsafely, resulting in service disruption and threats to public safety and continuity.
risk · 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
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
Absent or untested business continuity / disaster recovery plan
No BCP/DR plan, or plans that exist but have never been exercised end-to-end, so a natural disaster, pandemic, civil unrest, or infrastructure failure disables critical processes with no tested recovery path.
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
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
Lack of independent audit and compliance review
Because independent internal and external audit and review of information security are not performed, control deficiencies and non-conformities are neither detected nor challenged, so weaknesses persist unremediated and management and the board lose reliable assurance over control effectiveness.
risk · Context
Adverse regulatory or policy change
Changes in law, regulation, tax policy, or government programs materially alter the entity’s cost structure, competitive dynamics, or permissible business practices, requiring costly adaptation.
risk · Context
Sector regulatory non-compliance (financial, healthcare, trade)
Non-compliance with sector regimes — banking prudential rules, consumer-lending laws, payment-network rules, healthcare (FDA/HIPAA/CMS, Anti-Kickback/Stark, False Claims), export controls (EAR/ITAR), antitrust, and environmental/labor rules — triggering fines, sanctions, or loss of license.
risk · 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
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
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
Corruption or integrity loss of critical data
Intentional or accidental alteration, deletion, defacement, or injection of false-but-believable data into systems (including web defacement and data from untrustworthy sources) renders data inaccurate and erodes confidence in it.
risk · 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
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
Measurement and calculation errors (accuracy)
Errors in revenue recognition amounts, cost of goods sold, depreciation/amortization, payroll calculations, fair-value measurement, journal-entry posting, tax provision, and foreign-currency translation misstating the financial statements.
risk · Context
Understatement of liabilities/expenses (completeness)
Unrecorded payables (cut-off failure), accrued expenses, unrecorded revenue for delivered goods, off-balance-sheet obligations, uncaptured inventory write-downs, and understated payroll/tax liabilities — understating obligations and overstating income.
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
Period cut-off errors
Revenue, vendor invoices, payroll, capital expenditure, treasury transactions, or tax provisions recorded in the wrong period — deliberately shifted to meet targets or erroneously mis-timed — distorting period results.
risk · Context
Data-quality and IPE integrity failures in reporting
Poor data lineage, inconsistent master-data definitions, or uncontrolled data transformation (weak IPE completeness/accuracy) cause management decisions and regulatory reports to rest on inaccurate or incomplete data.
risk · Context
Overstatement of assets/revenue (existence & occurrence)
Revenue, receivables, inventory, capitalized assets, prepaid expenses, treasury investments, or tax assets recorded without underlying existence or occurrence — inflating the balance sheet and income statement.
risk · Context
Financial-statement fraud and management override
Intentional misstatement through fictitious revenue, phantom inventory/assets, ghost-employee payroll, or management override of controls — inflating results and deceiving investors and regulators.
risk · 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
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
Organizational change and transformation failure
Significant structural or cultural change (restructuring, ERP/digital transformation) causes employee resistance, productivity loss, or talent departures that undermine the entity’s capacity to adapt to strategic imperatives.
risk · 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
Innovation and R&D governance failure
Insufficient investment in or poor governance of innovation and R&D pipelines results in loss of competitive differentiation, failure to meet customer expectations, and premature obsolescence of products and services.
risk · 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
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
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
Acceptance of data from untrustworthy sources
Injection or acceptance of data from untrusted or malicious sources (including position-detection/tracking data) causes incorrect processing or decisions and can seed downstream integrity loss.
risk · 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
Transaction-processing and execution errors
Data-entry (fat-finger) errors, incorrect settlement instructions, collateral-management errors, reconciliation failures, and mis-application of corporate actions cause failed settlement, penalties, and undetected position discrepancies.
risk · Context
Product design and model errors
Defective product design, errors in model or pricing assumptions embedded in products, and failure to investigate customer complaints cause systematic customer harm and mis-selling losses.
risk · 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
Absence of privacy-by-design and default
Because systems and products are built without embedding privacy controls at the architecture level, privacy protections are bolted on after launch rather than applied by default, so personal data is over-collected and exposed and costly manual remediation is required.
risk · 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
Competitive disruption and business-model obsolescence
A new entrant with a superior model, lower cost, or breakthrough technology captures share faster than the company can respond; industry/technology/customer shifts render the existing business model obsolete.
risk · 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
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
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
COBIT 2019
COBIT 2019 Governance & Management Objectives
unified · Context
UC-AUDIT-21 — Assess control effectiveness through testing and monitoring
Management operates a monitoring program over the system of internal control that combines ongoing evaluations with separate assessments, including management self-assessments and internal audit evaluations. Controls are assessed for design and operating effectiveness on a defined frequency by assessors with a level of independence appropriate to the assessment, under documented assessment plans, and plans for security testing, training exercises, and monitoring are developed, maintained, and executed. Identified deficiencies are evaluated and communicated to those responsible for corrective action, including senior management and the board as appropriate.
unified · Context
UC-AUDIT-22 — Review risk strategy and performance with leadership
Leadership periodically reviews the cybersecurity and risk management strategy and program performance against defined metrics, targets, and conformance requirements. Review outcomes are used to adjust strategy, direction, and program activities to ensure coverage of organizational requirements and risks. Performance and conformance monitoring follows a defined cadence with documented results and assigned follow-up actions.
unified · Context
UC-AUDIT-23 — Coordinate independent assurance reviews across providers
The organization plans and obtains independent reviews of its approach to managing and implementing information security - including people, processes, and technologies - at planned intervals, after significant changes, and where required by applicable law or regulation. Before relying on another provider's work, each reliance decision assesses and records the provider's independence and objectivity, competence and methodology rigor, evidence quality and reperformance capability, and recency against the covered risk's cadence, together with the resulting reliance level and rationale. Assurance activities are coordinated across internal and external providers to ensure coverage, minimize duplication, and support reliance on others' work. Material reliance limitations, assurance gaps, and duplication remain visible to management and the board. Results are reported to management and the board and drive corrective actions.
unified · Context
UC-AUDIT-24 — Manage compliance with external legal and regulatory requirements
The organization identifies applicable external legal, regulatory, and contractual requirements - including intellectual property rights and software licensing obligations - and maintains them in a compliance register with assigned owners. Compliance with these requirements is evaluated on a defined cadence, confirmed through documented reviews, and non-compliance is remediated with status reported to management. The register and evaluation results are retained as evidence.
unified · Context
UC-BCDR-01 — Maintain business continuity and disaster recovery plans
Maintain documented, management-approved business continuity and disaster recovery plans that cover critical business functions and ICT services, recovery time and recovery point objectives, assigned roles, and how information security is preserved at required levels during disruption. Base the plans on a business impact analysis, distribute them to responsible personnel, and review and update them at least annually and after significant organizational or technology changes.
unified · Context
UC-BCDR-06 — Resolve operational incidents and eliminate root causes
Log, classify, and prioritize operational and security incidents and service requests, respond within defined service levels, and escalate by severity until service is restored. Classify and report major ICT incidents to regulators, customers, and affected parties within required timeframes. Perform root-cause analysis of significant and recurring incidents, and track underlying problems through to permanent resolution.
unified · Context
UC-BCDR-12 — Operate IT services according to defined procedures
Execute day-to-day IT operations, including job scheduling, processing, infrastructure monitoring, and facility management, according to documented operating procedures. Monitor operations against expected outcomes, record exceptions, and correct deviations to sustain reliable service delivery.
unified · Context
UC-BCDR-13 — Operate continuous security protection services
Operate ongoing protection services, including malware defense, network and endpoint security, and security monitoring, so that attacks and disruptions do not compromise service availability or data. Review and tune these services regularly to keep security risk within accepted levels.
unified · Context
UC-BCDR-14 — Embed control activities in business processes
Define and operate control activities embedded within key business processes - input, processing, and output controls, segregation of duties and levels of authority, error and exception handling, and traceability of transactions - so that information processed remains complete, accurate, and valid.
unified · Context
UC-GOV-01 — Establish and maintain the enterprise governance framework
Design, implement, and maintain an enterprise governance system for information and technology that sets direction, decision rights, and accountability, together with a supporting management framework (organizational structures, policies, processes, and culture) that puts governance direction into operation. Evaluate the effectiveness of the governance and management framework periodically and adjust it as the enterprise context, strategy, and regulatory environment change.
unified · Context
UC-GOV-10 — Attract, develop, and retain competent personnel
Plan and manage the workforce so the organization attracts, develops, and retains individuals competent for their security and control responsibilities, including qualified cybersecurity personnel sufficient to manage the organization's risks and perform core security functions. Define required competencies, evaluate them periodically, address gaps through training, development, and succession planning, and verify that key security personnel maintain current knowledge of evolving threats and countermeasures.
unified · 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-12 — Align strategy and business objectives with mission and risk
Define and maintain an enterprise and technology strategy aligned with the organization's mission, evaluating alternative strategy options in light of the risk profile and formulating business objectives at all levels that align with and support the chosen strategy. Translate the strategy into a communicated roadmap and monitor execution against it, revisiting objectives when context or risk changes.
unified · Context
UC-GOV-13 — Govern the technology investment portfolio for value
Govern the portfolio of technology investments and innovation to secure optimal value: define investment criteria, evaluate and prioritize initiatives — including emerging technologies and innovation opportunities — based on benefit, cost, and risk, and monitor programs against expected benefits. Take corrective action, including reprioritization or termination, when expected value is not being realized.
unified · Context
UC-GOV-15 — Operate a management-approved information security program
Establish, implement, and maintain an organization-wide information security program, documented in a program plan approved by senior management and based on the organization's risk assessment. Define the program's scope, security objectives, protective functions (identify, protect, detect, respond, recover), supporting management processes, and coordination among organizational entities, and review and update the program plan at planned intervals and after significant change.
unified · Context
UC-GOV-17 — Establish enterprise risk management strategy and appetite
Establish, document, and communicate a leadership-approved enterprise risk management strategy, including risk management objectives agreed by stakeholders, defined risk appetite and tolerance statements, and a documented risk assessment policy with procedures and a consistent methodology for identifying, analyzing, prioritizing, and responding to risk. Ensure governance activities keep risk-taking optimized within appetite, and review and update the strategy, appetite, and policy at planned intervals.
unified · Context
UC-GOV-19 — Maintain enterprise security and privacy architecture
Establish and maintain an enterprise architecture, including security and privacy architectures, that describes how systems, information flows, and protections align with the organization's mission and strategy and address security and privacy risks. Review and update the architecture at defined intervals and reflect it in system security plans, solution designs, and acquisition decisions.
unified · Context
UC-GOV-20 — Govern data as an asset with accountable oversight bodies
Establish data governance: policies and standards for managing data through its life cycle, and formally chartered governance bodies (e.g., a data governance body and, where required, a data integrity board) with defined membership and responsibilities. These bodies oversee data management, data quality and integrity, and the review and approval of data-sharing and matching agreements, and report on data governance at defined intervals.
unified · Context
UC-GOV-21 — Communicate and report risk and control information
Establish channels, responsibilities, and cadences to communicate risk, control, and performance information internally at all levels — including objectives and internal control responsibilities — and with external stakeholders, business partners, and the technology function. Leverage information systems to capture, process, and deliver this reporting, and report on risk, culture, and performance to stakeholders at defined intervals and on significant events.
unified · Context
UC-GOV-22 — Assess control effectiveness and authorize systems
Maintain a documented assessment and authorization policy with procedures, defined performance measures, and quality monitoring to regularly evaluate whether security policies, standards, and risk-management measures are implemented, complied with, and effective — including managers' reviews of compliance within their areas of responsibility. Feed assessment results into a formal, risk-based authorization process in which a senior official explicitly accepts residual risk before systems operate and at defined intervals thereafter, and track findings to closure.
unified · Context
UC-SDLC-02 — Plan and resource development programs and projects
Manage development initiatives as governed programs and projects with defined scope, stakeholders, benefits, milestones, and risk management through delivery. Identify information security requirements during planning and allocate the resources and budget needed to fulfill them as an explicit line item.
unified · Context
UC-SDLC-03 — Define and approve security requirements for applications
Elicit, analyze, document, and approve functional and non-functional requirements, including application security requirements such as authentication, authorization, input and output handling, logging, and data protection, before solution design and build, assessing feasibility and alternative options. Manage requirement changes and requirements risk, and obtain stakeholder and management approval of the final requirements.
unified · Context
UC-SDLC-04 — Engineer systems with secure architecture and design
Design and build systems using established secure architecture and engineering principles: least privilege, defense in depth, isolation of execution domains (process and memory separation), fail-safe defaults, and attack-surface minimization, applied from concept through implementation. Require developers to produce and maintain a security architecture description consistent with the enterprise architecture. Engineer solutions to remain accurate, robust, and resilient against errors, faults, and adversarial manipulation.
unified · Context
UC-SDLC-06 — Maintain configuration control over systems and code
Maintain configuration management over solution components throughout development and operation: identify configuration items, establish and protect baselines for code, dependencies, and build settings, record and verify configuration information, and review deviations. Require developers to track the integrity of changes to configuration items, implement only approved changes, and track and resolve resulting security flaws.
unified · Context
UC-SDLC-07 — Approve, test, and accept changes before production release
Evaluate, prioritize, and authorize all IT changes, including emergency changes, before implementation, with documented impact and risk assessment. Establish acceptance criteria, perform acceptance testing in an environment representative of production, obtain business and IT approval, and promote releases through a controlled, auditable transition with fallback plans and post-implementation review.
unified · Context
UC-SDLC-08 — Maintain current system documentation and knowledge
Obtain, produce, and maintain current administrator and user documentation for systems, covering secure configuration, use, and maintenance, and protect and distribute it to authorized roles. Keep development and operational knowledge validated, current, and available to the personnel who need it.
unified · Context
UC-SDLC-09 — Prepare and train users for new and changed systems
Plan and manage the organizational side of new and changed systems: communicate impacts, prepare business and IT stakeholders, and sustain adoption after go-live. Require system developers to provide role-appropriate training and training materials for administrators, users, and security personnel before deployment.
unified · Context
UC-SDLC-12 — Manage solution assets and retire unsupported components
Manage application and infrastructure assets through their life cycle: maintain an accurate record of solution assets, ownership, and licensing, and optimize their use and cost. Identify system components approaching end of support and replace or upgrade them, or apply documented compensating controls with explicit risk acceptance, before support lapses.
unified · Context
UC-SDLC-13 — Plan solution availability and capacity
Plan, monitor, and manage the availability and capacity of solutions and services against current and forecast business requirements. Assess the impact of demand changes, address projected shortfalls through corrective plans, and validate that agreed availability and capacity targets are met.
unified · 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.
workflow · Context
Cybersecurity Assurance Review
Cybersecurity Assurance Review — a CAE-owned assurance engagement that runs on the EXISTING Audit item opened from the audit plan (audit_type=it_audit, status PLANNED, lead_auditor and scope already set): the workflow instance attaches to that item and enriches it end to end, never creating a duplicate engagement record. It covers the three IIA Cybersecurity Topical Requirement domains (governance, risk management, and control activities) over the cyber estate bounded in the engagement memo (in scope: named legal entities, networks, cloud tenants, and OT/ICS where included; out of scope: areas whose assurance is documented as delivered by other engagements), testing against the NIST 800-53 Rev 5 catalog with CSF 2.0 / ISO 27001 as the aggregation frame. It originates from the audit plan (no upstream workflow) and produces the findings register (one four-Cs Issue per finding), the cyber posture summary carrying the per-domain and overall Standard 14.5 conclusions, and the approved engagement package — which it hands to the downstream Audit Report Drafting workflow.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
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
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
ISMS Internal Audit & Management Review
Runs one ISO 27001 clause 9.2 internal audit and clause 9.3 management review cycle — including clause 10.1 corrective actions — against the existing Audit item for this cycle (audit_type=internal), whose scope, lead_auditor, and period dates already carry the ISMS audit-programme entry: the workflow enriches that Audit item and its findings, never creates a duplicate audit. Upstream it consumes the Annex A control population (Control items, framework iso-27001) and the applicability decisions in the Statement of Applicability, the risk register (Risk items) and treatment plan, the prior-cycle Audit and open Issue records, and the org's ISMS policies and procedures (Policy items) as audit criteria. Named deliverables: the internal audit findings report, the clause 10.1 corrective-action records (recorded on the finding Issue items), the management review pack, and the approved clause 9.3 minutes and action register. Out of scope: the certification-body external audit and day-to-day control operation. No upstream workflow feeds this cycle and no single downstream workflow consumes its output; at close the cycle is archived on the Audit item as retained ISMS documented information, and carry-forward items re-enter the audit programme (the next PLANNED Audit item), the risk register, or the next review's inputs.
workflow · Context
SOC 2 Readiness & Evidence Collection
SOC 2 Readiness & Evidence Collection runs ON an already-opened Audit item — the SOC examination engagement record (audit_type readiness, or external_attestation) whose scope (report type and Type 1/Type 2), examination period (period_start/period_end), and CPA firm (external_firm) are already set. That Audit item is an INPUT: this workflow enriches it and attaches its run to it, never creating a duplicate engagement. It consumes the organization's own Control library — the Control items, framework tagged soc2/soc1 — and no upstream workflow feeds it. In scope: one SOC examination cycle end to end — map the Control library to each in-scope Trust Services criterion (Security always; Availability, Confidentiality, Processing Integrity, or Privacy only where a customer commitment requires it) and SOC 1 control objective, close readiness gaps, run the provided-by-client (PBC) evidence request list with QA, and coordinate the CPA firm through fieldwork and follow-ups. Named deliverables: the criteria-to-control mapping matrix and graded gap matrix, the owned PBC evidence request list, the QA'd evidence set, and the cross-referenced PBC response package — all attached to the anchor Audit and its workflow instance. Out of scope: the SOC report the CPA firm drafts and continuous control monitoring between examinations. No downstream workflow is declared; this run's next-cycle seed artifacts (the PBC list and control calendar) stay on the close step as the de facto handoff to the next examination.
workflow · Context
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
Security & Privacy Architecture Review Board
Standing operator workflow for the Security & Privacy Architecture Review Board. Each cycle runs as a recurring workflow instance attached to the existing UC-GOV-19 Control item (security & privacy architecture governance; framework nist-800-53 + cobit-2019) in the control library — it enriches that Control and its evidence trail, never creates a duplicate, and the chain of archived instances is that control's execution log (Control has no native execution-log field). The cycle maintains the enterprise, security, and privacy architecture views (across the business, data, application, technology, security, and privacy domains), runs a scheduled annual full-refresh branch, reviews solution designs and acquisition decisions for architectural alignment with a remediation loop, and pushes approved architecture updates into system security plans and acquisition requirements. It consumes: the prior cycle's archived baseline and architecture-view documents plus its open carryover Issue items; the live system/application inventory and mission/strategy statements (uploaded from external systems, no native item type); and the Risk items that form the security (category cyber_security) and privacy (category privacy) risk registers. Named deliverables: the refreshed enterprise architecture baseline package and drift log, the updated security and privacy architecture views with risk-crosswalk gap lists, the alignment assessment register, the pushed-updates package of SSP and acquisition-requirement changes, and the program-health dashboard. In scope: enterprise/security/privacy architecture maintenance, solution-design and acquisition alignment review, and SSP and acquisition-requirement updates. Out of scope: implementing the individual system security controls and running procurement themselves — those execute in the owning system-authorization (ATO) and acquisition/procurement workflows, which are the real downstream consumers of this cycle's SSP and acquisition-requirement updates. No upstream workflow feeds this cadence; it is triggered by the standing quarterly ARB cadence, the annual refresh date, or an ad hoc urgent design or acquisition submission.
workflow · Context
Cybersecurity Incident Response
Cybersecurity incident-response cycle as a decision-aware workflow spanning detection and validation, scoping, incident declaration and response-plan activation, containment with evidence preservation, eradication and recovery, POA&M updates for the control deficiencies the incident exposed, and a technical lessons-learned retrospective, closed through a disposition decision and archival. The workflow instance runs on the incident record — an Issue item (issue_type=exception, source=management_identified, severity per the org scheme) created at detection, since the schema has no native Incident type — and enriches that one record through to archival rather than creating duplicates. In scope: security events and confirmed incidents affecting the system boundary and its NIST 800-53 IR-family controls — the detection sources (logging/monitoring Control items, UC-LOG-06), affected systems (Process items, UC-ASSET-11), containment and recovery actions, forensic evidence, the deficiency Issues that become the POA&M, and their linked Risk items. Out of scope: the enterprise incident-management ticketing lifecycle and external breach-notification/legal reporting, which run in their own workflows. Where an Incident Management Lifecycle workflow is running, this cycle consumes its handoff package (initial ticket, reporter, affected systems); it hands the closed incident's control-deficiency findings — the open POA&M Issues (issue_type=deficiency) — to the Continuous Controls Monitoring (ISCM) Cycle as shared items it queries directly.
workflow · Context
Change & Release Management (CAB)
Change & Release Management (CAB) as a decision-aware workflow that runs one recurring weekly instance against the EXISTING change-management ITGC Control item in the control library (domains: secure_configuration_change_management; mapped via Control.framework to nist-800-53, cobit-2019, iso-27001, and soc1, alongside the related UC-CONFIG-02/03, UC-ACCESS-16, and UC-SDLC-06/07/08/09 controls) — it enriches that control's operating evidence each cycle, it does not create the control. Upstream it consumes the open change-request queue and the emergency-change log exported from the ticketing system, plus the prior cycle's closure export as its carry-forward backlog. It covers change intake, security and risk impact analysis, environment segregation and configuration-baseline control, acceptance testing, the single CAB authorization gate, the emergency-change path, and controlled deployment with rollback and post-implementation verification — producing the prioritized CAB agenda and authorization packet, per-change risk-assessment memos, the environment-and-baseline verification memo, acceptance-testing summaries, the deployment-and-verification record, and the archived per-cycle evidence set. In scope: application, database, infrastructure, configuration, and procedure changes across development, test, and production environments. Out of scope: authoring the change itself — this workflow governs authorization and release, not development of the underlying code or configuration. Studio ships no native Change Request item type, so per-change records live as lines in step documents and in the workflow instance rather than as items. This is a terminal workflow with no downstream handoff: closure archives the cycle evidence set in place under retention, and the next cycle's intake reads this instance's closure export as its carry-forward source.
workflow · Context
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
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
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
Technology Lifecycle & Capacity Review
Standing operator workflow for the quarterly solution-asset lifecycle review and the availability/capacity planning cycle, from asset reconciliation and end-of-support disposition through capacity monitoring, corrective planning, and prior-period target validation. Each quarterly run is a recurring workflow instance attached to the EXISTING technology-lifecycle-and-capacity-management Control item (UC-SDLC-12/13; frequency = quarterly; control_owner = the IT control owner) — the instance enriches that standing Control and its linked records, never a fresh duplicate; the governing COBIT 2019 / NIST 800-53 mapping rides on Control.framework. In scope: the in-scope solutions, applications, and supporting infrastructure components (the services they run are Process items) with named owners, and the services carrying agreed availability and capacity (SLA/SLO) targets. Out of scope: the projects that execute an approved replacement or upgrade (each tracked externally as its own project item) and live incident response for availability outages. Named deliverables: the reconciled solution-asset register and optimization actions, the ranked end-of-support exposure list and disposition, funded replacement/upgrade plans (Issue items) and compensating-control records (Control items) with signed risk acceptances (policy_exception Issues carrying exception_expiry_date, on treatment: accept Risks), the capacity/availability dashboard and corrective plans, and the validated prior-period target package. No upstream workflow feeds this cycle and there is no separate downstream workflow to hand off to — the still-open replacement/upgrade plans, capacity corrective plans, and risk-acceptance expiries (their existing Issue and Risk items, linked to the anchor Control) carry forward as explicit inputs to the next quarterly run of this same workflow.
workflow · Context
ISO 27001 SoA Review & Controls Assessment
Review the ISO 27001 Statement of Applicability and assess the controls behind it. Each run attaches to an Audit item created for the review cycle (audit_type = compliance, e.g. "ISO 27001 SoA Review 2026-H2"), which accumulates the scope, the per-control test instances, the assessment package, the approval, and the rating. The workflow locks the assessment workplan, reconciles every Annex A control's applicable/excluded decision and justification against the current risk treatment plan, verifies implementation evidence, assesses the sampled controls for design and operating effectiveness, routes deficiencies to owners, and approves and publishes the version-controlled Statement of Applicability (SoA) — then classifies the disposition and prepares, approves, hands off, and archives the review package. In scope: reconciling and assessing the SoA's Annex A control applicability decisions and their implementation for the ISMS in scope, and publishing the approved SoA version. It consumes the ISMS Risk Assessment & Treatment Cycle's handoff package (the current risk register, the risk treatment decisions, and the required-controls determination) and hands its named deliverable — the approved, version-controlled published SoA and the assessment package — off to the downstream ISO 27001 Certification Readiness workflow. Out of scope: the enterprise risk assessment and treatment decisions that determine which controls are required (owned upstream by the ISMS Risk Assessment & Treatment Cycle) and the certification audit preparation that follows (owned by the downstream ISO 27001 Certification Readiness workflow, which consumes this review's approved package). The trigger is the scheduled SoA review interval or a material change to scope, risk, or the control environment.
workflow · Context
Change Request, Approval & Migration
Runs on the existing system item. Move a system change from request through independent testing and approval to production migration, evidencing developer-migrator segregation. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Emergency Change
Runs on the existing system item. Record an emergency change that bypassed normal change control, evidence the elevated access used, and retrospectively test whether the bypass was justified. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
New System Implementation (SDLC)
Runs on the existing system item. Take a new system from control requirements through testing and acceptance to an evidenced go-live readiness decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
NIST RMF System Authorization (ATO) Cycle
Runs the seven NIST SP 800-37r2 RMF phases — Prepare, Categorize, Select, Implement, Assess, Authorize, and Monitor — against a single information system to reach and then sustain an authorization-to-operate (ATO) decision. The cycle is anchored on an Audit item created per authorization ("RMF ATO Cycle — <system> <year>", audit_type=it_audit, scope=the authorization boundary, period_start/period_end=the AO decision calendar); the information system itself is enriched as an existing Process item (process_type=security_process). Studio has no System/Asset type, so the RMF-specific facts (FIPS 199 categorization, selected baseline, ATO decision, authorization-termination date) live in the phase documents and on the Audit anchor rather than in dedicated fields. In scope: the defined authorization boundary and its inherited, hybrid, and system-specific controls (existing Control items). Out of scope: enterprise-wide common-control-provider programs and standalone penetration testing, which run as their own engagements and are consumed here only as assessment evidence. Named deliverables: the FIPS 199 categorization memo, the System Security Plan (SSP), the Security Assessment Report (SAR), the Plan of Action & Milestones (POA&M), and the signed ATO letter — assembled into one authorization package for the authorizing official. No upstream workflow feeds this cycle; it originates at Prepare. Downstream it hands off to itself: the Monitor phase's reauthorization triggers re-instantiate this template against the same system, and the Monitor phase's closing export is the authorization record the next cycle's Prepare consumes.
workflow · Context
Incident & Problem Management
Runs on the existing system item. Record an incident on a system, evidence containment against response targets, and determine root cause with preventive action. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Security Control Assessment & POA&M Remediation
Run this assessment on the EXISTING Audit item for the engagement (audit_type: it_audit or compliance) — enrich that record, never create a duplicate: Audit.scope carries the authorization boundary and Audit.period_start/period_end the assessment window. Consumes, from the upstream SSP-development / system-categorization effort, the approved System Security Plan (SSP), the FIPS 199 system categorization, and the tailored NIST 800-53 baseline (existing Control items, framework: nist-800-53). Assess each in-scope control with 800-53A examine/interview/test methods, record satisfied / other-than-satisfied determinations, open a POA&M Issue for every gap, re-validate remediation, and issue the Security Assessment Report (SAR). In scope: control assessment, determinations, the POA&M lifecycle, and the SAR for the authorization boundary agreed at kickoff. Out of scope: the authorization (ATO) decision itself and the steady-state continuous-monitoring cadence. On completion, the frozen SAR and POA&M package are handed to the NIST RMF System Authorization (ATO) Cycle.
workflow · Context
Control Design Assessment
Runs on the existing control item. Assess whether a control is clearly specified and designed to address its stated risk before deciding what follow-up or testing is appropriate. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control Remediation Retest and Closure
Runs on the existing control item. Verify remediation readiness, independently retest the changed control, evaluate sustained results, and approve a supported closure decision. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Control Walkthrough
Runs on the existing control item. Walk one representative transaction or event through the control to understand actual execution, evidence, handoffs, and changes. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ISO 27001 Stage 1 ISMS Documentation Review
Certification-body Stage 1 review of the ISMS against ISO/IEC 27001:2022 clauses 4–10: context and leadership, planning and support, operation, and performance evaluation with improvement - walking each clause group against the governing documents and the operating processes that carry it, and concluding Stage 2 readiness with dual sign-off. Stage 1 documentation and readiness review for ISO/IEC 27001:2022 clauses 4–10, conducted under the engagement methodology. It informs Stage 2 planning and does not issue a certification decision. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
ISO 27001 Stage 2 Annex A Controls Audit
Attach to the existing Audit engagement, owned by Internal Audit, using its approved Statement of Applicability, risk treatment plan, scope, review period and operating evidence; produce the Stage 2 Annex A Controls Audit report, four signed theme conclusions and finding register for the engagement and remediation owners. Apply the approved Statement of Applicability to ISO/IEC 27001:2022 Annex A.5.1–A.5.37, A.6.1–A.6.8, A.7.1–A.7.14 and A.8.1–A.8.34; document each exclusion and assess direct and inherited responsibilities. This Annex A assessment contributes to the engagement and does not independently establish full ISMS conformity or issue certification. Stage 1 and readiness remain separate workflows; any certification decision remains with the authorized certification body.
workflow · Context
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
Domain Oversight and Management Review
Quarterly management review of one process area - the process area's own oversight run. The domain owner reviews the registers the domain operates (systems, tenants, audits), the health and evidence of the operating-process runs, the domain's risks, issues and metrics, and the operation of its controls, then records direction and a dual sign-off. Instantiated once per process area; the operating processes keep their own runs.
workflow · Context
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
Interim Operating Effectiveness Testing
Runs on the existing SOX Audit using approved Control-hosted TOD/TOE results and the interim scope. Produces the program coverage and exception register, remaining-period commitments, all-controls auditor handoff and management status communications for year-end roll-forward.
workflow · Context
Period-End Roll-Forward Testing
Runs on the existing SOX Audit using approved interim results and remaining-period commitments. Produces independently reviewed year-end coverage, a separate Year-end Management Inquiry Package and the full-year conclusion for audit reporting and deficiency aggregation.
workflow · Context
ISO/IEC 42001 AI Management System Internal Audit
An independent internal-audit cycle for the AI management system: set scope and criteria, test governance, risk, documentation, operations, value-chain controls, and reporting, then issue findings and an evidence-backed conclusion. The audit supports management improvement and assurance; it does not certify conformity.
workflow · Context
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
Third-Party Vendor Risk Lifecycle
Operate the third-party vendor risk lifecycle end to end: scope and tier the vendor population, gather and analyze assurance evidence (SOC reports and CUECs, plus C-SCRM controls), embed contractual protections, enroll ongoing monitoring, and reach a governed disposition and approval. The vendor register IS the set of Vendor items — tiered by criticality (tier) and data exposure (data_classification), owned (business_owner, risk_owner), and driven by reassessment_cadence with last/next assessment dates and monitoring_status; each assessment cycle runs as one workflow instance over that register. In scope: vendor and supplier third-party risk assessment, onboarding controls, and periodic reassessment. Out of scope: procurement sourcing and commercial negotiation, and the deeper fieldwork of a Third-Party Vendor Assurance Engagement, to which the approved package is handed off. This workflow is self-initiating and consumes no upstream workflow package.
workflow · Context
IT Governance Objective Review (COBIT)
Periodic review of selected COBIT 2019 governance and management objectives, run per cycle on an Audit item (audit_type: it_audit; scope = the in-scope objectives; period_start/period_end = the assessment cycle) that the workflow instance attaches to and archives at close. Each in-scope COBIT objective is a Process item (process_type: it_general_control) linked to that Audit, and the review produces named deliverables against it: an evidence register and pre-scored capability sheet, a signed capability profile, a gap table with the benchmark decision, a committed improvement roadmap of Issue initiatives, and the governance board report and dashboard. In scope: the COBIT 2019 objectives selected for this cycle, each with a justified 0-5 target capability level, a named accountable owner, and the review cadence; out of scope: objectives explicitly excluded with recorded rationale. Self-originating: its scope sheet and target profile are supplied as workflow inputs, and it hands off to no distinct downstream workflow — the carry-forward improvement Issues and the archived instance seed its own next cycle.
workflow · Context
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
Technology Investment & Project Risk Governance
Technology Investment & Project Risk Governance as a decision-aware checkpoint graph, run as a recurring workflow instance attached to the existing Process item for the technology-investment / portfolio-governance process (process_type: business_process) — each quarterly board cycle enriches that standing process record rather than creating a new one. In the cycle the investment board refreshes its criteria, scores and prioritizes the technology and innovation portfolio, routes the annual capital-planning leg that allocates security funding to the risk strategy, monitors in-flight value and reprioritizes or terminates where value is not realized, and enforces security-risk sections in every project gate with ERM-linked artifacts. In scope: the quarterly technology investment-board review (always), the annual capital-planning and security-budget leg (when the funding and staffing envelope must be set or re-planned this cycle), and every project stage gate falling due. Out of scope: individual project execution and delivery mechanics and day-to-day security operations. The cycle consumes the ERM cyber-risk register (Risk items, category: cyber_security) and the approved program business cases as standing inputs, and produces a board decision record and evidence pack as its named deliverable. There is no downstream workflow hand-off, so cross-references are recorded as linked records (Issue ↔ Risk) rather than routed onward; the scored portfolio, in-flight programs, and stage-gated projects have no native item type and live as step documents.
workflow · Context
Combined Assurance Mapping
Combined Assurance Mapping as a decision-aware workflow. Each cycle runs as one workflow instance attached to an Audit item created for the cycle (audit_type: advisory, scope = the combined-assurance mapping scope for the period, period_start/period_end = the cycle period) — no other Studio type represents an assurance-coordination cycle, so the workflow enriches that Audit item rather than any pre-existing engagement. In scope: mapping assurance coverage across the Three Lines of Defense for the confirmed risk universe and entities this cycle — cataloging assurance providers, mapping their coverage onto the risk universe, assessing reliance, identifying gaps and duplication, coordinating coverage plans, publishing the combined assurance map, and preparing audit-committee reporting inputs. Out of scope: performing the underlying assurance engagements themselves (owned by internal audit, second-line functions, and external providers) and any risk, entity, or provider not named in this cycle's confirmed scope. It consumes the risk universe and residual positions (Risk items with their residual_rating and treatment) from the upstream Enterprise Risk Assessment & Portfolio Oversight Cycle and hands its named deliverables — the published combined assurance map, the reliance conclusions, and the gap action plans — to the downstream Quarterly Board & Audit-Committee GRC Reporting workflow rather than duplicating repeated work.
workflow · Context
Strategic Context & Objectives Alignment Cycle
Strategic Context & Objectives Alignment Cycle as a decision-aware workflow. Anchor: this recurring governance cycle runs on and enriches the existing "Strategic Planning & Objectives Alignment" Process item (process_type business_process, annual frequency) that represents the strategy-refresh process itself; where no such convention item is seeded it runs standalone with every output attached to the workflow instance. No upstream workflow feeds this cycle — it is the top of the governance chain and its own trigger, run annually or on an event-driven change such as an acquisition, a new market or regulation, a material risk-profile shift, or a significant incident; its only prior-cycle input is this workflow's own previous run, archived at close-and-archive. It refreshes the mission statement and stakeholder register, builds a bidirectional objectives-and-dependency map, communicates that context to risk-scoping owners, realigns and cascades strategy into a published and monitored roadmap, and closes by documenting mission-essential business processes as Process items with their information-protection needs as the approved basis for risk-assessment scoping. Named deliverables: the refreshed mission statement (DOCX) and stakeholder register (XLSX), the objectives-and-dependency map, the published context package and change summary, the strategy realign-or-reaffirm decision, the realigned enterprise and technology strategy (realign branch), the cascaded objectives and published roadmap, the mission-essential Process definitions, and the archived cycle record. In scope: the mission and stakeholder context refresh, strategy realignment and objective cascade, and the mission-essential process and risk-scoping definitions. Out of scope: executing the risk assessment itself. Downstream handoff: the exported cycle record and the approved mission-essential Process items are the scoping basis consumed by the Enterprise risk-assessment cycle.
workflow · Context
Data Governance Council Operations
Data Governance Council Operations as a decision-aware workflow. Each quarterly cycle runs as one workflow instance attached to the existing UC-GOV-20 Control item (data governance council oversight; domains=governance_policy_oversight, frequency=quarterly) — it enriches that Control as its execution record and never creates a governing body. It validates the chartered council's charter and membership, runs the annual policy and lifecycle-standards review when due, compiles data-quality and integrity metrics, reviews and approves data-sharing and matching agreements, convenes the council with recorded minutes, and reports data governance status at the defined interval. Upstream, it consumes the prior cycle's archived governance record — the council and data-integrity-board charters (Policy items, policy_type: charter) and membership rosters, the current data-governance policy and data-lifecycle standards library (Policy items), the prior minutes and status report, and the open action-item register (Issue items linked to the Control). Named deliverables: the data-quality and integrity dashboard, the data-management oversight summary, the chair-approved council (and integrity board) minutes, the per-agreement dispositions, and the data-governance status report; the annual branch adds the refreshed policy and standards redlines and the charter and roster amendments. In scope each quarterly cycle: the named business units and data domains, the data governance council (always), and the data integrity board wherever data-matching (Privacy Act computer matching) or new data-sharing requires its review; a metrics-only cycle need not convene the integrity board. Out of scope: bodies and data domains not named in the cycle's scope. Downstream the workflow is self-contained — no separate workflow depends on it — but it chains cycle to cycle: this cycle's archived governance record, filed with the status report, is the next quarterly instance's primary input.
workflow · Context
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
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
Risk & Control Self-Assessment (RCSA) Program
Risk & Control Self-Assessment (RCSA) Program as a modular, decision-aware workflow. Each wave runs on its own Audit item — created per wave (audit_type: operational; period_start/period_end = the wave window; report_date = the risk-committee date) — with the workflow instance attached to that item and the wave's questionnaires, attested returns, and calibration record kept inside the run. Each wave rebuilds the assessment universe from the existing Process, Risk, and Control items and their owners (enriching them, never recreating them), issues rating questionnaires to named control and process owners, collects attested self-assessments with structured exception capture, chases completeness, subjects the results to second-line challenge and calibration, aggregates a residual-risk view across units, updates the risk register's residual ratings, and routes self-identified issues to remediation and exceptions to time-bound acceptance before the results reach the risk committee. In scope: first-line self-assessment of in-scope business units and shared functions against their own risks and controls. Out of scope: independent testing/audit of those controls, and the remediation and formal risk-acceptance of what the wave surfaces, which are handed off downstream to the Finding Remediation & Action-Plan Monitoring (deficiencies), Policy Exception & Risk Acceptance (risk-acceptances/waivers), and Quarterly Board & Audit-Committee GRC Reporting (the wave report) workflows.
workflow · Context
Regulatory Exam & External Audit Management
Manage a live regulator examination or external audit end to end — from notification intake through request fulfillment, QC’d evidence release, fieldwork support, preliminary-findings response, and commitment closure. Runs on an Audit engagement item created per exam (audit_type = regulatory_exam, or external_attestation for an external audit); the workflow instance attaches to that Audit anchor, and preliminary findings and their corrective-action commitments become linked Issue items. No upstream workflow feeds this — it is triggered by the exam or audit notification itself. In scope: coordinating examiner requests, controlled evidence release, and management responses for a single exam or audit engagement. Out of scope: remediating the underlying control gaps — the findings and committed corrective actions hand off to Finding Remediation & Action-Plan Monitoring — and standing up new obligations surfaced by the exam, which hand off to Regulatory Horizon Scanning & Triage and Regulatory Obligation Implementation.
workflow · Context
Control Library Lifecycle
One control, one record: intake, author, classify, link, publish, review, retire — the library that audit RCM and SOX scoping read from.
workflow · Context
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
Regulatory Compliance Attestation Cycle
Regulatory Compliance Attestation Cycle: runs on and enriches the existing Audit item created for this authority and reporting period (audit_type = compliance or regulatory_exam; scope = certification boundary; period_start/period_end = the reporting period) — that Audit item is the attestation record the cycle updates throughout, never a duplicate. Over the cycle: compile evidence for the authority source across the reporting period, validate and resolve evidence gaps, produce the five-section regulatory attestation package, route certifying-officer certification, and archive the package. In scope: the legal entities, products, geographies, and systems named in the certification boundary for that authority and period. Consumes the implemented, owned, control-mapped obligation baseline as the handoff package from the Regulatory Obligation Implementation workflow (the implementations themselves are the Control items whose framework multiselect includes this authority, linked to the anchor Audit). Out of scope: obligations under other authorities, entities outside the certification boundary, and the obligation-to-control implementation itself. Hands the certification outcome, exception register, action plans, and accepted risks off to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Legal & Regulatory Compliance Register Evaluation
Runs the compliance office's recurring register-evaluation cycle as a compliance-review engagement: the workflow instance attaches to an Audit item created per cycle (audit_type: compliance, period_start/period_end bounding the evaluation period, lead_auditor = the compliance officer), and every gap, management directive, and result produced this cycle links back to that Audit. A decision-aware cycle that refreshes the register of applicable legal, regulatory, and contractual requirements — including intellectual-property and software-licensing obligations — confirms ownership, schedules and performs documented compliance evaluations on each requirement's defined cadence, remediates non-compliance, reports status to management, and retains the register and results as evidence. Consumes upstream: between-cycle regulatory change flows in as a data feed from the Regulatory Horizon Scanning & Triage workflow, swept at the register-refresh entry point (a feed, not a formal handoff package). Named deliverables: the dated register of record, the period evaluation schedule, the evaluation results register, the compliance determination, the exposure-ranked remediation set (Issues linked to the cycle Audit), the compliance status report and dashboard, and the retained cycle evidence set. Hands off downstream: obligations that need standing up route to the Regulatory Obligation Implementation workflow — named in prose at close-and-archive, with no handoff package produced here. In scope: the legal, regulatory, and contractual requirements already in the compliance register that fall due for evaluation this period — cadence-due, overdue, or event-triggered. Out of scope: standing up brand-new obligations. The cycle scope — register population, the due subset including overdue catch-ups, and the period boundaries — is set at the register-refresh entry point.
workflow · Context
EU AI Act Obligation Impact Analysis
EU AI Act Obligation Impact Analysis runs on a compliance Audit item created at intake (`audit_type: compliance`, `scope` = the fixed entities/AI-systems/markets boundary) — the "impact-analysis item" the whole run enriches and closes. It parses in-scope EU AI Act provisions, classifies affected AI use cases by operator role and risk tier, crosswalks obligations to existing Control items, rates conformity gaps as Issue items, and routes high-risk gaps to the AIMS (ISO/IEC 42001 AI management system). Consumes the horizon-scanning handoff package from Regulatory Horizon Scanning & Triage. Named deliverables: the locked workplan, the obligation register (the durable run-to-run workbook), the per-use-case classification set, the obligation-to-control crosswalk, the ranked conformity-exposure list, and the version-pinned final analysis package. Hands its approved gap-and-action package to Regulatory Obligation Implementation. In scope: obligation parsing, use-case classification, control crosswalk, and gap rating for the entities, AI systems, and markets fixed at intake. Out of scope: implementing remediations, performing conformity assessments, and running fundamental-rights impact assessments (FRIAs) — FRIAs route to the AI Governance & Risk/Impact Assessment module.
workflow · Context
Regulatory Impact Analysis & Obligation Mapping
Regulatory Impact Analysis & Obligation Mapping runs on a compliance Audit engagement record — an Audit item created per triggering instrument (audit_type=compliance) whose scope holds the locked scope statement and to which every gap Issue, risk acceptance, and the workflow instance attach. It consumes two upstream inputs: the triage handoff package from Regulatory Horizon Scanning & Triage (instrument, canonical citation, publication and effective dates, triage disposition) and the canonical instrument text itself — the Official Journal or regulator-register version, the authoritative source the whole analysis cites. It parses that instrument into obligations, maps them to the existing Policy and Control library, classifies and rates gaps, and reconciles the obligation register. Named deliverables: the cited regulatory impact note, the obligation inventory, the authority-to-policy crosswalk, the classified and rated gap Issues, the versioned obligation register, and the final evidence and decision package. In scope: obligation analysis, crosswalk, gap classification, exposure rating, and register reconciliation for the in-scope entities, products, and jurisdictions. Out of scope: remediation build-out (handed off to Regulatory Obligation Implementation) and re-prioritizing the instrument (owned by Regulatory Horizon Scanning & Triage). Confirmed gaps and their action plans hand off to Regulatory Obligation Implementation.
workflow · Context
Third-Party ICT Vendor Regulatory Assurance
Third-Party ICT Vendor Regulatory Assurance as a decision-aware workflow. Each cycle runs on its own Audit engagement item (audit_type = vendor_review) created at kickoff, with Audit.scope set to the in-scope legal entities, regimes, and vendor population; every workpaper, decision form, and gap attaches to that instance. In scope: ICT third-party service providers — including intra-group ICT providers — assessed against DORA, NIS2, and US interagency/FFIEC third-party expectations; out of scope: non-ICT vendors, which stay with the general vendor lifecycle. It consumes the arrangement-level inventory, tiering, and due-diligence handoff package from Third-Party Vendor Risk Lifecycle (whose provider records are the Vendor items); refers vendor SOC 1/SOC 2 reports carrying real reliance to the Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow and folds back its reliance conclusions; and produces a provision-cited, severity-rated gap register (Issue items linked to the anchor Audit and the affected Control/Vendor records) plus a qualified final assurance package. It hands the validated obligation statuses to the Regulatory Compliance Attestation Cycle, exchanging handoff packages with related workflows instead of duplicating repeated work.
workflow · Context
Year-End Deficiency Aggregation & Severity Evaluation
Year-End Deficiency Aggregation & Severity Evaluation as a modular, decision-aware workflow. The instance runs against the existing fiscal-year ICFR assessment engagement — the Audit item with audit_type=sox_testing whose period_end is fiscal year end — enriching it rather than creating a duplicate: the frozen register snapshot and the full evaluation memo trail attach to its steps, and the overall ICFR conclusion lands on that Audit item (rating/opinion/report_date). It closes the gap between per-deficiency handling and the portfolio view: it freezes the register, reconciles it to every failed test, aggregates related deficiencies, concludes control deficiency versus significant deficiency versus material weakness, and hands conclusions to certification support, remediation, and audit-committee reporting instead of duplicating their work. The named deliverables are the year-end deficiency-evaluation memo (carrying the overall ICFR conclusion) and the countersigned final severity schedule. In scope: freezing and severity-evaluating the year-end deficiency population as of the fiscal-year-end assessment date, kept live through the 10-K filing date under a late-arrival rule. Out of scope, handed off rather than duplicated: fixing the deficiencies (SOX Deficiency Remediation) and reporting them to the board (Quarterly Board & Audit-Committee GRC Reporting). Severity thresholds and the contributing-test population are consumed from the Annual ICFR Scoping & Risk Assessment, SOX Key Control TOD/TOE Test, and SOX ITGC Testing runs — the deficiency register itself is the Issue population (issue_type deficiency, escalating to significant_deficiency and material_weakness as this workflow finalizes).
workflow · Context
Quarterly 302/906 Sub-Certification Cascade
Quarterly 302/906 sub-certification as a modular, decision-aware workflow: it maintains the certifier hierarchy, refreshes the questionnaire for new systems, reorgs, known control issues, and pending deficiencies, launches the tiered cascade, tracks completion and cures gaps at the cutoff, triages exceptions and qualifications with escalation to the disclosure committee where material, summarizes the population for principal-officer 302/906 sign-off, and archives the certification evidence with the period's support. The instance runs against a campaign-record Audit item created for the quarter (audit_type: compliance; period_start/period_end = the quarter; scope = the in-scope entity and process population), enriching that one record — every questionnaire form, certification register, decision form, dashboard, and attestation package hangs off it and the run's own instance is the audit trail. It consumes the in-scope Process items (each carrying its process_owner) and the open deficiency Issue log, originates on its own recurring quarterly cadence with no upstream handoff, and hands its deficiencies downstream as linked Issue items into the SOX Deficiency Remediation, Year-End Deficiency Aggregation & Severity Evaluation, and Quarterly Board & Audit-Committee GRC Reporting workflows. In scope: the quarter's in-scope entities and processes per the current consolidation scope, from process-owner sub-certification through principal-officer 302/906 sign-off and archival, back-planned from the SEC filing date. Out of scope: the officers' external SEC filing mechanics, and the deficiency, year-end aggregation, and board reporting handled by the downstream SOX Deficiency Remediation, Year-End Deficiency Aggregation & Severity Evaluation, and Quarterly Board & Audit-Committee GRC Reporting workflows this cascade routes into.
workflow · Context
Control Interim Testing Record
Runs on the existing control item. Test a defined interim-period population using a documented sampling and attribute plan, then record exceptions and a bounded conclusion. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Period-End Roll-Forward / Rollover Testing
Runs on the existing control item. Bridge an approved interim control test through period end by assessing change, remaining occurrences, incremental evidence, and unresolved exceptions. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOX Control Testing
Runs on an existing SOX-applicable Control under a sox-testing template. SAMPLE reviews history, attributes and reproducible selection; TEST reviews evidence, exceptions and the approved result artifact. Keep fiscal year on Workflow.customFields.sox.fiscalYear and hand the published result to the SOX program.
workflow · Context
Management Assessment & Assertion
Runs on the existing audit item. Assemble and govern management’s annual ICFR assessment record, including scope, test results, deficiencies, certifications, disclosures, and assertion approval. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Process Walkthrough & Design Assessment
Runs on the existing process item. Perform a SOX process walkthrough, update the ICFR narrative and control mapping, and document design observations for management follow-up. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Deficiency Evaluation & Committee
Runs on the existing audit item. Evaluate SOX control deficiencies individually and in aggregate, obtain management challenge, and govern committee communication and disposition. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOX ITGC Testing
SOX ITGC Testing as a modular, decision-aware workflow. It runs on the existing Audit engagement item for this ITGC cycle (audit_type: sox_testing, period_start/period_end = the test period) — enrich that item, never create a duplicate — while per-control operating-effectiveness results live on Control-hosted SOX testing workflows, one created per in-scope ITGC control per Workflow.customFields.sox.fiscalYear, each hosted directly on the Control under test. It consumes the ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment, produces the reperformable final ITGC testing package as its named deliverable, and hands the deficiencies off to SOX Deficiency Remediation. In scope: the operating-effectiveness conclusion on the ITGCs protecting in-scope financial systems, reached by referencing the controls-owned NIST 800-53 catalog and its test scripts — not by rebuilding procedures. Out of scope, owned by related workflows: scoping of significant accounts and applications (Annual ICFR Scoping & Risk Assessment), deep completeness-and-accuracy validation of system-generated populations (SOX IPE Validation), and remediation of what fails (SOX Deficiency Remediation, the downstream handoff). It can stand alone, but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.
workflow · Context
SOX Key Control TOD/TOE Test
Runs directly on an existing SOX-applicable Control for the fiscal year, using the approved walkthrough, scope, methodology and evidence. Produces an independently approved TOD memo before sampling, period-specific TOE results and reviewed exception evidence for interim/year-end assessment and deficiency remediation. Require that the Control fields.sox_applicable value is the literal boolean true; use Workflow.customFields.sox.fiscalYear for the cycle. TOD/TOE test periods remain step-level facts.
workflow · Context
SOX Process Walkthrough
Runs on the existing Process item being walked (process_type=financial_reporting) — one workflow instance per walkthrough unit (process × location × variant), with the SOX program's Audit item (audit_type=sox_testing) linked as engagement context. It enriches that Process item and seeds its controls; it never creates a duplicate process. Consumes upstream: the significant-account and location scoping baseline, which it takes as a handoff package from the SOX Scoping Decision workflow rather than re-deriving. Produces the named deliverables: the documented process understanding, the identified key controls and their attributes, the control-to-risk mapping (the Risk & Control Matrix, RCM), the walkthrough memo (which doubles as the process's standing narrative), and draft Control records seeded into the register. Out of scope, owned downstream: design-effectiveness conclusions, sampling, and control testing — the handoff splits the control population so confirmed-design controls go to the SOX Key Control TOD/TOE Test workflow and open-design-gap controls go to the Control Design workflow first. It can stand alone but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.
workflow · Context
SOX Key Control Operation (Close Cycle)
Runs against the existing Financial Close **Process** item (process_type: financial_reporting, monthly) — one workflow instance per close period that operates that period's SOX key controls and is archived when the control owner's sub-certification closes the period, as the period's durable, control-indexed evidence trail; it enriches the standing Process and Control records, never recreating them. Consumes upstream: the in-scope close-cycle key-control population from the risk & control matrix — **Control** items (key_control: true, framework includes sox + coso-ic, domains includes financial_reporting_controls) produced by the *Annual ICFR Scoping & Risk Assessment* workflow and linked to this Financial Close Process — plus the prior period's carry-forward **Issue** items (aged reconciling items, approved carryovers). In scope: the close-cycle key controls operating each period — account reconciliations, management review controls, and journal-entry approval — scoped against the period-end close boundary. Named deliverables: the period IPE log, the signed account reconciliations, the completed MRC checklists, the journal-entry approval register, the control-indexed period evidence package, and the control owner's signed sub-certification (supporting the officers' Section 302 certification). Downstream handoff: the archived evidence package and control execution log stand as the sampling population for the *SOX Key Control TOD/TOE Test*; escalated potential deficiencies continue in the *Year-End Deficiency Aggregation & Severity Evaluation* (deficiency-evaluation) track. Out of scope: deficiency severity evaluation and TOD/TOE testing themselves, both of which consume this cycle's archived evidence.