Skip to main content
Coverbase ships a curated Control Set library: ready-to-use control set templates you fork into your organization, tailor, and apply. Templates are versioned and maintained by Coverbase, and administrators can promote additional private templates from an uploaded spreadsheet. The library has two halves, reached from different tabs on the Controls page:

Vendor Controls Library

52 templates · 4,099 controls. Frameworks, regulations and questionnaires you assess a third party against: ISO 27001, SIG, HECVAT, NIST CSF, HIPAA, PCI DSS and the rest. Opens from the Vendor Controls tab.

Internal Controls Library

21 templates · 362 controls. Controls Coverbase Inspect evaluates against your own applications by signing in and reading the live admin console. Opens from the Internal Controls tab.
That is 73 templates spanning 4,461 curated controls in total. This page documents each one in more depth than the in-app picker: its full description, the risk types and domains it addresses, typical use cases, its control count, and, where the template is derived from a published framework, a link to the authoritative source.
Which library a template appears in follows from the kind of control set it creates, so a template is only ever listed in one of them. Forking either one produces an ordinary control set you own and can edit; nothing syncs back.
Control counts and wording are Coverbase’s structured interpretation of each source framework, intended to accelerate assessment. They are not a substitute for the official standard. Always consult the linked primary source for authoritative, legally binding text.

​
Vendor Controls Library

The 52 templates below assess a third party. Fork one, tailor it, then apply it to vendors, services, or assessments.

​
Cybersecurity & vendor security

Coverbase’s curated set of publicly verifiable security controls based on observable evidence available without vendor cooperation.Official source: Coverbase Content Library
  • Risk types: Information Security, Third-Party Risk
  • Risk domains: Vendor Due Diligence, Risk Governance
  • Typical use cases: Initial vendor screening; Lightweight due diligence; Passive vendor risk assessment; Pre-engagement risk triage
  • Coverage: 28 controls across 5 sections
Cloud Security Alliance Consensus Assessments Initiative Questionnaire v4, designed to assess cloud service providers against CCM security controls.Official source: CSA Cloud Controls Matrix / CAIQ
  • Risk types: Information Security, Third-Party Risk
  • Risk domains: Cloud Security, Data Protection, Identity & Access Management
  • Typical use cases: Cloud provider due diligence; SaaS vendor security assessment; Cloud security maturity evaluation; CSA STAR certification readiness
  • Coverage: 261 controls across 17 sections
Higher Education Community Vendor Assessment Tool (HECVAT) Full v4, the long-form questionnaire for assessing vendor security in higher education contexts.Official source: EDUCAUSE - HECVAT
  • Risk types: Third-Party Risk, Information Security, Data Privacy
  • Risk domains: Vendor Due Diligence, Data Protection
  • Typical use cases: Higher education vendor assessments; University third-party risk management; EdTech platform security evaluation; FERPA-aligned vendor due diligence
  • Coverage: 227 controls across 18 sections
Higher Education Community Vendor Assessment Tool (HECVAT) Lite v4, a condensed questionnaire for lower-risk vendors in higher education environments.Official source: EDUCAUSE - HECVAT
  • Risk types: Third-Party Risk, Information Security
  • Risk domains: Vendor Due Diligence, Data Protection
  • Typical use cases: Lightweight higher education vendor review; Annual vendor reassessments; Low-risk EdTech evaluation; Tiered vendor risk program (education)
  • Coverage: 56 controls across 11 sections
ISO/IEC 27001:2022 Edition 3, the international standard for information security management systems (ISMS), updated with new controls for cloud security, threat intelligence, and privacy.Official source: ISO/IEC 27001:2022
  • Risk types: Information Security, Regulatory Compliance
  • Risk domains: Risk Governance, Data Protection, Cloud Security
  • Typical use cases: ISO 27001 certification readiness; ISMS implementation assessment; International security compliance; Supply chain security evaluation
  • Coverage: 93 controls across 4 sections
MITRE ATT&CK framework controls mapped to adversary tactics, techniques, and procedures (TTPs) for evaluating threat detection and response capabilities.Official source: MITRE ATT&CK
  • Risk types: Information Security, Operational Risk
  • Risk domains: Threat Intelligence, Incident Response, Network Security
  • Typical use cases: Threat detection capability assessment; Red team readiness evaluation; SOC maturity measurement; Adversary simulation alignment
  • Coverage: 52 controls across 19 sections
The original NIST Cybersecurity Framework covering five core functions: Identify, Protect, Detect, Respond, and Recover. Widely adopted as the foundational cybersecurity standard.Official source: NIST Cybersecurity Framework 1.1
  • Risk types: Information Security, Operational Risk
  • Risk domains: Risk Governance, Network Security, Incident Response
  • Typical use cases: Cybersecurity program baseline; Legacy CSF alignment; Security maturity measurement; NIST CSF 1.1 compliance verification
  • Coverage: 108 controls across 23 sections
NIST Cybersecurity Framework 2.0, updated in 2024 with a new Govern function, covering cybersecurity risk management for organizations of any size.Official source: NIST Cybersecurity Framework
  • Risk types: Information Security, Operational Risk
  • Risk domains: Risk Governance, Network Security, Incident Response
  • Typical use cases: Cybersecurity program governance; Board-level security reporting; Regulatory baseline alignment; Third-party risk governance
  • Coverage: 106 controls across 22 sections
