AIUC-1 (Jul 2026)
179 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
A001 — Establish input data policy
Establish input data policy
control · Direct
A002 — Establish output data policy
Establish output data policy
control · Direct
A003 — Limit AI agent data access
Limit AI agent data access
control · Direct
A004 — Protect IP & trade secrets
Protect IP & trade secrets
control · Direct
A005 — Prevent cross-customer data exposure
Prevent cross-customer data exposure
control · Direct
A006 — Prevent PII leakage
Prevent PII leakage
control · Direct
A007 — Prevent IP violations
Prevent IP violations
control · Direct
A008 — Prevent leakage of credentials and secrets
Prevent leakage of credentials and secrets
control · Direct
B001 — Third-party testing of adversarial robustness
Third-party testing of adversarial robustness
control · Direct
B002 — Detect adversarial input
Detect adversarial input
control · Direct
B003 — Manage public release of technical details
Manage public release of technical details
control · Direct
B004 — Prevent AI endpoint scraping
Prevent AI endpoint scraping
control · Direct
B005 — Implement real-time input filtering
Implement real-time input filtering
control · Direct
B006 — Prevent unauthorized AI agent actions
Prevent unauthorized AI agent actions
control · Direct
B007 — Enforce user access privileges to AI systems
Enforce user access privileges to AI systems
control · Direct
B008 — Protect AI system deployment environment
Protect AI system deployment environment
control · Direct
B009 — Limit output over-exposure
Limit output over-exposure
control · Direct
B010 — Promote secure patterns in generated code
Promote secure patterns in generated code
control · Direct
C001 — Define AI risk taxonomy
Define AI risk taxonomy
control · Direct
C002 — Conduct pre-deployment testing
Conduct pre-deployment testing
control · Direct
C003 — Prevent harmful outputs
Prevent harmful outputs
control · Direct
C004 — Prevent out-of-scope outputs
Prevent out-of-scope outputs
control · Direct
C005 — Prevent agent-specific high risk outputs
Prevent agent-specific high risk outputs
control · Direct
C006 — Prevent output vulnerabilities
Prevent output vulnerabilities
control · Direct
C007 — Flag high risk outputs for human review
Flag high risk outputs for human review
control · Direct
C008 — Monitor AI risk categories
Monitor AI risk categories
control · Direct
C009 — Enable real-time feedback and intervention
Enable real-time feedback and intervention
control · Direct
C010 — Third-party testing for harmful outputs
Third-party testing for harmful outputs
control · Direct
C011 — Third-party testing for out-of-scope outputs
Third-party testing for out-of-scope outputs
control · Direct
C012 — Third-party testing for customer-defined risk
Third-party testing for customer-defined risk
control · Direct
D001 — Prevent hallucinated outputs
Prevent hallucinated outputs
control · Direct
D002 — Third-party testing for hallucinations
Third-party testing for hallucinations
control · Direct
D003 — Restrict unsafe tool calls
Restrict unsafe tool calls
control · Direct
D004 — Third-party testing of tool calls
Third-party testing of tool calls
control · Direct
E001 — AI failure plan for security breaches
AI failure plan for security breaches
control · Direct
E002 — AI failure plan for harmful outputs
AI failure plan for harmful outputs
control · Direct
E003 — AI failure plan for hallucinations
AI failure plan for hallucinations
control · Direct
E004 — Assign accountability
Assign accountability
control · Direct
E005 — Document data storage security
Document data storage security
control · Direct
E006 — Conduct vendor due diligence
Conduct vendor due diligence
control · Direct
E008 — Review internal processes
Review internal processes
control · Direct
E009 — Monitor third-party access
Monitor third-party access
control · Direct
E010 — Establish AI acceptable use policy
Establish AI acceptable use policy
control · Direct
E011 — Record processing locations
Record processing locations
control · Direct
E012 — Document regulatory compliance
Document regulatory compliance
control · Direct
E013 — Implement quality management system
Implement quality management system
control · Direct
E015 — Log AI system activity
Log AI system activity
control · Direct
E016 — Implement AI disclosure mechanisms
Implement AI disclosure mechanisms
control · Direct
E017 — Document system transparency policy
Document system transparency policy
control · Direct
F001 — Prevent AI cyber misuse
Prevent AI cyber misuse
control · Direct
F002 — Prevent catastrophic misuse
Prevent catastrophic misuse
risk · Context
Excessive privilege and wrong assignment of access rights
Overly broad or wrongly assigned access rights, applications/services running with excessive privileges, and failure to enforce least privilege — a compromise or insider then gains broad access to systems and data.
risk · Context
Abuse of rights, forged rights, and repudiation of actions
Authorized users or administrators exploit legitimate access beyond permitted scope, fabricate or forge credentials/rights to gain privileges, and repudiate performed actions — undermining accountability and audit-trail integrity.
risk · Context
Unauthorized use of equipment and unauthorized access escalation
Use of systems, networks, or devices without authorization, and users with authorized access reaching resources that exceed their authorization, potentially to exfiltrate data or conduct attacks.
risk · Context
AI accountability gaps and organizational liability
Ambiguous responsibility across developers, deployers, and operators means no party is clearly accountable when AI causes harm; organizations face reputational damage, regulatory sanctions, and civil liability from AI failures at scale, and operational disruption when AI is unavailable.
risk · Context
Adversarial attacks, data poisoning and prompt injection
Data-poisoning corrupts training data and embeds backdoors; adversarial evasion, prompt injection, and jailbreaks fool deployed models at inference; model extraction steals proprietary weights/logic — enabling harmful or policy-violating outputs.
risk · Context
Unauthorized or unsafe autonomous agent actions and tool calls
AI agents with excessive permissions or weak action controls execute tool calls, transactions, or code outside their authorized task scope — through prompt injection, misinterpretation, or emergent behaviour — causing data loss, financial loss, or irreversible changes in connected systems.
risk · Context
Harmful AI bias and discrimination against protected groups
Models encode/amplify historical bias, producing allocative harm (biased hiring/lending/housing/benefits), representational harm (stereotyping), and evaluation bias masking disparate subgroup performance — systematically disadvantaging protected groups.
risk · Context
Misuse of AI systems for offensive cyber operations or catastrophic harm
Users obtain meaningful uplift from an AI system for offensive cyber operations (malware development, vulnerability exploitation, autonomous intrusion) or for biological, chemical, nuclear, or radiological harm, exposing the deploying organization to severe legal, regulatory, and societal consequences.
risk · Context
Emergent behaviour and unsafe AI system integration
Large-scale or multi-model pipelines exhibit emergent capabilities/failures not present in any component and not predictable from component testing; integration with legacy systems introduces interface mismatches and configuration errors.
risk · Context
AI endpoint abuse, scraping and model extraction
Adversaries scrape inference endpoints at scale to extract model behaviour or proprietary data, exhaust compute budgets through unbounded consumption, or harvest system prompts and technical details disclosed in outputs or documentation, degrading service and eroding competitive and security posture.
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
Rights harm from biometric-identification AI
Because remote biometric identification, categorization, or emotion-recognition systems (EU AI Act Annex III(1)) are deployed without conformity assessment, data governance, human oversight, accuracy/robustness controls, or a fundamental-rights impact assessment, they can misidentify, misclassify, or surveil individuals, resulting in wrongful treatment, discrimination, and rights violations.
risk · Context
Public-safety harm from AI in critical infrastructure
Because AI acting as a safety component in critical digital infrastructure, road traffic, or utilities (Annex III(2)) operates without the required risk management, robustness, and human oversight, it can fail or behave unsafely, resulting in service disruption and threats to public safety and continuity.
risk · Context
Unfair exclusion by AI in education and training
Because AI determining access, admission, assessment, or proctoring in education and vocational training (Annex III(3)) operates without bias controls, transparency, human oversight, or fundamental-rights safeguards, learners can be scored or excluded unfairly, resulting in denial of educational opportunity and discrimination.
risk · Context
Discriminatory outcomes from AI in employment
Because AI used for recruitment, selection, promotion, task allocation, or worker monitoring (Annex III(4)) operates without bias mitigation, worker transparency, human oversight, or a data-protection impact assessment, it can decide about workers on biased or opaque grounds, resulting in discriminatory or unfair employment outcomes.
risk · Context
Unlawful denial of essential services by AI
Because AI evaluating eligibility for public benefits, creditworthiness, or insurance risk and pricing (Annex III(5)) operates without fairness, explainability, human oversight, or the required conformity controls, it can wrongly deny or misprice essential services, resulting in unlawful exclusion and consumer harm.
risk · Context
Harm to due process and democratic integrity from AI
Because AI assisting judicial decisions or intended to influence elections or voter behaviour (Annex III(8)) operates without human oversight, transparency, and integrity safeguards, it can distort legal outcomes or manipulate electorates, resulting in threats to due process and democratic integrity.
risk · Context
Rights violations from AI in law enforcement
Because AI for individual risk assessment, evidence evaluation, profiling, or predictive policing (Annex III(6)) operates without strict accuracy, human oversight, logging, and fundamental-rights safeguards, it can drive wrongful enforcement action, resulting in unjust detention, profiling harm, and rights violations.
risk · Context
Wrongful denial by AI in migration and border control
Because AI for migration, asylum, or visa risk assessment and border-control screening (Annex III(7)) operates without the required accuracy, human oversight, and fundamental-rights protections, it can misjudge individuals, resulting in wrongful denial of entry or status and discrimination.
risk · Context
Inaccurate, unreliable or hallucinated AI outputs
AI outputs contain factual errors, hallucinations, or confidently wrong predictions; inappropriate proxy metrics, overfitting/underfitting, or insufficient pre-deployment testing undermine trust in decisions made on their basis.
risk · Context
Inappropriate human/AI task allocation and end-of-life risk
Tasks needing contextual judgment, ethics, or accountability are improperly delegated to AI; and decommissioning raises data-persistence in weights, loss of institutional knowledge, and service-continuity gaps.
risk · Context
Insecure AI-generated code and hallucinated or typosquatted dependencies
Code-generating AI produces insecure defaults (injection-prone queries, weak authentication and session handling, unsafe logging) or specifies non-existent, hallucinated, or typosquatted packages that attackers pre-register, introducing vulnerabilities and malicious dependencies into production software.
risk · Context
Insufficient human oversight and automation complacency
Because consequential AI decisions run under full automation with reviewers who lack the authority, information, or AI literacy to intervene, meaningful human control is absent and automation complacency erodes vigilance, so erroneous or harmful automated decisions reach individuals unchecked.
risk · Context
Lack of AI explainability, documentation and disclosure
Because AI models are opaque, model cards and datasheets are missing, and AI involvement in consequential interactions is not disclosed, affected individuals cannot obtain recourse and operators cannot see failure modes, resulting in unaccountable decisions, uninformed consent, and misplaced confidence in spurious, non-causal model reasoning.
risk · Context
Model/data drift and inadequate post-deployment monitoring
Distribution shift between training and deployment data silently degrades accuracy, and without ongoing monitoring, model decay and emerging failure modes go undetected with no trigger to retrain or decommission. Uncontrolled updates alter behaviour and invalidate prior assessments.
risk · Context
Insufficient AI resilience and fallback mechanisms
AI systems lacking fallback, redundancy, or graceful degradation fail catastrophically under adversarial conditions, infrastructure outages, or out-of-distribution inputs, disrupting dependent business processes.
risk · Context
Poor-quality, unrepresentative or mislabeled training data
Training data that is too small, unrepresentative, error-contaminated, or mislabeled produces systematic failure modes; data-lifecycle risks (unlawful collection, insecure storage, failure to purge) further corrupt model quality or violate privacy.
risk · Context
AI power concentration and erosion of societal trust
Disproportionate access to data, compute, and AI talent creates winner-take-all dynamics foreclosing competition; proliferation of AI-generated synthetic media and automated influence operations degrades the shared epistemic environment and democratic institutions.
risk · Context
AI privacy leakage and re-identification
Model inversion and membership-inference attacks reconstruct training data or reveal individuals in the training set; AI inference re-identifies anonymized data and infers sensitive attributes; training on data without consent/legal basis creates regulatory liability.
risk · Context
Deployment of prohibited AI practices (EU AI Act Art.5)
Use of prohibited AI: subliminal/manipulative techniques, social scoring, untargeted facial-image scraping, real-time/post remote biometric identification for law enforcement, sensitive-attribute biometric categorization, and emotion recognition in work/education settings.
risk · Context
AI safety failures causing physical or psychological harm
AI errors in safety-critical systems (autonomous vehicles, medical devices, industrial controls) cause injury or death; safety-constraint violations by agentic AI, cascading failures across coupled systems, and AI-generated misinformation/deepfakes cause harm.
risk · Context
Credential and secret leakage through AI inputs, outputs, logs and generated code
API keys, tokens, private keys, and connection strings pasted into prompts, returned in outputs, hardcoded in generated code, or captured in conversation logs are exposed to unauthorized parties or persisted outside secret management, enabling account takeover and lateral movement.
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
Phishing, spear-phishing and social engineering
Adversary counterfeits trustworthy communications (email, phone, spoofed websites) to trick individuals — including high-value executives — into revealing credentials or sensitive information, or into enabling wire-transfer/BEC fraud.
risk · Context
User error and mishandling of sensitive information
Authorized users make mistakes — incorrect data entry, misconfiguration, improper procedures, incorrect privilege settings, or spilling/mishandling sensitive information — causing harm to information assets without malicious intent.
risk · Context
Sector regulatory non-compliance (financial, healthcare, trade)
Non-compliance with sector regimes — banking prudential rules, consumer-lending laws, payment-network rules, healthcare (FDA/HIPAA/CMS, Anti-Kickback/Stark, False Claims), export controls (EAR/ITAR), antitrust, and environmental/labor rules — triggering fines, sanctions, or loss of license.
risk · Context
Internet-exposed or misconfigured systems
Adversary gains access through the Internet to systems not authorized for Internet connectivity or that do not meet configuration requirements, and exploits attacks over unauthorized ports, protocols, and services.
risk · Context
Credentials and sensitive data transmitted in clear text
Authentication credentials or sensitive system communications transmitted unencrypted over networks, and absence of mutual sender/receiver authentication, enable interception, credential theft, and spoofing.
risk · Context
Compromised or counterfeit certificates / certificate authority
Adversary counterfeits or compromises a certificate authority so that malware or connections appear legitimate, defeating trust in TLS and code-signing and enabling man-in-the-middle or malicious-code delivery.
risk · Context
Weak or absent encryption and key management
Sensitive data stored or transmitted without adequate encryption, or use of weak/flawed cryptography and poor key generation, storage, rotation, and destruction — enabling interception, disclosure, or tampering of data.
risk · Context
Attacks by capable, motivated threat actors
Because capable, motivated threat actors - outsiders, privileged and non-privileged insiders, organized groups, competitors, malicious partners or suppliers, and nation-states - actively target the organization's cyber resources, deliberate attacks are attempted against its systems and data, resulting in compromise, disruption, or theft when defenses are outmatched.
risk · Context
Coordinated multi-stage / APT campaigns
Adversary coordinates continuous, adaptive, multi-staged campaigns (hopping across systems, combining insider/outsider/supply-chain vectors, spreading from existing presence) to persist and progressively undermine mission/business functions.
risk · Context
Unauthorized disclosure / breach of sensitive information
Unauthorized disclosure of information to parties not entitled to receive it, whether by insecure controls (insecurity), spillage, or authorized users induced to expose data — resulting in identity theft, economic loss, and loss of trust.
risk · Context
Corruption or integrity loss of critical data
Intentional or accidental alteration, deletion, defacement, or injection of false-but-believable data into systems (including web defacement and data from untrustworthy sources) renders data inaccurate and erodes confidence in it.
risk · Context
Data exfiltration and theft of information by attackers
Adversary (outsider, insider, nation-state, or competitor) installs malware or sniffers to locate and exfiltrate sensitive/proprietary information, or steals data by external actors — including systems-security losses from hacking.
risk · Context
Privacy harms: distortion, stigmatization, unwarranted restriction
Processing inaccurate/out-of-context data (distortion), attaching negative social labels (stigmatization), or denying services based on personal data without justification (unwarranted restriction / algorithmic gatekeeping) — causing discrimination and economic loss.
risk · Context
Privacy-program non-compliance (GDPR, CCPA, state laws)
Failure to honour data-subject rights (access, deletion, portability, restriction) on time, missing lawful-basis/consent documentation, defective consent mechanisms, invalid cross-border transfer mechanisms, or inadequate notices — driving fines and private rights of action.
risk · Context
Re-identification and unanticipated revelation from data
Insufficient de-identification/pseudonymization, plus inference or linkage attacks and metadata leakage, re-identify individuals or reveal information they did not intend to disclose — causing embarrassment, harm, and regulatory exposure.
risk · Context
Manual journal entries and management-override risk
Manual/automated journal entries posted with transposition errors, wrong account codes, or amounts; recurring entries not updated; and top-side entries used to override controls and manage earnings at period-end.
risk · Context
Revenue-recognition misstatement (fictitious, mis-timed, mis-measured)
Fictitious or channel-stuffed revenue, revenue not recorded for delivered goods, incorrect transaction-price allocation or percentage-of-completion, and principal-vs-agent gross/net errors — the highest-risk assertion cluster in the revenue cycle.
risk · Context
Segregation-of-duties conflicts in financial processes
Incompatible duties (initiate, approve, record, and custody) concentrated in one role or via broad system access enable unauthorized or fraudulent transactions to be recorded and concealed.
risk · Context
Insufficient personnel screening and vetting
Failure to vet employees, contractors, or third parties before granting access enables insider threats or introduces compromised individuals; adversaries may deliberately place subverted individuals into (privileged) positions.
risk · Context
Missing or insufficient logging and audit trails
Absence of logging/audit trails means unauthorized activity cannot be detected, investigated, or attributed, and adversary actions (obfuscation of intrusion detection, tampering with logs) go unnoticed.
risk · Context
Communications interception, eavesdropping and man-in-the-middle
Passive monitoring/sniffing of communications, interception of unencrypted or weakly encrypted channels, wireless interception, and man-in-the-middle attacks capture or corrupt transmitted data — including TEMPEST-type emanation capture.
risk · Context
Client intake, documentation and account-management failures
Missing signed agreements, incomplete legal/ISDA documentation, unretained KYC/AML records, misfiled client files, unauthorized access to client accounts, and negligent loss of client assets held in custody.
risk · Context
Product design and model errors
Defective product design, errors in model or pricing assumptions embedded in products, and failure to investigate customer complaints cause systematic customer harm and mis-selling losses.
risk · Context
Cross-border personal-data transfer without safeguards
Transferring personal data to jurisdictions lacking equivalent protection without SCCs, BCRs, adequacy decisions, or other recognized mechanisms, exposing individuals and the organization to legal risk.
risk · Context
Absence of privacy-by-design and default
Because systems and products are built without embedding privacy controls at the architecture level, privacy protections are bolted on after launch rather than applied by default, so personal data is over-collected and exposed and costly manual remediation is required.
risk · Context
Power imbalance and loss of self-determination over personal data
Structural informational asymmetry (take-it-or-leave-it consent, opaque algorithmic decisions) and inability to correct, delete, or restrict processing deprive individuals of meaningful control over their own data and narrative.
risk · Context
Applications running with excessive privilege / insecure design
Applications or services running under privileged accounts, opening unnecessary network connections, or lacking secure-by-design architecture mean a single compromise grants broad system access and expands attack surface.
risk · Context
Malware delivery, insertion and compromise of systems
Adversary crafts and delivers known, modified, or targeted malware (via email, web, removable media, or downloadable software) and compromises system software to take control, exfiltrate data, or degrade functions.
risk · Context
Ransomware disrupting operations and data availability
Criminal groups deploy ransomware that encrypts systems and data, disrupting operations, causing losses, and demanding extortion payment — a high-impact convergence of malware, availability, and continuity risk.
risk · Context
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
Zero-day exploitation
Adversary employs attacks that exploit as-yet-unpublicized vulnerabilities (targeted, based on reconnaissance, or nontargeted), compromising systems before any patch or signature exists.
standard · Direct
AIUC-1 (Jul 2026)
AIUC-1 — AI agent security, safety and reliability standard (requirement level)
unified · Context
UC-ACCESS-03 — Enforce least privilege, need-to-know, and segregation of duties
A documented access control policy grants access strictly on business need-to-know, with entitlements defined through roles that default to least privilege. Segregation-of-duties conflicts (e.g., request versus approve, develop versus deploy) are defined in a conflict matrix, enforced in systems, and mitigated with compensating controls where unavoidable. Role and entitlement definitions are approved by data or system owners and re-approved whenever they change.
unified · Context
UC-ACCESS-05 — Enforce approved authorizations for information and functions
Systems mediate every access attempt through a tamper-resistant, always-invoked enforcement mechanism that applies approved authorizations before granting access to information or functions. Restrictions use roles and security attributes bound to data and subjects, limiting access to sensitive information, source code, and administrative functions to explicitly authorized identities. Enforcement rules are applied consistently across applications, databases, and infrastructure and are tested for effectiveness.
unified · Context
UC-ACCESS-14 — Authorize public content and external information sharing
Actions permitted without identification or authentication are explicitly defined, documented, and limited to designated public functions. Information shared with external parties requires owner authorization consistent with classification and sharing agreements. Only trained, designated individuals may post content to publicly accessible systems, with pre-publication review and periodic checks to ensure no nonpublic information is exposed.
unified · Context
UC-AI-01 — Maintain and periodically review the AI policy
Establish a management-approved AI policy that sets principles and requirements for developing and using AI systems, and keep it demonstrably consistent with related organizational policies such as security, privacy, and ethics. Review the policy at planned intervals and upon significant regulatory or technology change, recording review outcomes and revisions. Publish the current version to all relevant personnel and retain prior versions as evidence.
unified · Context
UC-AI-02 — Define AI roles, responsibilities, and competencies
Define and assign roles, responsibilities, and authorities for AI governance and for each AI system life-cycle stage, recording them in a maintained RACI or equivalent register. Document the human resources involved in AI development, deployment, and operation, including the competences each role requires and how competence gaps are addressed. Review assignments and competence records when systems, personnel, or obligations change.
unified · Context
UC-AI-04 — Assess impacts and classify AI systems before deployment
Operate a documented AI impact assessment process performed before deployment and repeated on significant change, assessing consequences for individuals, groups of individuals, and society, including fairness, safety, and fundamental-rights effects. Classify each system against applicable regulatory risk categories, including any high-risk designation, and record the classification rationale. Retain assessment reports, approvals, and reassessment triggers as evidence.
unified · Context
UC-AI-06 — Maintain AI system technical documentation
Produce and maintain technical documentation for each AI system covering design and development decisions, architecture, model and data characteristics, performance, and limitations, including all content mandated by applicable regulation for higher-risk systems. Keep documentation up to date through changes and retain it for the regulatorily mandated period. Documentation must be sufficient for regulators and assessors to evaluate compliance.
unified · Context
UC-AI-07 — Verify, validate, and control AI deployment and changes
Verify and validate each AI system against its requirements and responsible-AI objectives, documenting test plans, acceptance criteria, and results before release approval. Gate deployment on a documented deployment plan and sign-off confirming requirements are met. Route updates, retraining, and other changes through the same assessment and approval process, including impact reassessment where relevant, and retain verification records and deployment and change approvals.
unified · Context
UC-AI-08 — Log and monitor AI system behavior in operation
Ensure AI systems automatically record event logs that enable traceability of operation over the system's lifetime, including events relevant to identifying risk situations and substantial modification. Retain logs for at least the mandated regulatory minimum, or longer where required. Monitor deployed systems against defined performance and behavior metrics with alerting and escalation for anomalies and drift, and retain logs and monitoring reviews as evidence.
unified · Context
UC-AI-10 — Meet transparency obligations for AI systems
Provide users, deployers, and other interested parties with documentation and instructions for each AI system describing its intended purpose, capabilities, limitations, performance characteristics, and required human-oversight measures. Disclose when people are interacting with an AI system, and mark AI-generated or manipulated content, including deepfakes, in a machine-readable and clearly perceptible way where required. Keep transparency materials current with system changes and retain distribution evidence.
unified · Context
UC-AI-11 — Operate AI concern, incident, and external reporting channels
Operate channels through which personnel and other stakeholders can report concerns about the organization's role in developing or using AI systems, with documented triage and follow-up. Define and execute procedures for communicating AI incidents to affected users and interested parties, and for making required reports to regulators and other external bodies within mandated timeframes. Retain concern reports, incident communications, and resolution records as evidence.
unified · Context
UC-AI-12 — Enforce responsible and lawful use of AI systems
Define objectives and documented processes for responsible use of AI systems, and ensure each system is used only in accordance with its intended use and accompanying documentation. Screen proposed and existing uses against legal prohibitions on unacceptable practices — such as manipulative techniques, social scoring, and untargeted facial-image scraping — and block or discontinue prohibited uses. Retain use approvals and screening records.
unified · Context
UC-AI-13 — Assign AI value-chain roles and discharge obligations
For each AI system, determine and document the organization's role in the value chain, such as provider or deployer, and allocate life-cycle responsibilities among the organization, partners, suppliers, and customers. Maintain a register of the obligations attached to each role, including provider duties for high-risk systems (quality management, conformity assessment, CE marking, registration) and deployer duties (instruction-compliant operation, oversight assignment, log retention), tracking each obligation to an owner and evidence. Review the register when systems or regulations change.
unified · Context
UC-AI-14 — Manage responsible AI with suppliers and customers
Govern supplier relationships that provide AI systems, components, or data through a documented process that verifies supplier alignment with the organization's responsible-AI requirements. Ensure the organization's responsible development and use of AI considers customer needs and expectations, and provide customers with the information they need to use AI systems responsibly. Retain supplier evaluations and customer communications as evidence.
unified · Context
UC-AI-16 — Ensure human oversight of AI decisions
Design and operate high-risk AI systems so that natural persons can effectively oversee them during use, through human-machine interface tools and oversight measures built into the system or defined for the deployer. Assign oversight to persons who understand the system's capacities and limitations, can monitor operation, remain aware of automation bias, correctly interpret output, and can decide not to use, override, or halt the system. Evidence includes oversight procedures, oversight assignments, and intervention records.
unified · Context
UC-AI-17 — Define customer data-use and output-rights policies for AI services
Publish and maintain customer-facing policies for AI services that state how customer inputs are used for model training and inference, how long inputs and outputs are retained, who owns and may use generated outputs, and how customers can opt in or out, request deletion, or exercise other data rights. Communicate the policies before onboarding, version them, and retain customer acknowledgements and periodic review records as evidence.
unified · Context
UC-AI-18 — Defend AI interfaces against adversarial input, injection, and endpoint abuse
Protect the inference and agent interfaces of AI systems with layered input defenses: screen prompts, uploaded content, retrieved data, and tool results for prompt-injection and jailbreak patterns before they reach the model or trigger actions; detect and alert on adversarial-input campaigns; and rate-limit, authenticate, and monitor endpoints to prevent scraping, model extraction, and resource-exhaustion abuse. Tune detections from evaluation findings and retain filter configurations and detection logs as evidence.
unified · Context
UC-AI-19 — Constrain agent actions and tool use to authorized scope
Bound what autonomous agents may do: allow-list the tools, connectors, and actions each agent may invoke; scope its permissions to the task, user, and context; require human approval for irreversible, high-value, or out-of-policy actions; execute agent-generated code only in isolated sandboxes; and scan agent configuration artifacts such as hooks, skills, and rules for injected instructions. Log every tool call with its authorization decision and review denied and escalated calls.
unified · Context
UC-AI-20 — Prevent harmful, out-of-scope, hallucinated, and over-exposed AI outputs
Filter and shape every AI output before release: block or transform content that matches the system's harmful-output taxonomy, keep responses within the declared scope and capabilities, detect agent-specific high-risk outputs and route them to defined responses by severity, ground factual claims in cited sources and verify them to limit hallucination, withhold system prompts, internal data, and other over-exposed information, and sanitize outputs consumed by downstream systems so they cannot carry executable or injected payloads. Measure filter effectiveness and retain configurations, block logs, and review samples as evidence.
unified · Context
UC-AI-21 — Commission independent third-party AI evaluations on a quarterly cadence
Engage an independent evaluator at least quarterly to test each in-scope AI system against its defined risk categories: adversarial robustness and jailbreak resistance, harmful and out-of-scope outputs, agent-specific high-risk outputs, hallucination rates, and unsafe or unauthorized tool calls. Fix the test scope and pass thresholds in advance, track every finding to remediation and retest, and retain evaluator reports, methodologies, and remediation evidence.
unified · Context
UC-AI-22 — Prevent leakage of credentials and secrets through AI systems
Detect credentials, tokens, private keys, and connection strings in prompts, pasted content, retrieved data, and generated code using pattern- and entropy-based scanning; warn users and block or redact detected secrets before model processing, logging, and storage; guide code-generating systems to reference secret managers and environment variables rather than hardcoding credentials; and store any user-supplied credentials only in a dedicated secret manager encrypted at rest. Retain detection rules, redaction logs, and storage configurations as evidence.
unified · Context
UC-AI-23 — Prevent misuse of AI systems for cyber offense and catastrophic harm
Recognize and refuse requests that seek meaningful uplift for offensive cyber operations or for biological, chemical, nuclear, or radiological harm, calibrated to the capability level of the deployed models; monitor for misuse patterns, escalate and report confirmed attempts, and keep refusal policies, classifiers, and escalation procedures current as capabilities change. Retain misuse-detection configurations, incident records, and periodic review evidence.
unified · Context
UC-AI-24 — Operate an AI quality management system
Establish and maintain a documented quality management system for AI products covering quality objectives and responsibilities; documented design, development, testing, and release procedures; change management; data management procedures; issue tracking and corrective action; stakeholder and regulator communication procedures; and record keeping. Review the system periodically for effectiveness and continual improvement, and retain the quality manual, procedures, review records, and corrective-action logs as evidence.
unified · Context
UC-AI-25 — Guide code-generating systems toward secure patterns and safe dependencies
Configure code-generating AI systems with secure-by-default guidance: steer generated code toward parameterized queries and safe frameworks for common vulnerability classes, established authentication and authorization libraries, secure session and cookie settings, input validation and safe error handling, and logging that excludes secrets; require pinned, verified dependency specifications so hallucinated or typosquatted packages are not introduced; and test the guidance against a vulnerability benchmark on change. Retain system-prompt and policy configurations and benchmark results as evidence.
unified · Context
UC-CONFIG-10 — Map where information resides and how data is processed
Identify and document the location of information and the specific system components on which it is processed and stored, including designated data types such as personally identifiable information. Develop and maintain a map of system data actions covering collection, processing, storage, and transmission, and update location and mapping documentation upon change.
unified · Context
UC-CRYPTO-01 — Encrypt data at rest and in transit
Sensitive and nonpublic data at rest is rendered unreadable using strong, industry-accepted encryption, or truncation/tokenization for stored account data, with storage and retention minimized to defined business need. Data in transit is protected with strong cryptography and trusted certificates over all open, public, or external networks, rejecting fallback to insecure protocols. Transmission, movement, and removal of information, including to removable media, is restricted to authorized users and processes, and the integrity of data in both states is protected. Where encryption of nonpublic information is infeasible, compensating controls are documented, approved by the CISO, and reviewed at least annually.
unified · Context
UC-DATA-11 — Control data flows, leakage, and cross-border transfers
Enforce approved authorizations for information flows within and between systems using technical flow-control mechanisms, and deploy data-leakage-prevention measures on systems and channels that could exfiltrate sensitive data. Transfer personal data across borders only under a valid transfer mechanism (adequacy decision, standard contractual clauses, binding corporate rules, or a documented derogation), with the transfer risk assessed and the safeguard recorded.
unified · Context
UC-DATA-12 — De-identify, mask, or pseudonymize personal data
Apply masking, pseudonymization, or de-identification when full identifiers are not required, following policy and the applicable legal standard (e.g., expert determination or safe-harbor methods, limited data sets under agreement). Protect the keys and mappings that could re-identify data, and prohibit re-identification attempts.
unified · Context
UC-LOG-09 — Monitor providers and exchange audit data across organizations
Define monitoring requirements for external service providers and monitor their activities, service status, and security-relevant events against contractual obligations, reviewing provider-supplied logs and reports on a defined cadence. Where audit trails cross organizational boundaries, agree methods for coordinating, exchanging, and protecting audit information with the external parties and preserve the identity context needed to trace cross-organizational actions.
unified · Context
UC-SDLC-04 — Engineer systems with secure architecture and design
Design and build systems using established secure architecture and engineering principles: least privilege, defense in depth, isolation of execution domains (process and memory separation), fail-safe defaults, and attack-surface minimization, applied from concept through implementation. Require developers to produce and maintain a security architecture description consistent with the enterprise architecture. Engineer solutions to remain accurate, robust, and resilient against errors, faults, and adversarial manipulation.
workflow · Context
SOC 2 Trust Services Readiness
Runs on the existing Audit engagement with its system description, service commitments, review period, control and risk registers, and available evidence; assesses CC1–CC9 design readiness and consumes reviewed companion assessments for selected optional Trust Services categories. Delivers the criterion-to-control mapping, criterion-level evidence and design conclusions, owned gap register, and approved SOC 2 readiness disposition to management for remediation and examination planning; Type II testing, management-owned PBC preparation and management assertion remain separate workflows.
workflow · Context
ITGC Change & Provisioning Testing
Runs ON a control item (a change-management or access-provisioning ITGC). Validates the change and provisioning populations for the period, draws reproducible samples, tests each sampled ticket against the control attributes (approval before migration, segregation of developer and migrator, approval before access, access matches the requested profile), records design and operating conclusions on the control, and raises every exception as an issue.
workflow · Context
Technical Security Testing & Pentest Engagement
Runs ON an existing Audit item (audit_type: it_audit) that represents the authorized penetration-test engagement — the workflow instance attaches to that record and enriches it (scope, ratings, dates, and the assurance conclusion write back to its fields); it never creates a duplicate engagement record. In scope: authorized technical testing (reconnaissance, discovery, exploitation validation, severity rating, reporting, and retest) of the defined system boundary against its control baseline and assessment objective, with each confirmed finding recorded as an Issue linked to the anchor Audit and its affected Controls. Out of scope: any testing beyond the agreed rules of engagement, and the downstream remediation program itself — confirmed control gaps and open POA&M findings are handed to the Security Control Assessment & POA&M Remediation workflow, and the assurance conclusion to the Cybersecurity Assurance Review workflow. No upstream workflow feeds this engagement; its inputs are the anchor Audit, the in-scope system boundary (Process items), the control baseline (Control items, framework nist-800-53), the assessment objective and signed authorization, and any open Issue items (source: penetration_test / vulnerability_scan) from prior engagements.
workflow · Context
User Access Review & Recertification
Runs on the existing Control item for UC-ACCESS-02 (user access review) — with UC-ACCESS-03 linked by item relationship — enriching that Control, never creating a duplicate; each quarterly or event-triggered cycle is a workflow instance attached to it, so archived instances accumulate as the de-facto control execution log. A decision-aware workflow covering entitlement extraction, manager certification, revocation, and independent verification. Consumes at start the prior cycle's scope-change carry-forward Issues and prior signed report (both attached to the same Control) plus the period's source-of-record entitlement extracts and period-end HR roster. Produces a signed, audit-ready recertification evidence package and control-owner report as the named deliverable. In scope: SOX-significant applications, systems holding data classified Confidential or above, identity infrastructure (directory, SSO, PAM), and privileged-reach platforms, across all account populations (standard, privileged, service, shared, emergency break-glass, third-party); triggered on scheduled cadence or by event (post-incident, auditor request). Out of scope: lifecycle provisioning and the privileged-access model itself — systemic findings hand off to the Joiner-Mover-Leaver Access Lifecycle (lifecycle gaps) and Privileged Access & Authorization Model Management (privileged-model findings) workflows.
workflow · Context
Joiner-Mover-Leaver Access Lifecycle
Run one instance per HR-triggered joiner, mover, or leaver event as a decision-routed access-lifecycle control that enriches the EXISTING Control item for JML / user-access provisioning-deprovisioning (control library, domains=access_control_identity, framework nist-800-53 + iso-27001) - attach the instance to that control, never create a duplicate. Consume the authoritative HR event record from the external HR system of record (the trigger): classify the event, then provision role-based access, adjust with SoD checks on transfer, or evidence timely removal on exit, and file the named audit-ready access-lifecycle evidence package before closing. In scope: identity-provider, directory, HR-system, ERP, and connected-SaaS entitlements for the affected worker. Out of scope: HR record creation itself, physical-security badge policy, and system-owner entitlement design. The run is terminal - no upstream or downstream AssureSwarm workflow: it starts from the external HR event and ends at the archived evidence package attached to the Control item. The anchor Control links (item relationship) to the access Risk it mitigates.
workflow · Context
Privileged Access & Authorization Model Management
Standing operator workflow for the quarterly privileged-access recertification cycle, separate-account and utility-program controls, and application allowlisting, paired with role and security-attribute authorization-model maintenance and enforcement spot-testing across applications, databases, and infrastructure. Each quarterly instance runs as the operating cycle of the existing privileged-access Control item in the control library (UC-ACCESS-04, with UC-ACCESS-05 linked) — it enriches that Control's operating-effectiveness record rather than creating a new subject, and reads risk context from the linked Risk item (category cyber_security, domains access_control_identity). Consumes standing account, log, change-queue, and org-change feeds pulled live from IAM/PAM, directory, SIEM, allowlist tooling, and the HR system of record, plus the prior quarter's archived instance for its inventory register and carryover exceptions; it consumes no upstream workflow's handoff package. In scope: privileged and administrative accounts, control-overriding utility programs, the application allowlist, and the role and attribute authorization model with its enforcement points. Out of scope: standard non-privileged joiner-mover-leaver provisioning, network and perimeter controls, and application change management, each handled by its own workflow. Every exception and enforcement gap normalizes to an Issue item linked to the anchor Control, and the archived workflow instance is the cycle's evidence of record — open Issues are the cross-cycle carry-forward. Runs on a routine quarterly cadence, or out of cycle when an audit finding, incident, or major organizational change (reorg, new system, acquisition) requires it; no upstream workflow feeds it and it hands off to no single downstream workflow. Owned by the IAM Operations Lead.
workflow · Context
Public Content & External Sharing Authorization
Standing operator workflow for the public-posting and external-sharing authorization queue plus the quarterly permitted-without-authentication register and public-content exposure sweep, run per publication request and each quarter. Each operating cycle runs as one instance that enriches the existing UC-ACCESS-14 Control item in the control library (NIST 800-53 AC-14/AC-21/AC-22, family AC, preventive, quarterly) — it never creates a new control, and the workflow instance itself is the durable audit trail attached to that Control. In scope: public-facing systems (public website, support portal, developer documentation, status page, social channels) and external data shares governed by sharing agreements. Out of scope: authenticated internal content and access provisioning. Consumes each cycle: the living public-content and external-share register, the permitted-without-authentication register, and the active-sharing-agreements register (all pre-existing, refreshed cycle over cycle); the information-classification scheme (a Policy item, policy_type: standard); and the prior cycle's open carry-forward Issues. Named deliverables: the classified intake register, the authorization-verification log, the per-request publication dispositions, the refreshed permitted-without-authentication register, the quarterly exposure-sweep dashboard and findings report, and exposure corrective-action Issues linked to the Control. This control runs standalone — no upstream workflow feeds it and no downstream workflow consumes its output; the per-request authorization path and the quarterly sweep path are independent and both close in this instance.
workflow · Context
Data Encryption & In-Use Protection Operations
Standing operator workflow for the quarterly encryption sweep across data at rest, in transit, and in use, including CISO-approved compensating controls where encryption is infeasible, with a dashboarded readiness classification and corrective-action tracking. Each quarterly instance runs against — and enriches — the existing Control item for the data-encryption / in-use-protection control (domains cryptography_key_management + data_protection_privacy, quarterly frequency, control_owner set); it never creates a duplicate control. It consumes the prior cycle's carry-forward — the still-open corrective-action Issue items and the active compensating-control Control items already linked to that anchor Control (there is no upstream handoff package). Named deliverables: the sensitivity-classified inventory register; the at-rest, in-transit, movement-control, and data-in-use findings registers; the CISO-approved compensating-control register; the program-health dashboard; the corrective-action register; and the archived operating record. In scope: every data store, transmission channel, and removable-media pathway that holds or moves sensitive or account data, plus high-sensitivity workloads that process data in use. Out of scope: key and certificate inventory and rotation, which are reviewed under the separate key-management program. Terminal by design: no downstream workflow consumes this cycle's output — open corrective actions and compensating controls carry forward as explicit inputs to the next quarterly cycle.
workflow · Context
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
Network Segmentation & Boundary Rule Management
Network Segmentation & Boundary Rule Management as a decision-aware operator workflow covering trust-zone maintenance, gated rule-change implementation, boundary threat monitoring, the quarterly segmentation and rule-set review, and cross-domain exchange-policy enforcement. This cycle runs on the EXISTING boundary-protection Control item (domains network_communications_security; framework NIST 800-53, NIST CSF 2.0, ISO 27001, SOC 2; frequency quarterly; the boundary control owner as control_owner) — each quarterly run is one workflow instance attached to and enriching that Control, never a new control record. In scope: the trust-zone model, the managed interfaces (firewalls, gateways, proxies) mediating traffic between zones, the external boundary and key internal boundaries, and the cross-domain interconnection points, all under a deny-by-default baseline (NIST 800-53 SC-7, SC-16, SC-46; NIST CSF 2.0 PR.IR-01; ISO 27001 A.8.22; SOC 2 CC6.6). No upstream workflow feeds this cycle; it self-seeds from its own prior-cycle carry-forward — open corrective-action Issue items linked to the Control plus the prior run's closure record and archived rule-change record log. Named deliverables: the reconciled trust-zone model, the verified rule-change record log, the boundary threat-monitoring summary, the cross-domain exchange-policy enforcement report, the quarterly segmentation & rule-set review report, the boundary-posture dashboard, and corrective-action Issues linked to the Control. Downstream, it hands off only to its own next cycle via the carry-forward closure record; a confirmed intrusion is escalated to the incident-response workflow (out of scope), as are host/endpoint controls.
workflow · Context
Network & Provider Service Monitoring
Each monthly run attaches to the EXISTING network & provider monitoring Control item (UC-LOG-08/UC-LOG-09, frequency = monthly; framework = iso-27001 | nist-csf-2 | nist-800-53) — enrich that Control's evidence trail, never create a duplicate control. The cycle keeps network devices hardened and controlled, network-service documentation (including outsourced services) current, delivered services monitored for conformance, and external providers reviewed against their contractual obligations, feeding every deviation into a single owned remediation log — Issue items linked to the anchor Control — and producing a signed monthly monitoring record archived under retention. In scope: in-scope network devices and services, external service providers (the Vendor register) and their contracts, cross-organizational audit-trail exchange arrangements, and the deviations they produce. Out of scope: incident response and investigation for a provider-reported security event, which is tracked in its own incident case rather than in this monitoring cycle. Consumes no upstream workflow — self-originating, triggered by its own monthly cadence, a newly onboarded network service or provider, or a carried-forward deviation requiring follow-up; the previous instance hands off its still-open remediation Issues (linked to the same Control) as this cycle's carry-forward inputs. Terminal: it hands off to nothing downstream — closure seeds its own next cycle.
workflow · Context
Secure SDLC Phase-Gate Program
Operate the secure SDLC phase-gate program as a modular, decision-aware workflow where the accountable control owner chairs the intake, requirements, design, and build/release gates end to end. Each recurring operating cycle runs as a new workflow instance attached to the existing secure-SDLC phase-gate Control item (domains = secure_development_sdlc; framework = nist-800-53 / iso-27001 / cobit-2019 / nist-csf-2) — that Control already exists in the library, so the instance enriches it with this cycle's gate evidence rather than creating a duplicate control. In scope: chairing those four security-integrated lifecycle gates for every development initiative due this cycle, remediating held or blocked initiatives, and monitoring the process itself; it is self-initiating and consumes no upstream workflow package, and it seeds its own next cycle. Out of scope and distinct from it: the independent SDLC gate review's release-milestone verification, and the release-security-gate's technical testing practice.
workflow · Context
AI Operations Monitoring & Incident Response
Each monthly instance runs against the existing Control item for AI operations monitoring and incident response (framework eu-ai-act + iso-42001; domains ai_governance / logging_monitoring_detection / incident_management_response; frequency monthly; control_owner AI Operations Manager) — the run enriches that Control's execution history and is its evidence of operation, it never creates a duplicate. The decision-aware cycle covers event-logging and retention verification, alert resolution, human-oversight confirmation, AI-use screening against legal prohibitions, and AI concern-and-incident triage through required communications and regulator reporting, consolidating all five streams into a named cycle report and cycle dashboard while every residual gap is booked as an Issue (source: management_identified) linked to the anchor Control. In scope: every deployed production, limited-risk, and high-risk AI system under the EU AI Act, its event-log sources and monitoring dashboards, the human-oversight roster, the AI use inventory, and the AI concern-reporting channels. Out of scope: pre-deployment model development and conformity assessment, and third-party/vendor AI due diligence, which are governed by their own workflows. This cycle consumes no upstream workflow handoff; it hands off only to the next monthly run of itself, seeding it with the open carry-forward Issues (corrective actions, in-flight blocks, incident follow-ups) that the cycle-metrics-and-report step links to the anchor Control so next month can query them as its prior-cycle input.
workflow · Context
AI Guardrail Configuration & Agent Permission Review
Each monthly or release-triggered instance runs against the existing Control item for AI guardrail configuration and agent permission review (framework aiuc-1 + iso-42001 + eu-ai-act; frequency monthly and per release; control_owner AI Platform Security Lead) — the run enriches that Control's execution history and is its evidence of operation, never a duplicate. The decision-aware cycle confirms the in-scope agent population and baseline; reviews input defenses and endpoint limits, tool allow-lists, permissions and sandboxing, output filters and grounding, misuse refusals, secrets redaction, and secure-code-generation defaults; decides on agent permission scope and on guardrail drift with a remediation branch for each; and consolidates the results into a signed guardrail attestation with cycle metrics and owned actions, booking every residual gap as an Issue (source: management_identified) linked to the anchor Control. In scope: every production AI agent and inference endpoint, its guardrail configuration, tool-call and detection logs, and configuration artifacts. Out of scope: model development, pre-deployment evaluation, and vendor AI due diligence, which have their own workflows. The cycle hands off only to its next instance through the carry-forward Issues that the guardrail attestation step links to the anchor Control.
workflow · Context
Quarterly Third-Party AI Evaluation Cycle
Each quarterly instance runs against the existing Control item for independent third-party AI evaluation (framework aiuc-1 + iso-42001 + eu-ai-act; domains ai_governance; frequency quarterly; control_owner AI Product Lead) — the run enriches that Control's execution history and is its evidence of operation, it never creates a duplicate Control; the one record it does create is a per-quarter Audit item (audit_type: it_audit) for the evaluator engagement. The decision-aware cycle confirms the quarter's in-scope systems and risk taxonomy, engages an independent evaluator with the test plan, categories, and pass thresholds fixed in advance, provisions contained test access, triages every finding by category and severity against the tested control, routes failed thresholds through remediation and evaluator retest, gates acceptance of the evaluator report, publishes the accepted evidence (trust-portal summary, customer-facing attestation, evidence register), and tunes guardrails from the findings. In scope: every in-scope AI system and agent under the AIUC-1 program and its six mandatory third-party test categories (B001 adversarial robustness, C010 harmful outputs, C011 out-of-scope outputs, C012 agent-specific risk, D002 hallucinations, D004 tool calls). Out of scope: internal red-teaming, pre-release model evaluation, and vendor AI due diligence, which run in their own workflows. It hands off only to the next quarterly run of itself, seeding it with the open carry-forward finding Issues that the publish-evidence-and-tune-guardrails step links to the anchor Control.
workflow · Context
Onboarding & Access Provisioning
Runs on the existing personnel item. Provision a joiner access from an approved role profile, evidence each grant, and approve the provisioning record that ITGC access testing samples. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
Transfer & Access Modification
Runs on the existing personnel item. Modify a mover access for a new role, remove entitlements the prior role no longer justifies, and approve the modification record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
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 2 Annex A Controls Audit
Attach to the existing Audit engagement, owned by Internal Audit, using its approved Statement of Applicability, risk treatment plan, scope, review period and operating evidence; produce the Stage 2 Annex A Controls Audit report, four signed theme conclusions and finding register for the engagement and remediation owners. Apply the approved Statement of Applicability to ISO/IEC 27001:2022 Annex A.5.1–A.5.37, A.6.1–A.6.8, A.7.1–A.7.14 and A.8.1–A.8.34; document each exclusion and assess direct and inherited responsibilities. This Annex A assessment contributes to the engagement and does not independently establish full ISMS conformity or issue certification. Stage 1 and readiness remain separate workflows; any certification decision remains with the authorized certification body.
workflow · Context
SOC 2 Type II Interim Testing
Interim fieldwork for the Type II examination: cycle walkthroughs, design assessment against the Trust Services Criteria, the first operating-effectiveness testing wave over the agreed interim evidence window, and exception triage feeding remediation and retest planning before the period closes. Interim SOC 2 Type II fieldwork for the listed control selections and agreed interim window. Later-period testing and the service auditor's independent opinion remain outside this module. Attach this workflow to the existing audit engagement item; retain evidence and conclusions on its workflow steps.
workflow · Context
System and Third-Party Risk Review
Runs on the existing system item. Review system and provider dependencies, assess current risk and control evidence, select response actions, and approve the review record. Deliver the reviewed result and open actions to the responsible register owner and the named companion procedure.
workflow · Context
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
AI Governance & Risk/Impact Assessment
Assess a single AI system end to end under ISO/IEC 42001 (AIMS) and the NIST AI RMF: govern and register the system, map context and risks, measure risks and impacts, manage treatment, produce transparency artifacts, and authorize deployment with monitoring. The instance attaches to an Audit item created for this assessment cycle (audit_type compliance, or advisory for a pre-deployment review); because Studio has no native AI System type, the system under assessment is named in that Audit's scope and its lifecycle/EU-AI-Act detail lives in the scoping memo and step documents. In scope: one named AI system or use case and its lifecycle risk posture. Out of scope: enterprise-wide AI policy authoring and detailed EU AI Act legal obligation mapping, which are consumed as an input handoff package from the EU AI Act Obligation Impact Analysis workflow. The named deliverable is the approved AI assessment package (executive summary plus recommended governance decision), backed by the AI risk register (Risk items, category ai_governance), the model/system card and AI impact-assessment record, and a deployment authorization with live drift/fairness monitoring; approved outputs hand off to Quarterly Board & Audit-Committee GRC Reporting.
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
AI Governance Framework, Roles & Obligations Review
AI Governance Framework, Roles & Obligations Review as a modular, decision-aware workflow. Each quarterly instance runs on the existing "AI Governance Program" Process item (process_type operational, quarterly, process_owner = AI Governance Officer) and enriches its standing registers — it never recreates them. It keeps the AI policy current and republished, refreshes the RACI and competency records, maintains each AI system's resource and dependency inventory, and walks the value-chain obligations register so every provider and deployer duty traces to an owner and evidence. Consumes at launch: the cycle trigger (interval, folded-in annual re-approval, or a regulatory/technology change) and prior-cycle registers — the AI policy as a Policy item (framework iso-42001 + eu-ai-act, domains ai_governance), the obligations register as EU AI Act / ISO 42001 Control items (control_owner = obligation owner), plus the in-scope AI system list, the RACI and competency register, and the per-system resource inventory, which have no native item type and travel as versioned step documents. Deliverables: the republished AI policy version, the refreshed RACI and competency register, the current resource and dependency inventory, the walked obligations register, and a four-area cycle evidence package. In scope: those four governance registers for the AI systems in boundary this quarter; out of scope: the AI systems' own development, risk assessment, and control testing. Terminal — no downstream workflow consumes the output; the cycle closes to its own archived workflow record, linked back to the anchor Process item.
workflow · Context
Regulatory Exam & External Audit Management
Manage a live regulator examination or external audit end to end — from notification intake through request fulfillment, QC’d evidence release, fieldwork support, preliminary-findings response, and commitment closure. Runs on an Audit engagement item created per exam (audit_type = regulatory_exam, or external_attestation for an external audit); the workflow instance attaches to that Audit anchor, and preliminary findings and their corrective-action commitments become linked Issue items. No upstream workflow feeds this — it is triggered by the exam or audit notification itself. In scope: coordinating examiner requests, controlled evidence release, and management responses for a single exam or audit engagement. Out of scope: remediating the underlying control gaps — the findings and committed corrective actions hand off to Finding Remediation & Action-Plan Monitoring — and standing up new obligations surfaced by the exam, which hand off to Regulatory Horizon Scanning & Triage and Regulatory Obligation Implementation.
workflow · Context
AI Service Data Policy & Quality Management Cycle
AI Service Data Policy & Quality Management Cycle as a modular, decision-aware workflow. Each annual instance — and each semiannual regulatory-compliance checkpoint — runs on the existing "AI Service Data Policy & Quality Management" Process item (process_type operational, process_owner = AI Product Owner) and enriches its standing records; it never recreates them. Run by the AI Governance Lead (second line) and owned by the AI Product Owner (first line), it refreshes the customer-facing input data policy and output data policy, collects customer acknowledgements where the changes are material, reviews the AI quality management system for effectiveness, and refreshes the regulatory compliance documentation and obligations register shared with customers. Consumes at launch: the cycle trigger and mode, the in-scope AI service list with each service's value-chain role (a step document — there is no AI System item type), both data policies and the quality manual and procedures as Policy items, and the obligations register as Control items. Deliverables: the published policy versions with their acknowledgement records, the quality management system review record, the refreshed compliance statement and obligations register, the corrective-action log, and an indexed cycle evidence pack. Out of scope: the AI services' own development, risk assessment, and control testing, and fulfilment of individual customer data requests. Terminal — the cycle closes to its own archived workflow record, linked back to the anchor Process item.
workflow · Context
Personal Data Quality & De-identification
Personal Data Quality & De-identification runs as a recurring operate cycle attached to the existing Control for personal-data quality & de-identification (framework gdpr/hipaa/ccpa/nist-800-53, domain data_protection_privacy): each period is a workflow instance that enriches that Control's operating record — never a new Control. The cycle consumes the data map / RoPA, the data-quality ruleset and retention schedule (Policy items), the individual correction-request queue, the disclosure log and the recipient/processor Vendor register, and the de-identification policy; it checks PII accuracy, relevance, timeliness, and completeness, corrects or deletes failing records and notifies downstream recipients under GDPR Art. 19, adjudicates individual correction requests within statutory deadlines, and de-identifies datasets that do not require full identifiers. It produces the exception register (exception Issue items), the corrected-and-deleted set, the recipient correction/deletion notices, and the de-identification and residual-risk reports; systemic findings hand off to the internal privacy backlog as Issue items. This is a terminal operate cycle — the archived, regulator-ready cycle record is the deliverable, not a handoff package for a named downstream workflow.
workflow · Context
AI System Development, Data & Deployment Gate
Runs as a standalone per-release gate cycle — one workflow instance per new AI system or substantial modification. The schema has no native AI System item type, so the instance links (Item relationship) to the existing Control items it operates (UC-AI-04/05/06/07/09; framework eu-ai-act|iso-42001, domains ai_governance) and to the ai_governance Risk it mitigates, and all cycle evidence attaches to its steps. It consumes the AI system inventory profile and the enterprise responsible-AI objectives (Policy items) upstream; the release board then approves those objectives and the per-system requirements before build, governs training, validation, and test data with bias mitigation, executes the pre-deployment impact assessment and EU AI Act risk classification, applies the high-risk conformity obligations where they trigger, assembles Annex IV-grade technical documentation, and records verification-and-validation results and the deployment sign-off. Named deliverables: the risk-classification decision, the pre-deployment impact-assessment report, the Annex IV technical-documentation package, the verification-and-validation report, and the recorded sign-off. Retraining and substantial changes re-enter the same gate as a fresh instance (a self-loop, no downstream handoff).
workflow · Context
AI Transparency & Value-Chain Communications
Each quarterly instance runs against the existing "AI Transparency & Value-Chain Communications" Process item (process_type: business_process, frequency: quarterly), enriching it rather than recreating it, and links to the existing Control items UC-AI-10 and UC-AI-14 (framework: iso-42001 + eu-ai-act, domains: ai_governance) that the cycle executes. A recurring operate cycle that keeps AI system documentation, interaction disclosures, and content marking current with system changes, retains distribution evidence, evaluates AI suppliers (Vendor items) against responsible-AI requirements, and reviews customer needs and communications; the transparency policy and content-marking standard it enforces are Policy items. It consumes no upstream handoff package (a self-originating quarterly cadence) and terminates in no downstream workflow — systemic findings and carry-forwards land as Issue items in the AI governance backlog. In scope: every AI system in production or customer-facing use and every AI supplier providing an AI system, model component, training data, or inference service; out of scope: risk-classification and conformity assessment itself — purpose or risk-class drift is routed to the EU AI Act Impact Analysis workflow (as an observation Issue referencing it) rather than resolved in this cycle.
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
Third-Party ICT Vendor Regulatory Assurance
Third-Party ICT Vendor Regulatory Assurance as a decision-aware workflow. Each cycle runs on its own Audit engagement item (audit_type = vendor_review) created at kickoff, with Audit.scope set to the in-scope legal entities, regimes, and vendor population; every workpaper, decision form, and gap attaches to that instance. In scope: ICT third-party service providers — including intra-group ICT providers — assessed against DORA, NIS2, and US interagency/FFIEC third-party expectations; out of scope: non-ICT vendors, which stay with the general vendor lifecycle. It consumes the arrangement-level inventory, tiering, and due-diligence handoff package from Third-Party Vendor Risk Lifecycle (whose provider records are the Vendor items); refers vendor SOC 1/SOC 2 reports carrying real reliance to the Vendor SOC 1/SOC 2 Report Review & CUEC Mapping workflow and folds back its reliance conclusions; and produces a provision-cited, severity-rated gap register (Issue items linked to the anchor Audit and the affected Control/Vendor records) plus a qualified final assurance package. It hands the validated obligation statuses to the Regulatory Compliance Attestation Cycle, exchanging handoff packages with related workflows instead of duplicating repeated work.
workflow · Context
SOX ITGC Testing
SOX ITGC Testing as a modular, decision-aware workflow. It runs on the existing Audit engagement item for this ITGC cycle (audit_type: sox_testing, period_start/period_end = the test period) — enrich that item, never create a duplicate — while per-control operating-effectiveness results live on Control-hosted SOX testing workflows, one created per in-scope ITGC control per Workflow.customFields.sox.fiscalYear, each hosted directly on the Control under test. It consumes the ICFR scoping handoff package from Annual ICFR Scoping & Risk Assessment, produces the reperformable final ITGC testing package as its named deliverable, and hands the deficiencies off to SOX Deficiency Remediation. In scope: the operating-effectiveness conclusion on the ITGCs protecting in-scope financial systems, reached by referencing the controls-owned NIST 800-53 catalog and its test scripts — not by rebuilding procedures. Out of scope, owned by related workflows: scoping of significant accounts and applications (Annual ICFR Scoping & Risk Assessment), deep completeness-and-accuracy validation of system-generated populations (SOX IPE Validation), and remediation of what fails (SOX Deficiency Remediation, the downstream handoff). It can stand alone, but is designed to exchange handoff packages with these related workflows instead of duplicating repeated work.