EU NIS2
60 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
NIS2-Art20 — Governance and management body accountability / training
Governance and management body accountability / training
control · Direct
NIS2-Art21a — Policies on risk analysis and information system security
Policies on risk analysis and information system security
control · Direct
NIS2-Art21b — Incident handling
Incident handling
control · Direct
NIS2-Art21c — Business continuity, backup management and disaster recovery, crisis management
Business continuity, backup management and disaster recovery, crisis management
control · Direct
NIS2-Art21d — Supply chain security
Supply chain security
control · Direct
NIS2-Art21e — Security in acquisition, development and maintenance of network and information systems (incl. vulnerability handling and disclosure)
Security in acquisition, development and maintenance of network and information systems (incl. vulnerability handling and disclosure)
control · Direct
NIS2-Art21f — Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
control · Direct
NIS2-Art21g — Basic cyber hygiene practices and cybersecurity training
Basic cyber hygiene practices and cybersecurity training
control · Direct
NIS2-Art21h — Policies on the use of cryptography and encryption
Policies on the use of cryptography and encryption
control · Direct
NIS2-Art21i — Human resources security, access control policies and asset management
Human resources security, access control policies and asset management
control · Direct
NIS2-Art21j — Use of multi-factor authentication, secured communications and emergency communication systems
Use of multi-factor authentication, secured communications and emergency communication systems
control · Direct
NIS2-Art23 — Reporting obligations (early warning 24h, incident notification 72h, final report 1 month)
Reporting obligations (early warning 24h, incident notification 72h, final report 1 month)
risk · Context
GPAI transparency, systemic-risk and synthetic-content obligations
GPAI providers failing transparency/copyright/training-data obligations; systemic-risk models (>10^25 FLOPs) lacking red-teaming, incident reporting, and cybersecurity; unlabeled deepfake/synthetic content; and concentration of GPAI capability creating ecosystem single points of failure.
risk · Context
AI supply-chain compromise and provider concentration
Because the organization relies on third-party pretrained models, datasets, and libraries that may carry backdoors, malicious code, or bias, and concentrates on a few external AI API providers, AI-dependent workflows are exposed to both supply-chain compromise and provider outage or insolvency, resulting in compromised model behaviour or sudden loss of AI capability.
risk · Context
Improper business or market practices
Losses from antitrust violations, market manipulation (spoofing, layering, front-running), benchmark/rate rigging, unlicensed business activity, and sanctions/export-control violations in the conduct of business.
risk · Context
Litigation, investigation and enforcement exposure
Adverse judgments, class actions, contract/IP disputes, government subpoenas, DOJ/FTC/SEC investigations, consent decrees, or deferred-prosecution agreements imposing penalties, remediation, and management distraction.
risk · Context
Lack of independent audit and compliance review
Because independent internal and external audit and review of information security are not performed, control deficiencies and non-conformities are neither detected nor challenged, so weaknesses persist unremediated and management and the board lose reliable assurance over control effectiveness.
risk · Context
Climate transition risk — carbon pricing and stranded assets
Carbon taxes, cap-and-trade, and mandatory Scope 1-2-3 reporting increase operating costs or strand carbon-intensive assets; failure to credibly plan a net-zero transition jeopardizes access to capital and changing consumer preferences.
risk · Context
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
Internal fraud — asset misappropriation, embezzlement, forgery
Employees defraud the entity for financial gain: embezzlement or theft of company/client funds, fraudulent expense/payroll claims, forgery to obtain unauthorized disbursements, bribery/kickback schemes, insider trading on own account, and wilful tax evasion.
risk · Context
Inadequate board and management oversight of risk and control
Because board and management oversight of risk and control is weak - unclear tone at the top, ineffective board composition or independence, poor committee structure, and limited senior-management commitment - control priorities are not enforced and resources are withheld, so risks accumulate unmanaged and control failures go uncorrected across the entity.
risk · Context
Missing or insufficient security and privacy policies
Because documented, approved, and enforced security and privacy policies are missing and roles and duties are undefined, personnel operate without guidance on required controls and behaviours, so controls are applied inconsistently and accountability gaps leave violations undetected and unaddressed.
risk · Context
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
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
Critical vendor failure, insolvency or concentration
A key supplier, SaaS provider, or outsourced partner becomes insolvent, exits the market, or suffers a prolonged outage; sole-source and shared-tier concentration (multiple tier-1 vendors on a common tier-2) creates hidden single points of failure with no backup.
risk · Context
Supply-chain disruption of critical inputs
Geopolitical events, natural disasters, port congestion, or logistics failures interrupt supply of critical raw materials or components (semiconductors, rare earths); just-in-time models are exposed to demand spikes.
risk · Context
Third-party compliance failure creating vicarious liability
A vendor, subcontractor, or channel partner violates labor, environmental, anti-bribery (FCPA/UKBA), or data-protection rules, exposing the company to liability and reputational harm; fourth-party/N-tier dependencies are opaque.
risk · Context
Vendor/outsourcing service non-performance and disputes
Outsourced processing, IT, payroll/HR, print/mail, or sub-custodian providers fail to meet service levels, deliver defective software, make incorrect payments, or breach contractual deliverables, causing processing errors, outages, and loss.
risk · Context
Weak supplier security requirements and monitoring
Because supplier contracts omit security requirements and SLAs and third-party service delivery is not monitored, processors and sub-processors operate without equivalent, audited obligations, so third-party weaknesses and breaches propagate into the organization undetected.
standard · Direct
EU NIS2
EU NIS2 Directive
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-14 — Establish and maintain approved security policies and procedures
Establish, approve, publish, and maintain the organization's information-security policy suite as a governed whole: a top-level policy plus the topic-specific policies, each with an accountable owner, board/management approval, planned review cycles, and communication to relevant parties. Domain-specific policy content is governed by its own unified control; this objective owns the suite-level lifecycle (inventory, approval chain, review cadence, communication, exceptions).
unified · Context
UC-GOV-22 — Assess control effectiveness and authorize systems
Maintain a documented assessment and authorization policy with procedures, defined performance measures, and quality monitoring to regularly evaluate whether security policies, standards, and risk-management measures are implemented, complied with, and effective — including managers' reviews of compliance within their areas of responsibility. Feed assessment results into a formal, risk-based authorization process in which a senior official explicitly accepts residual risk before systems operate and at defined intervals thereafter, and track findings to closure.
unified · Context
UC-GOV-24 — Notify regulators of incidents and file required certifications
Maintain documented procedures to notify supervisory and regulatory bodies of reportable cybersecurity events within mandated regulatory timelines, including any staged early-warning, detailed-notification, and final-report deadlines, and to submit required periodic compliance certifications and filings. Handle regulatory submissions and related materials confidentially, and retain evidence of all notifications, certifications, and supporting records.
unified · Context
UC-GOV-29 — Maintain secure acquisition, development, and maintenance policies
Establish, document, and disseminate policies and procedures governing security in system and services acquisition, in-house application development, configuration management, and system maintenance — including secure development standards, evaluation criteria for externally developed applications, and baseline configuration requirements. Review, assess, and update these policies and procedures at least annually under accountable security leadership and after significant changes.
unified · Context
UC-GOV-31 — Maintain access control, identity, and personnel security policies
Establish, document, and disseminate policies and procedures governing logical access control, identification and authentication, and personnel (human resources) security — covering authorization based on need-to-know and least privilege, credential and authenticator management, and personnel screening, transfer, and termination requirements. Communicate these policies to the workforce and review and update them at defined intervals and upon significant change.
unified · Context
UC-GOV-32 — Maintain security awareness and cyber-hygiene policies
Establish, document, and disseminate policies and procedures for security awareness, training, and basic cyber-hygiene practices applicable to all personnel, defining required content, frequency, audiences, and completion tracking. Review and update the policy and program requirements at defined intervals and in response to changes in threats and incidents.
unified · Context
UC-GOV-34 — Maintain business continuity and contingency planning policy
Establish, document, and disseminate contingency planning policy and procedures, identify risks arising from potential business disruptions — including to critical infrastructure and essential services — and select and develop mitigation activities (including consideration of insurance and other risk transfer) proportionate to those risks. Review and update the policy and the mitigation portfolio at defined intervals and after significant disruptions.
unified · Context
UC-GOV-35 — Maintain incident response policy and procedures
Establish, document, and disseminate an incident response policy and supporting procedures that define what constitutes a security incident, roles, responsibilities, and authorities, and requirements for detection, internal reporting, handling, escalation, and post-incident review. Review and update the policy and procedures at defined intervals and after significant incidents or exercises.
unified · Context
UC-GOV-36 — Maintain communications security and cryptography policies
Establish, document, and disseminate policies and procedures for system and communications protection, including the required use of cryptography and encryption, secured communication channels, and multi-factor and strong authentication expectations for remote and privileged access. Review and update these policies at defined intervals and as cryptographic standards and threats evolve.
unified · Context
UC-TPRM-01 — Operate a third-party security risk management program
Establish and operate a management-approved third-party and supply-chain risk management program with a written strategy, policies, and procedures, reviewed at defined intervals and after significant changes to the supply chain or threat landscape. Define and communicate roles and responsibilities for supplier, customer, and partner relationships, and integrate third-party and supply-chain risk into enterprise and cybersecurity risk management. Maintain a register of third-party relationships and contractual arrangements prioritized by criticality, and assess criticality, substitutability, and concentration risk before contracting. Apply risk-based due diligence, embed security requirements, audit and access rights, termination rights, and sub-outsourcing conditions in agreements, and protect organizational information processed, stored, or transmitted on external systems. Define, agree, and periodically review service agreements and supplier performance, reassess third parties on a defined cycle, operate controls to identify and address weaknesses across the relationship life cycle, and maintain documented, tested exit strategies for providers supporting critical or important functions.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
Third-Party Vendor Assurance Engagement
Runs on the existing Audit item for this engagement (audit_type=vendor_review) — the workflow enriches that already-planned engagement record, it never creates a duplicate — consuming the confirmed scope, criteria, and calendar handed off from Audit Engagement Planning. An IA-led third-party vendor assurance engagement that concludes on the design and operating effectiveness of the organization’s TPRM program — governance, risk tiering, vendor control-environment reliance, monitoring, exclusions, and reporting. Vendors under test are the existing Vendor items, each finding is an Issue item, and the named deliverable is a reperformable engagement workpaper package. In scope: assuring the program (IA evaluates management’s third-party risk management; it does not operate it). Out of scope: operating the vendor lifecycle (onboarding, tier refresh, remediation), which belongs to the second-line Third-Party Vendor Risk Lifecycle workflow; deep single-report SOC work, which can be delegated to the reusable Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow; and ICT arrangements caught by regulatory regimes, which route to Third-Party ICT Vendor Regulatory Assurance. Findings and the engagement conclusion exit through Audit Report Drafting, and action plans route to Finding Remediation & Action-Plan Monitoring.
workflow · Context
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
Security Policy Suite Review
Standing operator workflow for the security policy owner's annual (and change-triggered) review, redline, reapproval, and dissemination of the full security policy suite -- secure acquisition/development/configuration-management/maintenance, asset/media/physical protection, access/identity/personnel security, communications/cryptography, security awareness and cyber-hygiene, audit-logging/monitoring/system-integrity, contingency planning and disruption mitigation, and incident response. Anchor: each run is a workflow instance attached to the existing "Security Policy Management" Process item (process_type=security_process, process_owner=policy owner, frequency=annual) -- that instance IS the cycle record the tracked review items roll up to; the eight policy families are the existing Policy items the cycle enriches (never recreates). In scope: reviewing each Policy item against current risk and threat inputs, consolidating findings into one suite-level revision disposition, routing redlines to the right stakeholders, reapproving under accountable security leadership (writing Policy.approved_by / version / effective_date / next_review_date back onto each policy), and tracking dissemination and workforce acknowledgment as a single evidence set. Out of scope: authoring net-new policy domains and operating the technical controls the policies govern. The workflow has no upstream feeder workflow -- its inputs are the policy register (the eight Policy items), the prior-cycle workflow instance and its exported operating record, and the annual review calendar carried on Policy.next_review_date -- and no named downstream workflow; open corrective actions (Issue items) carry forward as explicit inputs to the next cycle. The eight domain reviews run in parallel and converge on a single revision-disposition decision.
workflow · Context
Security Control Assessment & POA&M Remediation
Run this assessment on the EXISTING Audit item for the engagement (audit_type: it_audit or compliance) — enrich that record, never create a duplicate: Audit.scope carries the authorization boundary and Audit.period_start/period_end the assessment window. Consumes, from the upstream SSP-development / system-categorization effort, the approved System Security Plan (SSP), the FIPS 199 system categorization, and the tailored NIST 800-53 baseline (existing Control items, framework: nist-800-53). Assess each in-scope control with 800-53A examine/interview/test methods, record satisfied / other-than-satisfied determinations, open a POA&M Issue for every gap, re-validate remediation, and issue the Security Assessment Report (SAR). In scope: control assessment, determinations, the POA&M lifecycle, and the SAR for the authorization boundary agreed at kickoff. Out of scope: the authorization (ATO) decision itself and the steady-state continuous-monitoring cadence. On completion, the frozen SAR and POA&M package are handed to the NIST RMF System Authorization (ATO) Cycle.
workflow · Context
ISO 27001 Stage 1 ISMS Documentation Review
Certification-body Stage 1 review of the ISMS against ISO/IEC 27001:2022 clauses 4–10: context and leadership, planning and support, operation, and performance evaluation with improvement - walking each clause group against the governing documents and the operating processes that carry it, and concluding Stage 2 readiness with dual sign-off. Stage 1 documentation and readiness review for ISO/IEC 27001:2022 clauses 4–10, conducted under the engagement methodology. It informs Stage 2 planning and does not issue a certification decision. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
ISO 27001 Stage 2 Annex A Controls Audit
Attach to the existing Audit engagement, owned by Internal Audit, using its approved Statement of Applicability, risk treatment plan, scope, review period and operating evidence; produce the Stage 2 Annex A Controls Audit report, four signed theme conclusions and finding register for the engagement and remediation owners. Apply the approved Statement of Applicability to ISO/IEC 27001:2022 Annex A.5.1–A.5.37, A.6.1–A.6.8, A.7.1–A.7.14 and A.8.1–A.8.34; document each exclusion and assess direct and inherited responsibilities. This Annex A assessment contributes to the engagement and does not independently establish full ISMS conformity or issue certification. Stage 1 and readiness remain separate workflows; any certification decision remains with the authorized certification body.
workflow · Context
Annual Policy Review
Runs on the existing policy item. Canonical annual policy review: establish scope, obtain the policy owner and policy team sign-offs, record any required change path, and approve a documented review outcome and next review date. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Policy Change
Runs on the existing policy item. Canonical policy-change governance: scope and propose a controlled change, obtain policy-team approval, publish only the approved version, and close with a traceable document and communication record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Quarterly Board & Audit-Committee GRC Reporting
Runs on the existing standing "Board & Audit-Committee GRC Reporting" governance Process item (process_type=business_process, frequency=quarterly): one workflow instance per quarter attaches to that Process and enriches it (the Process is not created here), and each closed instance is the prior-quarter baseline for the next run. The named deliverable is the quarterly board & audit-committee GRC pack (six-domain narrative deck, Word + PDF, redaction-cleared). It compiles that pack across six domains — risk profile, control health, open issues, regulatory deadlines, audit-plan progress, and SOX posture — computed over one quarter window. In scope: aggregating and synthesizing existing GRC records (Risk, Control, Issue, Audit, and Control-hosted SOX testing workflows) into a board-level narrative, obtaining executive and committee approval, and archiving the decision and action register. Out of scope: performing the underlying risk assessments, audits, or control tests themselves. Consumes two upstream handoff packages: the Enterprise Risk Assessment & Portfolio Oversight Cycle package (risk register, residual scores, appetite positions) and the Audit Report Drafting & Regulatory Compliance Attestation Cycle package (audit-plan status, issued reports, attestation status); there is no downstream workflow — the closed package feeds the next quarterly run of this workflow.
workflow · Context
Risk Appetite Definition & Board Reporting
Define enterprise risk appetite statements, tolerances, and KRIs, secure executive and board approval, monitor actuals against tolerances, and report the appetite position to the board. Runs as a standalone recurring instance per appetite cycle (typically annual): appetite spans the whole Risk register rather than a single item, so the register, tolerance and KRI matrix, monitoring workbook, and reporting pack attach to the workflow instance's steps as the versioned documents of record, with the existing Risk items as the linked reference data and KRI breaches recorded as Issue items (issue_type: exception, linked to their Risk). In scope: appetite-statement definition, tolerance and KRI design, executive validation, board approval, ongoing monitoring, and ERM board reporting. Out of scope: the enterprise-wide risk identification and scoring that produces the risk universe, and the assembly of the full quarterly board deck. Consumes the risk-assessment handoff package from the Enterprise Risk Assessment & Portfolio Oversight Cycle (the risk universe as Risk items plus inherent and residual ratings) rather than re-deriving it, and hands the board-approved appetite package to the Quarterly Board & Audit-Committee GRC Reporting workflow.
workflow · Context
Third-Party Vendor Risk Lifecycle
Operate the third-party vendor risk lifecycle end to end: scope and tier the vendor population, gather and analyze assurance evidence (SOC reports and CUECs, plus C-SCRM controls), embed contractual protections, enroll ongoing monitoring, and reach a governed disposition and approval. The vendor register IS the set of Vendor items — tiered by criticality (tier) and data exposure (data_classification), owned (business_owner, risk_owner), and driven by reassessment_cadence with last/next assessment dates and monitoring_status; each assessment cycle runs as one workflow instance over that register. In scope: vendor and supplier third-party risk assessment, onboarding controls, and periodic reassessment. Out of scope: procurement sourcing and commercial negotiation, and the deeper fieldwork of a Third-Party Vendor Assurance Engagement, to which the approved package is handed off. This workflow is self-initiating and consumes no upstream workflow package.
workflow · Context
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
Third-Party Risk Program & Vendor Oversight Cycle
A standing quarterly cycle the vendor-management office runs as control owner. The workflow instance is a recurring run attached to the EXISTING Process item "Third-Party / Vendor Risk Management" (process_type: operational, process_owner: Vendor Risk Program Lead, frequency: quarterly), linked to the Control items for the unified controls it operates (UC-TPRM-01/04/05/08) — it enriches that standing program, never recreating it. It consumes no upstream workflow handoff: each run is self-feeding, drawing its criteria and prior state from the program's own standing artifacts — the SCRM plan, third-party risk policy, and program strategy held as Policy items; the criticality-tiered Vendor register (Vendor items); and the prior cycle instance's step documents (the DORA Article 28(3) register of information and the ICT concentration-risk view). In scope: reaffirming or revising the governing Policy items; re-tiering the Vendor register; refreshing the DORA Article 28(3) register of information and the concentration-risk view (a dashboard over the Vendor items); verifying critical-provider exit strategies; executing this cycle's tier-based reassessments and driving findings to tracked third-party Risk items (remediation or risk-committee escalation); confirming external and cloud service provider oversight; and verifying critical suppliers carry live incident-notification coverage. Named deliverables: the refreshed criticality-tiered Vendor register, the updated DORA Article 28(3) register of information, the recomputed ICT concentration-risk view, the exit-readiness summary, this cycle's tracked Risk items, and the archived cycle evidence package on the workflow instance. Terminal at close-and-archive with no downstream handoff — open or escalated vendor risks persist as Risk items in the risk register. Out of scope and handled by separate workflows: the continuous monitor-line vendor lifecycle and the per-engagement due-diligence gate for onboarding a new vendor.
workflow · Context
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
Regulatory Compliance Attestation Cycle
Regulatory Compliance Attestation Cycle: runs on and enriches the existing Audit item created for this authority and reporting period (audit_type = compliance or regulatory_exam; scope = certification boundary; period_start/period_end = the reporting period) — that Audit item is the attestation record the cycle updates throughout, never a duplicate. Over the cycle: compile evidence for the authority source across the reporting period, validate and resolve evidence gaps, produce the five-section regulatory attestation package, route certifying-officer certification, and archive the package. In scope: the legal entities, products, geographies, and systems named in the certification boundary for that authority and period. Consumes the implemented, owned, control-mapped obligation baseline as the handoff package from the Regulatory Obligation Implementation workflow (the implementations themselves are the Control items whose framework multiselect includes this authority, linked to the anchor Audit). Out of scope: obligations under other authorities, entities outside the certification boundary, and the obligation-to-control implementation itself. Hands the certification outcome, exception register, action plans, and accepted risks off to Quarterly Board & Audit-Committee GRC Reporting.
workflow · Context
Regulatory Obligation Implementation
Implement a new or changed regulatory obligation end to end on the Audit item created for this implementation (audit_type = compliance or readiness): its scope names the obligation and authority, its period_end holds the effective (compliance-by) date, and the workflow instance attaches to it. There is no native Regulation type, so the regulator, region, and obligation summary live in the anchor Audit.description with the operative source text uploaded to the gap-analysis step. The work — gap analysis, policy updates (Policy items), control design (Control items), process operationalization (a Process item), and coverage validation — enriches that Audit rather than creating a parallel record. In scope are the legal entities, products, systems, and vendor relationships (Vendor items) the obligation touches; entities and processing below the regulation's applicability thresholds are out of scope. This workflow consumes the obligation map handed off from Regulatory Impact Analysis & Obligation Mapping and hands its named deliverable — a validated coverage package (the gap list, the drafted policies and controls, the operationalized process, and the validation run) — to the Regulatory Compliance Attestation Cycle.
workflow · Context
Third-Party ICT Vendor Regulatory Assurance
Third-Party ICT Vendor Regulatory Assurance as a decision-aware workflow. Each cycle runs on its own Audit engagement item (audit_type = vendor_review) created at kickoff, with Audit.scope set to the in-scope legal entities, regimes, and vendor population; every workpaper, decision form, and gap attaches to that instance. In scope: ICT third-party service providers — including intra-group ICT providers — assessed against DORA, NIS2, and US interagency/FFIEC third-party expectations; out of scope: non-ICT vendors, which stay with the general vendor lifecycle. It consumes the arrangement-level inventory, tiering, and due-diligence handoff package from Third-Party Vendor Risk Lifecycle (whose provider records are the Vendor items); refers vendor SOC 1/SOC 2 reports carrying real reliance to the Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow and folds back its reliance conclusions; and produces a provision-cited, severity-rated gap register (Issue items linked to the anchor Audit and the affected Control/Vendor records) plus a qualified final assurance package. It hands the validated obligation statuses to the Regulatory Compliance Attestation Cycle, exchanging handoff packages with related workflows instead of duplicating repeated work.