The Shared Assessments SIG Core questionnaire, an 800+ question vendor risk assessment covering 20 risk domains.Official source: Shared Assessments - SIG
  • Risk types: Information Security, Third-Party Risk, Operational Risk
  • Risk domains: Vendor Due Diligence, Cloud Security, Identity & Access Management
  • Typical use cases: Full third-party vendor due diligence; Enterprise vendor risk assessments; Outsourced service provider evaluations; Regulatory-aligned vendor management
  • Coverage: 755 controls across 33 sections
A condensed version of the SIG Core questionnaire for lower-risk vendors, covering the most critical risk domains with fewer questions.Official source: Shared Assessments - SIG
  • Risk types: Third-Party Risk, Information Security
  • Risk domains: Vendor Due Diligence, Data Protection
  • Typical use cases: Lower-risk vendor assessments; Annual reassessments of established vendors; Faster onboarding due diligence; Tiered vendor risk programs
  • Coverage: 126 controls across 33 sections
Vendor Security Alliance (VSA) questionnaire 2025, a vendor security assessment covering cloud security, data management, and operational resilience.Official source: Vendor Security Alliance
  • Risk types: Third-Party Risk, Information Security, Operational Risk
  • Risk domains: Vendor Due Diligence, Cloud Security, Operational Continuity
  • Typical use cases: Vendor security program assessment; Cloud and SaaS vendor evaluation; VSA member organization compliance; Enterprise third-party risk management
  • Coverage: 106 controls across 7 sections

​
Compliance, privacy & payments

California Consumer Privacy Act (CCPA) and California Privacy Rights Act (CPRA) requirements for businesses handling California residents’ personal information.Official source: California OAG - CCPA
  • Risk types: Data Privacy, Regulatory Compliance
  • Risk domains: Privacy Rights, Data Protection
  • Typical use cases: California privacy law compliance; Consumer data rights assessment; Data service provider evaluation; US state privacy law alignment
  • Coverage: 23 controls across 17 sections
COBIT 5/2019 governance and management framework for enterprise IT, covering IT governance, risk management, and information systems controls.Official source: ISACA - COBIT
  • Risk types: Operational Risk, Regulatory Compliance, Financial Controls
  • Risk domains: Risk Governance, Operational Continuity
  • Typical use cases: IT governance program assessment; Enterprise risk management alignment; IT audit readiness; SOX IT controls evaluation
  • Coverage: 30 controls across 7 sections
The customer-side (user entity) controls a SOC 2 report assigns to the organizations that consume a service, organized to mirror the five Trust Services Criteria categories. Use it to track the shared-responsibility controls you must implement for a provider’s SOC 2 controls to operate effectively.Official source: AICPA SOC 2 (Trust Services Criteria)
  • Risk types: Third-Party Risk, Information Security, Regulatory Compliance
  • Risk domains: Vendor Due Diligence, Data Protection, Risk Governance
  • Typical use cases: SOC 2 shared-responsibility tracking; Vendor onboarding CUEC attestation; User-entity control self-assessment; Third-party SOC report review
  • Coverage: 30 controls across 5 sections
EU General Data Protection Regulation (GDPR) standard requirements covering lawful processing, data subject rights, controller obligations, and breach notification.Official source: EU GDPR (Regulation 2016/679)
  • Risk types: Data Privacy, Regulatory Compliance
  • Risk domains: Privacy Rights, Data Protection
  • Typical use cases: EU/EEA data privacy compliance; Data processor assessment; Privacy-by-design evaluation; GDPR vendor due diligence
  • Coverage: 18 controls across 13 sections
NIST SP 800-18 Revision 2, guidance for developing and maintaining system security, privacy, and cybersecurity supply-chain risk management (C-SCRM) plans that document a system’s purpose, boundary, categorization, and selected controls across its life cycle.Official source: NIST SP 800-18 Rev 2
  • Risk types: Regulatory Compliance, Information Security, Operational Risk
  • Risk domains: Risk Governance, Data Protection, Supply Chain
  • Typical use cases: System security plan development; RMF authorization package preparation; Privacy and C-SCRM plan alignment; Federal system documentation review
  • Coverage: 39 controls across 11 sections
The PCI 3DS Core Security Standard defines physical and logical security requirements for environments that perform EMV 3-D Secure (3DS) functions: the 3DS Server, 3DS Directory Server, and 3DS Access Control Server. It comprises Part 1 baseline security requirements and Part 2 3DS-specific requirements, and applies to entities that store, process, or transmit 3DS data or that could impact the security of 3DS transactions.Official source: PCI SSC - 3DS
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Data Protection, Network Security, Financial Reporting
  • Typical use cases: EMV 3-D Secure environment security; 3DS Server / DS / ACS assessment; 3DS data and key management; Authentication service compliance
  • Coverage: 37 controls across 12 sections
The prior major version of the Payment Card Industry Data Security Standard, retired in 2024 but retained for legacy audits and contracts that still reference v3.2.1. Use it for historical gap analysis and transition planning toward PCI DSS v4.0.Official source: PCI SSC Document Library (legacy)
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Financial Reporting, Data Protection, Network Security
  • Typical use cases: Legacy PCI DSS v3.2.1 assessment; Contract referencing v3.2.1; Historical compliance gap analysis; Transition planning to v4.0
  • Coverage: 89 controls across 12 sections
Payment Card Industry Data Security Standard v4.0, the security standard for organizations that handle cardholder data, updated with new authentication and monitoring requirements.Official source: PCI SSC Document Library
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Financial Reporting, Data Protection, Network Security
  • Typical use cases: Payment processing compliance; Merchant security assessment; Card data environment evaluation; PCI QSA audit preparation
  • Coverage: 63 controls across 12 sections
