GRCLibrary.ai

Document type

Procedures

59 documents. Multi-actor, cross-functional workflows that coordinate several roles.

Documents, 59

Every document of this type

Each with its area and its purpose; a document that states no purpose gets a line naming its type and area. A title in a corpus area opens the document's page, which holds the record and, where the document has them, its outline, frameworks, and related documents; a title in the Library area is a library specification with no page and opens its source on GitHub. The full text of every document is read on GitHub.

  • AI Assurance Case ProcedureAIThis procedure defines how an assurance case for an AI system is established, argued, evidenced, reviewed, reported, maintained, and closed. ai/framework-ai-assurance-evidence.md owns the evidence model that the assurance case organizes: the claim taxonomy, the evidence classes, the attestation tiers, and the sufficiency criteria. That framework deliberately defines no assurance activity; this procedure supplies the activity. It adapts the assurance case structure of ISO/IEC/IEEE 15026-2:2022 (Clause 5) to the corpus's existing evidence model, by paraphrase and clause reference only: the 15026 series is a licensed proprietary reference and is not reproduced here.
  • AI Audit ProcedureAIThis procedure defines the process for planning, executing, reporting, and following up on AI audits across the organization's AI system inventory. AI audits verify that deployed AI systems operate within defined ethical, technical, and compliance boundaries, and that the AI Management System (AIMS) remains effective and improving.
  • AI Evaluation ProcedureAIThis procedure defines the process for evaluating AI systems before initial deployment, after significant changes, and at scheduled review intervals. AI evaluation provides the evidence base for deployment approval, ongoing governance, and risk management decisions made by the AI Governance Council.
  • AI Model Lifecycle Management ProcedureAIThis procedure defines the end-to-end lifecycle management process for AI models, from initial development or procurement through deployment, monitoring, retraining, and decommissioning. It ensures that every AI model in the organization's inventory is governed, documented, and reviewed throughout its operational life.
  • AI Model Risk Assessment ProcedureAIThis procedure defines a reusable method for assessing AI model risk. It supports consistent evaluation of data provenance, lineage, interpretability, representation, robustness, alignment, monitoring, evidence sufficiency, residual risk, and approval readiness.
  • AI System Impact Assessment ProcedureAIThis procedure defines a reusable method for assessing AI system impacts before approval, deployment, material change, expanded use, supplier onboarding, or retirement.
  • Foundation Model Lifecycle ProcedureAIThis procedure governs the lifecycle of foundation and frontier models consumed by the organization: evaluation, supplier selection, contractual integration, deployment, ongoing monitoring, version-transition management, and exit. It complements the AI model lifecycle management procedure (which is generic) with the specific obligations and risk vectors of foundation-model consumption.
  • Integrated AI and Privacy Assessment ProcedureAIA single system can fall in scope of more than one assessment regime at once: the data protection impact assessment (DPIA) under GDPR Article 35, the automated decision-making (ADM) provisions of GDPR Article 22, the AI System Impact Assessment for a high-risk AI system, and the fundamental rights impact assessment (FRIA) under EU AI Act Article 27. The library carries each instrument separately. This procedure is the router that ties them together: given a system's regime triggers, it says which assessments to run, which limb each one owns, and how they compose into one coordinated pass.
  • Training Data Governance ProcedureAIThis procedure governs the lifecycle of data used to train, fine-tune, or otherwise shape model behaviour. It addresses sourcing, lawful basis, consent, sensitive-content removal, lineage, deletion propagation, supplier disclosure, and the recurring obligations that arise when a model derived from a dataset remains in use after the dataset itself has changed.
  • Architecture Review ProcedureArchitectureThis procedure defines how proposed architectures are reviewed before commitment. It expresses outcomes and operating expectations for the architecture review board (ARB) and for ad-hoc review.
  • Audit Planning ProcedureComplianceThis procedure operationalizes the Internal Audit Standard (compliance/standard-internal-audit.md) by defining the specific steps, responsibilities, templates, and timelines required to plan, prepare, execute, and report on individual internal audits and the overall annual audit programme.
  • Control Testing ProcedureComplianceThis procedure defines the processes for testing the design and operating effectiveness of internal controls across the organization's governance, risk, compliance, security, and operational domains. Control testing provides objective evidence that controls are functioning as intended and supports certification, audit readiness, and continuous assurance activities.
  • Corrective and Preventive Action (CAPA) ProcedureComplianceThis procedure governs the identification, recording, assessment, treatment, verification, and closure of nonconformities and opportunities for improvement across all GRC domains.
  • HIPAA Operational Compliance ProcedureComplianceThis procedure operationalizes the HIPAA obligations that a covered entity or business associate must execute on a clock: the HIPAA Privacy Rule individual-rights response timelines, the Notice of Privacy Practices and minimum-necessary duties, the cross-rule six-year documentation-retention requirement, the breach-determination test that decides whether the notification clock starts, and the business associate agreement content requirement. It translates the regulatory landscape mapped in the Healthcare Sector GRC Requirements Annex into repeatable operational steps, so a compliance office can run its request-handling, records-retention, breach-response, and vendor-assurance programmes directly.
  • Mergers and Acquisitions Due Diligence ProcedureComplianceThis procedure operationalizes the governance, risk, and compliance (GRC) due diligence required when the organization acquires, merges with, or takes a controlling interest in another entity. The GRC Programme Management and Annual Review Procedure names a merger, acquisition, or divestiture as a major-organizational-change trigger for a programme review, but provides no transaction-level checklist, pre-close instrument, or integration playbook. This procedure is that instrument: it defines the phases, the GRC dimensions to assess, the deal-breaker escalation path, and the hand-off into the organization's standing controls.
  • UK AEO IT Self-Assessment ProcedureComplianceThis procedure defines the process for completing the IT and cybersecurity elements of the organization's annual Authorized Economic Operator (AEO) and AEO-S (Authorized Economic Operator Security and Safety) self-assessment. Its held basis is section 12.2 of the HMRC Customs Technical Handbook (AEO), on monitoring, which says that HMRC will review AEO status periodically, that regular monitoring is the primary responsibility of the business, and that it is recommended that the business continue to self-assess its compliance with the conditions of the authorization. The annual cycle and its internal submission deadline are the organization's own schedule for that recommended, continuing self-assessment: no held section names a self-assessment submission to HMRC or an annual cycle. The held HMRC security and safety criteria (UK HMRC AEO security and safety criteria handbook, section 11) say that procedures are to be documented and made available for HMRC during the audit of the AEO criteria (section 11.1), and the only self-assessment they name is the one in section 11.2, on the security and safety risk assessment.
  • Secure Code Review ProcedureDev securityThis procedure defines how code is reviewed for security defects before merge to a protected branch and before release. It applies to human-authored, AI-assisted, and AI-generated code, and to changes that affect runtime behaviour, dependencies, configuration, infrastructure-as-code, and security-critical components.
  • Continuous Improvement Register ProcedureGovernanceThis procedure defines the process for capturing, tracking, and managing improvement initiatives across all governance domains through the Continuous Improvement Register (CIR). The CIR is the organization's central record of proactive improvement actions, distinct from reactive CAPA actions, and supports the PDCA (Plan-Do-Check-Act) continual improvement cycle across GRC, security, compliance, and operational domains.
  • GRC Programme Management and Annual Review ProcedureGovernanceThis procedure governs the annual GRC programme management cycle. It defines how the GRC library is reviewed, updated, version-controlled, reported on, and presented to the Enterprise Risk Committee (ERC). It establishes the cadence and accountability framework for annual governance reviews, quarterly reporting, policy owner attestation, control testing scheduling, risk treatment status updates, and ERC reporting.
  • Library Quality and Review Cadence ProcedureGovernanceThis procedure governs the continuous quality and review of artefacts in this CC BY-SA 4.0 governance library. It complements the continuous assurance and improvement framework (which is library-wide) by setting concrete cadence, drift-detection, refresh, and retirement practice for individual documents.
  • Standard Version Upgrade ProcedureGovernanceThis procedure governs how the library transitions from one edition of an external standard it cites to a newer edition (for example, a published revision of an ISO/IEC standard, a new NIST Special Publication revision, or a new COBIT release). It exists because ad-hoc, one-location edits produce drift: a version bumped in the document a maintainer happened to be reading while the same citation stays stale elsewhere, or a plausible-but-nonexistent edition year introduced during a hurried update.
  • Whistleblower and Incident Reporting ProcedureGovernanceThis procedure defines the channels, protections, investigation processes, and reporting obligations for whistleblower disclosures and internal incident reporting. It ensures that concerns about misconduct, legal violations, ethical breaches, security incidents, or regulatory non-compliance are reported safely, investigated thoroughly, and resolved appropriately.
  • Change Management and Configuration Control ProcedureOperationsTo ensure that changes to production systems are controlled, traceable, and reversible, minimizing disruption to services and preventing unauthorized modifications to security-critical configurations.
  • Endpoint Management and Device Compliance ProcedureOperationsTo ensure that all organizational endpoints, including workstations, laptops, servers, and mobile devices, are enrolled, hardened, continuously monitored, and maintained in a compliant state throughout their operational lifetime, reducing the risk of compromise arising from misconfiguration, unpatched software, or unsanctioned devices accessing corporate resources.
  • Media Handling and Transport ProcedureOperationsTo protect information held on physical and digital media from unauthorized disclosure, loss, or tampering during storage, internal movement, external transfer, and disposal. This procedure implements the media controls required by the Data Classification and Handling Standard and the Records Retention and Destruction Standard, ensuring that the method of media protection is always proportionate to the sensitivity classification of the information it contains.
  • OT Change Management ProcedureOperationsThis procedure defines change management for Operational Technology (OT) environments. It extends the general change management and configuration control procedure (operations/procedure-change-management-and-configuration-control.md) with OT-specific requirements: extended change windows aligned with production-maintenance schedules, mandatory vendor coordination for vendor-controlled systems, regression testing for safety-critical functions, and integration with safety-management of change (MOC) under IEC 61511 where the change affects Safety Instrumented Systems.
  • OT Incident Response ProcedureOperationsThis procedure defines the operational sequence for responding to security incidents in Operational Technology (OT) environments. It extends the general security incident response procedure (security/procedure-security-incident-response.md) with OT-specific considerations: safety-first decision-making, vendor coordination, longer recovery windows, and integration with safety management.
  • Patch Management ProcedureOperationsThis procedure defines the end-to-end process for identifying, classifying, testing, authorizing, deploying, and verifying security patches and software updates across the organization's technology estate. It operationalizes the patch remediation SLAs established in the Production Security Requirements Standard and the Vulnerability Management Procedure, translating policy obligations into repeatable operational steps.
  • Release Management ProcedureOperationsThis procedure governs the release of software, configuration, and infrastructure changes to production. It complements the change management procedure (which authorizes the change) and the secure code review procedure (which validates the artefact) by governing how changes move from acceptance to live operation safely, predictably, and reversibly.
  • Security Monitoring and Alert Management ProcedureOperationsTo ensure that security events from all production systems and environments are collected, normalized, correlated, and acted upon in a timely and consistent manner. This procedure operationalizes the control requirements established in the Logging and Monitoring Standard, providing the Security Operations Centre (SOC) with a clear and repeatable workflow from log ingestion through alert closure or escalation to the Incident Response Procedure.
  • Threat Intelligence and SIEM Operations ProcedureOperationsThis procedure defines the operational processes for managing threat intelligence, operating the Security Information and Event Management (SIEM) platform, developing and maintaining correlation rules, conducting threat hunting, and sharing intelligence with sector peers. It establishes the practices by which threat intelligence is operationalized into detection capability and feeds back into continual improvement of the organization's security posture.
  • Data Protection and Privacy Breach Response ProcedurePrivacyThis procedure defines the lifecycle for detecting, containing, assessing, notifying, remediating, and closing personal data breaches and privacy incidents. It establishes mandatory roles, response timeframes, jurisdiction-specific notification obligations, and evidence requirements, and supports meeting regulatory notification deadlines for all applicable laws.
  • Data Subject Rights Management ProcedurePrivacyThis procedure defines the end-to-end process for receiving, validating, fulfilling, and documenting requests from individuals exercising their rights over personal data held by the organization. It ensures that compliance with applicable data subject rights obligations under GDPR, UK GDPR, PIPEDA, PIPL, and related laws is maintained, and establishes consistent standards for identity verification, response timelines, denial justification, and record keeping.
  • Privacy Impact and Cross-Border Transfer ProcedurePrivacyThis procedure defines the process for conducting Privacy Impact Assessments (PIAs), AI Impact Assessments (AI-IAs), and Cross-Border Data Transfer Assessments to identify, evaluate, and mitigate privacy and data protection risks associated with data processing activities, including AI training and inference operations.
  • Works Council and Employee Representative Consultation ProcedurePrivacyThis procedure defines the steps for consulting works councils and employee representatives where such consultation, or co-determination, is legally required before a workforce monitoring capability is deployed or materially changed. It operationalizes the consultation and co-determination requirement of the Workforce Network Monitoring Policy (Section 4, item 3, and the workforce-representatives role in Section 9), giving the steps, the information to provide, the evidence to retain, and the sign-off that demonstrate the duty was met.
  • Backup and Recovery ProcedureResilienceThis procedure defines an organization-neutral process for backup, replication, recovery validation, restoration, and evidence capture for business-critical systems and data.
  • Business Impact Analysis ProcedureResilienceThis procedure defines a reusable method for conducting business impact analysis. It identifies critical processes, dependencies, impact tolerances, recovery priorities, and evidence required to support continuity and disaster recovery planning.
  • Continuity and Recovery Testing ProcedureResilienceThis procedure defines a reusable method for planning, executing, documenting, evaluating, and improving continuity and recovery tests.
  • Crisis Management and Emergency Operations Activation ProcedureResilienceThis procedure defines a reusable process for activating, operating, and deactivating a crisis management structure and emergency operations coordination capability during significant disruptive events.
  • Cross-Domain Incident Coordination ProcedureResilienceThis procedure defines how an incident is coordinated across domains when more than one response stream is involved: information security, privacy, supplier, AI, operations, communications, legal, and executive. It provides the common lifecycle, the domain-ownership decision rule, the joint command structure, and the hand-off checklists that the domain-specific procedures build on.
  • Security Incident Reporting and Escalation ProcedureResilienceThis procedure defines a reusable process for reporting, triaging, escalating, documenting, and transferring security incidents into incident response, privacy breach response, crisis management, supplier escalation, or risk governance processes.
  • Risk Acceptance ProcedureRiskThis procedure defines how residual risk is formally accepted, reviewed, monitored, renewed, or closed. It prevents undocumented risk ownership from being quietly converted into institutional folklore.
  • Risk Assessment Methodology ProcedureRiskThis procedure defines the methodology for conducting risk assessments across all organizational domains including information security, privacy, AI, business continuity, supply chain, and operational risk. It establishes a consistent approach for identifying, analyzing, evaluating, and treating risks, aligned with ISO 31000:2018 and ISO/IEC 27005:2022.
  • Risk Register ProcedureRiskThis procedure defines how risks are recorded, maintained, reviewed, escalated, and closed in a risk register.
  • Access Control ProcedureSecurityThis procedure defines the processes for granting, reviewing, modifying, and revoking access to organizational systems, applications, data, and network resources. It implements the principle of least privilege and need-to-know access model across all platforms, ensuring access is appropriate, authorized, and periodically reviewed.
  • Cryptographic Key Operations ProcedureSecurityThis procedure defines the step-by-step operational instructions for all cryptographic key operations including generation, registration, distribution, activation, rotation, revocation, and destruction. It implements the controls established in the Cryptographic Key Lifecycle Management Framework and ensures that consistent, auditable execution of key management operations is achieved.
  • Identity Management ProcedureSecurityThis procedure defines the processes for managing digital identities throughout their lifecycle: creation, maintenance, authentication configuration, privileged access management, and termination. It ensures that every identity within the organization's systems is unique, accountable, appropriately privileged, and subject to regular review.
  • IT Onboarding and Offboarding ProcedureSecurityThis procedure governs the provisioning and deprovisioning of system access and IT assets across the full personnel lifecycle: pre-joining, first-day onboarding, role transfers and changes, voluntary departure, and involuntary termination. It ensures that access rights are granted on a least-privilege basis, are aligned to approved role profiles, and are removed promptly and completely when no longer required.
  • Key Escrow and Recovery ProcedureSecurityThis procedure governs key escrow and key recovery operations within the organization. It distinguishes recovery of productivity-data keys (where business continuity favours recovery) from recovery of cryptographic root and signing keys (where recovery is governed by stricter ceremony and dual control). It defines the escrow architecture, the authority model, the recovery triggers, the ceremony, and the auditable evidence retained.
  • Security Disciplinary Process ProcedureSecurityThis procedure defines the process for investigating and responding to security policy violations, including graduated disciplinary actions proportionate to severity. It ensures that security breaches, misuse of assets, and non-compliance events are handled consistently, fairly, and in accordance with employment law and regulatory obligations.
  • Security Incident Response ProcedureSecurityThis procedure defines the end-to-end lifecycle for managing information security incidents: from initial detection and triage through containment, eradication, recovery, regulatory notification, and post-incident review. It establishes mandatory roles, response timeframes, evidence-handling requirements, and escalation obligations that apply to all confirmed and suspected security incidents.
  • Vulnerability Management ProcedureSecurityTo ensure that vulnerabilities in organizational systems, applications, cloud environments, and third-party components are identified, assessed, prioritized, and remediated within defined timeframes, reducing exposure to exploitation and maintaining a defensible security posture.
  • Fourth-Party and Nth-Party Risk ProcedureSupply chainThis procedure defines how the organization identifies, monitors, and escalates risk arising from suppliers beyond the direct third-party relationship: fourth-party (the supplier's supplier) and nth-party (any subsequent tier). It supports a financial entity's DORA ICT third-party risk management, limited to the Article 29(2) and Article 30(2)(a) parts named in the Framework alignment section, GDPR Article 28 sub-processor obligations, NIS 2 supply-chain security obligations, and the organization's broader supplier governance.
  • Supplier Audit ProcedureSupply chainThis procedure defines the process for conducting periodic audits of suppliers, vendors, and third-party service providers to verify adherence to contractual obligations, security standards, regulatory requirements, and ethical conduct principles.
  • Supplier Due Diligence ProcedureSupply chainThis procedure defines the methodology for pre-qualification, risk assessment, and ongoing compliance review of suppliers, vendors, and third-party partners. It establishes a consistent, evidence-based approach to evaluating supplier fitness prior to engagement and at defined reassessment intervals throughout the supplier lifecycle.
  • Supplier Exit and Data Return ProcedureSupply chainThis procedure defines the steps for managing the termination of a supplier relationship, ensuring that access is revoked, data is returned or securely deleted, contractual obligations are confirmed as fulfilled, and the transition to an alternative supplier or in-house capability is conducted without operational disruption or residual data risk.
  • Supplier Onboarding Security Review ProcedureSupply chainThis procedure defines the steps, gates, and responsibilities for conducting a security review as part of the supplier onboarding process. It ensures that every new supplier is risk-classified, assessed against the requirements of supply-chain/standard-supplier-security-and-privacy-assurance.md, and approved before receiving access to organization systems, data, or networks.
  • Supplier Ongoing Monitoring ProcedureSupply chainThis procedure defines the activities, frequencies, and escalation steps for ongoing monitoring of active supplier relationships. Monitoring ensures that supplier risk ratings remain current, contractual obligations are being met, and emerging risks are identified before they cause harm to the organization's operations, data, or compliance posture.
  • Third-Party AI Due Diligence ProcedureSupply chainThis procedure defines the AI-specific due diligence steps required before engaging any third-party AI service provider, AI model supplier, AI agent platform, or AI-enabled software-as-a-service application.

With script, All Documents, filtered to Procedures, lists these 59 documents, and the area chips holding any of them, and its text filter, narrow them further.