COSO IC 2013
124 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
P1 — The organization demonstrates a commitment to integrity and ethical values.
The organization demonstrates a commitment to integrity and ethical values.
control · Direct
P10 — The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
control · Direct
P11 — The organization selects and develops general control activities over technology to support the achievement of objectives.
The organization selects and develops general control activities over technology to support the achievement of objectives.
control · Direct
P12 — The organization deploys control activities through policies that establish what is expected and procedures that put policies into action.
The organization deploys control activities through policies that establish what is expected and procedures that put policies into action.
control · Direct
P13 — The organization obtains or generates and uses relevant, quality information to support the functioning of internal control.
The organization obtains or generates and uses relevant, quality information to support the functioning of internal control.
control · Direct
P14 — The organization internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.
The organization internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control.
control · Direct
P15 — The organization communicates with external parties regarding matters affecting the functioning of internal control.
The organization communicates with external parties regarding matters affecting the functioning of internal control.
control · Direct
P16 — The organization selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
The organization selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.
control · Direct
P17 — The organization evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate.
The organization evaluates and communicates internal control deficiencies in a timely manner to those parties responsible for taking corrective action, including senior management and the board of directors, as appropriate.
control · Direct
P2 — The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.
The board of directors demonstrates independence from management and exercises oversight of the development and performance of internal control.
control · Direct
P3 — Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives.
Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives.
control · Direct
P4 — The organization demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives.
The organization demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives.
control · Direct
P5 — The organization holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
The organization holds individuals accountable for their internal control responsibilities in the pursuit of objectives.
control · Direct
P6 — The organization specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
The organization specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives.
control · Direct
P7 — The organization identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
The organization identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed.
control · Direct
P8 — The organization considers the potential for fraud in assessing risks to the achievement of objectives.
The organization considers the potential for fraud in assessing risks to the achievement of objectives.
control · Direct
P9 — The organization identifies and assesses changes that could significantly impact the system of internal control.
The organization identifies and assesses changes that could significantly impact the system of internal control.
risk · Context
Incomplete asset inventory and classification
No authoritative inventory of information and associated assets, missing ownership, acceptable-use, classification, labelling, or handling rules — preventing effective protection, risk assessment, and secure disposal.
risk · Context
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
Poor configuration management and insecure baseline drift
Without documented, enforced baseline configurations and change control, systems drift into insecure states, contain unauthorized changes, or expose unnecessary network services, expanding attack surface.
risk · Context
Absent or weak change-control procedures
Changes to systems, software, hardware, or configurations without formal approval and testing (including unauthorized or poorly tested hardware/config changes) introduce new vulnerabilities, instability, or failed releases.
risk · Context
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
Undocumented data inventory and unmapped data flows
No authoritative record of what personal data is held, where, who accesses it, and how it flows to processors/sub-processors and across borders — preventing risk assessment, DSR fulfilment, and enforcement of privacy obligations.
risk · Context
Social and human-rights failures in operations and supply chain
Failure to respect human rights — forced or child labour, discrimination, unsafe conditions — in operations and supply chains, resulting in legal liability, boycotts, and ESG rating downgrades.
risk · 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
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
Liquidity, capital-structure and refinancing risk
Cash-flow shortfall from working-capital deterioration, covenant breaches accelerating debt, loss of revolving credit, or capital-market disruption; debt maturity walls and downgrades limiting refinancing at acceptable terms; insufficient capital to absorb losses.
risk · Context
Internal fraud — asset misappropriation, embezzlement, forgery
Employees defraud the entity for financial gain: embezzlement or theft of company/client funds, fraudulent expense/payroll claims, forgery to obtain unauthorized disbursements, bribery/kickback schemes, insider trading on own account, and wilful tax evasion.
risk · Context
Unauthorized activity — rogue trading, position mismarking, concealment
Losses from transactions not reported or of an unauthorized type, deliberate mismarking of positions, fictitious trade bookings to conceal losses, and circumvention of position/risk limits without disclosure (e.g. rogue trader).
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
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
Missing security terms in contracts and no disciplinary process
Employment and supplier contracts omit security/confidentiality obligations, and there is no disciplinary process for security violations — removing legal recourse and the deterrent effect against repeat offenders.
risk · Context
No or insufficient incident-response procedures
Without documented, tested incident-response procedures, breaches and failures are handled inconsistently, slowly, or ineffectively, prolonging exposure and amplifying loss.
risk · Context
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
Brand and reputational crisis
Product-safety/quality failures, executive misconduct, data breaches, adverse media, or viral social-media/activist campaigns erode customer trust, investor confidence, partnerships, and brand equity — with long-term value loss exceeding near-term financial impact.
risk · Context
Stakeholder trust and social-license erosion
Gradual loss of trust and social license among customers, employees, investors, regulators, and communities — from perceived values misalignment, poor ESG/governance conduct, or repeated service failures — weakening stakeholder relationships and long-term enterprise value even absent a single acute crisis.
risk · Context
Inadequate or absent risk assessment process
No systematic process to identify, analyse, evaluate, and treat risk — including missing fraud-risk assessment and no ongoing risk monitoring — leaving material exposures unidentified and untreated before they materialise.
risk · Context
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
Innovation shortfall and emerging-technology adoption risk
Because the organization under-invests in or poorly governs its innovation pipeline while adopting unproven emerging technologies (AI/ML, blockchain, cloud) without adequate diligence, it faces both loss of differentiation and obsolescence and implementation failure, vendor lock-in, or ethical exposure, resulting in eroded competitiveness and failed technology bets.
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.
standard · Direct
COSO IC 2013
COSO Internal Control – Integrated Framework (2013)
unified · Context
UC-ACCESS-15 — Design control activities over technology access
Management selects and develops control activities, including general controls over technology, that mitigate identified access-related risks to acceptable levels, documented in a control matrix mapping risks to controls. Control designs cover the technology infrastructure, security management, and acquisition and development processes relevant to access, and are updated as risks and systems change.
unified · Context
UC-ASSET-02 — Inventory data and document processing activities and flows
Maintain inventories of data and corresponding metadata for designated data types, together with records of processing activities capturing purposes, data categories, recipients, retention periods, and safeguards as required by applicable privacy regulation. Maintain representations of authorized network communications and internal and external data flows, such as data-flow diagrams. Review and update these records upon significant change and at least annually so management relies on complete, quality information.
unified · Context
UC-AUDIT-18 — Communicate with stakeholders on assurance matters
The internal audit function builds relationships and communicates regularly with its stakeholders - the board, management, and relevant external parties such as regulators and external auditors - to develop trust and mutual understanding on internal control and assurance matters. Communication approaches are tailored to stakeholder needs and delivered through defined channels, and significant control matters are shared with external parties as appropriate. Communication plans and records evidence operation.
unified · 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-CONFIG-09 — Document configuration management policy, plan, and procedures
Develop, document, and implement a configuration management plan defining roles, responsibilities, processes, and procedures for identifying, managing, and protecting configuration items throughout the system development life cycle. Deploy these expectations through approved policies and actionable procedures, review them periodically, and update them when the environment or organization changes.
unified · Context
UC-GOV-04 — Set tone at the top: integrity, ethics, and risk-aware culture
Leadership defines and demonstrates commitment to integrity, core ethical values, and the desired risk-aware culture through an adopted code of conduct, consistent leadership behavior, and periodic evaluation of adherence with timely remediation of deviations. Organizational leadership is responsible and accountable for cybersecurity and internal-control risk and fosters a culture that is ethical, risk-aware, and continually improving, with expectations communicated to all personnel and business partners.
unified · Context
UC-GOV-05 — Ensure board-level oversight of risk and internal control
The board of directors (or equivalent governing body), demonstrating independence from management and appropriate expertise, oversees the development and performance of internal control and the cybersecurity risk management program, approving the risk strategy and material policies. The board periodically reviews risk-management outcomes, program effectiveness, and management reporting, and directs adjustments to strategy and direction; oversight activities and decisions are documented in minutes and supporting materials.
unified · Context
UC-GOV-06 — Define security roles, responsibilities, and authorities
Establish and document organizational structures, reporting lines, and the roles, responsibilities, and authorities for information security, risk management, and internal control, with board oversight of their design. Communicate assignments to the individuals and teams concerned, keep them current through organizational and personnel change, and enforce them in practice so that ownership of each security obligation is unambiguous.
unified · Context
UC-GOV-07 — Hold individuals accountable for control responsibilities
Management requires all personnel to apply information security in accordance with established policies and procedures and holds individuals accountable for their internal control responsibilities. Accountability is enforced through defined expectations, documented rules of behavior acknowledged before access is granted and re-acknowledged when updated, performance measures and incentives, and disciplinary consequences for violations.
unified · Context
UC-GOV-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-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-IR-10 — Learn from incidents and communicate corrective actions
Hold post-incident reviews for incidents meeting defined thresholds to capture what happened, what worked, and what failed. Convert lessons into tracked corrective actions — updates to controls, plans, training, and configurations — and use incident trends to identify and reduce recurring exposure. Communicate identified deficiencies and corrective-action status in a timely manner to the parties responsible for remediation, including senior management and, where significant, the board.
unified · Context
UC-RISK-04 — Define objectives and business context for risk assessment
The organization specifies business objectives with sufficient clarity to enable the identification and assessment of risks relating to those objectives. Mission-essential and business processes are defined, including their information protection needs, and serve as the basis for risk assessment scoping. Objective and process definitions are documented, approved, and revisited when strategy or operations change.
unified · Context
UC-RISK-06 — Perform periodic enterprise risk assessments
The organization performs an enterprise-wide risk assessment at least annually and upon significant change, identifying and analyzing risks to the achievement of objectives, including cybersecurity, privacy, and financial reporting risks. Assessments follow the documented methodology, address the design of the control environment and evolving threats and technologies, and are approved by management. Assessment reports, methodology references, and approvals are retained as evidence.
unified · Context
UC-RISK-11 — Assess changes that could significantly affect risk and control
The organization identifies and assesses internal and external changes - new business models, leadership, systems, regulations, and operating environment - that could significantly affect its risk profile or system of internal control. Risk assessments and responses are updated dynamically as changes and emerging risks are detected. Change-triggered assessments and resulting updates are documented.
unified · Context
UC-RISK-12 — Assess and mitigate fraud risk including management override
A documented fraud risk assessment considers fraudulent reporting, asset misappropriation, and corruption, evaluating incentives, pressures, opportunities, and rationalizations, and explicitly addresses the risk of management override of controls. Specific anti-override controls operate, including review of journal entries and significant estimates at an appropriate level of precision. The assessment and mitigating controls are refreshed at least annually with documented results.
workflow · Context
Fraud & Forensic Investigation Engagement
Fraud & Forensic Investigation Engagement as a decision-aware workflow. It runs on a dedicated Audit item (audit_type: investigation) created for this allegation at intake — the confidential case record — with the workflow instance attached to that item and its visibility restricted to the named investigation team. In scope: one specific fraud allegation, worked predication-gated and confidentially from intake through evidence preservation, forensic procedures, interviews, loss quantification, and audit-committee reporting; the named deliverables are the chain-of-custody register, the findings memorandum with its loss-quantification schedule, and the privilege-marked audit-committee fraud report. Out of scope: the enterprise fraud risk profile (owned by Fraud Risk Assessment & Anti-Override Control Review, which receives scheme intelligence from this case rather than being rerun here) and any unrelated conduct discovered in passing (which gets its own intake record). It consumes the hotline intake package from Control Responsibility Communications & Ethics Hotline when so routed, and hands each control breakdown off as an Issue item — control-gap findings to Finding Remediation & Action-Plan Monitoring and ICFR-affecting deficiencies to SOX Deficiency Remediation — rather than duplicating that work.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
Finding Remediation & Action-Plan Monitoring
Finding Remediation & Action-Plan Monitoring runs on the EXISTING parent Audit item — the issued engagement whose report findings are being followed up — enriching that Audit and its linked findings rather than creating a new engagement; the workflow instance attaches to that Audit item, and each report finding is an Issue item linked to it. It tracks issued-report findings and their agreed management actions from registration through evidence validation, closure, extension, risk acceptance, escalation, and committee reporting, and produces a verified disposition register and a signed final evidence-and-decision package. In scope: all open findings from the engagement plus any prior-cycle findings still open against the same auditee. Out of scope: re-performing engagement fieldwork and re-wording report findings (both belong to the upstream Audit Report Drafting workflow) and assembling the board pack (the downstream Quarterly Board & Audit-Committee GRC Reporting workflow consumes this cycle's outputs). It consumes the issued final report and findings register handed off from Audit Report Drafting and hands its verified outputs to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Internal Audit Charter, Independence & Board Governance Cycle
Runs on one Audit item created per governance cycle (audit_type: internal; scope set to the internal-audit charter/independence/board-governance cycle for the period) — the workflow instance attaches to that cycle item and writes to it throughout. The internal audit function and its board-approved charter — a Policy item (policy_type: charter) with its own version lineage — already exist and are reviewed, reaffirmed, or amended here, never recreated. The cycle as a decision-aware procedure: the CAE delivers functional reporting to the audit committee, affirms organizational independence in writing and treats any impairment, reviews and reapproves the board mandate and charter with its unrestricted-access provisions, runs the executive session and committee action on the CAE and the plan and budget, executes the stakeholder communication plan, and retains the governance evidence. Consumes upstream: closed assurance-engagement records (Audit items with their linked Issue findings) produced by the individual engagement workflows, the recommendation-tracking register (Issue items), and the prior cycle's carry-forward (open Issue items plus the prior run's carry-forward list). Named deliverables: the CAE functional reporting pack, the written organizational-independence affirmation, the reaffirmed or reapproved audit charter, the audit-committee minutes and resolution records, the stakeholder communication log, and the control-linked governance evidence set. In scope: the board-governance cycle for the internal audit function itself — charter, independence, committee reporting, and stakeholder communication; out of scope: the individual assurance engagements whose results feed the committee report, which run under their own workflows. Terminal by design: no downstream workflow is chained from this cycle; open threads carry forward to seed the next run of this same cycle.
workflow · Context
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
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
Cybersecurity Incident Response
Cybersecurity incident-response cycle as a decision-aware workflow spanning detection and validation, scoping, incident declaration and response-plan activation, containment with evidence preservation, eradication and recovery, POA&M updates for the control deficiencies the incident exposed, and a technical lessons-learned retrospective, closed through a disposition decision and archival. The workflow instance runs on the incident record — an Issue item (issue_type=exception, source=management_identified, severity per the org scheme) created at detection, since the schema has no native Incident type — and enriches that one record through to archival rather than creating duplicates. In scope: security events and confirmed incidents affecting the system boundary and its NIST 800-53 IR-family controls — the detection sources (logging/monitoring Control items, UC-LOG-06), affected systems (Process items, UC-ASSET-11), containment and recovery actions, forensic evidence, the deficiency Issues that become the POA&M, and their linked Risk items. Out of scope: the enterprise incident-management ticketing lifecycle and external breach-notification/legal reporting, which run in their own workflows. Where an Incident Management Lifecycle workflow is running, this cycle consumes its handoff package (initial ticket, reporter, affected systems); it hands the closed incident's control-deficiency findings — the open POA&M Issues (issue_type=deficiency) — to the Continuous Controls Monitoring (ISCM) Cycle as shared items it queries directly.
workflow · Context
IT Asset Inventory & Classification Upkeep
Standing operator workflow for the quarterly IT asset inventory reconciliation and the information and asset classification and labeling review. Anchor: each quarterly run is a workflow instance attached to the EXISTING Control item for the IT asset inventory & classification control (domains asset_management_inventory, frequency quarterly, framework including nist-800-53 / iso-27001 — e.g. control_id CM-8 / UC-ASSET-01) as its operating and execution record; enrich that Control, never create a duplicate. In scope: reconciling the authoritative hardware, software, systems, and services inventory against network, endpoint, cloud, and SaaS discovery scans and change records for the in-scope business units, and reviewing the classification, priority, and labeling of information and associated assets including physical media. Out of scope: the remediation engineering behind a decommission or security investigation (handed to those owners) and the downstream security-scoping processes that consume this cycle's outputs. Upstream: no upstream workflow — the cycle runs on the org's live inventory and discovery systems (external ITAM/CMDB, scanners, change/ticketing) plus the prior run's carry-forward Issue items linked to the anchor Control. Converges on two named deliverables — a signed reconciliation record and an updated classification register with an exported extract; that packaged, dual-signed record is the de-facto handoff package that downstream security-scoping processes consume (there is no named downstream workflow).
workflow · Context
Control Design
This instance runs against the Control item it creates: drafted at the objective step and committed to the Risk & Control Matrix (RCM) at record-the-control, so the archived instance is that control's design audit trail. It consumes no upstream workflow — a control is motivated by an existing Risk item or an audit Issue (finding/deficiency), which it links to rather than rebuilds. Design one new control end to end: control objective and attributes, risk mapping to the register, evidence and test-approach design, RCM record creation, disposition, packaging, and archival. The named deliverable is a new, uniquely identified control record in the RCM (a Control item) carrying a design determination statement, plus its test plan. In scope: designing and recording a single new control so it is operable and testable. Out of scope: executing the control's operating-effectiveness tests and remediating deficiencies, which are handed off downstream to the Security Control Assessment & POA&M Remediation workflow.
workflow · Context
Secure Baseline & Integrity Drift Management
Standing monthly operator workflow for the secure-baseline and integrity-drift cycle: maintain and approve hardening baselines and least-functionality settings against accepted industry standards, run configuration-compliance scanning and remediate drift as findings, triage file-integrity, hash/signature, and secure-boot alerts while verifying security functions self-test correctly, and keep the configuration management plan current annually or after significant environment change. In scope: system components and network security controls governed by CM-2/CM-6/CM-7/CM-9 and SI-6/SI-7 (ISO 27001 A.8.9, PCI DSS Req.1/Req.2, NIST CSF PR.PS-01/DE.CM-09). Out of scope: incident containment and response — unexplained changes are escalated as potentially adverse events to the detect-to-respond incident-analysis practice rather than contained here. Anchor: each monthly run is a recurring workflow instance attached to the EXISTING secure-configuration Control item (the CM-2/CM-6/CM-7 hardening-baseline control — domains=secure_configuration_change_management, frequency=monthly, framework nist-800-53/pci-dss/iso-27001); the cycle enriches that standing Control and never creates a new one. No upstream workflow feeds this cycle — it is self-seeding: its inputs are the prior instance's archived operating record, the approved hardening-baseline standards (Policy items linked to the Control), the open drift/integrity backlog and baseline-reassessment carry-forward (Issue items linked to the anchor Control), and the CM-plan review calendar. Named deliverables: the approved hardening-baseline standards and least-functionality list, the configuration-compliance scan-result register, the integrity-alert and self-test register, drift and corrective-action findings (Issue items linked to the Control), the reviewed configuration management plan (Policy item), the cycle-health dashboard and readiness summary, and the signed, archived cycle operating record. The only cross-workflow handoff is the adverse-event escalation package handed to the detect-to-respond incident-analysis practice.
workflow · Context
ISMS Risk Assessment & Treatment Cycle
Perform an ISO 27005 information security risk assessment and treatment cycle for a defined ISMS scope. The recurring cycle instance attaches to the existing Process item (process_type=security_process) that represents the ISMS scope — enrich that item, never create a duplicate; the risk register it produces is the set of Risk items the run creates and updates. The cycle: establish context and risk criteria, identify information security risks, analyze and evaluate them against the criteria, select treatment options, draft the risk treatment plan, obtain residual-risk acceptance, and retain the documented information. In scope: risk identification through treatment planning and residual-risk acceptance for the ISMS boundary. Out of scope: the Statement of Applicability control-applicability determination and control operating-effectiveness testing, which are handled downstream. This workflow has no upstream workflow — its boundary and inventory are initial inputs: the in-scope business processes are existing Process items, while the asset/information inventory and risk criteria are uploaded documents (no native Asset type). It produces the named deliverables — the current risk register (Risk items), the Risk Treatment Plan (RTP), and the SoA inputs — handed off to the ISO 27001 SoA Review & Controls Assessment workflow.
workflow · Context
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
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
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
Risk Assessment and Treatment Review
Runs on the existing risk item. Assess a risk against current context and evidence, select a supported treatment response, and approve a traceable review record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
SOC 2 Reporting and Management Assertion
Reporting close for the Type II examination: drafting and validating the system description under the carve-out method, preparing the management assertion, reviewing complementary user entity controls and subservice reliance, and the dual-approval close of the examination file at the agreed period end. Management-owned SOC 2 Type II reporting support: system description, management assertion, CUECs, subservice reliance, and auditee file closure. The independent service auditor retains responsibility for examination conclusions and the CPA opinion. Attach this workflow to the existing SOC 2 evidence or reporting process item; retain evidence and conclusions on its workflow steps.
workflow · Context
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
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
Board Risk & Internal Control Oversight Cycle
Board Risk & Internal Control Oversight Cycle as a decision-aware workflow: the governance office verifies board independence and expertise, compiles the board risk & internal-control oversight pack, routes the at-least-annual governance-framework effectiveness evaluation, facilitates the independent board's approval of the risk strategy and material policies, captures and minutes the directed adjustments, and launches and tracks them as an owned open directives register. It is standalone: the governing body and the governance framework are not Studio item types, so there is no natural item anchor — each cycle runs as a fresh recurring workflow instance and its deliverables attach to the run's own steps. The named deliverables are the composition-and-independence summary, the board risk & internal-control oversight pack, the annual governance-and-management-framework effectiveness evaluation when in scope, the adopted board/committee minutes, and the board directives-and-adjustments register (one Issue item per directive, linked across cycles). The risk strategy and material policies the board approves are Policy items (approved_by, version, next_review_date); board directives, approval conditions, and framework adjustments are Issue items (issue_type: observation, source: management_identified). In scope: a single named governing body's quarterly (or specially convened) risk and internal-control oversight meeting and, where the annual clock or a substantial-change trigger applies, that cycle's enterprise governance and management framework effectiveness evaluation. Out of scope: the day-to-day first- and second-line control operation, testing, and assurance that feed the pack — no workflow hands into this cycle, and the board's directives flow onward into control-remediation and policy-update execution as prose, not a wired downstream template.
workflow · Context
Code of Conduct & Workforce Accountability Cycle
Code of Conduct & Workforce Accountability Cycle as a decision-aware workflow that runs on an existing ethics Process item ("Ethics & Code of Conduct Program", process_type: business_process, frequency: annual): each annual cycle is a workflow instance attached to that Process, and the archived instances on it ARE the ethics register - version history plus the open-deviation log. The code of conduct and the rules of behavior are Policy items (policy_type: policy and procedure) enriched each cycle - never recreated - and the tone-at-the-top and acknowledgment Controls (UC-GOV-04, UC-GOV-07) are linked to the Process via item relationships. The cycle reissues the code and rules of behavior, secures leadership adoption, communicates expectations to personnel and business partners, gates access on acknowledgment, and evaluates adherence - routing violations through the documented disciplinary process and remediating deviations timely, with deviations and violations recorded as Issue items carrying the full remediation lifecycle. Named deliverables: the reissued code of conduct and rules of behavior (Policy items plus redline/change summary), the leadership adoption decision, the acknowledgment coverage report with access-gating evidence, the deviation and violation inventory (Issues), the disciplinary and remediation outcomes, and the archived self-contained cycle evidence package. In scope: one annual accountability cycle (a full reissue or an update-driven re-acknowledgment) covering all in-scope personnel and the business-partner populations bound by the code. Out of scope: the ethics-hotline intake that feeds reported concerns - an input, not a step here. No upstream workflow is required to start the cycle; it is triggered by its annual cadence or by a material change to the code or rules of behavior. Downstream, the operational access-provisioning system consumes this cycle's acknowledgment gate - the workflow's terminal handoff - before it grants access.
workflow · Context
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
Enterprise Risk Treatment Operations Cycle
Enterprise Risk Treatment Operations Cycle as a decision-aware workflow: it runs the documented risk methodology each cycle - identification and analysis of risks and opportunities, evaluation and prioritization against risk criteria, treatment selection and tracking for risks exceeding tolerance with residual re-evaluation, and risk-register and portfolio reporting to management and the board - triggering dynamic reassessment when internal or external change shifts the risk profile. This cycle has no anchor item of its own: the enterprise risk register it maintains IS the Risk item population, and the workflow instance is the cycle record and durable audit trail. In scope: entity-level and process-level risk across the enterprise, explicitly including cybersecurity, privacy, and financial-reporting risk alongside operational and strategic risk and opportunity. Out of scope: detailed control design and testing, which downstream control workflows own - a mitigate or share/transfer plan that creates or strengthens a control hands that work off to those workflows, which anchor on the affected Control items. This cycle has no upstream workflow feeding it; its starting inputs are the documented methodology, the consistent likelihood/impact scoring scales, the board-approved risk criteria and appetite/tolerance statements, and the risk-acceptance delegation matrix - all carried as Policy items - plus the existing control, insurance and transfer information (Control items and step documents) and the prior cycle's Risk register. Named deliverables: the maintained enterprise risk register (the Risk items), the prioritized risk heat-map dashboard, and the management and board portfolio report package.
workflow · Context
Risk Communication, Reporting & Performance Review
Risk Communication, Reporting & Performance Review as a decision-aware workflow that runs each quarter or on an out-of-cycle significant matter. Because none of the eight Studio item types represents the ERM reporting cycle itself, the workflow instance IS the durable record: its named deliverables - the tiered internal and external risk, control and performance reporting package, the event-driven report on a significant matter, the management-signed risk-and-control performance-review pack, and the tracked improvement actions - attach to its steps, its item-level writes land on the existing Risk, Control, and Issue items (improvement actions are tracked as Issues with source: self_assessment); control-testing results are read from SOX testing workflows hosted directly on the relevant Controls; and the risk-management framework is read as its Policy item (policy_type: charter) for the evaluation baseline and the suppliers and third parties consulted as their Vendor items. In scope: stakeholder consultation across every risk-process step (identification, assessment, response, monitoring) including suppliers and third parties; the cadenced internal and external reporting package; event-driven reporting on significant matters; the periodic review of risk-management and internal-control performance against the framework's design intent with accountable management; and converting lessons into owned, tracked improvement actions. Out of scope: running the underlying risk assessments, control testing, or business-performance measurement themselves - this workflow consumes their results as inputs. It starts on its own trigger (the quarterly cadence or a significant event) and has no upstream feeder workflow and no named downstream handoff workflow; each run's close-and-archive leaves the stakeholder, risk, and improvement registers current - the informal handoff both to the next cycle of this workflow and to the downstream risk-assessment and control-testing workflows whose results this cycle consumes.
workflow · Context
Enterprise Risk Assessment & Portfolio Oversight Cycle
Second-line ERM oversight cycle. Each run is anchored to a cycle Audit item created for the period (audit_type: operational, scope = the assessment boundary, period_start/period_end = the cycle window, report_date = the approval date); the workflow instance attaches to it as the durable audit trail, and the enterprise Risk items are the register it assesses and updates in place. Establish the assessment context (scope, criteria, appetite, scoring calibration), identify risks, score inherent and residual severity, select responses, publish the portfolio view, and route the package through disposition and governance approval. In scope: enterprise-level risk identification, assessment, response selection, and portfolio reporting for the current cycle. Out of scope: defining the board-approved risk appetite statement itself and preparing the board reporting deck, which are handled by downstream workflows. Consumes the prior-cycle risk-register handoff package (the existing Risk items plus the linked register document) from the Enterprise Risk Register Lifecycle workflow, and hands its named deliverables — the residual portfolio view (dashboard), the risk-movement narrative, and the approved assessment package — to the Risk Appetite Definition & Board Reporting and Quarterly Board & Audit-Committee GRC Reporting workflows.
workflow · Context
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
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
Emerging Risk & Horizon Scan
Runs on the existing risk item. Scan the forward horizon for signals of an emerging exposure, assess plausibility and velocity, and decide whether it enters the register or stays on the watchlist. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
ESG-Related Risk Materiality & Integration
ESG-Related Risk Materiality & Integration as a decision-aware workflow. Each cycle runs on the existing portfolio-level ESG Risk item (a Risk with category: esg — e.g. "ESG / sustainability risk — enterprise"): it enriches that umbrella entry and the ESG-tagged slice of the Risk register (Risk items tagged category: esg / taxonomies: esg_sustainability) rather than recreating them, and fans per-topic detail out onto the individual Risk items it creates or updates for each impact, risk, and opportunity (IRO). In scope: assessing ESG-related risks across the confirmed environmental, social, and governance topics, entities, and value-chain boundary for this cycle — defining the ESG risk universe (impacts, risks, opportunities), engaging affected stakeholders and information users, assessing double materiality and prioritizing the material topics, mapping controls and management responses, defining KRIs and disclosure metrics, and assembling disclosure inputs. Its named deliverables are the double-materiality assessment (the ranked material topic set with a materiality matrix), the control/response and assurance mapping, the disclosure metrics and leading KRIs, and the framework-mapped disclosure index (ESRS/CSRD, ISSB S1/S2, GRI, SEC climate). Out of scope: any ESG topic, entity, or business unit not named in this cycle's confirmed scope, and the drafting of the external sustainability report itself. It consumes the enterprise risk portfolio and residual positions from the upstream Enterprise Risk Assessment & Portfolio Oversight Cycle and hands its material ESG topics, KRIs, and disclosure inputs to the downstream Quarterly Board & Audit-Committee GRC Reporting workflow rather than duplicating repeated work.
workflow · Context
Incident Management Lifecycle
Run the enterprise incident management lifecycle on a single governed incident record — an Issue item created at intake that every step enriches (there is no separate Incident type; the workflow instance anchors to that Issue). Open the record, analyze scope and impact, anchor the regulatory and remediation notification clocks to the detection date, contain/eradicate/recover, execute severity-based notifications, run lessons-learned and CAPA, classify the disposition, then prepare, hand off, and archive the governance package. Named deliverables: the scope-and-impact assessment, the root-cause analysis, the owned CAPA / remediation action plan, and the final evidence-and-decision governance package. In scope: operational and security incidents from detection through closure, including regulatory-notification clock management and corrective/preventive actions. Upstream: the incident originates on detection itself, but for a security-category incident this workflow consumes the containment-and-forensics handoff package produced by the Cybersecurity Incident Response workflow (linked in at the eradicate-and-recover step) rather than re-running SOC triage. Out of scope: real-time SOC triage and containment mechanics (owned by that Cybersecurity Incident Response workflow) and board-level reporting — the final governance package is handed off to the Quarterly Board & Audit-Committee GRC Reporting workflow, which reports the outcome without re-investigating.
workflow · Context
Policy Lifecycle Management
Run one policy through its full lifecycle, anchored to a Policy item in the policy library — created at authoring for a net-new policy, enriched in place on each refresh cycle (never duplicated). In scope: authoring and control/authority linkage, stakeholder review, formal approval, publication and workforce attestation, acknowledgement tracking, disposition, and scheduled alignment refresh. Consumes read-only upstream: the enterprise risk assessment (Risk items), control design (Control items), and obligation mapping — this workflow neither produces nor edits them. Produces four named deliverables: the published policy version, a frozen workforce attestation completion record, a section-by-section alignment verdict, and a single approval-ready policy package. Out of scope: enterprise risk assessment, control design, and obligation mapping. The approved policy package is handed off to the Regulatory Compliance Attestation Cycle, which runs the recurring regulatory attestation; the acknowledgement campaign launched here is the one-time publication attestation and is explicitly flagged in the handoff as not-to-be-repeated downstream.
workflow · Context
Privacy Breach Assessment & Notification
Personal-data breach response, anchored on a breach-register Issue item created for the breach (issue_type: exception, source: management_identified, identified_date = the awareness timestamp); the workflow instance attaches to that Issue and the breach register is the queryable set of these Issues. Consumes the Incident Management Lifecycle workflow's handoff package (incident record, containment status, investigation timeline) and drives it from handoff to closure: a frozen, dated exposure inventory; a per-jurisdiction notifiability determination against GDPR Article 33, US state (California/CCPA included), and HIPAA clocks; regulator and data-subject notifications with milestone tracking; processor coordination against the processor's Vendor record and DPA; remediation and support Issue items; the Article 33(5) breach-register entry; and a post-breach review that hands off to the DPIA / Privacy Impact Assessment workflow for each affected processing activity. In scope: the notifiability judgment and notification execution downstream of the incident handoff; out of scope: incident containment and forensics, which stay with incident response.
workflow · Context
Regulatory Change Intake & Impact Assessment
Runs on the existing requirement item. Validate a new or amended external obligation against its authoritative source, determine applicability, and assess the impact on controls, policies, processes and systems. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
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 Horizon Scanning & Triage
Regulatory Horizon Scanning & Triage as a modular, decision-aware workflow. Each cycle runs on an Audit item created for the scan window — `audit_type` = compliance, titled "Regulatory Horizon Scanning — <period>", with `period_start`/`period_end` set to the detection window; the workflow instance attaches to that Audit and is archived against it at close. It can stand alone, but is designed to exchange handoff packages with related workflows instead of duplicating repeated work. In scope: detecting and summarizing regulator publications, routing them to the authority-source register, applicability screening against the compliance profile, entity profile, and activity inventory, owner assignment, and queueing. Out of scope: obligation mapping, gap and impact analysis, and implementation — those belong to the downstream Regulatory Impact Analysis & Obligation Mapping workflow, which consumes this workflow's named deliverables: the prioritized impact-analysis intake queue and the cycle evidence package. There is no upstream workflow and no prior handoff to consume; this is the sensing edge of the regulatory-change chain, and its standing inputs are the monitored feed list, the prior cycle's cursor, the authority-source register, and the Policy items that cite those authorities.
workflow · Context
Regulatory Impact Analysis & Obligation Mapping
Regulatory Impact Analysis & Obligation Mapping runs on a compliance Audit engagement record — an Audit item created per triggering instrument (audit_type=compliance) whose scope holds the locked scope statement and to which every gap Issue, risk acceptance, and the workflow instance attach. It consumes two upstream inputs: the triage handoff package from Regulatory Horizon Scanning & Triage (instrument, canonical citation, publication and effective dates, triage disposition) and the canonical instrument text itself — the Official Journal or regulator-register version, the authoritative source the whole analysis cites. It parses that instrument into obligations, maps them to the existing Policy and Control library, classifies and rates gaps, and reconciles the obligation register. Named deliverables: the cited regulatory impact note, the obligation inventory, the authority-to-policy crosswalk, the classified and rated gap Issues, the versioned obligation register, and the final evidence and decision package. In scope: obligation analysis, crosswalk, gap classification, exposure rating, and register reconciliation for the in-scope entities, products, and jurisdictions. Out of scope: remediation build-out (handed off to Regulatory Obligation Implementation) and re-prioritizing the instrument (owned by Regulatory Horizon Scanning & Triage). Confirmed gaps and their action plans hand off to Regulatory Obligation Implementation.
workflow · Context
Annual ICFR Scoping & Risk Assessment
Runs on the fiscal year’s existing SOX Audit, using financial balances, prior-year RCM and deficiency history, business changes, and the approved IA plan. Produces the Fiscal Year Audit Scope Memo, Risk & Control Matrix, approved workplan, kickoff records and recipient-specific annual communications for process walkthroughs and control testing.
workflow · Context
Fraud Risk Assessment & Anti-Override Control Review
Runs on an Audit item created for the cycle (audit_type internal or sox_testing; scope = "Annual fraud risk assessment & anti-override review FYxx"; period_start/period_end = the assessed period). The workflow instance attaches to that Audit, which is the cycle's durable record - a fresh Audit per cycle keeps successive years separable; the workflow enriches it, it does not create a duplicate. Covers the fraud triangle across fraudulent reporting, asset misappropriation, and corruption, the explicit assessment of management override risk, anti-override control recalibration (journal-entry review criteria and significant-estimates scrutiny), and audit committee reporting. Consumes upstream: the prior-period fraud risk register (Risk items, category financial_reporting, with their inherent_rating/residual_rating/treatment and dispositions) as the baseline; the SOX-scoped Process population; in-period Issue signals (deficiencies, findings); and the existing Control inventory - specifically the journal-entry-review and significant-estimates-challenge Control items whose description/frequency/control_owner hold the current criteria. In scope: the current SOX-scoped entity and process population, judged against the prior-period baseline; an event-triggered refresh scopes to the affected entities and fraud vectors, not automatically the whole map. No upstream workflow feeds this cycle - it originates from the prior-period assessment and interim events since. Named deliverable: the fraud risk assessment report and the audit committee package (fraud risk register, heat map, the explicit management-override determination, and the recalibrated anti-override control specification). Hands off to the journal-entry-review and significant-estimates control operators, who run the recalibrated anti-override controls; accepted residual risks persist as Risk items (treatment accept) that seed the next annual cycle's baseline.
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 Scoping Decision
Runs on the existing Process item for the one business process under decision — it enriches that Process item and the Control and Risk items in its RCM, never creating a duplicate. Determine whether the process is SOX-relevant and, if so, scope its key controls — otherwise document the exclusion. Consumes the Annual ICFR Scoping & Risk Assessment handoff package (accepted materiality set, scoping thresholds, aggregation floor). Named deliverables: the assessment worksheet, the SOX-relevance determination memo, the resulting Risk & Control Matrix (RCM) scope (Control and Risk items with live links), and the exclusion memo — compiled into a signed scoping decision package. Hands that signed package off to the downstream SOX Process Walkthrough for the in-scope slice, or routes a full exclusion into the annual monitoring/refresh cycle. Out of scope: entity-level materiality, significant accounts, and fraud-risk assessment, which are owned by the upstream Annual ICFR Scoping & Risk Assessment, and process understanding and control verification, which are owned by the downstream SOX Process Walkthrough.
workflow · Context
SOX Process Walkthrough
Runs on the existing Process item being walked (process_type=financial_reporting) — one workflow instance per walkthrough unit (process × location × variant), with the SOX program's Audit item (audit_type=sox_testing) linked as engagement context. It enriches that Process item and seeds its controls; it never creates a duplicate process. Consumes upstream: the significant-account and location scoping baseline, which it takes as a handoff package from the SOX Scoping Decision workflow rather than re-deriving. Produces the named deliverables: the documented process understanding, the identified key controls and their attributes, the control-to-risk mapping (the Risk & Control Matrix, RCM), the walkthrough memo (which doubles as the process's standing narrative), and draft Control records seeded into the register. Out of scope, owned downstream: design-effectiveness conclusions, sampling, and control testing — the handoff splits the control population so confirmed-design controls go to the SOX Key Control TOD/TOE Test workflow and open-design-gap controls go to the Control Design workflow first. It can stand alone but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.