For card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS validated third parties, with no electronic storage, processing, or transmission of cardholder data on the merchant’s systems.Official source: PCI SSC - SAQs
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Financial Reporting, Data Protection, Network Security
  • Typical use cases: Fully outsourced e-commerce merchant; Mail/telephone-order (MOTO) merchant; No electronic cardholder data storage; All payment functions handled by validated third parties
  • Coverage: 22 controls across 7 sections
For e-commerce merchants that partially outsource payment processing to a PCI DSS validated third party but whose own website can impact the security of the payment transaction, with no electronic storage of cardholder data on merchant systems.Official source: PCI SSC - SAQs
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Financial Reporting, Data Protection, Network Security
  • Typical use cases: Partially outsourced e-commerce merchant; Merchant website impacts payment transactions; Direct-post or JavaScript-based payment integration; No electronic cardholder data storage
  • Coverage: 90 controls across 12 sections
For merchants that process cardholder data only via imprint machines or standalone, dial-out payment terminals with no electronic cardholder data storage, and that do not transmit cardholder data over the internet.Official source: PCI SSC - SAQs
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Financial Reporting, Data Protection, Network Security
  • Typical use cases: Imprint-machine merchant; Standalone dial-out terminal merchant; No internet-connected payment processing; No electronic cardholder data storage
  • Coverage: 40 controls across 5 sections
For merchants with payment application systems connected to the internet (for example a POS system on a network with internet access) that do not electronically store cardholder data after a transaction is authorized.Official source: PCI SSC - SAQs
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Financial Reporting, Data Protection, Network Security
  • Typical use cases: Payment application connected to the internet; Internet-connected POS environment; No electronic cardholder data storage; Segmented merchant location network
  • Coverage: 80 controls across 11 sections
For all other merchants not addressed by SAQ types A through C, and for all service providers eligible to complete an SAQ. This SAQ covers substantially the full set of PCI DSS v4.0 requirements.Official source: PCI SSC - SAQs
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Financial Reporting, Data Protection, Network Security
  • Typical use cases: Merchant storing cardholder data electronically; Service provider eligible for SAQ; Full-scope PCI DSS environment; Complex payment processing environment
  • Coverage: 130 controls across 12 sections
Full defined-requirement-level coverage of PCI DSS v4.0 across all 12 requirements, with one control per numbered requirement for organizations that store, process, or transmit cardholder data. Intended for in-depth, QSA-grade assessment of the entire cardholder data environment.Official source: PCI SSC Document Library
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Financial Reporting, Data Protection, Network Security
  • Typical use cases: Full PCI DSS v4.0 audit preparation; Level 1 merchant/service provider assessment; QSA-led compliance evaluation; Cardholder data environment deep review
  • Coverage: 249 controls across 12 sections
The PCI PIN Security Requirements define controls for the secure management, processing, and transmission of personal identification number (PIN) data during online and offline payment transactions on ATMs and attended/unattended POS terminals. They apply to acquirers, processors, and any entity that manages PINs or the cryptographic keys used to protect them.Official source: PCI SSC - PIN Security
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Data Protection, Network Security, Financial Reporting
  • Typical use cases: PIN encryption and key management; ATM and POS terminal security; Cryptographic key lifecycle governance; Acquirer and processor PIN compliance
  • Coverage: 33 controls across 7 sections
The PCI Point-to-Point Encryption (P2PE) Standard defines security requirements for solutions that encrypt account data at the point of interaction and decrypt it only within a secure environment, so that clear-text account data is never present in the merchant environment. It applies to P2PE solution providers, component providers, and merchants seeking to reduce PCI DSS scope through a validated P2PE solution.Official source: PCI SSC - P2PE
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Data Protection, Network Security, Financial Reporting
  • Typical use cases: Point-to-point encryption solution validation; POI device and key-injection management; Merchant PCI DSS scope reduction; Decryption environment (HSM) security
  • Coverage: 38 controls across 6 sections
The PCI Software Security Framework comprises the Secure Software Standard and the Secure Software Lifecycle (Secure SLC) Standard, defining security requirements and assessment procedures for payment software and for the processes used to design, develop, and maintain it. It applies to software vendors and their payment software products, and is the successor to the legacy PA-DSS program.Official source: PCI SSC - Software Security Framework
  • Risk types: Regulatory Compliance, Information Security, Financial Controls
  • Risk domains: Data Protection, Network Security, Financial Reporting
  • Typical use cases: Secure payment software validation; Secure software lifecycle governance; Software vulnerability and threat management; PA-DSS successor compliance
  • Coverage: 40 controls across 20 sections
SOC 2 Type II standard requirements covering the Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy.Official source: AICPA SOC 2 (Trust Services Criteria)
  • Risk types: Audit Readiness, Information Security, Regulatory Compliance
  • Risk domains: Data Protection, Operational Continuity, Risk Governance
  • Typical use cases: SOC 2 audit preparation; Customer security questionnaire responses; Service provider compliance verification; SaaS security due diligence
  • Coverage: 18 controls across 1 sections

​
Financial services & banking

For how these map onto the supervisory expectations themselves, stage by stage, see Regulatory alignment for banks and credit unions.
Bank Secrecy Act (BSA) and Anti-Money Laundering (AML) controls covering customer due diligence, suspicious activity reporting, and transaction monitoring.Official source: FinCEN - Bank Secrecy Act
  • Risk types: Regulatory Compliance, Financial Controls
  • Risk domains: Banking & Finance, Financial Reporting
  • Typical use cases: BSA/AML compliance program assessment; FinCEN regulatory alignment; Financial crime risk management; AML vendor evaluation
  • Coverage: 35 controls across 24 sections
EU Digital Operational Resilience Act (DORA) controls for financial entities, covering ICT risk management, incident reporting, third-party risk, and resilience testing.Official source: EU DORA (Regulation 2022/2554)
  • Risk types: Regulatory Compliance, Operational Risk, Third-Party Risk
  • Risk domains: Resilience, Banking & Finance, Supply Chain
  • Typical use cases: EU financial institution DORA compliance; ICT third-party risk assessment; Digital resilience program evaluation; Financial sector operational continuity
  • Coverage: 25 controls across 6 sections
Federal Financial Institutions Examination Council (FFIEC) guidance on managing third-party service provider relationships for financial institutions.Official source: FFIEC IT Handbook - Outsourcing
  • Risk types: Regulatory Compliance, Third-Party Risk, Financial Controls
  • Risk domains: Banking & Finance, Supply Chain, Risk Governance
  • Typical use cases: Financial institution third-party oversight; Bank vendor due diligence; FFIEC regulatory compliance; Financial services outsourcing review
  • Coverage: 30 controls across 13 sections
Gramm-Leach-Bliley Act (GLBA) Safeguards Rule (16 CFR Part 313) requirements for financial institutions protecting customer financial information.Official source: 16 CFR Part 313 (eCFR)
  • Risk types: Regulatory Compliance, Data Privacy, Financial Controls
  • Risk domains: Banking & Finance, Data Protection
  • Typical use cases: GLBA compliance for financial services; Customer financial data protection; Financial institution privacy program; FTC Safeguards Rule alignment
  • Coverage: 20 controls across 3 sections
Detailed interagency guidance on third-party relationships for banking organizations, with controls across the full vendor lifecycle.Official source: Interagency Guidance on Third-Party Relationships
  • Risk types: Regulatory Compliance, Third-Party Risk, Operational Risk
  • Risk domains: Banking & Finance, Supply Chain, Risk Governance
  • Typical use cases: Full-lifecycle bank vendor oversight; Critical third-party assessments; OCC/Fed/FDIC regulatory alignment; Senior management reporting on TPRM
  • Coverage: 156 controls across 12 sections
Interagency guidance on third-party relationships for banking organizations, covering risk management expectations for vendor lifecycle management.Official source: Interagency Guidance on Third-Party Relationships
  • Risk types: Regulatory Compliance, Third-Party Risk
  • Risk domains: Banking & Finance, Supply Chain
  • Typical use cases: Bank third-party risk program; Federal banking agency compliance; Vendor lifecycle risk management; Regulatory examination preparation
  • Coverage: 44 controls across 13 sections
National Credit Union Administration (NCUA) Information Security Examination (ISE) program covering cybersecurity maturity for credit unions.Official source: NCUA - Information Security Examination
  • Risk types: Regulatory Compliance, Information Security
  • Risk domains: Banking & Finance, Risk Governance
  • Typical use cases: Credit union security examination; NCUA regulatory compliance; Credit union cybersecurity maturity; NCUA examination preparation
  • Coverage: 30 controls across 17 sections
Sarbanes-Oxley Act (SOX) controls based on the COSO internal control framework, covering financial reporting accuracy and IT general controls for public companies.Official source: COSO - Internal Control Framework
  • Risk types: Financial Controls, Regulatory Compliance, Audit Readiness
  • Risk domains: Financial Reporting, Risk Governance
  • Typical use cases: SOX compliance program assessment; Public company internal controls review; IT general controls evaluation; External auditor readiness
  • Coverage: 56 controls across 12 sections

​
Healthcare & life sciences

Good Practice (GxP) controls for life sciences, covering GMP, GLP, and GCP requirements for pharmaceutical, biotech, and medical device companies.Official source: FDA - GxP Compliance
  • Risk types: Life Sciences, Regulatory Compliance, Operational Risk
  • Risk domains: Pharmaceutical, Data Protection
  • Typical use cases: Pharma/biotech supplier qualification; FDA/EMA compliance assessment; Clinical trial data integrity; GxP-regulated vendor due diligence
  • Coverage: 83 controls across 11 sections
Health Insurance Portability and Accountability Act (HIPAA) security and privacy rules covering administrative, physical, and technical safeguards for protected health information (PHI).Official source: HHS - HIPAA Security Rule
  • Risk types: Healthcare, Data Privacy, Regulatory Compliance
  • Risk domains: Healthcare Compliance, Data Protection
  • Typical use cases: HIPAA Business Associate assessment; Healthcare data security evaluation; PHI vendor due diligence; Healthcare compliance auditing
  • Coverage: 42 controls across 10 sections

​
AI governance

AIUC-1, the AI Usage & Controls standard for AI agents, covering security, safety, reliability, data & privacy, accountability, and societal risk. Its 51 controls span six domains (A Data & Privacy, B Security, C Safety, D Reliability, E Accountability, F Society) and crosswalk to the EU AI Act, NIST AI RMF, ISO/IEC 42001, MITRE ATLAS, and OWASP.Official source: AIUC-1
  • Risk types: AI Risk, Information Security, Third-Party Risk, Regulatory Compliance
  • Risk domains: AI Governance, Data Protection
  • Typical use cases: AI agent vendor due diligence; AI safety and security assessment; Generative AI supplier evaluation; AI governance readiness
  • Coverage: 51 controls across 6 sections
Cloud Security Alliance AI Controls Matrix (AICM) 2025, a framework of security controls specifically designed for AI/ML systems and platforms.Official source: CSA AI Controls Matrix
  • Risk types: AI Risk, Information Security, Regulatory Compliance
  • Risk domains: AI Governance, Cloud Security, Data Protection
  • Typical use cases: AI/ML platform security assessment; Cloud AI vendor evaluation; AI security controls gap analysis; Emerging AI regulatory alignment
  • Coverage: 243 controls across 19 sections
EU AI Act (Regulation (EU) 2024/1689), the European Union’s horizontal regulation for artificial intelligence. This template organizes the Act’s core obligations by theme: prohibited practices, risk classification, high-risk system requirements, provider and deployer duties, transparency, general-purpose AI models, and post-market governance.Official source: Regulation (EU) 2024/1689
  • Risk types: AI Risk, Regulatory Compliance, Data Privacy
  • Risk domains: AI Governance, Risk Governance
  • Typical use cases: EU AI Act readiness assessment; High-risk AI system conformity review; AI vendor regulatory due diligence; GPAI model obligation mapping
  • Coverage: 22 controls across 8 sections
ISO/IEC 42001:2023, the international management-system standard for artificial intelligence (AIMS). This template covers the Annex A reference controls across nine control objectives, from AI policy and impact assessment to data governance and third-party relationships.Official source: ISO/IEC 42001:2023
  • Risk types: AI Risk, Regulatory Compliance, Audit Readiness
  • Risk domains: AI Governance, Risk Governance
  • Typical use cases: AI management system (AIMS) assessment; ISO/IEC 42001 readiness and gap analysis; AI vendor due diligence; Responsible AI program evaluation
  • Coverage: 38 controls across 9 sections
MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems), a knowledge base of adversary tactics and techniques against AI/ML systems, modeled on MITRE ATT&CK. This template turns the ATLAS tactics into a defensive assessment of a vendor’s resilience to adversarial machine-learning attacks.Official source: MITRE ATLAS
  • Risk types: AI Risk, Information Security, Third-Party Risk
  • Risk domains: AI Governance, Threat Intelligence
  • Typical use cases: Adversarial ML threat assessment; AI/ML security vendor evaluation; AI red-team and threat-model scoping; AI supply-chain security review
  • Coverage: 14 controls across 1 section
NIST AI Risk Management Framework (AI RMF 1.0), a voluntary framework for managing risks of AI systems across four core functions: Govern, Map, Measure, and Manage.Official source: NIST AI Risk Management Framework
  • Risk types: AI Risk, Operational Risk, Regulatory Compliance
  • Risk domains: AI Governance, Risk Governance
  • Typical use cases: AI system risk assessment; Responsible AI program evaluation; AI vendor due diligence; AI governance readiness
  • Coverage: 72 controls across 4 sections
NIST SP 800-53 controls adapted for AI systems, a catalog of security and privacy controls for AI risk management in federal and enterprise contexts.Official source: NIST SP 800-53 Rev 5
  • Risk types: AI Risk, Information Security, Regulatory Compliance
  • Risk domains: AI Governance, Risk Governance, Data Protection
  • Typical use cases: Federal AI system compliance; AI risk control catalog alignment; Enterprise AI security program; FedRAMP-adjacent AI assessments
  • Coverage: 17 controls across 4 sections
OWASP Top 10 for Large Language Model Applications (2025), the ten most critical security risks for LLM and generative-AI applications, from prompt injection and sensitive-information disclosure to excessive agency and unbounded consumption. Used to assess the security posture of AI/LLM vendors.Official source: OWASP Top 10 for LLM Apps
  • Risk types: AI Risk, Information Security, Third-Party Risk
  • Risk domains: AI Governance, Data Protection
  • Typical use cases: LLM application security assessment; Generative AI vendor security review; AI red-team scoping; Secure AI development gap analysis
  • Coverage: 10 controls across 1 section

​
Operations & supply chain

Five templates for suppliers of physical goods and services, where the risk is a stopped production line rather than a breach. Each is organised into six sections covering the supplier lifecycle from planning through verification. Unlike the frameworks above, these are written by Coverbase rather than derived from a single published standard, so they cite no external source. Individual controls do reference standards where one applies, such as ISO 9001 for quality systems or EU 10/2011 for food contact materials.
Whether a supplier can keep your line fed, and what happens when it cannot. Covers continuity planning and annual testing, recovery objectives, alternate sites and the lead time to qualify one, ownership and transfer of customer tooling, lead time and buffer stock, sub-tier visibility and geographic concentration, and how constrained supply is allocated across customers. Asks for a dated continuity test rather than the existence of a plan, and treats an alternate source the supplier cannot name as no alternate at all.
  • Risk types: Operational Risk, Third-Party Risk
  • Risk domains: Operational Continuity, Supply Chain, Resilience
  • Typical use cases: Production-critical supplier review; Single-source exposure; Business continuity due diligence
  • Sections: Continuity planning, Alternate sourcing and capacity, Lead time and inventory, Upstream dependency, Disruption response, Verification
  • Coverage: 27 controls across 6 sections
Oversight of a third party building your product. Covers quality system scope at the producing site, change control and which changes need your approval, undisclosed onward subcontracting, batch traceability, non-conformance handling and who may release held product, and capacity and customer-owned tooling. Backward traceability alone does not bound a recall, so it also asks the forward question: given a suspect input lot, which finished units contain it.
  • Risk types: Operational Risk, Third-Party Risk, Audit Readiness
  • Risk domains: Manufacturing Quality, Supply Chain, Vendor Due Diligence
  • Typical use cases: Contract manufacturer onboarding; Toll processing oversight; Private label supplier qualification
  • Sections: Quality management system, Change control, Subcontracting, Traceability and records, Non-conformance and corrective action, Capacity and tooling
  • Coverage: 25 controls across 6 sections
Freight forwarders, carriers and third-party logistics providers. Covers cargo cover set against the governing liability convention, chain of custody and seal integrity, condition monitoring and excursion reporting, the named list of facilities that will hold your goods, contingency routing and peak capacity, and trade compliance. Insurance limits and convention caps are asked separately, because the gap between the two is where your exposure sits.
  • Risk types: Operational Risk, Third-Party Risk
  • Risk domains: Logistics, Supply Chain, Operational Continuity
  • Typical use cases: 3PL onboarding; Freight forwarder review; Cold chain partner qualification
  • Sections: Coverage and liability, Chain of custody, Condition control, Network and facilities, Contingency, Trade compliance
  • Coverage: 24 controls across 6 sections
Resin, chemical and commodity inputs. Covers certificates of analysis issued against an agreed specification, composition disclosure including substances below reportable thresholds, restricted substance and PFAS declarations, regulatory change monitoring, country of origin and lot traceability, responsible sourcing and forced labour risk, and shelf life and retained samples. Undisclosed blending across sources breaks the link between certificate and delivery, so it is asked directly.
  • Risk types: Operational Risk, Regulatory Compliance, Third-Party Risk
  • Risk domains: Supply Chain, Risk Governance
  • Typical use cases: Raw material supplier qualification; Restricted substance diligence; Responsible sourcing review
  • Sections: Specification and certification, Composition and restricted substances, Regulatory monitoring, Origin and traceability, Responsible sourcing, Handling and stability
  • Coverage: 25 controls across 6 sections
Converters and packaging suppliers. Covers product contact compliance across the markets you sell into, declarations of compliance and what triggers a reissue, recycled content substantiation and whether a claim is physical or mass balance, the data behind packaging waste reporting, migration testing conditions, and recall support. Recycled content in a product contact layer usually needs its own authorisation, which a general recycled claim does not provide.
  • Risk types: Regulatory Compliance, Operational Risk
  • Risk domains: Manufacturing Quality, Risk Governance, Supply Chain
  • Typical use cases: Packaging supplier qualification; Product contact compliance; Packaging waste reporting readiness
  • Sections: Product contact compliance, Declarations and change management, Sustainability claims, Extended producer responsibility, Testing and verification, Recall and incident support
  • Coverage: 23 controls across 6 sections

​
Internal Controls Library

The 21 templates below are evaluated against your own applications, not a vendor’s. Coverbase Inspect signs in to the application with read-only credentials, drives its admin console, and decides each control from what it can actually see.
These controls are written for an agent rather than a person. Each one states an expectation carrying its own threshold, names the admin surface to look at plus the alternate labels other vendors use for it, and defines what counts as incomplete. Incomplete is a real outcome, not a failure: an application that does not sell a capability cannot fail a control about it. Every control also forbids destructive or outbound actions, so a run reads state and never changes it.
Start with Security Configuration Baseline on a newly onboarded application, then layer a domain set on top. It is deliberately vendor-neutral and short enough to run against the long tail of niche tools that will never justify a bespoke control set.

​
Identity and access

How workforce users actually sign in to an application, read from the live admin console rather than from an attestation. Covers MFA enforcement and its exceptions, SSO federation and whether the local login form survives beside it, password and session policy, and the authentication events the tenant keeps. Written for continuous Inspect runs: every expectation carries its own threshold so a run can decide it without asking anyone.
  • Risk types: Information Security, Operational Risk
  • Risk domains: Identity & Access Management
  • Typical use cases: Continuous verification that MFA is enforced, not merely available; Detecting authentication policy drift between assessments; Evidence that SSO enforcement survived a tenant migration; Pre-contract validation of a SaaS application’s login controls
  • Coverage: 22 controls across 4 sections
Who holds administrative power inside an application right now, and what bounds it. Counts and names administrators from the live member list, checks whether privilege is standing or requested, and looks for the break-glass, service, and API principals that ordinary access reviews miss. Sized so an Inspect run can complete it against most admin consoles in one session.
  • Risk types: Information Security, Operational Risk, Audit Readiness
  • Risk domains: Identity & Access Management, Risk Governance
  • Typical use cases: Continuous administrator-count monitoring between access reviews; Detecting privilege creep in a high-risk SaaS application; Evidence for a SOX or SOC 2 access-review control; Finding service and break-glass accounts nobody owns
  • Coverage: 18 controls across 4 sections
Joiner, mover and leaver evidence read from inside the application rather than from the HR system that is supposed to drive it. Finds the accounts that outlived their owner, the invitations nobody accepted, the external collaborators still holding a seat, and the offboarding steps that stop at the identity provider and never reach the app.
  • Risk types: Information Security, Operational Risk, Audit Readiness
  • Risk domains: Identity & Access Management, Risk Governance
  • Typical use cases: Continuous leaver-account detection between HR and SaaS; Evidence that offboarding reached every in-scope application; Finding dormant seats before a renewal negotiation; Access-review support for an audited application
  • Coverage: 15 controls across 4 sections

​
Application scope and integrations

What an application is being used for today, checked against what it was approved for. An assessment scopes a vendor once; the vendor then ships features, an admin turns one on, and the application quietly starts touching data or performing functions nobody vetted. These controls read the live feature and module state so a re-inspection surfaces the drift as a diff.
  • Risk types: Third-Party Risk, Operational Risk, Regulatory Compliance
  • Risk domains: Vendor Due Diligence, Risk Governance
  • Typical use cases: Detecting features enabled after the vendor was assessed; Confirming an application stayed inside its approved use case; Re-scoping trigger for an annual vendor review; Shadow-module discovery inside an approved application
  • Coverage: 13 controls across 3 sections
The fourth-party surface an application accumulates. Every OAuth grant, installed app, webhook and inbound connection is a path for data to leave the tenant, and most of them were authorised by an individual user rather than through a review. These controls enumerate the connections, read their scopes, and check whether an administrator ever has to approve one.
  • Risk types: Information Security, Third-Party Risk, Data Privacy
  • Risk domains: Supply Chain, Data Protection, Identity & Access Management
  • Typical use cases: Fourth-party discovery inside an approved application; OAuth scope review for a data-bearing SaaS tenant; Detecting user-authorised integrations that bypassed review; Shadow-integration monitoring between assessments
  • Coverage: 18 controls across 4 sections
The settings any business application should hold regardless of what it does. Deliberately vendor-neutral and short enough to run against every application in an estate, including the long tail of niche tools that will never justify a bespoke control set of their own. Use it as the default set for a newly onboarded application and layer a domain set on top.
  • Risk types: Information Security, Operational Risk
  • Risk domains: Identity & Access Management, Data Protection
  • Typical use cases: Default control set for every newly onboarded application; Baseline coverage across the long tail of niche SaaS tools; Configuration drift detection between assessments; Fast first Inspect run on an unfamiliar application
  • Coverage: 16 controls across 3 sections
What the organization is paying for against what it is using. Seat waste, unassigned licences, dormant accounts and shadow expansion are financial findings that happen to be readable from the same admin surfaces as the security ones, so a run that is already logged in should collect them.
  • Risk types: Financial Controls, Operational Risk, Third-Party Risk
  • Risk domains: Vendor Due Diligence, Risk Governance
  • Typical use cases: Seat utilisation evidence ahead of a renewal negotiation; Detecting licence expansion between contract reviews; Finding dormant paid seats across an estate; Reconciling contracted entitlement against deployed configuration
  • Coverage: 12 controls across 2 sections

​
Data handling and privacy

The storage, encryption, backup and key-management state an application exposes to its tenant. Most of this is the vendor’s to configure, but the parts a tenant owns (customer-managed keys, backup schedules, storage region, attachment handling) drift silently and are exactly what a SOC 2 report will not tell you about this tenant on this day.
  • Risk types: Information Security, Operational Risk
  • Risk domains: Data Protection, Cloud Security
  • Typical use cases: Verifying customer-managed encryption keys are still bound to the tenant; Confirming backup configuration between assessments; Storage region validation for a data-residency commitment; Evidence for an encryption-at-rest control
  • Coverage: 13 controls across 3 sections
Which categories of personal data an application actually holds, established from field names, object schemas and data-classification surfaces rather than from a questionnaire. Includes the masking, minimisation and subject-rights machinery a privacy programme depends on. Every instruction reads metadata: Inspect establishes that a field exists, never what any individual’s value is.
  • Risk types: Data Privacy, Regulatory Compliance, Information Security
  • Risk domains: Data Protection, Privacy Rights
  • Typical use cases: Continuous PII inventory for a records-of-processing obligation; Detecting personal data appearing in an application never scoped for it; Evidence that masking is applied to identifiers in a support tool; Privacy review of a newly onboarded SaaS application
  • Coverage: 16 controls across 4 sections
Where data sits, how long it stays, and what actually happens when somebody deletes it. These are contractual and regulatory commitments that live as tenant settings, which means they can be changed by an administrator without anyone renegotiating the contract, and a point-in-time assessment would never notice.
  • Risk types: Data Privacy, Regulatory Compliance, Operational Risk
  • Risk domains: Data Protection, Privacy Rights
  • Typical use cases: Verifying a contractual data-residency commitment still holds; Retention-policy drift detection between audits; Evidence for a records-management control; Confirming deletion reaches backups and logs
  • Coverage: 15 controls across 3 sections
Every way data leaves an application through a route the application itself provides: public links, external sharing, downloads, bulk exports, printing and email forwarding. These settings are changed by administrators for good operational reasons and are almost never revisited, which is what makes them worth reading on every run rather than once a year.
  • Risk types: Information Security, Data Privacy, Operational Risk
  • Risk domains: Data Protection
  • Typical use cases: Continuous monitoring of external sharing defaults; Finding public links created before a policy tightened; Evidence for a data-loss-prevention control; Egress review of a collaboration application
  • Coverage: 16 controls across 4 sections
The HIPAA Security Rule technical safeguards, expressed as things an agent can read from a live application rather than as policy language. Covers unique user identification, emergency access, automatic logoff, audit controls, transmission security and the minimum-necessary access standard. Written for covered entities and business associates running clinical, claims or patient- facing SaaS.
  • Risk types: Regulatory Compliance, Data Privacy, Healthcare
  • Risk domains: Healthcare Compliance, Data Protection, Identity & Access Management
  • Typical use cases: Continuous HIPAA Security Rule evidence for an in-scope application; Detecting PHI appearing in an application with no BAA; Minimum-necessary access verification between audits; Business associate application monitoring
  • Coverage: 21 controls across 4 sections
GDPR obligations that are configuration rather than paperwork: where personal data sits, who processes it, what the tenant can produce for a subject request, how long records live, and which transfers leave the EEA. Read from the live application so the record of processing reflects the tenant as configured today rather than as described at onboarding.
  • Risk types: Data Privacy, Regulatory Compliance
  • Risk domains: Privacy Rights, Data Protection
  • Typical use cases: Keeping an Article 30 record of processing accurate between reviews; Verifying an international transfer commitment still holds; Establishing that subject-rights requests can actually be served; Privacy review of an EEA-facing SaaS application
  • Coverage: 22 controls across 4 sections

​
AI usage

The AI surface a vendor has switched on inside an application. This is the fastest-drifting scope in any SaaS estate: features arrive enabled by default in a release the tenant did not choose, they read whatever the application holds, and they route it to a model the assessment never named. These controls enumerate what is on, what it reads, where it sends, and whether tenant data trains anything.
  • Risk types: AI Risk, Data Privacy, Third-Party Risk, Information Security
  • Risk domains: AI Governance, Data Protection, Supply Chain
  • Typical use cases: Detecting AI features enabled by a vendor release nobody reviewed; Establishing whether tenant data trains a vendor model; AI inventory for an EU AI Act or ISO 42001 obligation; Continuous monitoring of an application’s AI scope
  • Coverage: 23 controls across 4 sections
AI that acts rather than answers. An agent configured inside an application holds a standing identity, a set of tools, and permission to write, which makes it a privileged principal that no access review lists and no joiner process created. These controls enumerate the agents, read what they may do, and check whether their actions are attributable and reversible.
  • Risk types: AI Risk, Information Security, Operational Risk
  • Risk domains: AI Governance, Identity & Access Management
  • Typical use cases: Inventorying autonomous agents operating inside a business application; Establishing what an agent is permitted to write and to whom it can send; Attribution evidence for actions taken by an AI agent; Continuous monitoring of agent scope expansion
  • Coverage: 17 controls across 3 sections

​
Resilience, performance and audit

Resilience evidence gathered from inside a live application on an ordinary working day, rather than from a scheduled Saturday failover test the vendor agreed to in advance. Reads the tenant’s own status, incident, maintenance and capacity surfaces, and records the observations that only mean something as a series: which instance served the run, what the response looked like, whether the data present today matches yesterday.
  • Risk types: Operational Risk, Third-Party Risk, Regulatory Compliance
  • Risk domains: Operational Continuity, Resilience
  • Typical use cases: Continuous third-party resilience testing without vendor coordination; Regulatory evidence for an operational resilience programme; Detecting an unannounced failover or instance migration; Building an uptime record independent of the vendor’s own status page
  • Coverage: 21 controls across 4 sections
Whether the service the tenant is receiving matches the service that was contracted. Reads the uptime figures, support response commitments, credit mechanisms and observed responsiveness that together answer ‘did they actually meet the SLA’, a question most organizations can only ask retrospectively, from the vendor’s own numbers.
  • Risk types: Operational Risk, Third-Party Risk, Financial Controls
  • Risk domains: Operational Continuity, Vendor Due Diligence
  • Typical use cases: Independent SLA conformance evidence for a renewal negotiation; Continuous uptime measurement not sourced from the vendor; Service credit eligibility detection; Support responsiveness monitoring for a critical application
  • Coverage: 14 controls across 3 sections
Whether an application can tell you what happened in it. Covers event coverage, attribution, retention, export and alerting: the properties that decide whether an investigation is possible at all. Kept deliberately small so it can run alongside a domain-specific set rather than competing with it for session time.
  • Risk types: Information Security, Audit Readiness, Operational Risk
  • Risk domains: Incident Response, Risk Governance
  • Typical use cases: Establishing whether an application supports a forensic investigation; Log retention and export verification for an in-scope application; Evidence for a monitoring control in an audited environment; Pre-incident readiness check on a critical SaaS tenant
  • Coverage: 13 controls across 3 sections

​
Application classes

A CRM holds the customer relationship: contacts, pipeline, contract terms, support history and whatever a salesperson attached to a record. It is usually the widest-reach application an organization runs and the one with the most integrations hanging off it. Written against the surfaces a Salesforce, HubSpot, Dynamics or Zoho admin console actually exposes.
  • Risk types: Information Security, Data Privacy, Operational Risk
  • Risk domains: Data Protection, Identity & Access Management
  • Typical use cases: Continuous monitoring of the organization’s primary CRM; Detecting customer data leaving through a CRM integration; Sharing-model verification after a CRM administrator change; Pipeline and contract data exposure review
  • Coverage: 22 controls across 4 sections
An HRIS holds the most sensitive employee data an organization has (compensation, bank details, national identifiers, performance and health-related absence), and it is the system that drives access everywhere else. These controls read the access model, the identifier fields, the payroll change trail and the downstream provisioning that depends on it.
  • Risk types: Data Privacy, Information Security, Financial Controls
  • Risk domains: Data Protection, Identity & Access Management, Financial Reporting
  • Typical use cases: Continuous monitoring of the system of record for employee data; Payroll change control evidence; Verifying HR-driven provisioning still reaches downstream applications; Employee personal-data exposure review
  • Coverage: 18 controls across 4 sections
Controls for applications operating inside a regulated financial institution, where the supervisory expectation is continuous rather than annual. Covers segregation of duties, records retention under books-and-records rules, communications capture, change control and the operational resilience evidence supervisors increasingly ask to see for a critical third party.
  • Risk types: Financial Controls, Regulatory Compliance, Operational Risk
  • Risk domains: Banking & Finance, Financial Reporting, Operational Continuity
  • Typical use cases: Continuous control evidence for a regulated financial institution; Books-and-records retention verification on a communications tool; Segregation-of-duties monitoring in a financial application; Critical third-party resilience evidence for a supervisor
  • Coverage: 17 controls across 4 sections