# Abbreviations and Descriptions (/docs/abbreviations)
# Abbreviations and Descriptions
A comprehensive glossary of terms and abbreviations used throughout Safeguard documentation.
## Safeguard Products
| Term | Description |
| ---------------- | ------------------------------------------- |
| **ESSCM** | Enterprise Software Supply Chain Manager |
| **OSM** | Open Source Manager |
| **TPRM** | Third Party Risk Manager |
| **Portal** | Centralized SBOM management platform |
| **Griffin AI** | Purpose-built LLM for supply chain security |
| **AI Remediate** | Automated vulnerability remediation feature |
## Security Terms
| Term | Description |
| -------- | ---------------------------------------------- |
| **CVE** | Common Vulnerabilities and Exposures |
| **CVSS** | Common Vulnerability Scoring System |
| **EPSS** | Exploit Prediction Scoring System |
| **KEV** | Known Exploited Vulnerabilities (CISA catalog) |
| **NVD** | National Vulnerability Database |
## SBOM Standards
| Term | Description |
| ------------- | ------------------------------------------ |
| **SBOM** | Software Bill of Materials |
| **SPDX** | Software Package Data Exchange format |
| **CycloneDX** | OWASP SBOM format |
| **VEX** | Vulnerability Exploitability eXchange |
| **PURL** | Package URL - universal package identifier |
## Supply Chain Security
| Term | Description |
| -------- | ------------------------------------------ |
| **SLSA** | Supply chain Levels for Software Artifacts |
| **SSDF** | Secure Software Development Framework |
| **SCA** | Software Composition Analysis |
| **ESCM** | Software Supply Chain Management |
## Compliance
| Term | Description |
| ------------ | ---------------------------------------------------------- |
| **EO 14028** | Executive Order 14028 on Cybersecurity |
| **FedRAMP** | Federal Risk and Authorization Management Program |
| **IL5** | Impact Level 5 (DoD classification) |
| **NTIA** | National Telecommunications and Information Administration |
| **SOC2** | Service Organization Control 2 |
## Infrastructure
| Term | Description |
| ------- | -------------------------------- |
| **ACR** | Azure Container Registry |
| **ECR** | Elastic Container Registry (AWS) |
| **GCR** | Google Container Registry |
| **OCI** | Open Container Initiative |
| **SCM** | Source Code Management |
## Authentication
| Term | Description |
| -------- | ------------------------------------------- |
| **SSO** | Single Sign-On |
| **SAML** | Security Assertion Markup Language |
| **OIDC** | OpenID Connect |
| **SCIM** | System for Cross-domain Identity Management |
| **MFA** | Multi-Factor Authentication |
## Definitions
### Software Bill of Materials (SBOM)
A formal, structured list of components, libraries, and modules that make up a piece of software, along with their relationships and metadata.
### AI Remediate
Safeguard's automated remediation feature powered by Griffin AI that generates pull requests to fix vulnerabilities.
### Attestation Score
A measure of package integrity and trustworthiness based on malicious package detection, supply chain verification, and provenance attestation.
### Risk Score
Overall security scoring based on the package itself, including vulnerability count, severity distribution, maintenance status, and community trust.
# Account Recovery & Keys (/docs/account-recovery)
# Account Recovery & Keys
## Password reset & change
* **Forgot password.** `POST /auth/api/v1/password/forgot` with your account email. Safeguard emails a reset link; the token is valid for **24 hours**. In the app, this is the **"Forgot password?"** link on the login screen.
* **Reset with token.** `POST /auth/api/v1/password/reset` with the token from the email plus your new password. Password rules: **minimum 8 characters, with at least one uppercase letter, one lowercase letter, one number, and one special character.**
* **Change password (while signed in).** `POST /auth/api/v1/password/change` with your current and new password. The same complexity rules apply.
## Secret keys (Guard SDK)
Secret keys are self-service credentials the Guard SDK uses to pull live policy. They live under the base path `/auth/api/v1/secret-keys`.
* **Create.** `POST /auth/api/v1/secret-keys` with a `purpose`. The **plaintext key is returned only once**, in the create response — Safeguard stores only a hash, so copy it immediately. If you lose it, revoke the key and create a new one.
* **List your keys.** `GET /auth/api/v1/secret-keys`.
* **Revoke.** `POST /auth/api/v1/secret-keys/{id}/revoke` disables the key so it stops working; you can create a replacement at any time.
* **Delete.** `DELETE /auth/api/v1/secret-keys/{id}` removes it permanently.
These self-service secret keys are distinct from the user API keys and organization tokens covered in [RBAC, Teams & Organizations](/docs/rbac-teams) — see that page for those credential types rather than duplicating them here.
## Locked out of SSO / SSO provider down
* **You only have SSO and can't get in** (the SSO provider is down, misconfigured, or an admin disabled SSO): use the **"Request access"** option on the login screen. This calls `POST /auth/api/v1/sso/request-access` and emails **every Tenant Admin** in your tenant that you've requested access, with a link for them to invite or link your account. So the first people who can help are **your own tenant's Admins/Owners** — they can re-enable SSO, invite you, or link your account.
* **If password login is still enabled** for your tenant, use the password reset flow above as a fallback to get in without SSO.
* **If SSO is your only method and no admin is reachable** (for example, the sole admin is themselves locked out): this needs Safeguard support — contact Safeguard support to arrange recovery.
For the admin-side emergency-access mechanism, see the [Break-Glass](/docs/rbac-teams) section of RBAC, Teams & Organizations. For SSO setup, see [SSO Authentication](/docs/sso-authentication).
# AI-BOM & Model Security (/docs/ai-bom-model-security)
# AI-BOM & Model Security
As models ship inside products, the same supply chain risks that affect code affect model weights. Safeguard treats AI artifacts as first-class objects with their own SBOM — an **AI-BOM** — and applies equivalent governance to their lifecycle.
## What an AI-BOM Contains
For every model in your environment, Safeguard captures:
* **Model identity** — name, version, architecture, parameter count, dtype, quantization.
* **Weight provenance** — where the weights came from (Hugging Face, internal registry, customer-provided) and the hash.
* **Signing status** — whether the weights are signed; by whom; on what transparency log.
* **Fine-tune lineage** — which base model, which adapter, which dataset.
* **Training / fine-tuning data** — dataset references, licenses, PII / regulated-data flags where declared.
* **Dependencies** — `transformers`, `torch`, `vllm`, quant libraries, tokenizer packages, config files.
* **Evaluation metrics** — if provided by the producer.
* **Deployment targets** — which workloads load these weights.
The AI-BOM is emitted in CycloneDX ML-BOM extension format and SPDX 3.0 AI profile.
## Integrations
Safeguard connects to:
* **Hugging Face** — org, user, private repos. Auto-discovers models you've published or starred.
* **MLflow** — model registry, experiments, versions.
* **AWS SageMaker Model Registry**.
* **Vertex AI Model Registry (GCP)**.
* **Azure ML Model Registry**.
* **Databricks Model Serving**.
* **Kubeflow / KServe**.
* Custom registries via a simple CRUD API.
## Risks Safeguard Tracks
### Pickle-Based Payloads
PyTorch's default `pickle` serialization can execute code at load time. Safeguard scans weights for embedded executable code and flags any model that would run code outside allow-listed operations when loaded.
### Model-Weight Backdoors
Eagle runs statistical tests on weights for:
* Trojan triggers (a specific input pattern produces attacker-controlled output).
* Class-level backdoors (one class systematically mis-classified under a trigger).
* Gradient-inversion susceptibility.
Findings are probabilistic; Safeguard reports the likelihood score and contributing evidence.
### Prompt Injection / Jailbreak Surfaces
For agentic systems that call Safeguard-wrapped LLMs, the AI-BOM annotates which models have:
* Built-in jailbreak resistance tests passing / failing.
* Input / output filter chains applied at serving time.
* Tool-use allow-lists enforced.
### Training-Data License Risk
For fine-tuned models, Safeguard tracks the dataset provenance and flags:
* Unknown-license data.
* Copyleft data used in proprietary models.
* Regulated data (PII, PHI, PCI) used without controls.
### Model Card Discrepancies
If a vendor's model card claims a training set but the weights show signs of additional data, Safeguard surfaces the discrepancy.
## Governance Policies
Enforce policies at load time:
```yaml
apiVersion: safeguard.sh/v1
kind: Policy
metadata:
name: ai-model-policy
spec:
targets:
- kind: Model
labels:
env: production
rules:
- id: require-signed-weights
condition: signatures.valid == false
effect: BLOCK
- id: no-unsafe-weights
condition: weights.unsafe_code == true
effect: BLOCK
- id: allowlist-publishers
condition: weights.publisher NOT IN ["internal", "huggingface:meta-llama", "huggingface:mistralai", "huggingface:anthropic"]
effect: WARN
```
Served models that fail load-time verification won't be loaded.
## Load-Time Verification
The Safeguard model loader verifies, at load time:
* Weight hash matches the attested hash.
* Signature verifies against the configured trust anchors.
* No disallowed code execution on load.
If any check fails, loading aborts.
## Fine-Tuning Lineage
Every fine-tune you run produces a signed attestation capturing:
* Base model + version.
* Training data snapshots (content hashes, not raw data).
* Hyperparameters and seed.
* Evaluation metrics.
* Environment (hardware, software, time).
The lineage is queryable — for any served model, you can answer: *"Show me every model this was derived from and every dataset that touched it."*
## Agent Security (Inference Time)
For LLM-powered agents:
* Tool-call logs are retained with prompt / response hashes.
* Safeguard validates that each tool call matches a declared tool surface.
* Unexpected tool calls (allowed but not typical for the workload) are surfaced.
* Prompt-injection attempts are detected and scored.
See the [MCP Threat Model blog post](/resources/blog/model-context-protocol-threat-model-2026) for deeper treatment.
## CLI
There is no CLI command for listing, verifying or exporting AI-BOMs yet. To scan a directory of model files for unsafe deserialization or embedded code:
```bash
safeguard aisec scan --dir ./models
```
## Related
* [AI Models (Griffin, Eagle, Lino)](/docs/ai-models) — Safeguard's own models.
* [Asset Discovery](/docs/asset-discovery) — how AI models are discovered.
* [Attestation & Signing](/docs/attestation-signing) — model-weight signing.
* [Compliance](/docs/compliance) — EU AI Act, NIST AI RMF, ISO 42001.
# AI-BOM Discovery (/docs/ai-bom)
# AI-BOM Discovery
You can't govern AI assets you don't know you have. AI-BOM discovery builds a continuously-updated inventory of every AI asset across your code, cloud, and connected SaaS — the bill of materials that AI-SPM's posture scoring, model scanning, and governance all build on.
## What it inventories
Discovery runs across three surfaces and catalogues each asset in your inventory:
| Surface | What is discovered | Asset types |
| --------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
| **Code** | Imports of AI SDKs (`openai`, `anthropic`, `langchain`, `transformers`, `llama_index`); model weight files (`.pt`, `.safetensors`, `.gguf`); prompt templates; notebooks; MCP server configuration | Models, services, prompts, notebooks, MCP servers |
| **Cloud** | Managed inference endpoints — SageMaker, Bedrock, Vertex AI — discovered through your cloud connectors | Endpoints, models |
| **SaaS** | Connected but unsanctioned AI tools surfaced through shadow-AI detection | Services |
Vector databases (Pinecone, Weaviate, pgvector) are inventoried as vector stores, and agent definitions as agents. Discovery brings AI signals that were previously scattered across separate checks into one place rather than duplicating them.
## The AI-BOM
Every discovered asset is catalogued with its type, name, source, format, and metadata, and the assets for a product are assembled into an **AI-BOM**: a tenant/org-scoped snapshot of your AI footprint at a point in time. The AI-BOM is the foundation the rest of AI-SPM builds on: model scanning attaches findings to the model assets it inventories, and the posture score reads the inventory for its AI-visibility factor (you can't have good posture over assets you can't see).
## Findings it produces
Discovery itself is an inventory pass, so its primary output is the AI-BOM rather than findings. The assets it surfaces feed the engines that do emit findings:
* **Model assets** are handed to [AI-SPM](/docs/ai-spm) model scanning, which produces AI-security findings (malware and hidden code in model files) in the [unified findings model](/docs/unified-findings).
* **Shadow-AI services** surface unsanctioned tools for governance review.
* **Missing-visibility gaps** lower your AI-visibility posture score.
## How to enable
AI-BOM discovery is part of the AI-SPM engine and is **admin-toggleable** via the `ff.aispm` [feature flag](/docs/unified-findings#feature-flags), enforced server-side. Once enabled, discovery runs across connected repositories, cloud accounts, and SaaS integrations through the standard scan flow, and the AI-BOM is queryable in the app and through the API.
## Related
* [AI-SPM](/docs/ai-spm) — model-artifact malware scanning over the models this inventory finds.
* [AI Gateway](/docs/ai-gateway) — runtime guardrails for the LLM apps and endpoints in the AI-BOM.
* [AI-BOM & Model Security](/docs/ai-bom-model-security) — model provenance, signing, and lineage governance.
* [Asset Discovery](/docs/asset-discovery) — discovery across the rest of your estate.
* [Unified Findings & Feature Flags](/docs/unified-findings) — where AI findings land and how the engine is toggled.
# AI Gateway (LLM Firewall) (/docs/ai-gateway)
# AI Gateway (LLM Firewall)
The AI Gateway is a runtime enforcement point for the AI in your applications — the analog of the [Package Firewall](/docs/package-firewall), but for prompts, responses, and tool calls instead of dependencies. It evaluates every LLM interaction against a set of guardrails and can observe, redact, or block, all without becoming a single point of failure for the protected app.
> **Rollout note.** The gateway's **decision core is built** — the evaluation engine, the guardrail checks, the monitor-mode telemetry path, and the safe-fail behavior. **Inline proxy enforcement (redact/block on live traffic) is rolling out.** Monitor mode is available to evaluate traffic and emit guardrail events today; enforce mode is gated behind an explicit per-tenant policy plus the `ff.aispm_gateway` flag. Default behavior is fail-open with alert — the gateway never breaks your AI app.
## Monitor vs enforce
The gateway runs as an inline proxy (or a thin SDK shim around your LLM client) between your app and the model provider, in one of two modes:
* **Monitor** — every prompt, response, and tool call is evaluated, a guardrail event is recorded, and traffic passes through unchanged. This is the safe way to baseline what enforcement *would* do before turning it on.
* **Enforce** — the gateway acts on its verdict: **redact** PII or secret egress, or **block** injection and jailbreak attempts, per your policy.
Enforce mode requires the `ff.aispm_gateway` feature flag and explicit per-tenant opt-in. Monitor mode is the default everywhere.
## Guardrails
Each interaction is checked along the direction it flows:
| Path | Check | Default verdict |
| -------- | ------------------------------------------------------------------------------------------- | ------------------ |
| Prompt | **Direct prompt injection** — pattern plus classifier detection | block / monitor |
| Prompt | **Indirect injection** — scans retrieved or tool-supplied content, not just the user's turn | block / monitor |
| Prompt | **Jailbreak** patterns | block / monitor |
| Prompt | **Secret / PII in the prompt** | redact |
| Response | **PII / secret egress** — sensitive data leaving in the model's output | redact |
| Response | **Toxicity** and **hallucination** detection | monitor |
| Response | **Output-format / schema** enforcement | block on violation |
| Both | Per-tenant **rate / abuse** limits | throttle |
Indirect injection matters specifically because retrieved content (RAG results, tool output) is untrusted — the gateway inspects it, not only the human's input.
## Safe-fail by design
The gateway is built so that a failure in the gateway is never a failure of your application:
* **Fail-open by default.** On any gateway error or timeout, traffic is allowed through and an alert is raised. Fail-closed is available only if a tenant explicitly opts in.
* **Resource-capped.** Each request has an evaluation budget (default 150 ms). Over budget or under backpressure, the gateway passes traffic through with an alert rather than blocking the app.
* **Bounded inspection.** Bodies larger than the configured limit are truncated for scanning and flagged as truncated.
## Configuration
The gateway is configured per tenant. A representative policy:
```yaml
aigateway:
mode: monitor # monitor | enforce
fail_mode: open # open (never break the app) | closed
eval_budget_ms: 150 # per-request eval cap; over budget -> pass through + alert
provider: { name: anthropic, upstream: "https://api.anthropic.com" }
checks:
injection: block
indirect_injection: block
pii_egress: redact
secret_egress: redact
jailbreak: block
toxicity: monitor
hallucination: monitor
rate: { rpm_per_tenant: 600, burst: 60 }
redact: { patterns: [email, ssn, api_key, jwt], replacement: "[REDACTED]" }
```
The default policy is monitor mode, fail-open, with injection/jailbreak set to block and PII/secret egress set to redact. There is no CLI command for running the gateway yet.
## Findings and telemetry
Gateway decisions are high-volume runtime telemetry, so they are recorded as **guardrail events** rather than as standard findings — one event per decision, carrying the direction, verdict, category, model name, rule, mode, and latency overhead. Guardrail events are tenant-scoped and audited. Raw prompt and response text is **never persisted** — events carry redacted metadata only. Static AI issues (model scans, agent/MCP analysis) still flow into the [unified findings model](/docs/unified-findings) as AI-security findings.
## Related
* [AI-SPM](/docs/ai-spm) — model-artifact scanning for the weights your apps load.
* [AI-BOM Discovery](/docs/ai-bom) — inventory of the LLM apps and endpoints the gateway protects.
* [Red Team](/docs/red-team) — validating that your AI guardrails actually hold.
* [Package Firewall](/docs/package-firewall) — the same monitor/enforce pattern for dependencies.
* [Unified Findings & Feature Flags](/docs/unified-findings) — how the AI engines are toggled.
# AI Models (Griffin, Eagle, Lino) (/docs/ai-models)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# AI Models
Safeguard develops and operates three purpose-built AI models for software supply chain security. Each is trained on security-specific corpora (vulnerability databases, patch diffs, exploit PoCs, SBOM graphs, license texts, incident postmortems) rather than general-purpose web data.
## Model Overview
| Model | Role | Primary Use |
| ----------- | ---------------------------- | --------------------------------------------------------- |
| **Griffin** | Remediation and reasoning | Autonomous patching, vulnerability explanation, chat |
| **Eagle** | Discovery and classification | Zero-day candidate detection, malicious package detection |
| **Lino** | Compliance and attestation | Policy evaluation, SBOM QA, regulatory mapping |
All three share an ensemble retrieval layer backed by the Safeguard knowledge graph (CVEs, EPSS, KEV, OSV, upstream advisories, exploit feeds, and customer telemetry).
## Lineup facts
Griffin, Eagle and Lino are one model each. None of them comes in sizes: there is no Lite, S, M, L or XL. The model catalog at [safeguard.sh/models](https://safeguard.sh/models) lists Lino as Lion, next to Zero, which answers data questions with no model at all.
| Model | Model id | Parameters | Context window | Price per 1M tokens |
| ------------------------------ | ------------------- | ------------------------------------ | ------------------------------ | --------------------------------- |
| **Griffin** | `safeguard/griffin` | 750 billion | 1.1 million tokens (1,100,000) | $0.0001 input, $0.0001 output |
| **Eagle** | `safeguard/eagle` | 70 billion | 1 million tokens (1,000,000) | $0.00001 input, $0.00001 output |
| **Lino** (Lion in the catalog) | `safeguard/lion` | 15 billion | 128K tokens (128,000) | $0.000001 input, $0.000001 output |
| **Zero** | `safeguard/zero` | None: no model weights, no inference | Not applicable | $0. Zero uses no model tokens. |
None of them can be called through Safeguard's inference API yet: the API is in early access, and a request naming one of these models is refused with `503 model_unavailable`. See [Safeguard models](/docs/console/safeguard-models).
## Griffin
Griffin is the flagship reasoning model — the one most customers interact with directly through chat, AI Remediate, and the MCP server.
### What Griffin does
* **Autonomous remediation** — generates pull requests that upgrade, patch, or replace vulnerable dependencies. Reviews the diff, runs tests, iterates until green.
* **Vulnerability reasoning** — explains CVEs in context, assesses reachability against the specific codebase, recommends prioritization.
* **Natural language querying** — "show me all production workloads with KEV-listed CVEs published in the last 30 days".
* **Multi-step workflows** — chains discovery, scoring, remediation, and PR submission into a single autonomous run.
### Griffin versions
| Version | Released | Availability | Notes |
| ----------------------- | -------- | -------------------- | ------------------------------------------------------------------- |
| **Griffin 1.0** | 2024-Q2 | GA (all tiers) | First production release. Initial remediation corpus. |
| **Griffin 1.5** | 2024-Q4 | GA (all tiers) | Added reachability-aware prioritization and SLSA reasoning. |
| **Griffin 2.0** | 2025-Q2 | GA (all tiers) | Autonomous multi-file PRs. Long-context SBOM ingestion. |
| **Griffin 2.5** | 2025-Q4 | GA (all tiers) | Added SAST/DAST reasoning, improved test-repair loops. |
| **Griffin 3.0** | 2026-Q1 | GA (all tiers) | Default today. Tool-use agent loop, multi-repo awareness. |
| **Griffin 3.1-preview** | 2026-Q2 | Preview (Enterprise) | Evaluation dataset-hardened; reduced hallucination on obscure CVEs. |
Pick your version in **Settings → AI Models**. Enterprise customers can pin a version for reproducibility.
## Eagle
Eagle is the detection model. Unlike Griffin (which reasons about known vulnerabilities), Eagle finds new ones.
### What Eagle does
* **Malicious package detection** — classifies npm / PyPI / Maven uploads as likely benign, suspicious, or malicious based on install-script behavior, code patterns, and registry metadata.
* **Zero-day candidate detection** — flags code changes that introduce likely exploitable patterns, feeding the TAOR pipeline.
* **Typosquat and brand-impersonation detection** — finds packages masquerading as popular libraries.
* **Behavioral anomaly detection** — flags runtime workloads whose network, filesystem, or process behavior deviates from baseline.
### Eagle versions
| Version | Released | Availability | Notes |
| ------------- | -------- | ------------ | -------------------------------------------------------------------- |
| **Eagle 1.0** | 2024-Q3 | GA | Malicious npm package classifier. |
| **Eagle 2.0** | 2025-Q1 | GA | Added PyPI, Maven, crates.io. Behavioral model. |
| **Eagle 2.5** | 2025-Q3 | GA | Registered as inline detector for npm `--before-publish` hooks. |
| **Eagle 3.0** | 2026-Q1 | GA | Default today. Unified package-ecosystem detector + runtime anomaly. |
Eagle runs inline in the Safeguard registry (Gold) and on customer-configured webhooks. It also feeds the zero-day research queue (see [Zero-Day Discovery](/docs/zero-day-discovery)).
## Lino
Lino is the compliance model. It reads standards, policies, and evidence — and decides whether an artifact complies.
### What Lino does
* **Regulatory mapping** — maps a control catalog (NIST 800-53, ISO 27001 Annex A, CRA essential requirements, SSDF tasks) to concrete evidence from your Safeguard environment.
* **SBOM quality scoring** — evaluates CycloneDX / SPDX documents against NTIA minimum elements and CycloneDX completeness.
* **Policy authoring** — given a plain-English intent ("block any production image with an unpatched critical KEV CVE"), Lino drafts a policy YAML.
* **Attestation reasoning** — validates SLSA / in-toto attestations and explains why an artifact fails a required level.
### Lino versions
| Version | Released | Availability | Notes |
| ------------ | -------- | ------------ | ------------------------------------------------------------------------ |
| **Lino 1.0** | 2025-Q1 | GA | FedRAMP HIGH and EO 14028 mapping. |
| **Lino 1.5** | 2025-Q3 | GA | CRA, DORA, NIS2 regulatory mapping. |
| **Lino 2.0** | 2026-Q1 | GA | Default today. Multi-jurisdiction policy authoring. FedRAMP 20x support. |
Lino powers the Compliance dashboard in ESSCM and is available via the `POST /v1/compliance/evaluate` API.
## Deployment Options
Griffin, Eagle, Lino and Zero can run on-prem, air-gapped, in a private cloud (VPC) and in public cloud:
* **Public cloud**: the default is Safeguard's shared environment, designed to FedRAMP HIGH requirements, with no setup required. Safeguard can also be deployed on the public cloud you choose.
* **Private cloud (VPC)**: a single-tenant inference cluster in a private network, for Enterprise accounts.
* **On-prem**: in your own datacenter. Griffin, Eagle and Lino run as quantized builds on customer GPUs; Zero has no model weights and runs in process on the platform. Contact sales for the deployment guide.
* **Air-gapped**: the same as on-prem, with no outbound connection, for classified and IL5 deployments. See [Air-Gapped Deployment](/docs/air-gapped-deployment).
They are available in 245 countries and territories (the ISO 3166-1 list minus the exclusions). They are not offered in Cuba, Iran, North Korea or Syria, nor in the Crimea region of Ukraine or the so-called Donetsk People's Republic (DNR) and Luhansk People's Republic (LNR) regions of Ukraine.
## Privacy
* Your source code, SBOMs, and telemetry are never used to train shared models.
* Per-tenant fine-tunes are opt-in and stay inside your tenant boundary.
* Inference requests are logged with tenant-scoped keys for audit only; bodies are not retained beyond 24 hours by default (Enterprise: configurable 0–365 days).
## Related
* [Griffin AI](/docs/griffin-ai) — detailed Griffin feature guide.
* [Zero-Day Discovery](/docs/zero-day-discovery) — how Eagle feeds the research pipeline.
* [Compliance](/docs/compliance) — how Lino evaluates regulatory frameworks.
* [MCP Server](/docs/mcp) — how Griffin is exposed to external AI clients.
# AI Security Posture Management (AI-SPM) (/docs/ai-spm)
# AI Security Posture Management (AI-SPM)
Model weights are executable supply chain artifacts. A malicious pickle can run arbitrary code the moment a model is loaded. AI-SPM inspects model artifacts **before** they are trusted, catching malware and unsafe deserialization in the formats teams actually ship.
AI-SPM is the lifecycle wrapper around Safeguard's AI security — discover, assess, protect, govern, monitor. Model-artifact scanning (below) is the shipped core; it sits alongside [AI-BOM discovery](/docs/ai-bom), which inventories the models it scans, and the [AI Gateway](/docs/ai-gateway), the runtime LLM firewall.
## Model-artifact malware scanning
AI-SPM statically analyzes model files without loading them:
| Format | What AI-SPM checks for |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pickle** (`.pkl`, `.bin`, PyTorch state dicts) | Flags hidden code-execution instructions — imports of dangerous modules like `os` / `subprocess` / `eval`, and load-time steps that can run arbitrary code the moment the file is deserialized. Mapped to **CWE-502** (unsafe deserialization) and **CWE-94** (code injection). |
| **PyTorch `.pt` / `.zip` archives** | Unpacks the archive and inspects every embedded component for the same hidden code-execution patterns. |
| **safetensors** | Confirms the file is a genuine, tensor-only artifact with no executable payload. |
| **GGUF** | Validates the container so malformed or tampered files are caught before use. |
| **ONNX** | Inspects the model graph without executing it and flags two risks: (a) **custom or non-standard operators** and embedded code-execution steps — **CWE-94** (code injection); and (b) **external-data references whose path escapes the model directory** (absolute paths, `..`, UNC paths, or URLs) — **CWE-22** (path traversal). Malformed files fail safe. |
Because these formats can execute code the moment a model loads, AI-SPM treats any hidden code-execution instruction as a high-signal finding — the whole point is to catch it **before** the weights are loaded. Format coverage expands over time; ONNX is the most recent format AI-SPM inspects.
## Findings
Each finding identifies the artifact, the format, the specific risk that fired, and its CWE mapping. Findings flow into the [unified findings model](/docs/unified-findings) as AI-security findings, tenant/org-scoped end to end.
## Configuration
AI-SPM is **admin-toggleable** via a [feature flag](/docs/unified-findings#feature-flags), enforced server-side. Once enabled, model artifacts are scanned as they are ingested through your registries and pipelines.
## Related
* [AI-BOM Discovery](/docs/ai-bom) — inventory of the models AI-SPM scans.
* [AI Gateway (LLM Firewall)](/docs/ai-gateway) — runtime guardrails for prompts, responses, and tool calls.
* [AI-BOM & Model Security](/docs/ai-bom-model-security) — governing model provenance, signing, and lineage.
* [Malware Detection](/docs/malware-detection) — Eagle-based classification for packages, images, and weights.
* [Unified Findings & Feature Flags](/docs/unified-findings) — where AI-SPM findings land and how the engine is toggled.
# Air-Gapped Deployment (/docs/air-gapped-deployment)
# Air-Gapped Deployment
Classified environments, regulated industries, and critical-infrastructure operators often require no outbound internet from production. Safeguard ships a complete air-gapped deployment that runs every capability — scanning, reachability, Griffin, Eagle, Lino, Gold, self-healing — inside your perimeter.
## What Runs Air-Gapped
Every product and platform capability has an air-gapped equivalent:
* **ESSCM, Portal, TPRM, OSM** — the full web app.
* **Griffin / Eagle / Lino** — quantized builds that run on customer GPUs.
* **Zero**: it has no model weights and runs in process on the platform, so it answers data questions with no model inference.
* **Continuous scanning** — driven by delta-shipped vulnerability feeds.
* **MCP Server, API, CLI, Desktop App, Runner** — all available.
* **Kubernetes admission controller** — admits images without needing cloud connectivity.
* **Self-healing containers** — rebuilds inside your environment using your mirrored registries.
## Reference Architecture
```
Upstream snapshot bundle Your air-gapped perimeter
───────────────────────── ─────────────────────────
Safeguard Cloud ──(signed)──► Receiver ──► Safeguard Control Plane
(daily / │
hourly) ├── Web App
├── API + MCP
├── Inference (Griffin/Eagle/Lino)
├── Scanner
├── Gold Mirror
└── Storage (Postgres, S3-compat, Vault)
```
* A **snapshot bundle** ships from Safeguard on your chosen cadence.
* The **Receiver** is a DMZ-positioned service that verifies signatures and pushes deltas to the Control Plane.
* The **Control Plane** runs every Safeguard component.
* No component inside the perimeter ever calls outbound.
## Snapshot Contents
Each signed bundle contains:
* Vulnerability feed deltas (NVD, GitHub Advisory, OSV, Safeguard Research, CISA KEV, EPSS daily).
* Gold artifact deltas (tarballs and OCI layers).
* Eagle classification model deltas (behavioral signatures).
* Policy template updates.
* Platform binaries when releases ship.
Every bundle is signed with Safeguard's air-gap signing key and independently verifiable against a public transparency log (or a private transparency log for classified tenancies).
## Delivery Options
| Channel | Typical use |
| ------------------------ | ---------------------------------------------------------------- |
| **One-way diode** | Classified / IL5 / NERC CIP environments |
| **Manual media** | Signed USB / removable media, human courier |
| **Scheduled sync (DMZ)** | Short outbound window (daily or hourly) on a separate DMZ |
| **Pull replica** | A replica site pulls and mirrors to one or more air-gapped sites |
Cadence configurable from **hourly** down to **quarterly**.
## Install Footprint
Minimum for a production air-gapped deployment:
* Kubernetes cluster (OpenShift / EKS-Anywhere / Rancher / vanilla k8s) — 3 control-plane, 6 worker nodes.
* Postgres 15+.
* S3-compatible object storage (MinIO, CephRGW, AWS on GovCloud).
* Optional GPU pool for Griffin/Eagle/Lino inference (A10 / L4 / H100 depending on scale).
Scaled down, a single-node POC works for evaluations; we ship a 1-VM appliance image for that case.
## Inference at the Edge
For scenarios where even the air-gapped site can't afford GPU time:
* **CPU-only quantized builds** of Griffin, Eagle, Lino — usable for triage and summarization, slower than GPU.
* **Batch inference mode** — queue analysis jobs and process nightly.
* **Retrieval-only mode** — static answers from the shipped knowledge base without live inference.
## Compliance
Air-gapped Safeguard is the default deployment for:
* **DoD IL4 / IL5**.
* **FedRAMP HIGH** (with authorized boundary configuration).
* **NERC CIP** (critical electric infrastructure).
* **CMMC Level 3**.
* **ITAR / EAR-controlled environments**.
* **China MLPS 2.0 Level 3** — with separate tenancy in country.
See [Compliance](/docs/compliance) for the full framework matrix.
## Operational Runbook
### Install
The install runbook is provided as a private repository to authorized tenants. It covers:
* Pre-deployment hardening baselines.
* Helm values with safe defaults.
* Day-0 signing key ceremony.
* Disaster recovery and restore.
### Upgrade
* Validate the new snapshot bundle signatures.
* Blue/green Helm install in a new namespace.
* Cutover through your ingress.
* Keep the prior namespace for one release cycle as rollback.
### Key Rotation
* Signing keys rotate on a configurable cadence (default: annually).
* Rotation is a two-person, signed, logged operation.
* Both old and new keys are trusted for a grace period during rotation.
## Access
Because the control plane is air-gapped, access uses:
* Your existing SSO (SAML / OIDC) against your directory.
* Bastion hosts or PAM-gated access for operators.
* SCIM sync inside the perimeter.
## Support
Air-gapped tenants get:
* A named customer engineer.
* A secure one-way channel for snapshot delivery issues.
* Hot-patch bundles for critical zero-days with accelerated signing.
* Quarterly on-site architecture reviews (Enterprise).
## Related
* [Continuous Scanning](/docs/continuous-scanning) — air-gapped scan cadence.
* [AI Models](/docs/ai-models) — on-prem inference builds.
* [Compliance](/docs/compliance) — regulatory environments that require air-gapped deployment.
# All frameworks (/docs/all-frameworks)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Safeguard's framework library has **373** frameworks. Each links to its page: what a scan checks, its controls, its policy templates and its automated tests. How coverage works: [Compliance frameworks](/docs/frameworks).
## Americas (107)
| Framework | Country or scope | Sector |
| ---------------------------------------------------------------------------------------------------------- | -------------------------------- | ---------- |
| [Anguilla Data Protection Act 2020](/docs/frameworks/americas/anguilla-dpa) | Anguilla | Privacy |
| [Antigua and Barbuda Data Protection Act 2013](/docs/frameworks/americas/antigua-barbuda-dpa) | Antigua and Barbuda | Privacy |
| [Argentina PDPL (Law 25.326)](/docs/frameworks/americas/argentina-pdpl) | Argentina | Privacy |
| [Aruba Personal Data Protection Ordinance](/docs/frameworks/americas/aruba-dp) | Aruba | Privacy |
| [Bahamas Data Protection Act 2003](/docs/frameworks/americas/bahamas-dppa) | Bahamas | Privacy |
| [Barbados Data Protection Act 2019](/docs/frameworks/americas/barbados-dpa) | Barbados | Privacy |
| [Belize Data Protection Act 2021](/docs/frameworks/americas/belize-dpa) | Belize | Privacy |
| [Bermuda Personal Information Protection Act 2016](/docs/frameworks/americas/bermuda-pipa) | Bermuda | Privacy |
| [Bolivia Supreme Decree 1793](/docs/frameworks/americas/bolivia-dp) | Bolivia | Privacy |
| [Brazil LGPD](/docs/frameworks/americas/brazil-lgpd) | Brazil | Privacy |
| [British Virgin Islands Data Protection Act 2021](/docs/frameworks/americas/bvi-dpa) | British Virgin Islands | Privacy |
| [Canada CPPA](/docs/frameworks/americas/canada-cppa) | Canada | Privacy |
| [Canada PIPEDA](/docs/frameworks/americas/canada-pipeda) | Canada | Privacy |
| [Cayman Islands Data Protection Act 2017](/docs/frameworks/americas/cayman-islands-dpa) | Cayman Islands | Privacy |
| [CCPA / CPRA](/docs/frameworks/americas/ccpa-cpra) | United States | Privacy |
| [Chile Law 19.628](/docs/frameworks/americas/chile-19628) | Chile | Privacy |
| [CMMC 2.0](/docs/frameworks/americas/cmmc) | United States | Defense |
| [Colombia Law 1581](/docs/frameworks/americas/colombia-1581) | Colombia | Privacy |
| [Colorado CPA](/docs/frameworks/americas/colorado-cpa) | United States | Privacy |
| [Connecticut CTDPA](/docs/frameworks/americas/connecticut-ctdpa) | United States | Privacy |
| [COPPA](/docs/frameworks/americas/coppa) | United States | Privacy |
| [Costa Rica Law No. 8968 on Personal Data](/docs/frameworks/americas/costa-rica-law8968) | Costa Rica | Privacy |
| [Cuba Law 149/2022 on Personal Data Protection](/docs/frameworks/americas/cuba-dp) | Cuba | Privacy |
| [Curacao Personal Data Protection Ordinance](/docs/frameworks/americas/curacao-dp) | Curacao | Privacy |
| [Delaware PDPA](/docs/frameworks/americas/delaware-pdpa) | United States | Privacy |
| [DFARS 252.204-7012](/docs/frameworks/americas/dfars-7012) | United States | Defense |
| [Dominica National ICT / Privacy Framework](/docs/frameworks/americas/dominica-privacy) | Dominica | Privacy |
| [Dominican Republic Law No. 172-13 on Personal Data](/docs/frameworks/americas/dominican-republic-law172) | Dominican Republic | Privacy |
| [Ecuador Organic Law on Personal Data Protection](/docs/frameworks/americas/ecuador-lopdp) | Ecuador | Privacy |
| [El Salvador Cybersecurity and Information Security Law 2024](/docs/frameworks/americas/el-salvador-cyber) | El Salvador | Government |
| [El Salvador Personal Data Protection Law 2024](/docs/frameworks/americas/el-salvador-lpdp) | El Salvador | Privacy |
| [Falkland Islands Data Protection Ordinance](/docs/frameworks/americas/falkland-islands-dp) | Falkland Islands | Privacy |
| [FCRA / FACTA](/docs/frameworks/americas/fcra) | United States | Finance |
| [FDA 21 CFR Part 11](/docs/frameworks/americas/fda-21cfr-part11) | United States | Healthcare |
| [FDA Medical Device](/docs/frameworks/americas/fda-med-device) | United States | Healthcare |
| [FedRAMP](/docs/frameworks/americas/fedramp) | United States | Cloud |
| [FERPA](/docs/frameworks/americas/ferpa) | United States | Education |
| [FFIEC CAT](/docs/frameworks/americas/ffiec-cat) | United States | Finance |
| [FIPS 140-3](/docs/frameworks/americas/fips-140-3) | United States | Government |
| [FISMA](/docs/frameworks/americas/fisma) | United States | Government |
| [Florida Digital Bill of Rights](/docs/frameworks/americas/florida-dbr) | United States | Privacy |
| [FTC Safeguards Rule](/docs/frameworks/americas/ftc-safeguards) | United States | Finance |
| [GLBA](/docs/frameworks/americas/glba) | United States | Finance |
| [Greenland Data Protection Act](/docs/frameworks/americas/greenland-dp) | Greenland | Privacy |
| [Grenada National ICT / Privacy Framework](/docs/frameworks/americas/grenada-privacy) | Grenada | Privacy |
| [Guatemala Ley de Acceso a la Informacion Publica](/docs/frameworks/americas/guatemala-dp) | Guatemala | Privacy |
| [Guyana Data Protection Act 2023](/docs/frameworks/americas/guyana-dpa) | Guyana | Privacy |
| [Haiti National Privacy Framework](/docs/frameworks/americas/haiti-dp) | Haiti | Privacy |
| [HIPAA / HITECH](/docs/frameworks/americas/hipaa-hitech) | United States | Healthcare |
| [HIPAA Security Rule](/docs/frameworks/americas/hipaa) | United States | Healthcare |
| [HITRUST CSF](/docs/frameworks/americas/hitrust-csf) | United States | Healthcare |
| [Honduras Ley de Transparencia (Habeas Data)](/docs/frameworks/americas/honduras-dp) | Honduras | Privacy |
| [Illinois BIPA](/docs/frameworks/americas/il-bipa) | United States | Privacy |
| [Indiana CDPA](/docs/frameworks/americas/indiana-cdpa) | United States | Privacy |
| [Iowa CDPA](/docs/frameworks/americas/iowa-cdpa) | United States | Privacy |
| [Jamaica DPA](/docs/frameworks/americas/jamaica-dpa) | Jamaica | Privacy |
| [Maryland MODPA](/docs/frameworks/americas/maryland-modpa) | United States | Privacy |
| [Massachusetts 201 CMR 17.00](/docs/frameworks/americas/ma-201cmr17) | United States | Privacy |
| [Mexico LFPDPPP](/docs/frameworks/americas/mexico-lfpdppp) | Mexico | Privacy |
| [Minnesota CDPA](/docs/frameworks/americas/minnesota-cdpa) | United States | Privacy |
| [Montana CDPA](/docs/frameworks/americas/montana-cdpa) | United States | Privacy |
| [Montserrat National ICT / Privacy Framework](/docs/frameworks/americas/montserrat-dp) | Montserrat | Privacy |
| [NDAA Section 889](/docs/frameworks/americas/ndaa-section-889) | United States | Defense |
| [NERC CIP](/docs/frameworks/americas/nerc-cip) | United States | Energy |
| [New Hampshire DPA](/docs/frameworks/americas/new-hampshire-dpa) | United States | Privacy |
| [New Jersey CDPA](/docs/frameworks/americas/new-jersey-cdpa) | United States | Privacy |
| [Nicaragua Law No. 787 on Personal Data](/docs/frameworks/americas/nicaragua-law787) | Nicaragua | Privacy |
| [NIST AI RMF](/docs/frameworks/americas/nist-ai-rmf) | United States | AI |
| [NIST CSF 2.0](/docs/frameworks/americas/nist-csf) | United States | Government |
| [NIST CSF 2.0 (Full)](/docs/frameworks/americas/nist-csf-2) | United States | Government |
| [NIST Privacy Framework](/docs/frameworks/americas/nist-privacy-framework) | United States | Privacy |
| [NIST SP 800-161](/docs/frameworks/americas/nist-sp800-161) | United States | Government |
| [NIST SP 800-171](/docs/frameworks/americas/nist-sp800-171) | United States | Defense |
| [NIST SP 800-207](/docs/frameworks/americas/nist-sp800-207) | United States | Government |
| [NIST SP 800-218A](/docs/frameworks/americas/nist-sp800-218a) | United States | AI |
| [NIST SP 800-37 RMF](/docs/frameworks/americas/nist-sp800-37) | United States | Government |
| [NIST SP 800-53](/docs/frameworks/americas/nist-sp800-53) | United States | Government |
| [NIST SP 800-63](/docs/frameworks/americas/nist-sp800-63) | United States | Government |
| [NIST SP 800-66 r2](/docs/frameworks/americas/nist-sp800-66) | United States | Healthcare |
| [NIST SP 800-82](/docs/frameworks/americas/nist-sp800-82) | United States | Energy |
| [NIST SSDF](/docs/frameworks/americas/nist-ssdf) | United States | Government |
| [NY DFS 23 NYCRR 500](/docs/frameworks/americas/nyc-dfs-500) | United States | Finance |
| [NY SHIELD Act](/docs/frameworks/americas/ny-shield-act) | United States | Privacy |
| [Oregon OCPA](/docs/frameworks/americas/oregon-ocpa) | United States | Privacy |
| [Panama Law No. 81 of 2019 on Personal Data](/docs/frameworks/americas/panama-law81) | Panama | Privacy |
| [Paraguay Law No. 6534/2020 on Personal Data](/docs/frameworks/americas/paraguay-law6534) | Paraguay | Privacy |
| [Peru Law 29733](/docs/frameworks/americas/peru-29733) | Peru | Privacy |
| [Puerto Rico Act 111-2005 / US Frameworks](/docs/frameworks/americas/puerto-rico-dp) | Puerto Rico | Privacy |
| [Quebec Law 25](/docs/frameworks/americas/quebec-law25) | Canada | Privacy |
| [Saint Kitts and Nevis Data Protection Act 2018](/docs/frameworks/americas/saint-kitts-dpa) | Saint Kitts and Nevis | Privacy |
| [Saint Lucia Data Protection Act](/docs/frameworks/americas/saint-lucia-dpa) | Saint Lucia | Privacy |
| [Saint Vincent National ICT / Privacy Framework](/docs/frameworks/americas/saint-vincent-privacy) | Saint Vincent and the Grenadines | Privacy |
| [SOC2 Type 1](/docs/frameworks/americas/soc2) | United States | General |
| [SOC2 Type 2](/docs/frameworks/americas/soc2-type2) | United States | General |
| [SOX ITGC](/docs/frameworks/americas/sox-itgc) | United States | Finance |
| [StateRAMP](/docs/frameworks/americas/stateramp) | United States | Cloud |
| [Suriname National Privacy Framework](/docs/frameworks/americas/suriname-dp) | Suriname | Privacy |
| [Tennessee TIPA](/docs/frameworks/americas/tennessee-tipa) | United States | Privacy |
| [Texas TDPSA](/docs/frameworks/americas/texas-tdpsa) | United States | Privacy |
| [Trinidad and Tobago Data Protection Act 2011](/docs/frameworks/americas/trinidad-tobago-dpa) | Trinidad and Tobago | Privacy |
| [TSA Pipeline Security Directives](/docs/frameworks/americas/tsa-pipeline) | United States | Energy |
| [Turks and Caicos Data Protection Ordinance](/docs/frameworks/americas/turks-caicos-dp) | Turks and Caicos | Privacy |
| [Uruguay Law 18.331](/docs/frameworks/americas/uruguay-18331) | Uruguay | Privacy |
| [Utah UCPA](/docs/frameworks/americas/utah-ucpa) | United States | Privacy |
| [Venezuela Constitutional Habeas Data](/docs/frameworks/americas/venezuela-dp) | Venezuela | Privacy |
| [Virginia CDPA](/docs/frameworks/americas/virginia-cdpa) | United States | Privacy |
| [Washington My Health My Data Act](/docs/frameworks/americas/washington-mhmda) | United States | Healthcare |
## Europe (76)
| Framework | Country or scope | Sector |
| -------------------------------------------------------------------------------------------------------- | ---------------------- | ---------- |
| [Aland Finnish Data Protection Act](/docs/frameworks/europe/aland-dp) | Aland | Privacy |
| [Albania Law No. 9887 on Protection of Personal Data](/docs/frameworks/europe/albania-pdpl) | Albania | Privacy |
| [Andorra Qualified Law 29/2021 on Personal Data Protection](/docs/frameworks/europe/andorra-lqpd) | Andorra | Privacy |
| [Armenia Law on Protection of Personal Data](/docs/frameworks/europe/armenia-pdpl) | Armenia | Privacy |
| [Austria Data Protection Act (DSG)](/docs/frameworks/europe/austria-dsg) | Austria | Privacy |
| [Azerbaijan Law on Personal Data](/docs/frameworks/europe/azerbaijan-pdl) | Azerbaijan | Privacy |
| [Belarus Law No. 99-Z on Personal Data Protection](/docs/frameworks/europe/belarus-pdpl) | Belarus | Privacy |
| [Belgium Data Protection Act 2018](/docs/frameworks/europe/belgium-dpa) | Belgium | Privacy |
| [Bosnia and Herzegovina Law on Protection of Personal Data](/docs/frameworks/europe/bosnia-lpdp) | Bosnia and Herzegovina | Privacy |
| [BSI IT-Grundschutz](/docs/frameworks/europe/bsi-grundschutz) | Germany | Government |
| [BSI TR-03183-2](/docs/frameworks/europe/bsi-tr) | Germany | Government |
| [Bulgaria Personal Data Protection Act](/docs/frameworks/europe/bulgaria-pdpa) | Bulgaria | Privacy |
| [Croatia Act on Implementation of the GDPR 2018](/docs/frameworks/europe/croatia-gdpr-act) | Croatia | Privacy |
| [Cyprus Law 125(I)/2018](/docs/frameworks/europe/cyprus-law125) | Cyprus | Privacy |
| [Czechia Act No. 110/2019 on Personal Data Processing](/docs/frameworks/europe/czechia-dpa) | Czechia | Privacy |
| [Denmark Data Protection Act 2018](/docs/frameworks/europe/denmark-dpa) | Denmark | Privacy |
| [ENISA Good Practices](/docs/frameworks/europe/enisa-guidelines) | European Union | Government |
| [Estonia EISA / ISKE](/docs/frameworks/europe/estonia-eisa) | Estonia | Government |
| [ETSI EN 303 645](/docs/frameworks/europe/etsi-en303645) | European Union | IoT |
| [EU AI Act](/docs/frameworks/europe/eu-ai-act) | European Union | AI |
| [EU Cyber Resilience Act](/docs/frameworks/europe/eu-cra) | European Union | Government |
| [EU Cybersecurity Act](/docs/frameworks/europe/eu-cybersecurity-act) | European Union | Government |
| [EU Data Act](/docs/frameworks/europe/eu-data-act) | European Union | Privacy |
| [EU Digital Markets Act](/docs/frameworks/europe/eu-dma) | European Union | Privacy |
| [EU Digital Services Act](/docs/frameworks/europe/eu-dsa) | European Union | Privacy |
| [EU DORA](/docs/frameworks/europe/dora) | European Union | Finance |
| [EU eIDAS Regulation](/docs/frameworks/europe/eu-eidas) | European Union | Government |
| [EU NIS2 Directive](/docs/frameworks/europe/nis2) | European Union | Government |
| [EU PSD2](/docs/frameworks/europe/eu-psd2) | European Union | Finance |
| [Faroe Islands Data Protection Act](/docs/frameworks/europe/faroe-islands-dp) | Faroe Islands | Privacy |
| [Finland Data Protection Act (1050/2018)](/docs/frameworks/europe/finland-dpa) | Finland | Privacy |
| [France ANSSI RGS](/docs/frameworks/europe/france-anssi-rgs) | France | Government |
| [GDPR](/docs/frameworks/europe/gdpr) | European Union | Privacy |
| [GDPR Article 25](/docs/frameworks/europe/gdpr-art25) | European Union | Privacy |
| [Georgia Law on Information Security](/docs/frameworks/europe/georgia-infosec) | Georgia | Government |
| [Georgia Law on Personal Data Protection 2023](/docs/frameworks/europe/georgia-pdpl) | Georgia | Privacy |
| [Gibraltar Data Protection Act 2004](/docs/frameworks/europe/gibraltar-dpa) | Gibraltar | Privacy |
| [Greece Law 4624/2019](/docs/frameworks/europe/greece-law4624) | Greece | Privacy |
| [Guernsey Data Protection Law 2017](/docs/frameworks/europe/guernsey-dpl) | Guernsey | Privacy |
| [Holy See Data Protection Framework](/docs/frameworks/europe/vatican-dp) | Holy See (Vatican) | Privacy |
| [Hungary Act CXII of 2011 (Infotv)](/docs/frameworks/europe/hungary-infotv) | Hungary | Privacy |
| [Iceland Act on Data Protection No. 90/2018](/docs/frameworks/europe/iceland-dpa) | Iceland | Privacy |
| [Ireland Data Protection Act 2018](/docs/frameworks/europe/ireland-dpa) | Ireland | Privacy |
| [Isle of Man Data Protection Act 2018](/docs/frameworks/europe/isle-of-man-dpa) | Isle of Man | Privacy |
| [Italy ACN Cybersecurity](/docs/frameworks/europe/italy-acn) | Italy | Government |
| [Jersey Data Protection Law 2018](/docs/frameworks/europe/jersey-dpl) | Jersey | Privacy |
| [Kosovo Law No. 06/L-082 on Protection of Personal Data](/docs/frameworks/europe/kosovo-lpdp) | Kosovo | Privacy |
| [Latvia Personal Data Processing Law 2018](/docs/frameworks/europe/latvia-dpa) | Latvia | Privacy |
| [Liechtenstein Data Protection Act (DSG) 2018](/docs/frameworks/europe/liechtenstein-dsg) | Liechtenstein | Privacy |
| [Lithuania Law on Legal Protection of Personal Data](/docs/frameworks/europe/lithuania-dpa) | Lithuania | Privacy |
| [Luxembourg Data Protection Law of 1 August 2018](/docs/frameworks/europe/luxembourg-dpa) | Luxembourg | Privacy |
| [Malta Data Protection Act (Cap. 586) 2018](/docs/frameworks/europe/malta-dpa) | Malta | Privacy |
| [Moldova Law No. 133 on Personal Data Protection](/docs/frameworks/europe/moldova-law133) | Moldova | Privacy |
| [Monaco Law No. 1.165 on Personal Data](/docs/frameworks/europe/monaco-law1165) | Monaco | Privacy |
| [Montenegro Law on Personal Data Protection](/docs/frameworks/europe/montenegro-lpdp) | Montenegro | Privacy |
| [Netherlands NEN 7510](/docs/frameworks/europe/netherlands-nen7510) | Netherlands | Healthcare |
| [North Macedonia Law on Personal Data Protection 2020](/docs/frameworks/europe/north-macedonia-lpdp) | North Macedonia | Privacy |
| [Norway NSM Basic Principles](/docs/frameworks/europe/norway-nsm) | Norway | Government |
| [Poland KSC Act](/docs/frameworks/europe/poland-cyber-act) | Poland | Government |
| [Portugal Law No. 58/2019](/docs/frameworks/europe/portugal-lei58) | Portugal | Privacy |
| [Romania Law No. 190/2018](/docs/frameworks/europe/romania-law190) | Romania | Privacy |
| [Russia Federal Law 152-FZ on Personal Data](/docs/frameworks/europe/russia-152fz) | Russia | Privacy |
| [Russia Federal Law 187-FZ on Critical Information Infrastructure](/docs/frameworks/europe/russia-187fz) | Russia | Government |
| [San Marino Law 171/2018 on Data Protection](/docs/frameworks/europe/san-marino-dp) | San Marino | Privacy |
| [Serbia Law on Personal Data Protection 2018](/docs/frameworks/europe/serbia-lpdp) | Serbia | Privacy |
| [Slovakia Act No. 18/2018 on Personal Data Protection](/docs/frameworks/europe/slovakia-dpa) | Slovakia | Privacy |
| [Slovenia Personal Data Protection Act (ZVOP-2)](/docs/frameworks/europe/slovenia-zvop2) | Slovenia | Privacy |
| [Spain ENS (RD 311/2022)](/docs/frameworks/europe/spain-ens) | Spain | Government |
| [Sweden Data Protection Act (2018:218)](/docs/frameworks/europe/sweden-dpa) | Sweden | Privacy |
| [Switzerland revFADP](/docs/frameworks/europe/switzerland-revfadp) | Switzerland | Privacy |
| [TISAX](/docs/frameworks/europe/tisax) | Germany | Automotive |
| [UK Cyber Essentials](/docs/frameworks/europe/uk-cyber-essentials) | United Kingdom | Government |
| [UK GDPR / DPA 2018](/docs/frameworks/europe/uk-gdpr-dpa2018) | United Kingdom | Privacy |
| [UK NCSC CAF](/docs/frameworks/europe/uk-ncsc-caf) | United Kingdom | Government |
| [Ukraine Law on Basic Principles of Cyber Security 2017](/docs/frameworks/europe/ukraine-cybersec) | Ukraine | Government |
| [Ukraine Law on Protection of Personal Data (2297-VI)](/docs/frameworks/europe/ukraine-pdpl) | Ukraine | Privacy |
## Asia-Pacific (62)
| Framework | Country or scope | Sector |
| ------------------------------------------------------------------------------------------------------------- | ---------------- | ---------- |
| [Afghanistan National Privacy Framework](/docs/frameworks/asia-pacific/afghanistan-dp) | Afghanistan | Privacy |
| [Australia ACSC ISM](/docs/frameworks/asia-pacific/australia-ism) | Australia | Government |
| [Australia Essential Eight](/docs/frameworks/asia-pacific/aus-essential8) | Australia | Government |
| [Australia Privacy Act](/docs/frameworks/asia-pacific/australia-privacy) | Australia | Privacy |
| [Australia SOCI Act](/docs/frameworks/asia-pacific/australia-soci) | Australia | Government |
| [Bangladesh Cyber Security Act 2023](/docs/frameworks/asia-pacific/bangladesh-csa) | Bangladesh | Government |
| [Bhutan ICM Act 2018 (Data Protection)](/docs/frameworks/asia-pacific/bhutan-dp) | Bhutan | Privacy |
| [Brunei Personal Data Protection Order 2025](/docs/frameworks/asia-pacific/brunei-pdpo) | Brunei | Privacy |
| [Cambodia E-Commerce Law 2019 (Data Protection)](/docs/frameworks/asia-pacific/cambodia-dp) | Cambodia | Privacy |
| [China Cybersecurity Law](/docs/frameworks/asia-pacific/china-csl) | China | Government |
| [China Data Security Law](/docs/frameworks/asia-pacific/china-dsl) | China | Privacy |
| [China MLPS 2.0](/docs/frameworks/asia-pacific/china-mlps-2) | China | Government |
| [China PIPL](/docs/frameworks/asia-pacific/china-pipl) | China | Privacy |
| [DPRK National Data Framework](/docs/frameworks/asia-pacific/north-korea-dp) | North Korea | Privacy |
| [Fiji Cybercrime Act 2021](/docs/frameworks/asia-pacific/fiji-cyber) | Fiji | Government |
| [Fiji National ICT / Privacy Framework](/docs/frameworks/asia-pacific/fiji-privacy) | Fiji | Privacy |
| [French Polynesia Loi Informatique et Libertes](/docs/frameworks/asia-pacific/french-polynesia-dp) | French Polynesia | Privacy |
| [Guam Data Breach Law / US Frameworks](/docs/frameworks/asia-pacific/guam-dp) | Guam | Privacy |
| [Hong Kong PDPO](/docs/frameworks/asia-pacific/hong-kong-pdpo) | Hong Kong | Privacy |
| [India CERT-In](/docs/frameworks/asia-pacific/india-certin) | India | Government |
| [India DPDP Act](/docs/frameworks/asia-pacific/india-dpdp) | India | Privacy |
| [Indonesia PDP Law](/docs/frameworks/asia-pacific/indonesia-pdp) | Indonesia | Privacy |
| [Japan APPI](/docs/frameworks/asia-pacific/japan-appi) | Japan | Privacy |
| [Japan ISMAP](/docs/frameworks/asia-pacific/japan-ismap) | Japan | Cloud |
| [Japan METI SBOM Guidelines](/docs/frameworks/asia-pacific/japan-meti) | Japan | Government |
| [Kazakhstan Law on Personal Data and its Protection](/docs/frameworks/asia-pacific/kazakhstan-pdpl) | Kazakhstan | Privacy |
| [Kiribati National ICT / Privacy Framework](/docs/frameworks/asia-pacific/kiribati-privacy) | Kiribati | Privacy |
| [Korea ISMS-P](/docs/frameworks/asia-pacific/korea-isms-p) | South Korea | Privacy |
| [Kyrgyzstan Law on Personal Information](/docs/frameworks/asia-pacific/kyrgyzstan-pil) | Kyrgyzstan | Privacy |
| [Laos Law on Electronic Data Protection 2017](/docs/frameworks/asia-pacific/laos-edpl) | Laos | Privacy |
| [Macau PDPA](/docs/frameworks/asia-pacific/macau-pdpa) | Macau | Privacy |
| [Malaysia PDPA](/docs/frameworks/asia-pacific/malaysia-pdpa) | Malaysia | Privacy |
| [Maldives National Privacy Framework](/docs/frameworks/asia-pacific/maldives-dp) | Maldives | Privacy |
| [Marshall Islands National ICT / Privacy Framework](/docs/frameworks/asia-pacific/marshall-islands-privacy) | Marshall Islands | Privacy |
| [MAS TRMG](/docs/frameworks/asia-pacific/singapore-mas-trmg) | Singapore | Finance |
| [Micronesia National ICT / Privacy Framework](/docs/frameworks/asia-pacific/micronesia-privacy) | Micronesia | Privacy |
| [Mongolia Law on Personal Data Protection 2021](/docs/frameworks/asia-pacific/mongolia-pdpl) | Mongolia | Privacy |
| [Myanmar Law Protecting Privacy and Security of Citizens 2017](/docs/frameworks/asia-pacific/myanmar-privacy) | Myanmar | Privacy |
| [Nauru National ICT / Privacy Framework](/docs/frameworks/asia-pacific/nauru-privacy) | Nauru | Privacy |
| [Nepal Individual Privacy Act 2018](/docs/frameworks/asia-pacific/nepal-privacy-act) | Nepal | Privacy |
| [New Caledonia Loi Informatique et Libertes](/docs/frameworks/asia-pacific/new-caledonia-dp) | New Caledonia | Privacy |
| [New Zealand NZISM](/docs/frameworks/asia-pacific/new-zealand-nzism) | New Zealand | Government |
| [Pakistan PDPB](/docs/frameworks/asia-pacific/pakistan-pdpb) | Pakistan | Privacy |
| [Palau National ICT / Privacy Framework](/docs/frameworks/asia-pacific/palau-privacy) | Palau | Privacy |
| [Papua New Guinea Cybercrime Code Act 2016](/docs/frameworks/asia-pacific/png-cybercrime) | Papua New Guinea | Government |
| [Philippines Data Privacy Act](/docs/frameworks/asia-pacific/philippines-dpa) | Philippines | Privacy |
| [Samoa National ICT / Privacy Framework](/docs/frameworks/asia-pacific/samoa-privacy) | Samoa | Privacy |
| [Singapore Cybersecurity Act](/docs/frameworks/asia-pacific/singapore-cyber) | Singapore | Government |
| [Singapore PDPA](/docs/frameworks/asia-pacific/singapore-pdpa) | Singapore | Privacy |
| [Solomon Islands National ICT / Privacy Framework](/docs/frameworks/asia-pacific/solomon-islands-privacy) | Solomon Islands | Privacy |
| [South Korea PIPA](/docs/frameworks/asia-pacific/korea-pipa) | South Korea | Privacy |
| [Sri Lanka Personal Data Protection Act No. 9 of 2022](/docs/frameworks/asia-pacific/sri-lanka-pdpa) | Sri Lanka | Privacy |
| [Taiwan PDPA](/docs/frameworks/asia-pacific/taiwan-pdpa) | Taiwan | Privacy |
| [Tajikistan Law on Protection of Personal Data](/docs/frameworks/asia-pacific/tajikistan-pdpl) | Tajikistan | Privacy |
| [Thailand PDPA](/docs/frameworks/asia-pacific/thailand-pdpa) | Thailand | Privacy |
| [Timor-Leste National Privacy Framework](/docs/frameworks/asia-pacific/timor-leste-dp) | Timor-Leste | Privacy |
| [Tonga National ICT / Privacy Framework](/docs/frameworks/asia-pacific/tonga-privacy) | Tonga | Privacy |
| [Turkmenistan Law on Information about Private Life](/docs/frameworks/asia-pacific/turkmenistan-pdpl) | Turkmenistan | Privacy |
| [Tuvalu National ICT / Privacy Framework](/docs/frameworks/asia-pacific/tuvalu-privacy) | Tuvalu | Privacy |
| [Uzbekistan Law on Personal Data](/docs/frameworks/asia-pacific/uzbekistan-pdl) | Uzbekistan | Privacy |
| [Vanuatu National ICT / Privacy Framework](/docs/frameworks/asia-pacific/vanuatu-privacy) | Vanuatu | Privacy |
| [Vietnam Decree 13/2023](/docs/frameworks/asia-pacific/vietnam-decree13) | Vietnam | Privacy |
## Middle East & Africa (76)
| Framework | Country or scope | Sector |
| --------------------------------------------------------------------------------------------------------------------- | ------------------------ | ---------- |
| [Algeria Law No. 18-07 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/algeria-law1807) | Algeria | Privacy |
| [Angola Law No. 22/11 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/angola-pdpl) | Angola | Privacy |
| [Bahrain PDPL](/docs/frameworks/middle-east-and-africa/bahrain-pdpl) | Bahrain | Privacy |
| [Benin Digital Code 2018 (Personal Data)](/docs/frameworks/middle-east-and-africa/benin-digital-code) | Benin | Privacy |
| [Botswana Data Protection Act 2018](/docs/frameworks/middle-east-and-africa/botswana-dpa) | Botswana | Privacy |
| [Burkina Faso Law No. 010-2004 on Personal Data](/docs/frameworks/middle-east-and-africa/burkina-faso-pdpl) | Burkina Faso | Privacy |
| [Cameroon Law 2010/012 on Cybersecurity](/docs/frameworks/middle-east-and-africa/cameroon-cyber) | Cameroon | Government |
| [Cape Verde Law No. 133/V/2001 on Personal Data](/docs/frameworks/middle-east-and-africa/cape-verde-pdpl) | Cape Verde | Privacy |
| [Chad Law No. 007/PR/2015 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/chad-pdpl) | Chad | Privacy |
| [Congo Law 29-2019 on Data Protection](/docs/frameworks/middle-east-and-africa/congo-dp) | Republic of the Congo | Privacy |
| [Cote d'Ivoire Law No. 2013-450 on Personal Data](/docs/frameworks/middle-east-and-africa/ivory-coast-pdpl) | Cote d'Ivoire | Privacy |
| [DR Congo Digital Code 2023 (Personal Data)](/docs/frameworks/middle-east-and-africa/drc-digital-code) | DR Congo | Privacy |
| [Egypt PDPL (Law 151/2020)](/docs/frameworks/middle-east-and-africa/egypt-pdpl) | Egypt | Privacy |
| [Eswatini Data Protection Act 2022](/docs/frameworks/middle-east-and-africa/eswatini-dpa) | Eswatini | Privacy |
| [Ethiopia Personal Data Protection Proclamation 1321/2024](/docs/frameworks/middle-east-and-africa/ethiopia-pdpp) | Ethiopia | Privacy |
| [Gabon Law No. 001/2011 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/gabon-pdpl) | Gabon | Privacy |
| [Ghana Data Protection Act](/docs/frameworks/middle-east-and-africa/ghana-dpa) | Ghana | Privacy |
| [Guinea Law L/2016/037 on Data Protection](/docs/frameworks/middle-east-and-africa/guinea-dp) | Guinea | Privacy |
| [Iran Computer Crimes Law 2009](/docs/frameworks/middle-east-and-africa/iran-ccl) | Iran | Government |
| [Iraq National Privacy Framework](/docs/frameworks/middle-east-and-africa/iraq-dp) | Iraq | Privacy |
| [Israel INCD](/docs/frameworks/middle-east-and-africa/israel-incd) | Israel | Government |
| [Jordan PDP Law](/docs/frameworks/middle-east-and-africa/jordan-pdp) | Jordan | Privacy |
| [Kenya Data Protection Act 2019](/docs/frameworks/middle-east-and-africa/kenya-dpa) | Kenya | Privacy |
| [Kuwait Cybersecurity Law](/docs/frameworks/middle-east-and-africa/kuwait-cyber) | Kuwait | Government |
| [Lebanon Law 81](/docs/frameworks/middle-east-and-africa/lebanon-81) | Lebanon | Privacy |
| [Lesotho Data Protection Act 2011](/docs/frameworks/middle-east-and-africa/lesotho-dpa) | Lesotho | Privacy |
| [Madagascar Law No. 2014-038 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/madagascar-pdpl) | Madagascar | Privacy |
| [Malabo Convention (AU) - Burundi](/docs/frameworks/middle-east-and-africa/burundi-dp) | Burundi | Privacy |
| [Malabo Convention (AU) - Central African Republic](/docs/frameworks/middle-east-and-africa/car-dp) | Central African Republic | Privacy |
| [Malabo Convention (AU) - Comoros](/docs/frameworks/middle-east-and-africa/comoros-dp) | Comoros | Privacy |
| [Malabo Convention (AU) - Djibouti](/docs/frameworks/middle-east-and-africa/djibouti-dp) | Djibouti | Privacy |
| [Malabo Convention (AU) - Equatorial Guinea](/docs/frameworks/middle-east-and-africa/eq-guinea-dp) | Equatorial Guinea | Privacy |
| [Malabo Convention (AU) - Eritrea](/docs/frameworks/middle-east-and-africa/eritrea-dp) | Eritrea | Privacy |
| [Malabo Convention (AU) - Gambia](/docs/frameworks/middle-east-and-africa/gambia-dp) | Gambia | Privacy |
| [Malabo Convention (AU) - Guinea-Bissau](/docs/frameworks/middle-east-and-africa/guinea-bissau-dp) | Guinea-Bissau | Privacy |
| [Malabo Convention (AU) - Liberia](/docs/frameworks/middle-east-and-africa/liberia-dp) | Liberia | Privacy |
| [Malabo Convention (AU) - Libya](/docs/frameworks/middle-east-and-africa/libya-dp) | Libya | Privacy |
| [Malabo Convention (AU) - Mozambique](/docs/frameworks/middle-east-and-africa/mozambique-dp) | Mozambique | Privacy |
| [Malabo Convention (AU) - Namibia](/docs/frameworks/middle-east-and-africa/namibia-dp) | Namibia | Privacy |
| [Malabo Convention (AU) - Sao Tome](/docs/frameworks/middle-east-and-africa/sao-tome-dp) | Sao Tome and Principe | Privacy |
| [Malabo Convention (AU) - Sierra Leone](/docs/frameworks/middle-east-and-africa/sierra-leone-dp) | Sierra Leone | Privacy |
| [Malabo Convention (AU) - South Sudan](/docs/frameworks/middle-east-and-africa/south-sudan-dp) | South Sudan | Privacy |
| [Malabo Convention (AU) - Sudan](/docs/frameworks/middle-east-and-africa/sudan-dp) | Sudan | Privacy |
| [Malawi Data Protection Act 2024](/docs/frameworks/middle-east-and-africa/malawi-dpa) | Malawi | Privacy |
| [Mali Law No. 2013-015 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/mali-pdpl) | Mali | Privacy |
| [Mauritania Law 2017-020 on Data Protection](/docs/frameworks/middle-east-and-africa/mauritania-dp) | Mauritania | Privacy |
| [Mauritius Data Protection Act 2017](/docs/frameworks/middle-east-and-africa/mauritius-dpa) | Mauritius | Privacy |
| [Morocco Law 09-08](/docs/frameworks/middle-east-and-africa/morocco-0908) | Morocco | Privacy |
| [Niger Law No. 2017-28 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/niger-pdpl) | Niger | Privacy |
| [Nigeria NDPR / NDPA](/docs/frameworks/middle-east-and-africa/nigeria-ndpr) | Nigeria | Privacy |
| [Oman PDPL](/docs/frameworks/middle-east-and-africa/oman-pdpl) | Oman | Privacy |
| [Palestine Data Protection Framework](/docs/frameworks/middle-east-and-africa/palestine-dp) | Palestine | Privacy |
| [Qatar PDPL](/docs/frameworks/middle-east-and-africa/qatar-pdpl) | Qatar | Privacy |
| [Rwanda Law No. 058/2021 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/rwanda-pdpl) | Rwanda | Privacy |
| [SAMA Cybersecurity Framework](/docs/frameworks/middle-east-and-africa/saudi-sama-cyber) | Saudi Arabia | Finance |
| [Saudi Arabia NCA ECC](/docs/frameworks/middle-east-and-africa/saudi-nca) | Saudi Arabia | Government |
| [Saudi PDPL](/docs/frameworks/middle-east-and-africa/saudi-pdpl) | Saudi Arabia | Privacy |
| [Senegal Law No. 2008-12 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/senegal-pdpl) | Senegal | Privacy |
| [Seychelles Data Protection Act 2003](/docs/frameworks/middle-east-and-africa/seychelles-dpa) | Seychelles | Privacy |
| [Sierra Leone Cyber Security and Crime Act 2021](/docs/frameworks/middle-east-and-africa/sierra-leone-cyber) | Sierra Leone | Government |
| [Somalia Data Protection Act 2023](/docs/frameworks/middle-east-and-africa/somalia-dpa) | Somalia | Privacy |
| [South Africa POPIA](/docs/frameworks/middle-east-and-africa/south-africa-popia) | South Africa | Privacy |
| [Syria Cybercrime Law No. 20 of 2022](/docs/frameworks/middle-east-and-africa/syria-cyber) | Syria | Government |
| [Syria National Privacy Framework](/docs/frameworks/middle-east-and-africa/syria-dp) | Syria | Privacy |
| [Tanzania Cybercrimes Act 2015](/docs/frameworks/middle-east-and-africa/tanzania-cybercrimes) | Tanzania | Government |
| [Tanzania Personal Data Protection Act 2022](/docs/frameworks/middle-east-and-africa/tanzania-pdpa) | Tanzania | Privacy |
| [Togo Law No. 2019-014 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/togo-pdpl) | Togo | Privacy |
| [Tunisia Organic Law No. 2004-63 on Personal Data](/docs/frameworks/middle-east-and-africa/tunisia-pdpl) | Tunisia | Privacy |
| [Turkey KVKK](/docs/frameworks/middle-east-and-africa/turkey-kvkk) | Turkey | Privacy |
| [UAE NESA IA Standards](/docs/frameworks/middle-east-and-africa/uae-nesa) | United Arab Emirates | Government |
| [UAE PDPL](/docs/frameworks/middle-east-and-africa/uae-pdpl) | United Arab Emirates | Privacy |
| [Uganda Data Protection and Privacy Act 2019](/docs/frameworks/middle-east-and-africa/uganda-dppa) | Uganda | Privacy |
| [Yemen National Privacy Framework](/docs/frameworks/middle-east-and-africa/yemen-dp) | Yemen | Privacy |
| [Zambia Cyber Security and Cyber Crimes Act 2021](/docs/frameworks/middle-east-and-africa/zambia-cscca) | Zambia | Government |
| [Zambia Data Protection Act No. 3 of 2021](/docs/frameworks/middle-east-and-africa/zambia-dpa) | Zambia | Privacy |
| [Zimbabwe Cyber and Data Protection Act 2021](/docs/frameworks/middle-east-and-africa/zimbabwe-cdpa) | Zimbabwe | Privacy |
## International (41)
| Framework | Country or scope | Sector |
| ------------------------------------------------------------------------- | ---------------- | -------------------- |
| [CIS Controls v8](/docs/frameworks/international/cis-controls) | International | General |
| [Common Criteria (CC)](/docs/frameworks/international/common-criteria) | International | General |
| [CSA Cloud Controls Matrix](/docs/frameworks/international/csa-ccm) | International | Cloud |
| [CSA STAR](/docs/frameworks/international/csa-star) | International | Cloud |
| [CycloneDX VEX](/docs/frameworks/international/cyclonedx-vex) | International | Supply Chain |
| [DO-326A](/docs/frameworks/international/do-326a) | International | Aerospace |
| [GxP (GMP/GLP/GCP)](/docs/frameworks/international/gxp) | International | Healthcare |
| [IEC 62304](/docs/frameworks/international/iec62304) | International | Healthcare |
| [IEC 62443](/docs/frameworks/international/iec62443) | International | Energy |
| [IEC 62443-4-2](/docs/frameworks/international/iec-62443-4-2) | International | Energy |
| [in-toto](/docs/frameworks/international/in-toto) | International | Supply Chain |
| [ISO 22301](/docs/frameworks/international/iso-22301) | International | General |
| [ISO 28000](/docs/frameworks/international/iso28000) | International | Supply Chain |
| [ISO 31000](/docs/frameworks/international/iso31000) | International | General |
| [ISO/IEC 20000](/docs/frameworks/international/iso-20000) | International | General |
| [ISO/IEC 21434](/docs/frameworks/international/iso21434) | International | Automotive |
| [ISO/IEC 27001](/docs/frameworks/international/iso27001) | International | General |
| [ISO/IEC 27002:2022](/docs/frameworks/international/iso27002) | International | General |
| [ISO/IEC 27005](/docs/frameworks/international/iso27005) | International | General |
| [ISO/IEC 27017](/docs/frameworks/international/iso27017) | International | Cloud |
| [ISO/IEC 27018](/docs/frameworks/international/iso27018) | International | Cloud |
| [ISO/IEC 27032](/docs/frameworks/international/iso27032) | International | General |
| [ISO/IEC 27035](/docs/frameworks/international/iso27035) | International | General |
| [ISO/IEC 27701](/docs/frameworks/international/iso27701) | International | Privacy |
| [ISO/IEC 29147](/docs/frameworks/international/iso29147) | International | General |
| [ISO/IEC 42001](/docs/frameworks/international/iso-42001) | International | AI |
| [ISO/IEC 5962 (SPDX)](/docs/frameworks/international/iso5962) | International | General |
| [MITRE ATT\&CK](/docs/frameworks/international/mitre-attack) | International | General |
| [O-TTPS / ISO 20243](/docs/frameworks/international/o-ttps) | International | Supply Chain |
| [OpenChain ISO 5230](/docs/frameworks/international/openchain-iso5230) | International | Open Source |
| [OpenSSF Scorecard](/docs/frameworks/international/openssf-scorecard) | International | Open Source |
| [OWASP ASVS](/docs/frameworks/international/owasp-asvs) | International | Application Security |
| [OWASP CycloneDX BOM](/docs/frameworks/international/owasp-cyclonedx-bom) | International | Application Security |
| [OWASP MASVS](/docs/frameworks/international/owasp-masvs) | International | Application Security |
| [OWASP SCVS](/docs/frameworks/international/owasp-scvs) | International | Application Security |
| [OWASP Top 10](/docs/frameworks/international/owasp-top10) | International | Application Security |
| [PCI DSS 4.0 (Full)](/docs/frameworks/international/pci-dss-4) | International | Finance |
| [PCI DSS v4.0](/docs/frameworks/international/pci-dss) | International | Finance |
| [SLSA Supply Chain](/docs/frameworks/international/slsa) | International | Supply Chain |
| [SWIFT CSCF](/docs/frameworks/international/swift-cscf) | International | Finance |
| [UNECE WP.29](/docs/frameworks/international/unece-wp29) | International | Automotive |
## Internal (11)
| Framework | Country or scope | Sector |
| ---------------------------------------------------------------------- | ---------------- | ------------ |
| [CISA KEV Correlation](/docs/frameworks/internal/cisa-kev) | Internal | Supply Chain |
| [Component Health](/docs/frameworks/internal/component-health) | Internal | Supply Chain |
| [Crypto Algorithm Audit](/docs/frameworks/internal/crypto-algo-audit) | Internal | General |
| [Dependency Age](/docs/frameworks/internal/dependency-age) | Internal | Supply Chain |
| [Duplicate Detection](/docs/frameworks/internal/duplicate-components) | Internal | Supply Chain |
| [License Obligations](/docs/frameworks/internal/license-obligations) | Internal | Open Source |
| [Provenance Chain](/docs/frameworks/internal/provenance-chain) | Internal | Supply Chain |
| [Supply Chain Risk Score](/docs/frameworks/internal/supply-chain-risk) | Internal | Supply Chain |
| [Transitive Depth](/docs/frameworks/internal/transitive-depth) | Internal | Supply Chain |
| [Typosquatting Detection](/docs/frameworks/internal/typosquatting) | Internal | Supply Chain |
| [VEX Readiness](/docs/frameworks/internal/vex-readiness) | Internal | Supply Chain |
# Analytics & Dashboards (/docs/analytics-dashboards)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Analytics & Dashboards
The Safeguard Analytics surface lives at **Home → Dashboards**. It's designed for three audiences: engineers triaging their own findings, security leads running the program, and executives who want a single number they can share with the board.
## Built-In Dashboards
### Program Overview
A single page with the headline indicators:
* Total assets, SBOM coverage, ownership coverage.
* Open critical / high findings by environment.
* KEV-listed findings in production (should be zero).
* Time-to-remediate, rolling 30 / 90 day.
* Griffin auto-fix activity — PRs opened, merged, rejected.
### Vulnerability Backlog
* Open findings by severity, priority, reachability.
* Aging buckets (\< 7 days, 7-30, 30-90, > 90).
* Top 10 most-affected assets.
* Top 10 packages driving the backlog.
* Resolved-vs-new trend.
### Supply Chain Coverage
* Connected Git, registry, cloud, model-registry integrations.
* Shadow asset count and trend.
* Vendor SBOM freshness.
### Compliance
* Framework-by-framework readiness score (FedRAMP, EO 14028, CRA, DORA, SSDF, ISO 27001, SOC2, HIPAA, PCI DSS, etc.).
* Evidence completeness per control.
* Exceptions open and expiring.
### Zero-Days & Incidents
* Safeguard-published advisories affecting your environment.
* Mean time to remediate for Safeguard zero-days.
* Active exploitation findings (KEV overlap).
### Costs
* Griffin inference calls, Workflow runs, artifact storage, runner minutes.
* Per-team, per-environment breakdowns.
## Custom Dashboards
Build your own with the Dashboard Builder (drag-and-drop) or as YAML:
```yaml
apiVersion: safeguard.sh/v1
kind: Dashboard
metadata:
name: payments-team-weekly
spec:
filters:
team: payments
environment: ["production", "staging"]
widgets:
- type: metric
title: "KEV findings open"
query: "findings.severity >= high AND findings.kev == true"
compare: "7 days ago"
- type: timeseries
title: "New findings / day"
query: "count(findings) by day WHERE findings.created_at > '30d'"
- type: table
title: "Top 10 priorities"
query: "findings ORDER BY priority DESC LIMIT 10"
```
Dashboards live in Git alongside policies if you prefer (recommended for auditability).
## Metrics Layer (OpenTelemetry)
Safeguard exports every UI metric as OpenTelemetry metrics to your own OTLP endpoint (Datadog, New Relic, Grafana Cloud, Honeycomb, Chronosphere, self-hosted Prometheus):
* `safeguard.findings.open{severity, env, team}` — gauge
* `safeguard.findings.created_total{severity}` — counter
* `safeguard.findings.resolved_total{severity, method}` — counter
* `safeguard.sbom.coverage_ratio{env}` — gauge
* `safeguard.griffin.autofix.prs_total{status}` — counter
* `safeguard.workflows.runs_total{workflow, result}` — counter
Configure the OTLP endpoint under **Settings → Telemetry**.
## Scheduled Reports
Email-scheduled reports, driven by any dashboard:
* Daily digest at 09:00 local time.
* Weekly executive summary on Mondays.
* Monthly board pack with trend charts.
Reports ship as PDF with embedded charts, plus a structured JSON payload for ingest into reporting tools.
## Executive Packs
One-click generation of polished PDFs for board or audit consumption:
* **Security Posture Executive Summary** — high-level, 5 pages.
* **Compliance Evidence Pack** — per-framework evidence bundle for auditors.
* **Incident Retrospective** — timeline, contributing factors, remediations — for any resolved incident.
* **Vendor Risk Report** — per-vendor summary for procurement.
Generated from templates you can customize (`templates/*.md` in your tenant's report config).
## Exports
Every dashboard and every finding list can be exported:
* CSV, TSV, Excel, JSON, NDJSON.
* SBOM formats for component-level exports (CycloneDX, SPDX).
* OSCAL for compliance evidence.
* PDF for formal reporting.
Exports respect RBAC — you can only export what your role can see.
## Time-Travel
Dashboards support time-travel: pick any date in the last 24 months and see the state of your fleet at that time. Useful for:
* Post-incident analysis (what did our posture look like the day of the incident?).
* Program retrospectives.
* Demonstrating improvement to stakeholders.
## API
Every dashboard is backed by a query API. There is no CLI command for this yet.
```bash
curl -H "Authorization: Bearer $SG_TOKEN" \
"https://api.safeguard.sh/v1/metrics/query?query=..."
```
## Related
* [RBAC & Teams](/docs/rbac-teams) — who sees which dashboard.
* [Continuous Scanning](/docs/continuous-scanning) — the data layer feeding all metrics.
* [Portal](/docs/portal) — SBOM-specific dashboards.
* [Compliance](/docs/compliance) — compliance dashboards.
# API Reference (/docs/api-reference)
# API Reference
Safeguard's programmatic surface today is the **MCP server**. The REST API is
not yet generally available — see [REST API](#rest-api) below for what that
means and what to use instead.
## MCP Server
The Model Context Protocol server at `https://mcp.safeguard.sh/mcp` is the
supported way to query Safeguard programmatically. It works with Claude,
Cursor, Cline, and any other MCP-capable client.
### Configuration
For example, in Cursor's `mcp.json`:
```json
{
"mcpServers": {
"safeguard": {
"url": "https://mcp.safeguard.sh/mcp"
}
}
}
```
Clients that support OAuth open Safeguard's sign-in page; sign in and click
**Authorize access**. For a client that can only send a fixed header, create an
MCP key under **Settings → Developer** (key type **MCP key**) and send it as
`Authorization: Bearer sg_sk_...`. Safeguard hosts the server: there is nothing
to install. See [MCP Integrations](/docs/mcp) for each client.
### Available tools
Six read-only tools for your data, plus five [support tools](#support-tools). Scope (tenant, organization and product) comes from
the account you connect with and is applied automatically; there is no scope
argument to pass.
Arguments marked **required** must be supplied. Everything else is optional.
#### `safeguard_list_products`
Products in the active scope. Start here when you do not know which part of the
estate you mean.
| Argument | Type | Notes |
| -------- | ------- | ------------------------------------------------------ |
| `name` | string | Exact product name. Partial matching is not supported. |
| `limit` | integer | Max products to return (default 50). |
| `offset` | integer | Pagination offset (default 0). |
#### `safeguard_list_projects`
Projects in the active scope, with scan status and vulnerability counts.
| Argument | Type | Notes |
| -------- | ------ | ------------------------------------------------------ |
| `name` | string | Exact project name. Partial matching is not supported. |
| `limit` | number | Max projects to return. |
| `offset` | number | Number of projects to skip. |
#### `safeguard_get_project`
The full record for one project, including components, vulnerabilities and
attestations.
| Argument | Type | Notes |
| ------------ | ------ | --------------------------------------------- |
| `project_id` | string | **Required.** From `safeguard_list_projects`. |
#### `safeguard_list_vulnerabilities`
Vulnerabilities in the active scope.
| Argument | Type | Notes |
| ----------- | ------- | --------------------------------------------------- |
| `severity` | string | `all` (default) does not filter. |
| `ecosystem` | string | Package ecosystem. `all` (default) does not filter. |
| `cvss_min` | number | Minimum CVSS score. |
| `limit` | integer | 1–200, default 25. |
| `offset` | integer | Number to skip, for paging. |
#### `safeguard_get_vulnerability`
The full record for one CVE, including references.
| Argument | Type | Notes |
| -------- | ------ | ------------------------------------------ |
| `cve_id` | string | **Required.** For example `CVE-2024-1234`. |
#### `safeguard_list_findings`
Findings — vulnerability occurrences — for a specific SBOM or project.
| Argument | Type | Notes |
| ------------ | ------- | ---------------------------------------------- |
| `sbom_id` | string | Filter by SBOM. |
| `project_id` | string | Filter by project. |
| `severity` | string | `all` (default) does not filter. |
| `status` | string | Triage state. `all` (default) does not filter. |
| `limit` | integer | 1–200. |
| `offset` | integer | Number to skip, for paging. |
This list is generated from the server's own tool manifest and checked in CI
against `https://mcp.safeguard.sh/openapi.json`. If a tool is not listed here,
the server does not offer it.
### Support tools
Five more tools are on for every signed-in user, unless a workspace
administrator switches the **Support and requests** group off in **Settings ›
MCP access**, so an assistant can raise something with Safeguard or follow up
on it. They file and read the same tickets as the product's Help & Feedback
sheet, and only ever the signed-in user's own. A connection made with an API
key alone can't file requests, and auditor-only accounts don't have these
tools. More in [Help and support](/docs/help-and-support/cli-and-assistants).
#### `safeguard_submit_feedback`
Feedback, a feature request, praise or a complaint, sent to the Safeguard team.
| Argument | Type | Notes |
| ----------- | ------- | --------------------------------------------------------------------- |
| `message` | string | **Required.** The feedback, in the user's own words. |
| `type` | string | `feedback`, `feature_request`, `praise` or `complaint`. |
| `rating` | integer | 1 to 5, only if the user gave one. |
| `tool_name` | string | The MCP tool it is about, if any. The name only, never its arguments. |
| `context` | string | One sentence on what the user was doing. |
#### `safeguard_report_bug`
Something broken or wrong, filed as a ticket the engineering team triages.
| Argument | Type | Notes |
| -------------------- | ------ | ---------------------------------------- |
| `summary` | string | **Required.** One-line summary. |
| `steps_to_reproduce` | string | How to make it happen again. |
| `expected` | string | What the user expected. |
| `actual` | string | What happened instead. |
| `severity` | string | `low`, `medium`, `high` or `critical`. |
| `affected_project` | string | Project or product name, if any. |
| `tool_name` | string | The MCP tool it is about, if any. |
| `context` | string | One sentence on what the user was doing. |
#### `safeguard_create_support_request`
A question or problem for the support team, answered by email and in the app.
| Argument | Type | Notes |
| ------------- | ------ | -------------------------------------------- |
| `subject` | string | **Required.** Short subject line. |
| `description` | string | **Required.** What the user needs help with. |
| `urgency` | string | `low`, `normal`, `high` or `urgent`. |
| `tool_name` | string | The MCP tool it is about, if any. |
| `context` | string | One sentence on what the user was doing. |
#### `safeguard_list_my_support_tickets`
The user's own tickets, newest first, with reference, status and date.
| Argument | Type | Notes |
| -------- | ------- | ------------------------------------ |
| `status` | string | `all`, `open` or `closed`. |
| `limit` | integer | Maximum number of tickets to return. |
#### `safeguard_get_support_ticket`
One of the user's own tickets, with the team's replies.
| Argument | Type | Notes |
| ----------- | ------ | ----------------------------------------------------------------------- |
| `reference` | string | **Required.** The ticket reference (`SUP-XXXX-XXXX`) or its numeric id. |
When the MCP server runs on your own machine rather than as the hosted server,
`safeguard_submit_feedback`, `safeguard_report_bug` and
`safeguard_create_support_request` also take `attachment_path`: one local file
of up to 50 MB to attach.
### Paging
List tools return a total alongside the rows. When the total exceeds the rows
you received, page with `offset` rather than assuming you have everything.
## CLI
Install it with the one-line installer on [CLI installation](/docs/cli/installation),
which verifies the download against the published checksums.
### Authentication
```bash
safeguard login
```
This is an OAuth 2.0 device-code sign-in. `/login` inside the interactive
terminal does the same. The CLI does not read an API key from the environment.
### Commands
```bash
# Scan a local directory, an image, a repository, or an existing SBOM
safeguard scan --dir .
safeguard scan --image nginx:latest
safeguard scan --sbom sbom.json
# Secrets and misconfigurations, as SARIF
safeguard detect --format sarif --output detect.sarif
# Validate an SBOM against its specification
safeguard validate sbom.json
```
The full command list is on [CLI usage](/docs/cli/usage), and
`safeguard --help` is authoritative for the build you have.
## REST API
**Not yet generally available.** There is no public REST API at
`https://api.safeguard.sh/v1/`. Every path under `/v1/` returns 404.
Earlier revisions of this page documented a `/v1` endpoint set and told you to
generate API keys for it. That was wrong: those endpoints were never deployed.
Use the [MCP server](#mcp-server) for programmatic access.
The services behind `api.safeguard.sh` — authentication, the data plane, and
the query service — are internal interfaces consumed by Safeguard's own
clients. They require caller-supplied tenant, user, product and organization
scoping headers, and their contracts change without notice. They are not
documented here and are not supported for direct use.
A public REST API with API-key authentication is planned. If you have a use
case the MCP tools do not cover, [contact us](mailto:hi@safeguard.sh) and
we will factor it into that design.
### Single sign-on
The SSO endpoints under `https://api.safeguard.sh/auth/api/v1/` **are** live and
supported. See [SSO configuration](/docs/sso-authentication) for the callback, metadata and
access-request endpoints and their exact paths.
## Webhooks
Receive notifications for events. See [Webhooks and events](/docs/webhooks-events)
for signing, replay protection and the full event list.
### Configuration
1. Go to **Settings** → **Webhooks**
2. Click **Add Webhook**
3. Enter URL and select events
4. Save
### Events
* `sbom.created`
* `sbom.updated`
* `vulnerability.discovered`
* `gate.failed`
* `policy.violated`
### Payload
```json
{
"event": "vulnerability.discovered",
"timestamp": "2025-01-03T10:00:00Z",
"data": {
"cve": "CVE-2025-1234",
"severity": "critical",
"affected_projects": ["project-1", "project-2"]
}
}
```
## Rate limits
Rate limits apply per API key. Current limits and the plans they attach to are
published on the [pricing page](https://safeguard.sh/pricing) — that page is the
source of truth, and this one no longer duplicates it.
## SDKs
No official SDKs are published yet. Connect through the
[MCP server](#mcp-server), which most agent frameworks support natively.
# Application Security Testing (SAST & DAST) (/docs/application-security-testing)
# Application Security Testing (SAST & DAST)
Safeguard is extending its platform with **first-party application security testing** — static analysis of your source code (**SAST**) and dynamic testing of your running applications (**DAST**) — alongside the SCA, secrets, container, and IaC scanning you already use. Findings from every engine share **one unified model**, so a runtime issue can be correlated to the exact source-code sink that caused it.
> **Note:** SAST and DAST are rolling out. The platform wiring, the unified findings model, and the DAST safety controls are in place today; detection depth expands over time. This page documents the capability and how to configure it.
## How it fits the platform
Application security testing runs through the same path as your other scans:
```
Connect a repository or target → scan (in CI, in your pipeline, or on a local/on-prem runner) → findings in the app and API
```
You add a **Safeguard SAST** or **Safeguard DAST** integration the same way you add a repository or registry. Scans run in your pipeline or on a local/on-prem runner, and findings land in your tenant-scoped findings view — queryable in the app and through the API.
## SAST — static analysis
SAST analyzes source code without running it, tracing untrusted input from a **source** (a request parameter, CLI arg, file read) to a dangerous **sink** (a SQL query, command exec, file path) across functions and files.
| Aspect | Detail |
| ----------------------- | --------------------------------------------------------------------------------------------------- |
| **Inputs** | A connected repository or a local directory (no build required) |
| **Languages (phase 1)** | JavaScript/TypeScript, Python, Java (more to follow) |
| **What you get** | A finding with the source→sink **dataflow trace**, CWE/OWASP mapping, severity, and a code location |
| **Where it runs** | Pipeline, or a local runner so source never leaves your perimeter |
Each SAST finding carries a `dataflow` trace — the ordered hops from source to sink — so a developer can see exactly why it was flagged, not just where.
## DAST — dynamic analysis
DAST tests a **running** application for runtime issues (missing security headers, injection classes, misconfigurations) by sending safe, non-destructive requests and observing responses.
DAST is a **defensive, authorized-testing** capability. It is not a general offensive tool, and the following controls are enforced **in code**, not as UI conveniences:
* **Verified targets only.** A target is `unverified` until you prove ownership (DNS TXT record, uploaded file, meta tag, or verified email domain). Active checks **cannot run** against an unverified target.
* **Strict scope.** Every outbound request is checked against an allow-listed host/path scope. Out-of-scope requests are blocked and logged.
* **Rate limits & budgets.** Conservative per-target limits (requests/second, requests/node, max duration) are mandatory and configurable.
* **Non-destructive by default.** Detection uses benign markers and bounded, time-based or out-of-band inference — never data-destroying or denial-of-service payloads.
* **Safety modes.** `passive`, `safe_active`, and `authenticated_safe_active` for normal use. A heavier `lab_aggressive` mode is off by default, never auto-selected, and requires elevated authorization plus a target flagged owned-and-isolated.
* **Full audit trail.** Every DAST request and finding change is recorded with actor, tenant, and timestamp.
## Target verification & safety
Before a DAST scan can touch a target you must verify ownership. Choose a method:
| Method | How |
| ---------------- | ------------------------------------------------ |
| **DNS TXT** | Add a provided TXT record to the target's domain |
| **File upload** | Host a provided token file at a well-known path |
| **Meta tag** | Add a provided `` tag to the site |
| **Email domain** | Verify via an address on the target's domain |
Until verification succeeds, the target stays `unverified` and only passive, non-intrusive checks (if any) are permitted.
## Unified findings & correlation
SAST, DAST, and SCA findings share one model with **correlation keys**. When a DAST-confirmed runtime issue maps to the SAST source-code sink that produced it, the two are linked and prioritized together — a confirmed, reachable, exploitable finding rises to the top. Every finding is tenant/org-scoped (`X-Tenant-Id`, `X-Org-Id`, `X-Descendant-Org-Ids`) end to end.
## Configuration
Add an AppSec integration from the **Integrations** page:
* **Safeguard SAST** — select a repository or point at a source directory.
* **Safeguard DAST** — register a target, verify ownership, set the in-scope hosts/paths and safety mode.
Scans then trigger through the standard integration → pipeline → CLI flow, and results appear in your findings views.
## CLI
Run scans locally or in CI with the Safeguard CLI:
```bash
# Static analysis of a source directory
safeguard appsec sast --dir ./src --tenant-id --product-id
# Dynamic analysis of a verified, in-scope target
safeguard appsec dast \
--target-id \
--base-url https://app.example.com \
--scope-host app.example.com \
--tenant-id
```
The DAST command refuses to run against an unverified or out-of-scope target — the safety kernel enforces this regardless of flags.
## Reports
Findings appear in the app's AppSec views with severity, rule, CWE, location, and (for SAST) the dataflow trace. There is no CLI command for listing them yet.
## Related
* [Reachability Analysis](/docs/reachability-analysis) — prioritizing findings by whether they're actually reachable.
* [Continuous Scanning](/docs/continuous-scanning) — how assets are rescanned over time.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — using findings as policy gates in CI/CD.
* [CLI](/docs/cli) — running scans from the command line and local runners.
* [Air-Gapped Deployment](/docs/air-gapped-deployment) — keeping source and runtime data on-prem.
# Asset Discovery (/docs/asset-discovery)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Asset Discovery
You cannot secure what you cannot see. Safeguard's asset discovery continuously catalogs every software artifact your organization builds, buys, or consumes — and binds each to an owner, a business context, and a risk profile.
## What Gets Discovered
Safeguard discovers and tracks seven asset classes:
| Asset | Source | Example |
| ----------------------- | ------------------------ | --------------------------------------------------------- |
| **Source repositories** | Git providers | GitHub, GitLab, Bitbucket, Azure DevOps |
| **Container images** | Registries | ECR, ACR, GCR, GHCR, Artifactory, Harbor, Docker Hub |
| **Packages** | Build outputs, lockfiles | npm, PyPI, Maven, NuGet, Go, Rust, Ruby, PHP |
| **AI models** | Model registries | Hugging Face, MLflow, Vertex AI Model Registry, SageMaker |
| **SBOMs** | Internal and vendor | CycloneDX, SPDX, ingested from Portal or API |
| **Vendors** | TPRM module | SaaS vendors, open-source dependencies, hardware |
| **Runtime workloads** | Agents and operators | Kubernetes pods, Lambda, Cloud Run, ECS, VMs |
## How Discovery Works
Three connection modes power discovery: agentless integrations, lightweight agents, and SBOM ingestion.
### Agentless Integrations
Connect Safeguard to your Git provider, container registries, cloud accounts, and model registries with OAuth or IAM roles. Safeguard then continuously:
* Enumerates new repositories, images, and models.
* Polls for pushes, tags, releases, and deletions.
* Cross-references with your CI/CD logs to detect shadow builds.
See [Integrations](/docs/esscm/integrations) for the supported connector matrix.
### Lightweight Agents
Deploy the Safeguard runtime collector on:
* **Kubernetes clusters** — a DaemonSet observes image pulls, workload manifests, and admission events.
* **Linux hosts / VMs** — captures package inventories, running containers, and loaded shared libraries.
* **CI/CD runners** — captures build-time manifests and publishes them as runtime SBOMs.
Agents send telemetry over mTLS and do not ship source code or binaries off-host.
### SBOM Ingestion
For vendor software, partner platforms, and imported artifacts, ingest SBOMs directly via:
* Portal upload (drag-and-drop CycloneDX or SPDX).
* `POST /v1/sboms` API call.
Ingested SBOMs are normalized, de-duplicated, enriched with vulnerability data, and joined into the asset graph.
## The Asset Graph
Every discovered asset is a node. Safeguard stitches them together into a typed graph:
```
Vendor --provides--> SBOM
SBOM --describes--> Container Image
Container --runs-in--> Kubernetes Workload
Repository --builds--> Container Image
Package --belongs-to-> Repository
AI Model --uses--> Package
```
Queries answer practical questions:
* *"Which production workloads contain log4j-core 2.17.1?"*
* *"Which vendors ship AI models with unsigned weights?"*
* *"Which of our repositories publish containers that run in FedRAMP boundary?"*
Use the **Search** page in ESSCM for graph queries or the `/v1/graph/query` API for programmatic access.
## Ownership and Tagging
Every asset gets assigned:
* **Owner** — inferred from Git CODEOWNERS, container labels, or manually assigned.
* **Business unit** — mapped from repository topic tags, cloud account, or namespace.
* **Environment** — production, staging, dev, ephemeral.
* **Sensitivity** — customer data, regulated (FedRAMP, HIPAA, PCI), public, internal.
These fields drive routing: findings in a production PCI workload page different humans than a dev sandbox.
## Shadow Asset Detection
Safeguard continuously looks for assets that exist but are not governed:
* A new repository in your org that is not connected.
* An image in a registry with no SBOM.
* A running container image that is not in any SBOM.
* A vendor API being called from production but not listed in TPRM.
Shadow findings surface in the **Asset Discovery** dashboard as `UNGOVERNED` status and can drive automation — for example, opening a Jira ticket or blocking deployments until the asset is onboarded.
## Coverage Metrics
The dashboard reports three headline coverage metrics:
* **SBOM coverage** — % of running workloads with at least one fresh SBOM.
* **Vendor coverage** — % of third-party components covered by TPRM records.
* **Ownership coverage** — % of assets with an identified owner.
These metrics are exposed as time-series so coverage is trackable over quarters.
## CLI
There is no CLI command for listing assets or querying the asset graph yet.
## Related
* [Integrations](/docs/esscm/integrations) — connector matrix and setup.
* [TPRM](/docs/tprm) — vendor and third-party dependency governance.
* [Search](/docs/esscm/search) — asset-graph query UI.
* [Policies and Gates](/docs/esscm/policies-gates) — enforce policies against discovered assets.
# Attestation & Signing (/docs/attestation-signing)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Attestation & Signing
A signed attestation is a cryptographically verifiable claim: "this artifact was built by this pipeline from this commit, with this SBOM, at this time." Safeguard produces attestations for every artifact your pipelines build, and verifies attestations on every artifact you consume.
## What Gets Attested
Five attestation types, all in in-toto v1 format:
| Predicate | What it says |
| ---------------------- | --------------------------------------------------------------------------- |
| **SLSA Provenance v1** | Build system, source, build steps, materials used. |
| **CycloneDX SBOM** | Components present in the artifact. |
| **SPDX SBOM** | Same, in SPDX format. |
| **Vulnerability scan** | Snapshot of known vulnerabilities at build time. |
| **Safeguard Review** | Griffin-generated review: what changed, what was patched, what was blocked. |
Every attestation is signed and published to a transparency log.
## Signing
Safeguard signs with two backends:
### Sigstore (default)
* Keyless signing via Sigstore Fulcio — short-lived certificates bound to workload identity (GitHub OIDC, GitLab OIDC, AWS IAM Roles Anywhere, Azure Workload Identity, GCP WIF).
* Transparency logging via Rekor — anyone can verify your artifact was signed with a known identity.
* No long-lived keys to rotate or leak.
### X.509 / Notation
* For regulated environments that require traditional PKI.
* Certificates issued by your internal CA.
* Compatible with the Notation tool and OCI artifact signing.
Set your signing backend in **Settings → Signing**.
## Producing Attestations
### In CI
The standard workflow step:
```yaml
- name: Attest build
uses: safeguard/attest@v2
with:
artifact: ./dist/app.tar.gz
predicates:
- slsa-provenance
- sbom-cyclonedx
- vuln-scan
```
This step runs inside GitHub Actions, GitLab CI, Azure DevOps, Buildkite, CircleCI, Jenkins, and Safeguard's runner.
### For Container Images and Packages
There is no CLI command for signing yet.
## Verifying Attestations
### Inline, at consumption time
The Kubernetes admission controller (see [Guardrails](/docs/guardrails-enforcement)) verifies attestations on every pod admission:
* SBOM presence.
* Signature validity.
* SLSA level meets the policy (default: Level 3).
* Signer identity matches an allow-list.
Failed verification = admission denied.
### CI-time verification for vendor artifacts
There is no CLI command for verifying or listing attestations yet.
## SLSA Level Support
Safeguard produces attestations at every SLSA level; which one you achieve depends on your build environment:
| Level | Requirement | Achievable with |
| ------ | ------------------------------ | ---------------------------------------------------------- |
| **L1** | Any provenance | Any build system using the `safeguard/attest` step |
| **L2** | Tamper-resistant build service | GitHub Actions, GitLab CI, Safeguard runner |
| **L3** | Isolated, parameter-less build | GitHub reusable workflows, Safeguard runner (dedicated VM) |
| **L4** | Hermetic + two-person review | Safeguard runner (hermetic mode) + branch protection |
See [the blog post on SLSA Level 3](/resources/blog/why-slsa-level-3-matters-level-4-usually-doesnt) for practical guidance on which level to target.
## Transparency Log Access
Every Sigstore attestation is published to Rekor — the public, append-only transparency log.
* Query by artifact digest: `https://rekor.sigstore.dev/api/v1/log/entries?entryUUIDs=`
* Query by signer identity for Safeguard artifacts: `https://rekor.safeguard.sh/by-identity?email=`
Enterprise tenants get a private Rekor instance at `rekor..safeguard.sh` if you need the transparency semantics without using the public log.
## Tamper Evidence
Every attestation carries:
* The artifact digest (SHA-256).
* The signer's certificate chain.
* A Rekor transparency log inclusion proof.
* An in-toto-formatted predicate body.
Any change to the artifact invalidates every attestation. Any attempt to sign as a different identity creates an additional Rekor entry that Safeguard flags as anomalous.
## API
```bash
# Create
POST /v1/attestations
{
"artifact_digest": "sha256:abc...",
"predicate_type": "https://slsa.dev/provenance/v1",
"predicate": { ... }
}
# Verify
GET /v1/attestations/verify?digest=sha256:abc...&min_slsa=3
```
## Related
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — policies that require signed attestations.
* [ESSCM Attestation](/docs/esscm/attestation) — the UI for browsing attestations.
* [CI/CD Integration](/docs/cicd-integration) — adding the `attest` step to pipelines.
# Autonomous Agent (/docs/autonomous-agent)
# Autonomous Agent
Griffin AI Search doesn't only answer questions — inside a Search conversation, it can also run an **autonomous agent** that watches your screen and carries out a goal step by step, the same way a person would work through a task by looking at the screen, deciding what to click or type next, and repeating. You give it a goal in plain language; it observes, acts (or suggests an action), and keeps going until it decides the goal is done or you stop it.
What the agent is actually allowed to *do* depends on what you're sharing your screen for — some actions it performs directly, others it can only suggest. That split isn't an arbitrary product limitation; it comes directly from a real browser security boundary, explained below.
## Starting a run
1. A consent dialog opens first. Type your goal in plain language — for example, *"Navigate to the Vulnerabilities tab and filter to Critical."* — and check the box confirming you authorize the agent to take browser actions on your behalf for the session. **Start session** stays disabled until both the goal text and the checkbox are filled in.
2. Your browser then prompts you to choose what to share, using its native screen-share picker. Depending on your browser, the options are typically something like **This Tab**, **Window**, or **Entire Screen**.
3. Once you grant access, the agent begins observing your screen (captured roughly once per second) and issuing actions — `click`, `type`, `scroll`, or `wait` — each with a stated reason, until it emits `done` or you stop it.
What happens after you grant access depends on what you chose to share in that picker.
Every session is scoped and bounded regardless of what you share: the agent can only ever act inside the browser tab (never the OS, the file system, or other applications directly), and a session ends automatically after 30 actions or 60 seconds of wall-clock time, whichever comes first.
## Same-origin vs. cross-origin: why some actions execute and others don't
This is the core thing to understand about the autonomous agent, and it's worth explaining honestly rather than glossing over.
The browser's screen-sharing API (`getDisplayMedia`) lets the agent *see* almost anything you choose to share — the current tab, another window, or your whole screen. But being able to see a surface and being able to act inside it are two different permissions, governed by two different parts of the browser.
Acting inside a page — clicking an element, typing into a field — requires script access to that page's own document (finding the element under a point, dispatching keyboard events to it). Browsers only grant that access to scripts running on the **same origin** as the page itself. A browser tab showing Safeguard cannot reach into the DOM of a different tab, a different application window, or your desktop — no matter what you're sharing on screen — because that would be a fundamental breach of the same-origin sandbox every website runs inside. This isn't something Safeguard chooses to restrict; it's a boundary the browser itself enforces, and it's the same boundary that keeps any other website from reaching into your other open tabs.
So the agent checks what kind of surface you shared:
| You shared | What the agent can tell | Result |
| ------------------------------------------------ | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| **This tab** (the Safeguard tab itself) | Capture surface is the browser's own tab, so the agent's script and the visible page share an origin | Actions are executed directly |
| **A window, your entire screen, or another tab** | The captured content isn't the same document the agent's script runs in | Actions are only suggested — nothing is dispatched automatically |
If there's any ambiguity about which case applies, the agent defaults to suggestion-only. It's a deliberate fail-safe: when it isn't certain it can safely act, it doesn't guess.
## What you'll experience in each case
**Sharing this tab (same-origin):** the agent finds the element under the coordinates it wants to interact with and acts on it directly — clicking it, typing into whatever field currently has focus, or scrolling the page. You'll see the page respond as if the action happened, because it did.
**Sharing a window, your whole screen, or another tab (cross-origin):** the agent cannot reach into that content, so instead of dispatching anything, it draws an overlay marker at the screen position where it would click or type, while its reasoning for that step appears in the live session log. You remain the one actually operating the mouse and keyboard — the agent is suggesting the move, not making it. This lets the agent guide you through a task on any application or site you're sharing, without ever needing (or being able) to silently control it.
Every step the agent takes — whether executed directly or only suggested — is recorded as it happens, along with the reason the agent gave for it, so you can follow its reasoning as the run progresses. For example, a cross-origin session's log might show an entry like:
```
3 click (840,220) visualised
"Clicking the Critical severity filter to narrow results."
```
The `visualised` tag only appears on suggested actions that weren't actually dispatched; the same kind of entry from a same-origin (this-tab) run omits it, because the click really happened.
## Stopping a run
You can stop the agent at any time. Stopping is handled entirely on your side: it immediately ends the screen capture, closes the connection to the backend, and marks the run as finished — so it works even if the backend is slow or unreachable at that moment. Using your browser's own **Stop sharing** control (the one built into the screen-share indicator, not part of Safeguard's UI) has the same effect and ends the run immediately.
## FAQ & Troubleshooting
**Why does the agent click for me on the Safeguard tab but only draw a box when I share a different app?**
This is the same-origin boundary described above — it's the browser preventing any page's script from reaching into a different tab, window, or application's content, not a feature Safeguard has chosen to leave out.
**I shared "This Tab" but the agent still isn't clicking anything — why?**
The agent double-checks the capture surface before dispatching anything, and defaults to suggestion-only whenever it can't confirm same-origin access. If in doubt, it stays safe rather than acting.
**Can the agent act on a different website or app if I give it permission?**
No — this isn't a setting that can be relaxed. It's enforced by the browser's own sandboxing, the same mechanism that stops any website's script from reading or controlling a different site's tab.
**Does closing the shared tab or window stop the agent?**
Yes. The browser ends the screen share when the shared source closes, and the agent treats that the same as you clicking Stop.
**What kinds of actions can the agent take?**
Clicking, typing, scrolling, waiting, and signaling that it has finished the goal — each step comes with a stated reason so you can see why it chose that action.
**Is there a limit to how long a session can run, or how much it can do?**
Yes — a session ends automatically after 30 actions or 60 seconds of wall-clock time, whichever it hits first. This caps how much a single run can do even if the goal is broad or ambiguous.
**Do I have to explicitly opt in before each run?**
Yes. The consent dialog requires you to type a goal and check "I understand and authorize the assistant to take browser actions on my behalf for the duration of this session" — **Start session** stays disabled until both are done, and re-opening the dialog for a new run resets that consent, so it isn't remembered across sessions.
## Related
* [Griffin AI](/docs/griffin-ai) — the underlying AI that powers Search, natural-language queries, and remediation guidance across Safeguard.
* [Search](/docs/esscm/search) — the Griffin AI Search interface the autonomous agent runs inside of.
# AutoTriage (/docs/autotriage)
# AutoTriage
Multiple engines scanning the same code and infrastructure produce overlapping findings. AutoTriage deduplicates across scanners and reduces noise so your team sees a clean, prioritized list instead of a flood.
## What it does
* **Cross-scanner deduplication.** The same underlying issue reported by more than one engine (for example SAST and SCA pointing at the same component) is collapsed into a single correlated finding.
* **Noise reduction.** Low-signal and redundant findings are down-ranked or merged.
* **Reduction metric.** AutoTriage reports a **reduction percentage** — how much finding volume it removed — so the noise reduction is measurable and auditable rather than opaque.
## Hard guarantee
AutoTriage **never suppresses malware or secrets findings.** These categories are always surfaced in full, regardless of dedup or noise-reduction logic. Triage reduces noise; it does not hide the findings that matter most.
## How it fits
AutoTriage operates over the [unified findings model](/docs/unified-findings), so it can correlate across findings from every engine — static and dynamic application testing, red-team, AI security, data security, runtime, and dependency (SCA) findings. The result is a single deduplicated view that preserves every high-severity signal.
## Configuration
AutoTriage is **admin-toggleable** via a [feature flag](/docs/unified-findings#feature-flags), enforced server-side.
## Related
* [Unified Findings & Feature Flags](/docs/unified-findings) — the model AutoTriage operates over.
* [Malware Detection](/docs/malware-detection) and [Secrets Scanning](/docs/secrets-scanning) — the finding categories AutoTriage never suppresses.
# Browser Extension (/docs/browser-extension)
# Browser Extension
The Safeguard browser extension puts Safeguard's AI search one click away. Click the toolbar icon and a side panel (Chrome, Edge) or sidebar (Firefox) opens next to whatever page you're on, loaded with the same AI search experience you get at `app.safeguard.sh/portal/search`.
For Chrome, the extension is published on the Chrome Web Store — [**install Safeguard from the Chrome Web Store**](https://chromewebstore.google.com/detail/safeguard/dpadlgjdcjgplnnfjbglokhncalkgoae), no developer mode required.
The extension is intentionally thin: it embeds that production search page in a panel and nothing else. There is no separate login flow, no local credential storage, and no direct API calls from the extension code itself — you sign in inside the embedded page exactly as you would in a browser tab, and the panel just carries that session along. If you're looking for IDE-integrated scanning instead, see [IDE Support](/docs/ide-support).
## What it does
* Adds a toolbar icon titled **Open Safeguard**.
* Clicking it opens a panel that loads `https://app.safeguard.sh/portal/search`.
* Login and search both happen inside that embedded page, using your normal web session — the extension doesn't intercept, store, or forward credentials, and it doesn't call any Safeguard API on its own.
* The only browser permission requested is the panel API itself (`sidePanel` on Chrome/Edge; no special permission needed for Firefox's `sidebar_action`) — no host permissions, and no data is collected by the extension.
### What the manifest actually declares
You don't have to take the "no data collected" claim on faith — it's visible in each browser's `manifest.json`.
Chrome and Edge declare exactly one permission and nothing else:
```json
{
"manifest_version": 3,
"permissions": ["sidePanel"],
"side_panel": { "default_path": "panel.html" }
}
```
Firefox's manifest goes a step further and explicitly asserts no data collection, via the `browser_specific_settings.gecko.data_collection_permissions` field AMO uses for its listing:
```json
{
"browser_specific_settings": {
"gecko": {
"id": "safeguard-extension@safeguard.sh",
"strict_min_version": "113.0",
"data_collection_permissions": {
"required": ["none"]
}
}
},
"sidebar_action": { "default_panel": "panel.html" }
}
```
No `host_permissions` array appears in any of the three manifests — the extension has no ability to read or intercept requests to `app.safeguard.sh` or any other site beyond what the embedded page itself does.
## Supported browsers
Minimum versions differ per browser — check the one you're targeting:
| Browser | Minimum version | Panel mechanism |
| ----------- | --------------- | ---------------------------------------------------------------------------------------- |
| **Chrome** | 114+ | `chrome.sidePanel` (Manifest V3) |
| **Edge** | 114+ | `chrome.sidePanel` (Manifest V3) — same MV3 manifest as Chrome, no source changes needed |
| **Firefox** | 113+ | `sidebar_action` (Manifest V3) |
Chrome and Edge run identical extension code, since Edge is Chromium-based and accepts the same MV3 manifest and `sidePanel` API as Chrome. Firefox uses its own `sidebar_action` API instead of `side_panel`, so it doesn't need a background service worker — Chrome and Edge each run a small `background.js` service worker to manage the panel; Firefox does not.
## Installing the extension
Chrome installs come straight from the Chrome Web Store. Edge and Firefox aren't published to their stores yet, so those are installed unpacked from source in each browser's developer mode.
### Chrome
1. Open the [Safeguard listing on the Chrome Web Store](https://chromewebstore.google.com/detail/safeguard/dpadlgjdcjgplnnfjbglokhncalkgoae).
2. Click **Add to Chrome** and confirm.
3. Pin the **Safeguard** icon, then click it — the side panel opens.
If you're developing the extension itself, you can still load it unpacked instead: open `chrome://extensions`, turn on **Developer mode** (top right), click **Load unpacked**, and select the `extensions/chrome/` folder.
### Edge
1. Open `edge://extensions`.
2. Turn on **Developer mode** (left sidebar).
3. Click **Load unpacked** and select the `extensions/edge/` folder.
4. Pin the **Safeguard** icon, then click it — the side panel opens.
### Firefox
1. Open `about:debugging#/runtime/this-firefox`.
2. Click **Load Temporary Add-on…**.
3. Select the `manifest.json` file inside the `extensions/firefox/` folder.
The sidebar opens automatically on first load. To reopen it later, use **View → Sidebar → Safeguard**, or press **Ctrl+B** and pick **Safeguard** from the sidebar switcher dropdown.
> Firefox temporary add-ons are removed when Firefox restarts — you'll need to load the extension again each session. This is a Firefox limitation of unpacked/temporary installs, not something specific to Safeguard.
## Verifying the install
After loading the extension, run through this checklist to confirm it's working end to end — it's the same smoke test used during development of each browser build:
1. **Click the toolbar icon (Chrome/Edge) or open the sidebar (Firefox).** The panel should open showing the login page — not a blank panel.
2. **Sign in.** The search page should load in place of the login page once you authenticate.
3. **Run a search query.** Results should render in the panel.
4. **Close and reopen the panel, then restart the browser entirely.** You should still be signed in.
If step 4 fails — you're logged in during the session but land back on the login page after a full browser restart — see the cookie note below and the matching FAQ entry. If any other step fails (blank panel, login not loading, no results), start by confirming you're on a supported browser version (see the table above) before troubleshooting further.
## Login and session persistence
The panel is just an embedded view of the production search page, so signing in works the same way it does in a normal browser tab: click through the panel's login page, authenticate, and the search UI loads in its place. There's no separate extension-level auth step and nothing extra to configure.
Because the panel keeps using your regular web session, closing and reopening it should leave you signed in — including across a browser restart — as long as the browser still holds a valid session cookie for `app.safeguard.sh`.
> **Cookie behavior to be aware of:** the web app's session cookie is set with `SameSite=Lax`. Browsers can refuse to send a `SameSite=Lax` cookie inside a cross-site iframe context, which is effectively what the side panel/sidebar is. If you find that login doesn't persist across a browser restart (you're logged in during the session but land back on the login page after restarting), this cookie attribute is why. The fix lives server-side — marking the auth cookie `SameSite=None; Secure` — not in anything you control from the extension or browser settings.
## Publishing to browser stores
The official Chrome build is already live on the Chrome Web Store ([Safeguard](https://chromewebstore.google.com/detail/safeguard/dpadlgjdcjgplnnfjbglokhncalkgoae), published by Safeguard.sh Inc). For teams building or distributing their own copy of the extension, each browser has a documented store path:
| Store | Cost | Review time | Notes |
| ---------------------------- | ---------------------------------- | ----------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| **Chrome Web Store** | $5 one-time developer registration | \~1–3 days | Declare `sidePanel` as the only permission — no host permissions, no data collected. |
| **Microsoft Edge Add-ons** | Free (Partner Center) | A few days | The same zip built for the Chrome Web Store also works here, since Edge accepts Chrome MV3 manifests as-is. |
| **addons.mozilla.org (AMO)** | Free | Usually under a day for simple extensions | Build with `npx web-ext build --source-dir extensions/firefox`, or zip manually. |
In each case, the listing should note that no permissions beyond the panel API are requested and no data is collected — that's the whole extension's permission footprint.
### Packaging commands
Chrome (register at [chrome.google.com/webstore/devconsole](https://chrome.google.com/webstore/devconsole)):
```powershell
Compress-Archive -Path manifest.json,background.js,panel.html,panel.js,panel.css,icons -DestinationPath safeguard-chrome.zip
```
Edge (register at [partner.microsoft.com/dashboard/microsoftedge](https://partner.microsoft.com/dashboard/microsoftedge)) — the zip is built the same way and can reuse the Chrome Web Store build:
```powershell
Compress-Archive -Path manifest.json,background.js,panel.html,panel.js,panel.css,icons -DestinationPath safeguard-edge.zip
```
Firefox (submit at [addons.mozilla.org/developers/addon/submit](https://addons.mozilla.org/developers/addon/submit/)) — either build with `web-ext` or zip manually, since there's no background script to include:
```bash
npx web-ext build --source-dir extensions/firefox
# or, manually:
# Compress-Archive -Path manifest.json,panel.html,panel.js,panel.css,icons -DestinationPath safeguard-firefox.zip
```
Note what's excluded from each zip: `scripts/` (icon-generation tooling) is left out of the Chrome package, and there's no `background.js` in the Firefox package since `sidebar_action` doesn't use a background service worker.
## FAQ & Troubleshooting
**The panel opens but the page is blank.**
Confirm you're on a supported browser version (Chrome/Edge 114+, Firefox 113+) — the panel APIs the extension relies on don't exist on older versions.
**I signed in, but I'm logged out again after restarting my browser.**
This is the `SameSite=Lax` cookie behavior described above — it's a browser security restriction on cookies inside a cross-site panel, not a broken login. You'll need to sign in again each session until the cookie is served with `SameSite=None; Secure`.
**Does the extension talk to any Safeguard API directly?**
No. It has no host permissions and makes no API calls of its own — everything you see in the panel is the same `app.safeguard.sh/portal/search` page you'd get in a regular tab, doing its own login and search calls under your existing web session.
**The Firefox extension disappeared after I restarted my browser.**
That's expected for a temporary add-on, not a bug — Firefox unloads anything installed via **Load Temporary Add-on…** on every restart. Reload it from `about:debugging#/runtime/this-firefox` each session, or use a build signed and installed through AMO once it's published there, which persists across restarts.
**Can I use the same package for both the Chrome Web Store and Microsoft Edge Add-ons?**
Yes. Edge is Chromium-based and accepts the same Manifest V3 zip built for the Chrome Web Store without modification — you don't need a separate Edge-specific build.
**Where do I find vulnerability scanning or editor-integrated findings?**
That's a different product surface — see [IDE Support](/docs/ide-support). This extension is AI search only.
## Related
* [Web Application](/docs/web-app) — the full Safeguard web app, including the search experience this extension embeds.
* [Search](/docs/esscm/search) — the Griffin AI-powered search page (`/portal/search`) that loads inside the panel.
* [Griffin AI](/docs/griffin-ai) — the natural-language security model behind that search experience.
* [IDE Support](/docs/ide-support) — editor-integrated scanning and findings, separate from this extension.
# Slack, Teams & Discord (/docs/chatops-integrations)
# Slack, Teams & Discord
Safeguard can push findings and platform events directly into a team's existing chat tool — a Slack workspace, a Microsoft Teams tenant, or a Discord server — so security signal shows up where people already work instead of requiring them to log in and go looking for it. These are dedicated ChatOps integrations, each with its own connection setup, credential validation step, and default-channel routing; they're available across Safeguard's ESCM, Portal, and TPRM products under **Settings → Integrations**. (Per-event channel routing exists in the data model but not the UI yet — see [Channel mapping and routing](#channel-mapping-and-routing) below.)
This is a materially richer feature than a single "OAuth evidence source" line — if you're looking for the flat list of connectors Safeguard can pull compliance evidence from (which also lists Slack, Teams, and Discord as generic OAuth sources), see [Connectors](/docs/connectors) instead. This page covers the actual notification/ChatOps feature: its setup flow, its channel-routing model, and — most importantly — how much of it is genuinely two-way today.
## Which platform should I use?
| Platform | Auth options | Channel routing today | Inbound commands |
| ------------------- | --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- |
| **Slack** | Bot Token or Incoming Webhook | One default channel, set during setup. Per-event mapping (with @mention support) exists in the data model but has no UI control yet | Supported at the data-model level (no self-service UI yet) |
| **Microsoft Teams** | Incoming Webhook or Bot Framework | One default team + channel, set during setup. Per-event mapping exists in the data model but has no UI control yet | Not supported — notification-only |
| **Discord** | Bot Token or Webhook | One default channel, set during setup. Per-event mapping exists in the data model but has no UI control yet | Supported at the data-model level (no self-service UI yet) |
All three are configured the same general way: pick an authentication type, enter its credentials, let Safeguard validate them and pull your channel (or team/server) list, then pick where the default notifications go. Details differ per platform below.
## Setting up Slack
Going the `BOT_TOKEN` route? Install the Safeguard Slack app to your workspace first — Slack hands you a Bot User OAuth Token (`xoxb-...`) at the end of the install, which you then paste into the drawer below. Installing the app does not create the integration by itself: Safeguard has no Slack OAuth callback, so the token hand-off is manual either way.
1. In Safeguard, go to **Settings → Integrations** and click **Connect** on the Slack tile.
2. On the **Credentials** step, fill in:
| Field | Required | Notes |
| ------------------- | --------------------------- | ------------------------------------------------------------------------------------ |
| Integration Name | Yes | Must be unique across your integrations |
| Description | No | |
| Authentication Type | Yes | `BOT_TOKEN` or `INCOMING_WEBHOOK` |
| Bot Token | Only for `BOT_TOKEN` | A Slack app's bot token (`xoxb-...`), from **OAuth & Permissions** in your Slack app |
| Webhook URL | Only for `INCOMING_WEBHOOK` | A Slack Incoming Webhook URL (`https://hooks.slack.com/services/...`) |
3. Click **Next**. Safeguard validates the credentials first — for `BOT_TOKEN`, a successful validation also fetches your workspace's channel list; `INCOMING_WEBHOOK` credentials validate but skip channel listing, since a webhook is already bound to one channel.
4. On the **Channel** step:
* **Bot Token**: pick a **Default Channel** from the list Safeguard just fetched. If no channels appear, the bot hasn't been invited to any channel yet — see [Troubleshooting](#faq--troubleshooting).
* **Incoming Webhook**: there's nothing to pick — messages go to whatever channel the webhook URL is bound to. You can optionally type in a display name for that channel.
**Auth type comparison:** `BOT_TOKEN` ("Bot Token (Full Access)" in the UI) gives Safeguard a channel picker across your workspace, so you can choose which channel gets notifications. `INCOMING_WEBHOOK` ("Incoming Webhook (Send Only)") is faster to set up but only ever posts to the one channel the webhook was created for.
> Slack's configuration model also has `signingSecret` and `appToken` fields, and a `slashCommandEnabled` flag — none of these are exposed in the Settings connection flow today. See [Bidirectional input](#bidirectional-input-slash-commands) below.
## Setting up Microsoft Teams
1. Go to **Settings → Integrations** and click **Connect** on the Teams tile.
2. On the **Credentials** step, fill in:
| Field | Required | Notes |
| -------------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------- |
| Integration Name | Yes | Must be unique across your integrations |
| Description | No | |
| Authentication Type | Yes | `WEBHOOK` or `BOT_FRAMEWORK` |
| Webhook URL | Only for `WEBHOOK` | An Incoming Webhook connector URL created in a Teams channel (`https://outlook.office.com/webhook/...`) |
| Microsoft Tenant ID | Only for `BOT_FRAMEWORK` | Your Azure/Entra tenant GUID |
| App ID (Client ID) | Only for `BOT_FRAMEWORK` | The registered app's client ID |
| App Secret (Client Secret) | Only for `BOT_FRAMEWORK` | The registered app's client secret |
All three Bot Framework fields are required together — Safeguard won't let you proceed with only some of them filled in.
3. Click **Next**. Credentials are validated first; for `BOT_FRAMEWORK`, a successful validation also fetches the Microsoft Teams **teams** your app can see. `WEBHOOK` credentials validate but there's no team/channel list to fetch, since the webhook already targets one channel.
4. On the **Channel** step:
* **Bot Framework**: pick a **Team**, then pick a **Channel** within that team — Teams' hierarchy is team-then-channel, not a flat channel list like Slack or Discord.
* **Webhook**: nothing to pick; you can optionally type in a display name for the target channel.
**Auth type comparison:** `WEBHOOK` ("Incoming Webhook (Send Only)") is the fastest path and posts to a single, pre-bound channel. `BOT_FRAMEWORK` ("Bot Framework (Full Access)") requires registering an Azure AD app and grants Safeguard visibility into your teams and channels, so you can pick which team and channel gets the default notifications.
Microsoft Teams' configuration model also includes a `notificationTypes` field (a list of notification-type strings), which — like the fields noted for Slack — is present in the API model but not currently exposed as a control in the Settings connection flow.
## Setting up Discord
1. Go to **Settings → Integrations** and click **Connect** on the Discord tile.
2. On the **Credentials** step, fill in:
| Field | Required | Notes |
| ------------------- | -------------------- | --------------------------------------------------------------------------------- |
| Integration Name | Yes | Must be unique across your integrations |
| Description | No | |
| Authentication Type | Yes | `BOT_TOKEN` or `WEBHOOK` |
| Bot Token | Only for `BOT_TOKEN` | From the **Bot** section of a Discord application in the Discord Developer Portal |
| Webhook URL | Only for `WEBHOOK` | A Discord channel webhook URL (`https://discord.com/api/webhooks/...`) |
3. Click **Next**. Credentials are validated first — for `BOT_TOKEN`, a successful validation also fetches the list of Discord **servers (guilds)** the bot has been added to. For `WEBHOOK`, the validation response returns the webhook's own channel directly, since a Discord webhook is scoped to a single channel.
4. On the **Server & Channel** step:
* **Bot Token**: pick a **Server**, then pick a **Channel** in that server — Safeguard filters the channel list down to text channels only.
* **Webhook**: nothing to pick; you can optionally type in a display name for the channel.
**Auth type comparison:** `BOT_TOKEN` ("Bot Token (Full Access)") gives Safeguard a server/channel picker across every Discord server the bot has joined. `WEBHOOK` ("Webhook URL (Send Only)") is quicker but limited to the one channel the webhook is bound to.
> Like Slack, Discord's configuration model includes a `slashCommandEnabled` flag that isn't exposed in the connection drawer today — see the next section.
## Credential validation, every time
For all three platforms, Safeguard validates credentials in a dedicated step **before** it ever tries to list channels, teams, or servers — you can't get to a channel picker with credentials Safeguard hasn't already confirmed work. If validation fails (revoked token, wrong scopes, malformed webhook URL, wrong tenant), you get an inline error and the flow doesn't advance. This is the same underlying step whether you're creating a new integration or editing an existing one with new credentials.
## Channel mapping and routing
> **This section describes a data model, not a shipped feature.** All three platforms' configuration objects (`SlackConfiguration`, `TeamsConfiguration`, `DiscordConfiguration`) carry a `channelMappings` array meant to route specific event types to specific channels instead of sending everything to one default channel. We checked all three connection drawers directly: **none of them expose any UI to create, view, or edit a channel mapping.** Every integration you set up today — on any of the three platforms — sends everything to the single default channel (or team + channel, for Teams) you picked in step 2 of setup. A freshly created integration's `channelMappings` comes back as an empty array, and there is no self-service way to populate it.
If and when per-event routing ships, the mapping shape is **not identical across platforms** — don't assume feature parity:
| Field | Slack | Teams | Discord |
| ----------------------------------------------------- | :------------------: | :-----------------------------------------------------------------------: | :-----: |
| `eventType` | Yes | Yes | Yes |
| Target channel (`channelId` / `channelName`) | Yes | Yes (plus `teamId` / `teamName`, since Teams channels live inside a team) | Yes |
| `messageTemplate` | Yes | Yes | Yes |
| `mentionUsers` / `mentionGroups` (@-mention on match) | **Yes — Slack only** | No | No |
| `minSeverity` (minimum severity threshold) | Yes | Yes | Yes |
| `isEnabled` (per-mapping on/off) | Yes | Yes | Yes |
| `description` | Yes | Yes | Yes |
Concretely:
* **Slack** is the only platform whose mapping type carries `mentionUsers` and `mentionGroups` — a mapping could @-mention a person or group when it fires, on top of a custom `messageTemplate`, once this is exposed.
* **Teams** mappings are scoped by both `teamId`/`teamName` and `channelId`/`channelName`, reflecting that Teams channels are nested inside a team rather than existing in a flat list.
* **Discord** mappings look structurally like Slack's minus the mention fields — `eventType`, channel, template, severity threshold, enabled flag, description.
The intent is clear from the shape: `minSeverity` would let you route, say, only `critical`/`high` findings to a paged-on-call channel while lower-severity events go somewhere quieter, and `isEnabled` would let you silence a specific mapping without deleting it. None of that is usable yet — today, severity filtering and per-event routing happen upstream, if at all, via [webhook filters](/docs/webhooks-events#filters) rather than through a chat-integration setting.
### Example: what Safeguard stores after setup
Completing the Slack drawer with `BOT_TOKEN` auth produces a `SlackConfiguration` that looks like this (real field names, illustrative values):
```json
{
"id": 42,
"integrationName": "Security Alerts – Slack",
"authType": "BOT_TOKEN",
"workspaceName": "acme-corp",
"botUserName": "safeguard-bot",
"defaultChannelId": "C0123ABCDE",
"defaultChannelName": "security-alerts",
"webhookEnabled": false,
"slashCommandEnabled": false,
"channelMappings": [],
"isActive": true
}
```
`channelMappings` is `[]` here — and will stay `[]` for every integration created through Settings today, since there's no drawer step, button, or form field anywhere in the product that writes to it.
## Bidirectional input (slash commands)
This is the most important thing to understand about maturity here, so we'll be precise rather than aspirational.
**What's confirmed in the data model:** both the Slack and Discord configuration types (`SlackConfiguration` / `CreateSlackConfigurationRequest` and `DiscordConfiguration` / `CreateDiscordConfigurationRequest`) include a `slashCommandEnabled` field. That means Safeguard's integration data model is built to support **inbound** interaction — a user typing a command or query back into Safeguard from within a Slack or Discord conversation — not just one-way outbound notifications.
**What's actually in the setup UI today:** neither the Slack nor the Discord connection drawer (the Settings screens described above) expose a toggle, checkbox, or any control for `slashCommandEnabled`. We checked both directly — there is no self-service way to turn this on from Settings right now. Treat inbound slash commands as a capability the platform is architected to support, not a feature you can enable today.
**Microsoft Teams is notification-only.** The Microsoft Bot Framework is, generically, a real two-way bot protocol in the Microsoft ecosystem — but there is no equivalent field anywhere on `TeamsConfiguration` or `CreateTeamsConfigurationRequest`. Safeguard's Teams integration has no inbound-command capability today, at either the UI or data-model level; describe it as send-only.
If inbound commands matter to your workflow now, ask your Safeguard account team whether slash-command support has moved from the data model into general availability — the field being present doesn't guarantee a shipped, supported command surface yet.
## FAQ & Troubleshooting
**Credential validation fails immediately.**
Double-check you're using the right credential for the auth type you selected — a Slack bot token (`xoxb-...`) won't validate under `INCOMING_WEBHOOK`, and vice versa. For Teams `BOT_FRAMEWORK`, all three of Tenant ID, App ID, and App Secret must be correct together; a single wrong value fails validation with no partial credit.
**No channels show up in the Slack or Discord channel picker.**
This is the single most common setup snag with bot-based (not webhook-based) chat integrations: the bot has valid credentials, but it hasn't actually been added to any channel or server yet. In Slack, invite the bot to at least one channel (`/invite @your-bot-name` in that channel) and retry — Safeguard's own UI message here is literally "No channels found. Make sure the bot is invited to at least one channel." In Discord, make sure the bot has actually been added to a server (guild) via its OAuth invite link, with permission to view the channels you expect to route to — note that Discord's picker doesn't show an equivalent "no servers found" message; if your bot has no servers, the **Select Server** step just sits on "Loading servers..." indefinitely rather than telling you to invite the bot, so don't assume it's still working if it hasn't resolved after a few seconds.
**Teams shows no teams, or no channels within a team.**
Confirm the Azure AD app tied to your App ID/App Secret has actually been granted access to the tenant and to the specific teams you expect to see — an app that validates successfully can still have zero visibility into teams it hasn't been added to.
**Should I use a webhook or a bot/app integration?**
Webhooks (Slack Incoming Webhook, Teams Incoming Webhook, Discord Webhook) are the fastest to set up and are fine if you only ever want notifications in one fixed channel. Bot-based integrations (Slack Bot Token, Teams Bot Framework, Discord Bot Token) take a bit more setup but unlock a channel/team picker, so you can choose *which* single channel gets the default notifications instead of being stuck with whatever channel a webhook was created against. Neither path gets you per-event routing today — see [Channel mapping and routing](#channel-mapping-and-routing) above.
**How is this different from the Slack/Teams/Discord entries on the Connectors page?**
The [Connectors](/docs/connectors) page catalogs these three as generic OAuth evidence sources alongside 391 other systems Safeguard can pull compliance evidence from — it's a different, much shallower integration path. The ChatOps integrations on this page are dedicated notification features with their own setup drawer, credential validation, a default-channel picker, and (for Slack/Discord) an inbound-command data model — richer than a generic connector, even though per-event channel mapping isn't wired up to the UI yet either.
**Why can't I route different event types to different channels, or set a minimum severity per channel?**
Because there's no UI for it yet. The `channelMappings` data model (see above) is designed for exactly this — per-event routing, `minSeverity` thresholds, Slack @-mentions — but none of the three connection drawers expose a way to create a mapping, so every integration sends everything to its single default channel regardless of event type or severity. If this is a blocker, ask your Safeguard account team whether it's on a near-term roadmap.
**I'm editing an existing integration and it's not asking me to re-enter credentials.**
That's expected, not a bug: if you leave the Bot Token / Webhook URL / App Secret fields blank while editing and don't change the authentication type, Safeguard reuses the credentials already on file and skips re-validation for that step. Only fill in a credential field if you're actually rotating it.
## Related
* [Connectors](/docs/connectors) — the broader connector catalog, including Slack/Teams/Discord as generic OAuth evidence sources.
* [Integrations](/docs/integrations) — the full integrations index across SCM, registries, ticketing, and more.
* [Webhooks & Events](/docs/webhooks-events) — the event catalog that channel-mapping `eventType` values route from; useful if you're deciding which events deserve their own channel.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — Safeguard's policy-as-code severity gating, conceptually similar to a channel mapping's `minSeverity` threshold but enforced in your pipeline rather than routed to chat.
# CI/CD Integration (/docs/cicd-integration)
# CI/CD Integration
There are two ways Safeguard fits into a pipeline:
* **Connect the repository.** Once a repository is connected as an
[integration](/docs/esscm/integrations), the platform scans it and evaluates
your [policies and gates](/docs/esscm/policies-gates) on the results. Nothing
has to run in your pipeline for this.
* **Run the CLI in the job.** `safeguard scan` and `safeguard detect` run on
the build machine and write results you can keep as build artifacts or
upload to a code-scanning tab.
There is no published Safeguard GitHub Action, container image or pipeline
plugin for the CLI yet, and the CLI has no severity threshold flag. The CLI
reports findings; it does not fail a build on them. Enforcement is done by the
platform's policy gates.
## Install in a job
The installer is the same one you use locally. Pin a version in CI so a
release does not change a build under you:
```bash
curl -fsSL https://cli.safeguard.sh/install | SAFEGUARD_VERSION= bash
```
`safeguard scan` runs syft and grype. A fresh CI runner does not have them, so
install both on the `PATH` (or point `TOOLS_DIR` at a directory that holds
them) before the scan step.
## GitHub Actions
Secrets and misconfigurations as SARIF, shown in the repository's
code-scanning tab:
```yaml
name: Safeguard
on: [push, pull_request]
jobs:
detect:
runs-on: ubuntu-latest
permissions:
security-events: write
steps:
- uses: actions/checkout@v4
- name: Install the Safeguard CLI
run: curl -fsSL https://cli.safeguard.sh/install | SAFEGUARD_VERSION= bash
- name: Detect secrets and misconfigurations
run: safeguard detect --format sarif --output safeguard.sarif
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: safeguard.sarif
```
## GitLab CI/CD
```yaml
safeguard-scan:
stage: test
image: ubuntu:24.04
script:
- apt-get update && apt-get install -y curl
- curl -fsSL https://cli.safeguard.sh/install | SAFEGUARD_VERSION= bash
# syft and grype must be on the PATH before this step
- safeguard scan --dir . --output safeguard-results
artifacts:
paths:
- safeguard-results/
```
## Jenkins
```groovy
pipeline {
agent any
stages {
stage('Safeguard') {
steps {
sh 'curl -fsSL https://cli.safeguard.sh/install | SAFEGUARD_VERSION= bash'
sh 'safeguard detect --format json --output detect.json'
archiveArtifacts artifacts: 'detect.json'
}
}
}
}
```
## Azure DevOps
```yaml
steps:
- script: |
curl -fsSL https://cli.safeguard.sh/install | SAFEGUARD_VERSION= bash
safeguard detect --format sarif --output $(Build.ArtifactStagingDirectory)/safeguard.sarif
displayName: 'Safeguard detect'
```
## Exit codes
| Command | Exit code |
| ------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
| `safeguard scan` | `0` when the scan ran, whatever it found. `2` when results were written but the vulnerability scan did not run. `1` when the command failed. |
| `safeguard detect` | `0` when the scan ran, whatever it found. Non-zero only when the command failed, for example an invalid `--detect` value. |
## Dependency gate on Gold (planned)
A small dependency gate that checks your manifests against the free
[Gold Open Source](/docs/gold-open-source) database, and can fail a build on
actively exploited (CISA KEV) dependencies, is built but not yet published as a
GitHub Action or npm package. This section will carry the install line once it
is.
## Best practices
1. **Connect the repository** so the platform scans it and gates evaluate every result.
2. **Pin the CLI version** in CI and update it deliberately.
3. **Keep the results** as build artifacts; they are the evidence of what was scanned.
4. **Enable AI Remediate** so Griffin AI opens fix PRs for what the scans find.
# Claude Integration (/docs/claude-integration)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Claude](https://claude.ai) by [Anthropic](https://www.anthropic.com) directly to your software supply chain security data and ask questions in plain language. The Claude connector URL is **`https://mcp.safeguard.sh/mcp/anthropic`** — our MCP endpoint purpose-built for Claude. Once connected, Claude can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates — all through a connector named **Safeguard Security**. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
* Operate across multiple tenants (multi-tenant support).
## Add from Claude's connector directory
Safeguard is listed in Claude's connector directory. This is the shortest route — there is no URL to paste:
1. Open the directory entry: [Safeguard in Claude's connector directory](https://claude.ai/directory/connectors/297550a9-dcd9-4d5c-a4ab-7f96c92cc495).
2. Select **Safeguard** and connect.
3. Sign in to Safeguard, check the app name and the host the authorization code will be sent to, then click **Authorize access**.
The directory lives inside Claude and needs you signed in to claude.ai — opened without a session, the link lands on the Claude home instead. If the directory isn't available on your Claude plan or in your workspace, the manual steps below always work.
## Connect from Claude.ai (web)
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. In Claude, open **Customize → Connectors**, click **+ Add**, then **Add custom connector**.
3. Enter the name `Safeguard Security` and the URL `https://mcp.safeguard.sh/mcp/anthropic`, then click **Continue**.
4. Claude detects that Safeguard signs in with OAuth; click **Continue**. Under **Authentication**, choose **Sign in now** or **Sign in when needed**. Under **OAuth client**, choose **Register automatically**: Safeguard accepts only client IDs it issued itself. Click **Add**.
5. When Claude sends you to Safeguard, sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**.
6. That's it. Your enabled Safeguard security tools are now available to Claude. Start asking questions.
On a Team or Enterprise plan, an Owner or Primary Owner adds the connector first under **Organization settings → Connectors** (**Add**, then **Custom**, then **Web**, with the same name, URL and settings). Members then open **Customize → Connectors**, find **Safeguard Security** and click **Connect**. On the Free plan you can add one custom connector.
## Connect from Claude Desktop
Claude Desktop uses the connectors in your Claude account: once you add Safeguard Security as above, it is available in Claude Desktop too. Don't add Safeguard to `claude_desktop_config.json`. That file is for local servers only, Safeguard's server is hosted, and Safeguard publishes no npm package or local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). Claude connects with OAuth 2.0: when you add the Safeguard Security connector, Claude sends you to Safeguard, where you sign in (or create your account), check the app name and the host the page says the authorization code will be sent to, and click **Authorize access**. No keys to copy.
For a client that can only send a fixed header, the Safeguard MCP server also accepts an MCP key: in Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Other AI assistants
The same MCP server (and a REST/OpenAPI surface) lets you bring Safeguard into other assistants too:
| Assistant | How to connect |
| ------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Claude** (Anthropic) | Custom connector → `https://mcp.safeguard.sh/mcp/anthropic` (this page). |
| **ChatGPT** (OpenAI) | Plugins → Add custom MCP server with `https://mcp.safeguard.sh/mcp`, signing in with OAuth; or a Custom GPT Action that imports `https://mcp.safeguard.sh/openapi.json` with an MCP key ([guide](/docs/mcp/openai)). |
| **Gemini** (Google) | In Gemini CLI, add `https://mcp.safeguard.sh/mcp/gemini` as an HTTP server (`httpUrl`) ([guide](/docs/mcp/gemini)). |
| **Copilot Studio** (Microsoft) | Add an MCP connector using `https://mcp.safeguard.sh/mcp`. |
| **Cursor** | Add a `url` entry for `https://mcp.safeguard.sh/mcp` to `mcp.json` and sign in with OAuth ([guide](/docs/mcp/cursor)). |
| **VS Code / GitHub Copilot** | Add a `"type": "http"` server with the URL `https://mcp.safeguard.sh/mcp` to `.vscode/mcp.json` ([guide](/docs/mcp/copilot#github-copilot-in-vs-code)). |
| **Other editors** | Add `https://mcp.safeguard.sh/mcp` as a remote (Streamable HTTP) MCP server. No bridge or package is needed. |
| **Any MCP client / REST** | Speak MCP at `https://mcp.safeguard.sh/mcp`, or call the REST API at `https://mcp.safeguard.sh/openapi.json`. |
## Endpoints
| Endpoint | URL |
| ---------------------- | ---------------------------------------- |
| Claude connector URL | `https://mcp.safeguard.sh/mcp/anthropic` |
| MCP endpoint (generic) | `https://mcp.safeguard.sh/mcp` |
| Health | `https://mcp.safeguard.sh/health` |
# Compliance (/docs/compliance)
# Compliance
Safeguard is built for enterprise compliance requirements, with an architecture designed for FedRAMP HIGH and IL5, and comprehensive regulatory support.
## Coverage at a glance
Safeguard's [framework library](/docs/frameworks) has national data-protection, cybersecurity and sector laws from every region, industry standards such as SOC2, ISO/IEC 27001 and PCI DSS, and Safeguard's own supply-chain policies. For each framework, Safeguard checks a set of requirements when it scans your products, lists the framework's controls and offers policy templates. For SOC2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and NIST CSF 2.0 it also maps automated tests from the systems you connect.
* [Compliance frameworks](/docs/frameworks): how Safeguard covers a framework, what a readiness score counts, how to choose your frameworks, and a page for every framework.
* [All frameworks](/docs/all-frameworks): the full list on one page, by region.
* [Connectors](/docs/connectors): every connector, and whether it collects evidence automatically. How to connect one: [Compliance connectors](/docs/compliance-connectors).
* [Frameworks and connectors](/docs/framework-connectors): which connectors provide evidence for which framework.
* [Trust Center setup](/docs/trust-center): publish your posture to customers.
* [Requests and approvals](/docs/compliance-requests): the requests your programme handles and the decisions that wait for a person.
## Compliance posture
Safeguard does not currently hold a FedRAMP authorization and is not listed on the
[FedRAMP Marketplace](https://marketplace.fedramp.gov/). The sections below describe what the
platform's architecture is *designed to*, not authorizations it has been granted.
### FedRAMP HIGH
Architecture designed to FedRAMP HIGH requirements:
* Continuous monitoring
* Annual assessments
* Incident response procedures
* Security control implementation
### IL5 (Impact Level 5)
Designed for Department of Defense deployment requirements:
* Classified information handling
* Enhanced security controls
* DoD-specific requirements
### SOC2 Type 2
SOC2 Type 2 audit in progress, covering:
* Security
* Availability
* Confidentiality
* Processing Integrity
## EO 14028 Support
Executive Order 14028 compliance features:
### SBOM Requirements
* NTIA minimum elements
* SPDX and CycloneDX formats
* Automated completeness checking
* Compliance scoring
### Software Security
* Vulnerability disclosure
* Secure development practices
* Supply chain security
* Artifact signing
## Regulatory frameworks
The [framework library](/docs/frameworks) is grouped by region: [Americas](/docs/frameworks/americas), [Europe](/docs/frameworks/europe), [Asia-Pacific](/docs/frameworks/asia-pacific), [Middle East & Africa](/docs/frameworks/middle-east-and-africa), [International](/docs/frameworks/international), and Safeguard's own [internal policies](/docs/frameworks/internal). Each framework's page says what a scan checks for it, which requirements a scan decides and which need your evidence, and lists its controls, its policy templates and its automated tests.
## Compliance Reports
Generate compliance documentation:
### Pre-Built Reports
* FedRAMP POA\&M support
* EO 14028 compliance report
* SBOM completeness audit
* Vulnerability summary
### Custom Reports
Create reports for specific requirements:
1. Navigate to **Reports**
2. Click **Create Report**
3. Select compliance framework
4. Configure scope and date range
5. Generate and export
## Data Residency
Deployment options for data residency:
* **US Cloud** - US data centers only
* **EU Cloud** - EU data centers only
* **On-Premises** - Your infrastructure
* **Air-Gapped** - Disconnected environments
## Security Architecture
### Multi-Tenant Isolation
* Complete tenant separation
* Dedicated encryption keys
* Isolated compute resources
* Network segmentation
### Encryption
* TLS 1.3 in transit
* AES-256 at rest
* Customer-managed keys option
* Hardware security modules
### Access Control
* Role-based access (RBAC)
* Single Sign-On (SSO)
* Multi-factor authentication
* API key management
## Audit Support
Supporting your audits:
* Complete audit trails
* Evidence collection
* Assessor access (read-only)
* Documentation packages
# Connectors (/docs/connectors)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard connects to **672 integrations** across **24 categories**. Each connects with OAuth consent, an API token, or an MCP server. Every connector has its own page with how to connect it and the frameworks it provides evidence for: select its name below. How connecting works: [Compliance connectors](/docs/compliance-connectors), with step-by-step guides for the most common providers. Every connector's fields and grants in one table: [setup reference](/docs/compliance-connectors/reference).
| What a connection produces | Connectors |
| ----------------------------- | ---------- |
| Automated compliance tests | 345 |
| Automated evidence collection | 40 |
| People sync | 5 |
| Attested evidence | 8 |
| Search only | 3 |
| Connection record | 271 |
Automated compliance tests are switched on per workspace by the Safeguard team. A connection record stores the connection as evidence for its category; automated collection is not available for those providers yet.
## Identity & SSO (53)
Access control: who can sign in, and how (CC6).
| Connector | Connect with | Evidence |
| ----------------------------------------------------------------------------------------------------- | --------------------- | ----------------------------- |
| [**1Password**](/docs/compliance-connectors/setup/identity-and-sso/1password) | API token | Automated compliance tests |
| [**Auth0**](/docs/compliance-connectors/setup/identity-and-sso/auth0) | API token | Automated evidence collection |
| [**Auth0 SSO**](/docs/compliance-connectors/setup/identity-and-sso/auth0-sso) | API token | Automated evidence collection |
| [**Authentik**](/docs/compliance-connectors/setup/identity-and-sso/authentik) | API token | Automated compliance tests |
| [**Beyond Identity**](/docs/compliance-connectors/setup/identity-and-sso/beyond-identity) | API token | Automated compliance tests |
| [**Clerk**](/docs/compliance-connectors/setup/identity-and-sso/clerk) | API token | Connection record |
| [**Cloudflare Access**](/docs/compliance-connectors/setup/identity-and-sso/cloudflare-access) | API token | Automated compliance tests |
| [**CyberArk**](/docs/compliance-connectors/setup/identity-and-sso/cyberark) | API token | Connection record |
| [**CyberArk SSO**](/docs/compliance-connectors/setup/identity-and-sso/cyberark-sso) | API token | Connection record |
| [**Descope**](/docs/compliance-connectors/setup/identity-and-sso/descope) | API token | Connection record |
| [**Duo Security**](/docs/compliance-connectors/setup/identity-and-sso/duo-security) | API token | Automated compliance tests |
| [**Duo SSO**](/docs/compliance-connectors/setup/identity-and-sso/duo-sso) | API token | Connection record |
| [**Entrust**](/docs/compliance-connectors/setup/identity-and-sso/entrust) | API token | Connection record |
| [**ForgeRock**](/docs/compliance-connectors/setup/identity-and-sso/forgerock) | API token | Automated compliance tests |
| [**Frontegg**](/docs/compliance-connectors/setup/identity-and-sso/frontegg) | API token | Connection record |
| [**FusionAuth**](/docs/compliance-connectors/setup/identity-and-sso/fusionauth) | API token | Automated compliance tests |
| [**Google Cloud Identity**](/docs/compliance-connectors/setup/identity-and-sso/google-cloud-identity) | OAuth, API token | Automated evidence collection |
| [**Google SSO**](/docs/compliance-connectors/setup/identity-and-sso/google-sso) | OAuth, API token | Automated evidence collection |
| [**Google Workspace**](/docs/compliance-connectors/setup/identity-and-sso/google-workspace) | OAuth, API token | Automated evidence collection |
| [**HYPR**](/docs/compliance-connectors/setup/identity-and-sso/hypr) | API token | Connection record |
| [**IBM Verify**](/docs/compliance-connectors/setup/identity-and-sso/ibm-verify) | API token | Automated compliance tests |
| [**Idaptive**](/docs/compliance-connectors/setup/identity-and-sso/idaptive) | API token | Connection record |
| [**JumpCloud**](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud) | API token | Automated evidence collection |
| [**JumpCloud MDM**](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud-mdm) | API token | Automated evidence collection |
| [**JumpCloud SSO**](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud-sso) | API token | Automated evidence collection |
| [**Keycloak**](/docs/compliance-connectors/setup/identity-and-sso/keycloak) | API token | Automated evidence collection |
| [**LastPass SSO**](/docs/compliance-connectors/setup/identity-and-sso/lastpass-sso) | API token | Connection record |
| [**LoginRadius**](/docs/compliance-connectors/setup/identity-and-sso/loginradius) | API token | Connection record |
| [**Logto**](/docs/compliance-connectors/setup/identity-and-sso/logto) | API token | Automated compliance tests |
| [**Microsoft Entra ID**](/docs/compliance-connectors/setup/identity-and-sso/microsoft-entra-id) | OAuth, API token | Automated evidence collection |
| [**Microsoft Entra SSO**](/docs/compliance-connectors/setup/identity-and-sso/microsoft-entra-sso) | OAuth, API token | Connection record |
| [**miniOrange**](/docs/compliance-connectors/setup/identity-and-sso/miniorange) | API token | Connection record |
| [**Okta**](/docs/compliance-connectors/setup/identity-and-sso/okta) | API token | Automated evidence collection |
| [**Okta SSO**](/docs/compliance-connectors/setup/identity-and-sso/okta-sso) | API token | Automated evidence collection |
| [**OneLogin**](/docs/compliance-connectors/setup/identity-and-sso/onelogin) | API token | Automated compliance tests |
| [**OneLogin SSO**](/docs/compliance-connectors/setup/identity-and-sso/onelogin-sso) | API token | Automated compliance tests |
| [**Oracle Identity**](/docs/compliance-connectors/setup/identity-and-sso/oracle-identity) | API token | Automated compliance tests |
| [**Ping Identity**](/docs/compliance-connectors/setup/identity-and-sso/ping-identity) | API token | Automated compliance tests |
| [**Ping SSO**](/docs/compliance-connectors/setup/identity-and-sso/ping-sso) | API token | Connection record |
| [**PingOne**](/docs/compliance-connectors/setup/identity-and-sso/pingone) | API token | Automated compliance tests |
| [**RingCentral**](/docs/compliance-connectors/setup/identity-and-sso/ringcentral) | API token | Automated compliance tests |
| [**Rippling Identity**](/docs/compliance-connectors/setup/identity-and-sso/rippling-identity) | API token | Connection record |
| [**RSA SecurID**](/docs/compliance-connectors/setup/identity-and-sso/rsa-securid) | API token | Connection record |
| [**SailPoint**](/docs/compliance-connectors/setup/identity-and-sso/sailpoint) | API token | Automated compliance tests |
| [**Saviynt**](/docs/compliance-connectors/setup/identity-and-sso/saviynt) | API token | Connection record |
| [**SecureAuth**](/docs/compliance-connectors/setup/identity-and-sso/secureauth) | API token | Connection record |
| [**Stytch**](/docs/compliance-connectors/setup/identity-and-sso/stytch) | API token, MCP server | Connection record |
| [**SuperTokens**](/docs/compliance-connectors/setup/identity-and-sso/supertokens) | API token | Connection record |
| [**Teleport**](/docs/compliance-connectors/setup/identity-and-sso/teleport) | API token | Connection record |
| [**Transmit Security**](/docs/compliance-connectors/setup/identity-and-sso/transmit-security) | API token | Connection record |
| [**WorkOS**](/docs/compliance-connectors/setup/identity-and-sso/workos) | API token | Connection record |
| [**WorkOS SSO**](/docs/compliance-connectors/setup/identity-and-sso/workos-sso) | API token | Connection record |
| [**Zitadel**](/docs/compliance-connectors/setup/identity-and-sso/zitadel) | API token | Automated compliance tests |
## Cloud Infrastructure (49)
Encryption, logging and configuration of hosting (CC6/CC7/C1).
| Connector | Connect with | Evidence |
| ------------------------------------------------------------------------------------------------------------- | --------------------- | ----------------------------- |
| [**Akamai**](/docs/compliance-connectors/setup/cloud-infrastructure/akamai) | API token | Automated compliance tests |
| [**Alibaba Cloud**](/docs/compliance-connectors/setup/cloud-infrastructure/alibaba-cloud) | API token | Automated compliance tests |
| [**Amazon Web Services**](/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services) | API token | Automated evidence collection |
| [**Aptible**](/docs/compliance-connectors/setup/cloud-infrastructure/aptible) | API token | Automated compliance tests |
| [**AWS GovCloud**](/docs/compliance-connectors/setup/cloud-infrastructure/aws-govcloud) | API token | Automated evidence collection |
| [**Azure Government**](/docs/compliance-connectors/setup/cloud-infrastructure/azure-government) | API token | Automated evidence collection |
| [**Civo**](/docs/compliance-connectors/setup/cloud-infrastructure/civo) | API token | Automated compliance tests |
| [**Cloudflare**](/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare) | API token | Automated compliance tests |
| [**Cloudflare R2**](/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare-r2) | API token | Connection record |
| [**Crossplane**](/docs/compliance-connectors/setup/cloud-infrastructure/crossplane) | API token | Connection record |
| [**DigitalOcean**](/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean) | API token | Automated compliance tests |
| [**DigitalOcean Spaces**](/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean-spaces) | API token | Connection record |
| [**Fastly**](/docs/compliance-connectors/setup/cloud-infrastructure/fastly) | API token | Automated compliance tests |
| [**Fly.io**](/docs/compliance-connectors/setup/cloud-infrastructure/fly-io) | API token | Automated compliance tests |
| [**GoDaddy**](/docs/compliance-connectors/setup/cloud-infrastructure/godaddy) | API token | Automated compliance tests |
| [**Google Cloud Platform**](/docs/compliance-connectors/setup/cloud-infrastructure/google-cloud-platform) | OAuth, API token | Automated evidence collection |
| [**HashiCorp Consul**](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-consul) | API token | Automated compliance tests |
| [**HashiCorp Nomad**](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-nomad) | API token | Automated compliance tests |
| [**Heroku**](/docs/compliance-connectors/setup/cloud-infrastructure/heroku) | API token | Automated compliance tests |
| [**Hetzner**](/docs/compliance-connectors/setup/cloud-infrastructure/hetzner) | API token | Automated evidence collection |
| [**IBM Cloud**](/docs/compliance-connectors/setup/cloud-infrastructure/ibm-cloud) | API token | Automated compliance tests |
| [**Kubernetes**](/docs/compliance-connectors/setup/cloud-infrastructure/kubernetes) | API token | Automated compliance tests |
| [**Linode**](/docs/compliance-connectors/setup/cloud-infrastructure/linode) | API token | Automated compliance tests |
| [**Microsoft Azure**](/docs/compliance-connectors/setup/cloud-infrastructure/microsoft-azure) | OAuth, API token | Automated evidence collection |
| [**Netlify**](/docs/compliance-connectors/setup/cloud-infrastructure/netlify) | API token, MCP server | Automated compliance tests |
| [**Northflank**](/docs/compliance-connectors/setup/cloud-infrastructure/northflank) | API token | Automated compliance tests |
| [**Nutanix**](/docs/compliance-connectors/setup/cloud-infrastructure/nutanix) | API token | Automated compliance tests |
| [**OpenStack**](/docs/compliance-connectors/setup/cloud-infrastructure/openstack) | API token | Automated compliance tests |
| [**Oracle Cloud**](/docs/compliance-connectors/setup/cloud-infrastructure/oracle-cloud) | API token | Automated evidence collection |
| [**Oracle Cloud Government**](/docs/compliance-connectors/setup/cloud-infrastructure/oracle-cloud-government) | API token | Automated evidence collection |
| [**OVHcloud**](/docs/compliance-connectors/setup/cloud-infrastructure/ovhcloud) | API token | Automated compliance tests |
| [**Platform.sh**](/docs/compliance-connectors/setup/cloud-infrastructure/platform-sh) | API token | Automated compliance tests |
| [**Portainer**](/docs/compliance-connectors/setup/cloud-infrastructure/portainer) | API token | Automated compliance tests |
| [**Proxmox**](/docs/compliance-connectors/setup/cloud-infrastructure/proxmox) | API token | Automated compliance tests |
| [**Qovery**](/docs/compliance-connectors/setup/cloud-infrastructure/qovery) | API token | Automated compliance tests |
| [**Rackspace**](/docs/compliance-connectors/setup/cloud-infrastructure/rackspace) | API token | Connection record |
| [**Railway**](/docs/compliance-connectors/setup/cloud-infrastructure/railway) | API token | Automated compliance tests |
| [**Rancher**](/docs/compliance-connectors/setup/cloud-infrastructure/rancher) | API token | Automated compliance tests |
| [**Red Hat OpenShift**](/docs/compliance-connectors/setup/cloud-infrastructure/red-hat-openshift) | API token | Automated compliance tests |
| [**Render**](/docs/compliance-connectors/setup/cloud-infrastructure/render) | API token | Automated compliance tests |
| [**Scaleway**](/docs/compliance-connectors/setup/cloud-infrastructure/scaleway) | API token | Automated compliance tests |
| [**Spaceship**](/docs/compliance-connectors/setup/cloud-infrastructure/spaceship) | API token | Automated compliance tests |
| [**UpCloud**](/docs/compliance-connectors/setup/cloud-infrastructure/upcloud) | API token | Automated compliance tests |
| [**Vercel**](/docs/compliance-connectors/setup/cloud-infrastructure/vercel) | API token, MCP server | Automated compliance tests |
| [**VMware**](/docs/compliance-connectors/setup/cloud-infrastructure/vmware) | API token | Automated compliance tests |
| [**VMware Carbon Black**](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-carbon-black) | API token | Automated compliance tests |
| [**VMware Workspace ONE**](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-workspace-one) | API token | Automated compliance tests |
| [**Vultr**](/docs/compliance-connectors/setup/cloud-infrastructure/vultr) | API token | Automated compliance tests |
| [**Yotta**](/docs/compliance-connectors/setup/cloud-infrastructure/yotta) | Record only | Connection record |
## Version Control (19)
Change management and code review (CC8).
| Connector | Connect with | Evidence |
| ------------------------------------------------------------------------------------------------ | ---------------- | ----------------------------- |
| [**Assembla**](/docs/compliance-connectors/setup/version-control/assembla) | API token | Automated compliance tests |
| [**AWS CodeCommit**](/docs/compliance-connectors/setup/version-control/aws-codecommit) | API token | Automated evidence collection |
| [**Azure DevOps**](/docs/compliance-connectors/setup/version-control/azure-devops) | OAuth, API token | Automated compliance tests |
| [**Beanstalk**](/docs/compliance-connectors/setup/version-control/beanstalk) | API token | Automated compliance tests |
| [**Bitbucket**](/docs/compliance-connectors/setup/version-control/bitbucket) | OAuth, API token | Automated evidence collection |
| [**Codeberg**](/docs/compliance-connectors/setup/version-control/codeberg) | API token | Automated compliance tests |
| [**Gerrit**](/docs/compliance-connectors/setup/version-control/gerrit) | API token | Automated compliance tests |
| [**Gitea**](/docs/compliance-connectors/setup/version-control/gitea) | API token | Automated compliance tests |
| [**GitHub**](/docs/compliance-connectors/setup/version-control/github) | OAuth, API token | Automated evidence collection |
| [**GitHub Dependabot**](/docs/compliance-connectors/setup/version-control/github-dependabot) | OAuth, API token | Connection record |
| [**GitHub Enterprise**](/docs/compliance-connectors/setup/version-control/github-enterprise) | OAuth, API token | Automated evidence collection |
| [**GitHub Issues**](/docs/compliance-connectors/setup/version-control/github-issues) | API token | Automated evidence collection |
| [**GitKraken**](/docs/compliance-connectors/setup/version-control/gitkraken) | API token | Connection record |
| [**GitLab**](/docs/compliance-connectors/setup/version-control/gitlab) | API token | Automated evidence collection |
| [**GitLab Issues**](/docs/compliance-connectors/setup/version-control/gitlab-issues) | API token | Automated evidence collection |
| [**GitLab Self-Managed**](/docs/compliance-connectors/setup/version-control/gitlab-self-managed) | API token | Automated evidence collection |
| [**Launchpad**](/docs/compliance-connectors/setup/version-control/launchpad) | API token | Automated compliance tests |
| [**Perforce**](/docs/compliance-connectors/setup/version-control/perforce) | API token | Connection record |
| [**SourceForge**](/docs/compliance-connectors/setup/version-control/sourceforge) | API token | Connection record |
## Vulnerability Scanning (51)
Vulnerability and application-security scanning (CC7).
| Connector | Connect with | Evidence |
| ----------------------------------------------------------------------------------------------------------------------------------- | --------------------- | ----------------------------- |
| [**Acunetix**](/docs/compliance-connectors/setup/vulnerability-scanning/acunetix) | API token | Connection record |
| [**Aikido Security**](/docs/compliance-connectors/setup/vulnerability-scanning/aikido-security) | API token | Automated compliance tests |
| [**Anchore**](/docs/compliance-connectors/setup/vulnerability-scanning/anchore) | API token | Automated compliance tests |
| [**Apiiro**](/docs/compliance-connectors/setup/vulnerability-scanning/apiiro) | API token | Connection record |
| [**Arnica**](/docs/compliance-connectors/setup/vulnerability-scanning/arnica) | API token | Connection record |
| [**AWS Inspector**](/docs/compliance-connectors/setup/vulnerability-scanning/aws-inspector) | API token | Automated evidence collection |
| [**Bright Security**](/docs/compliance-connectors/setup/vulnerability-scanning/bright-security) | API token | Automated compliance tests |
| [**Bugcrowd**](/docs/compliance-connectors/setup/vulnerability-scanning/bugcrowd) | API token | Automated compliance tests |
| [**Burp Suite**](/docs/compliance-connectors/setup/vulnerability-scanning/burp-suite) | API token | Automated compliance tests |
| [**Chainguard**](/docs/compliance-connectors/setup/vulnerability-scanning/chainguard) | API token | Connection record |
| [**Checkmarx**](/docs/compliance-connectors/setup/vulnerability-scanning/checkmarx) | API token | Automated compliance tests |
| [**Cobalt**](/docs/compliance-connectors/setup/vulnerability-scanning/cobalt) | API token | Automated compliance tests |
| [**Contrast Security**](/docs/compliance-connectors/setup/vulnerability-scanning/contrast-security) | API token | Automated compliance tests |
| [**Dependency-Track**](/docs/compliance-connectors/setup/vulnerability-scanning/dependency-track) | API token | Automated compliance tests |
| [**Detectify**](/docs/compliance-connectors/setup/vulnerability-scanning/detectify) | API token | Automated compliance tests |
| [**Edgescan**](/docs/compliance-connectors/setup/vulnerability-scanning/edgescan) | API token | Connection record |
| [**Endor Labs**](/docs/compliance-connectors/setup/vulnerability-scanning/endor-labs) | API token | Automated compliance tests |
| [**Escape**](/docs/compliance-connectors/setup/vulnerability-scanning/escape) | API token | Automated compliance tests |
| [**GitGuardian**](/docs/compliance-connectors/setup/vulnerability-scanning/gitguardian) | API token | Automated compliance tests |
| [**Grype**](/docs/compliance-connectors/setup/vulnerability-scanning/grype) | API token | Connection record |
| [**HackerOne**](/docs/compliance-connectors/setup/vulnerability-scanning/hackerone) | API token | Automated compliance tests |
| [**Intruder**](/docs/compliance-connectors/setup/vulnerability-scanning/intruder) | API token | Automated compliance tests |
| [**Invicti**](/docs/compliance-connectors/setup/vulnerability-scanning/invicti) | API token | Automated compliance tests |
| [**JFrog Xray**](/docs/compliance-connectors/setup/vulnerability-scanning/jfrog-xray) | API token | Automated compliance tests |
| [**Legit Security**](/docs/compliance-connectors/setup/vulnerability-scanning/legit-security) | API token | Connection record |
| [**Mend**](/docs/compliance-connectors/setup/vulnerability-scanning/mend) | API token | Automated compliance tests |
| [**Nessus**](/docs/compliance-connectors/setup/vulnerability-scanning/nessus) | API token | Connection record |
| [**Nuclei**](/docs/compliance-connectors/setup/vulnerability-scanning/nuclei) | API token | Connection record |
| [**Nucleus Security**](/docs/compliance-connectors/setup/vulnerability-scanning/nucleus-security) | API token | Automated compliance tests |
| [**OpenVAS**](/docs/compliance-connectors/setup/vulnerability-scanning/openvas) | API token | Connection record |
| [**OWASP ZAP**](/docs/compliance-connectors/setup/vulnerability-scanning/owasp-zap) | API token | Connection record |
| [**Ox Security**](/docs/compliance-connectors/setup/vulnerability-scanning/ox-security) | API token | Automated compliance tests |
| [**Phylum**](/docs/compliance-connectors/setup/vulnerability-scanning/phylum) | API token | Connection record |
| [**Probely**](/docs/compliance-connectors/setup/vulnerability-scanning/probely) | API token | Automated compliance tests |
| [**Qualys**](/docs/compliance-connectors/setup/vulnerability-scanning/qualys) | API token | Automated compliance tests |
| [**Qualys EDR**](/docs/compliance-connectors/setup/vulnerability-scanning/qualys-edr) | API token | Automated compliance tests |
| [**Rapid7 InsightVM**](/docs/compliance-connectors/setup/vulnerability-scanning/rapid7-insightvm) | API token | Automated compliance tests |
| [**Red Hat Advanced Cluster Security**](/docs/compliance-connectors/setup/vulnerability-scanning/red-hat-advanced-cluster-security) | API token | Automated compliance tests |
| [**Safeguard**](/docs/compliance-connectors/setup/vulnerability-scanning/safeguard) | API token, MCP server | Connection record |
| [**Semgrep**](/docs/compliance-connectors/setup/vulnerability-scanning/semgrep) | API token | Automated compliance tests |
| [**Snyk**](/docs/compliance-connectors/setup/vulnerability-scanning/snyk) | API token | Automated compliance tests |
| [**Socket**](/docs/compliance-connectors/setup/vulnerability-scanning/socket) | API token | Automated compliance tests |
| [**SonarQube**](/docs/compliance-connectors/setup/vulnerability-scanning/sonarqube) | API token | Automated compliance tests |
| [**StackHawk**](/docs/compliance-connectors/setup/vulnerability-scanning/stackhawk) | API token | Automated compliance tests |
| [**StackRox**](/docs/compliance-connectors/setup/vulnerability-scanning/stackrox) | API token | Automated compliance tests |
| [**Tenable**](/docs/compliance-connectors/setup/vulnerability-scanning/tenable) | API token | Automated compliance tests |
| [**Tenable Cloud Security**](/docs/compliance-connectors/setup/vulnerability-scanning/tenable-cloud-security) | API token | Connection record |
| [**Trivy**](/docs/compliance-connectors/setup/vulnerability-scanning/trivy) | API token | Connection record |
| [**TruffleHog**](/docs/compliance-connectors/setup/vulnerability-scanning/trufflehog) | API token | Connection record |
| [**Veracode**](/docs/compliance-connectors/setup/vulnerability-scanning/veracode) | API token | Automated compliance tests |
| [**Wallarm**](/docs/compliance-connectors/setup/vulnerability-scanning/wallarm) | API token | Connection record |
## HRIS (40)
Onboarding and offboarding of personnel (CC6/HR).
| Connector | Connect with | Evidence |
| ----------------------------------------------------------------------------------- | ------------ | -------------------------- |
| [**15Five**](/docs/compliance-connectors/setup/hris/15five) | API token | Automated compliance tests |
| [**ADP Workforce Now**](/docs/compliance-connectors/setup/hris/adp-workforce-now) | API token | Connection record |
| [**Ashby**](/docs/compliance-connectors/setup/hris/ashby) | API token | Automated compliance tests |
| [**BambooHR**](/docs/compliance-connectors/setup/hris/bamboohr) | API token | People sync |
| [**Bob**](/docs/compliance-connectors/setup/hris/bob) | API token | People sync |
| [**Ceridian Dayforce**](/docs/compliance-connectors/setup/hris/ceridian-dayforce) | API token | Automated compliance tests |
| [**Charlie HR**](/docs/compliance-connectors/setup/hris/charlie-hr) | API token | Connection record |
| [**Culture Amp**](/docs/compliance-connectors/setup/hris/culture-amp) | API token | Automated compliance tests |
| [**Deel**](/docs/compliance-connectors/setup/hris/deel) | API token | People sync |
| [**Employment Hero**](/docs/compliance-connectors/setup/hris/employment-hero) | API token | Automated compliance tests |
| [**Factorial**](/docs/compliance-connectors/setup/hris/factorial) | API token | Automated compliance tests |
| [**Greenhouse**](/docs/compliance-connectors/setup/hris/greenhouse) | API token | Automated compliance tests |
| [**Gusto**](/docs/compliance-connectors/setup/hris/gusto) | API token | Automated compliance tests |
| [**HiBob**](/docs/compliance-connectors/setup/hris/hibob) | API token | People sync |
| [**Hourly**](/docs/compliance-connectors/setup/hris/hourly) | API token | Connection record |
| [**Humaans**](/docs/compliance-connectors/setup/hris/humaans) | API token | Automated compliance tests |
| [**Insperity**](/docs/compliance-connectors/setup/hris/insperity) | API token | Connection record |
| [**Justworks**](/docs/compliance-connectors/setup/hris/justworks) | API token | Connection record |
| [**Lattice**](/docs/compliance-connectors/setup/hris/lattice) | API token | Automated compliance tests |
| [**Lever**](/docs/compliance-connectors/setup/hris/lever) | API token | Automated compliance tests |
| [**Multiplier**](/docs/compliance-connectors/setup/hris/multiplier) | API token | Connection record |
| [**Namely**](/docs/compliance-connectors/setup/hris/namely) | API token | Connection record |
| [**Oyster HR**](/docs/compliance-connectors/setup/hris/oyster-hr) | API token | Connection record |
| [**Papaya Global**](/docs/compliance-connectors/setup/hris/papaya-global) | API token | Connection record |
| [**Paychex**](/docs/compliance-connectors/setup/hris/paychex) | API token | Automated compliance tests |
| [**Paycom**](/docs/compliance-connectors/setup/hris/paycom) | API token | Connection record |
| [**Paylocity**](/docs/compliance-connectors/setup/hris/paylocity) | API token | Connection record |
| [**Personio**](/docs/compliance-connectors/setup/hris/personio) | API token | Connection record |
| [**Remote**](/docs/compliance-connectors/setup/hris/remote) | API token | Connection record |
| [**Rippling**](/docs/compliance-connectors/setup/hris/rippling) | API token | People sync |
| [**Rippling MDM**](/docs/compliance-connectors/setup/hris/rippling-mdm) | API token | Connection record |
| [**Sage HR**](/docs/compliance-connectors/setup/hris/sage-hr) | API token | Automated compliance tests |
| [**SAP SuccessFactors**](/docs/compliance-connectors/setup/hris/sap-successfactors) | API token | Automated compliance tests |
| [**Sapling**](/docs/compliance-connectors/setup/hris/sapling) | API token | Automated compliance tests |
| [**TriNet**](/docs/compliance-connectors/setup/hris/trinet) | API token | Connection record |
| [**UKG**](/docs/compliance-connectors/setup/hris/ukg) | API token | Automated compliance tests |
| [**Workable**](/docs/compliance-connectors/setup/hris/workable) | API token | Automated compliance tests |
| [**Workday**](/docs/compliance-connectors/setup/hris/workday) | API token | Automated compliance tests |
| [**Workleap**](/docs/compliance-connectors/setup/hris/workleap) | API token | Connection record |
| [**Zenefits**](/docs/compliance-connectors/setup/hris/zenefits) | API token | Automated compliance tests |
## Endpoint Detection & Response (32)
Endpoint protection and threat detection (CC6/CC7).
| Connector | Connect with | Evidence |
| ---------------------------------------------------------------------------------------------------------------------------------------- | ------------ | -------------------------- |
| [**Arctic Wolf**](/docs/compliance-connectors/setup/endpoint-detection-and-response/arctic-wolf) | API token | Connection record |
| [**Arctic Wolf Managed Awareness**](/docs/compliance-connectors/setup/endpoint-detection-and-response/arctic-wolf-managed-awareness) | API token | Connection record |
| [**Bitdefender GravityZone**](/docs/compliance-connectors/setup/endpoint-detection-and-response/bitdefender-gravityzone) | API token | Automated compliance tests |
| [**Blackpoint Cyber**](/docs/compliance-connectors/setup/endpoint-detection-and-response/blackpoint-cyber) | API token | Connection record |
| [**Check Point Harmony**](/docs/compliance-connectors/setup/endpoint-detection-and-response/check-point-harmony) | API token | Automated compliance tests |
| [**Cisco Secure Endpoint**](/docs/compliance-connectors/setup/endpoint-detection-and-response/cisco-secure-endpoint) | API token | Automated compliance tests |
| [**Cortex XDR**](/docs/compliance-connectors/setup/endpoint-detection-and-response/cortex-xdr) | API token | Automated compliance tests |
| [**CrowdStrike Falcon**](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon) | API token | Automated compliance tests |
| [**CrowdStrike Falcon Cloud**](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon-cloud) | API token | Automated compliance tests |
| [**Cybereason**](/docs/compliance-connectors/setup/endpoint-detection-and-response/cybereason) | API token | Automated compliance tests |
| [**Cynet**](/docs/compliance-connectors/setup/endpoint-detection-and-response/cynet) | API token | Connection record |
| [**Deep Instinct**](/docs/compliance-connectors/setup/endpoint-detection-and-response/deep-instinct) | API token | Automated compliance tests |
| [**Elastic Security**](/docs/compliance-connectors/setup/endpoint-detection-and-response/elastic-security) | API token | Automated compliance tests |
| [**ESET Protect**](/docs/compliance-connectors/setup/endpoint-detection-and-response/eset-protect) | API token | Automated compliance tests |
| [**Fleet osquery**](/docs/compliance-connectors/setup/endpoint-detection-and-response/fleet-osquery) | API token | Connection record |
| [**Fortinet FortiEDR**](/docs/compliance-connectors/setup/endpoint-detection-and-response/fortinet-fortiedr) | API token | Automated compliance tests |
| [**Huntress**](/docs/compliance-connectors/setup/endpoint-detection-and-response/huntress) | API token | Automated compliance tests |
| [**Jamf Protect**](/docs/compliance-connectors/setup/endpoint-detection-and-response/jamf-protect) | API token | Automated compliance tests |
| [**Kaspersky Endpoint**](/docs/compliance-connectors/setup/endpoint-detection-and-response/kaspersky-endpoint) | API token | Automated compliance tests |
| [**Lookout**](/docs/compliance-connectors/setup/endpoint-detection-and-response/lookout) | API token | Connection record |
| [**Malwarebytes**](/docs/compliance-connectors/setup/endpoint-detection-and-response/malwarebytes) | API token | Automated compliance tests |
| [**Microsoft Defender for Endpoint**](/docs/compliance-connectors/setup/endpoint-detection-and-response/microsoft-defender-for-endpoint) | API token | Automated compliance tests |
| [**Rapid7 InsightIDR**](/docs/compliance-connectors/setup/endpoint-detection-and-response/rapid7-insightidr) | API token | Automated compliance tests |
| [**Red Canary**](/docs/compliance-connectors/setup/endpoint-detection-and-response/red-canary) | API token | Automated compliance tests |
| [**SentinelOne**](/docs/compliance-connectors/setup/endpoint-detection-and-response/sentinelone) | API token | Automated compliance tests |
| [**Sophos Intercept X**](/docs/compliance-connectors/setup/endpoint-detection-and-response/sophos-intercept-x) | API token | Automated compliance tests |
| [**Symantec Endpoint**](/docs/compliance-connectors/setup/endpoint-detection-and-response/symantec-endpoint) | API token | Automated compliance tests |
| [**Tanium**](/docs/compliance-connectors/setup/endpoint-detection-and-response/tanium) | API token | Automated compliance tests |
| [**Trellix**](/docs/compliance-connectors/setup/endpoint-detection-and-response/trellix) | API token | Automated compliance tests |
| [**Trend Micro Apex One**](/docs/compliance-connectors/setup/endpoint-detection-and-response/trend-micro-apex-one) | API token | Automated compliance tests |
| [**Webroot**](/docs/compliance-connectors/setup/endpoint-detection-and-response/webroot) | API token | Automated compliance tests |
| [**WithSecure**](/docs/compliance-connectors/setup/endpoint-detection-and-response/withsecure) | API token | Automated compliance tests |
## MDM (24)
Managed devices and their posture (CC6/C1).
| Connector | Connect with | Evidence |
| -------------------------------------------------------------------------------------------------- | ------------ | -------------------------- |
| [**42Gears**](/docs/compliance-connectors/setup/mdm/42gears) | API token | Automated compliance tests |
| [**Action1**](/docs/compliance-connectors/setup/mdm/action1) | API token | Automated compliance tests |
| [**Addigy**](/docs/compliance-connectors/setup/mdm/addigy) | API token | Connection record |
| [**Automox**](/docs/compliance-connectors/setup/mdm/automox) | API token | Automated compliance tests |
| [**Baramundi**](/docs/compliance-connectors/setup/mdm/baramundi) | API token | Automated compliance tests |
| [**Cisco Meraki SM**](/docs/compliance-connectors/setup/mdm/cisco-meraki-sm) | API token | Automated compliance tests |
| [**Citrix Endpoint Management**](/docs/compliance-connectors/setup/mdm/citrix-endpoint-management) | API token | Automated compliance tests |
| [**Esper**](/docs/compliance-connectors/setup/mdm/esper) | API token | Automated compliance tests |
| [**Fleet**](/docs/compliance-connectors/setup/mdm/fleet) | API token | Automated compliance tests |
| [**Hexnode**](/docs/compliance-connectors/setup/mdm/hexnode) | API token | Automated compliance tests |
| [**IBM MaaS360**](/docs/compliance-connectors/setup/mdm/ibm-maas360) | API token | Connection record |
| [**Ivanti Neurons**](/docs/compliance-connectors/setup/mdm/ivanti-neurons) | API token | Automated compliance tests |
| [**Jamf**](/docs/compliance-connectors/setup/mdm/jamf) | API token | Automated compliance tests |
| [**Kandji**](/docs/compliance-connectors/setup/mdm/kandji) | API token | Automated compliance tests |
| [**Kolide**](/docs/compliance-connectors/setup/mdm/kolide) | API token | Automated compliance tests |
| [**ManageEngine**](/docs/compliance-connectors/setup/mdm/manageengine) | API token | Automated compliance tests |
| [**Microsoft Intune**](/docs/compliance-connectors/setup/mdm/microsoft-intune) | API token | Automated compliance tests |
| [**Miradore**](/docs/compliance-connectors/setup/mdm/miradore) | API token | Automated compliance tests |
| [**Mosyle**](/docs/compliance-connectors/setup/mdm/mosyle) | API token | Automated compliance tests |
| [**NinjaOne**](/docs/compliance-connectors/setup/mdm/ninjaone) | API token | Automated compliance tests |
| [**Prey**](/docs/compliance-connectors/setup/mdm/prey) | API token | Automated compliance tests |
| [**Scalefusion**](/docs/compliance-connectors/setup/mdm/scalefusion) | API token | Connection record |
| [**SimpleMDM**](/docs/compliance-connectors/setup/mdm/simplemdm) | API token | Automated compliance tests |
| [**SOTI MobiControl**](/docs/compliance-connectors/setup/mdm/soti-mobicontrol) | API token | Connection record |
## Ticketing (30)
Ticketing and incident response (CC7/CC8).
| Connector | Connect with | Evidence |
| -------------------------------------------------------------------------------------------------- | --------------------- | -------------------------- |
| [**Aha!**](/docs/compliance-connectors/setup/ticketing/aha) | API token | Automated compliance tests |
| [**Airtable**](/docs/compliance-connectors/setup/ticketing/airtable) | API token, MCP server | Automated compliance tests |
| [**Asana**](/docs/compliance-connectors/setup/ticketing/asana) | API token, MCP server | Automated compliance tests |
| [**Azure Boards**](/docs/compliance-connectors/setup/ticketing/azure-boards) | API token | Connection record |
| [**Basecamp**](/docs/compliance-connectors/setup/ticketing/basecamp) | API token | Automated compliance tests |
| [**ClickUp**](/docs/compliance-connectors/setup/ticketing/clickup) | API token | Automated compliance tests |
| [**Freshdesk**](/docs/compliance-connectors/setup/ticketing/freshdesk) | API token | Automated compliance tests |
| [**Freshservice**](/docs/compliance-connectors/setup/ticketing/freshservice) | API token | Automated compliance tests |
| [**Hive**](/docs/compliance-connectors/setup/ticketing/hive) | API token | Automated compliance tests |
| [**Intercom Tickets**](/docs/compliance-connectors/setup/ticketing/intercom-tickets) | API token | Connection record |
| [**Jira**](/docs/compliance-connectors/setup/ticketing/jira) | OAuth, API token | Automated compliance tests |
| [**Jira Service Management**](/docs/compliance-connectors/setup/ticketing/jira-service-management) | API token | Automated compliance tests |
| [**Linear**](/docs/compliance-connectors/setup/ticketing/linear) | API token, MCP server | Automated compliance tests |
| [**Monday.com**](/docs/compliance-connectors/setup/ticketing/monday-com) | API token, MCP server | Automated compliance tests |
| [**Opsgenie Alerts**](/docs/compliance-connectors/setup/ticketing/opsgenie-alerts) | API token | Automated compliance tests |
| [**PagerDuty**](/docs/compliance-connectors/setup/ticketing/pagerduty) | API token, MCP server | Automated compliance tests |
| [**PagerDuty Incidents**](/docs/compliance-connectors/setup/ticketing/pagerduty-incidents) | API token | Connection record |
| [**Productboard**](/docs/compliance-connectors/setup/ticketing/productboard) | API token | Automated compliance tests |
| [**Redmine**](/docs/compliance-connectors/setup/ticketing/redmine) | API token | Automated compliance tests |
| [**ServiceNow**](/docs/compliance-connectors/setup/ticketing/servicenow) | API token | Automated compliance tests |
| [**Shortcut**](/docs/compliance-connectors/setup/ticketing/shortcut) | API token | Automated compliance tests |
| [**Smartsheet**](/docs/compliance-connectors/setup/ticketing/smartsheet) | API token | Automated compliance tests |
| [**SolarWinds Service Desk**](/docs/compliance-connectors/setup/ticketing/solarwinds-service-desk) | API token | Automated compliance tests |
| [**Teamwork**](/docs/compliance-connectors/setup/ticketing/teamwork) | API token | Automated compliance tests |
| [**Trello**](/docs/compliance-connectors/setup/ticketing/trello) | API token | Automated compliance tests |
| [**Wrike**](/docs/compliance-connectors/setup/ticketing/wrike) | API token | Automated compliance tests |
| [**YouTrack**](/docs/compliance-connectors/setup/ticketing/youtrack) | API token | Automated compliance tests |
| [**Zendesk**](/docs/compliance-connectors/setup/ticketing/zendesk) | API token | Automated compliance tests |
| [**Zendesk Sell**](/docs/compliance-connectors/setup/ticketing/zendesk-sell) | API token | Automated compliance tests |
| [**Zoho Desk**](/docs/compliance-connectors/setup/ticketing/zoho-desk) | API token | Automated compliance tests |
## Observability (35)
Availability and performance monitoring (A1).
| Connector | Connect with | Evidence |
| ------------------------------------------------------------------------------------------------------ | --------------------- | ----------------------------- |
| [**Amazon CloudWatch**](/docs/compliance-connectors/setup/observability/amazon-cloudwatch) | API token | Automated evidence collection |
| [**AppDynamics**](/docs/compliance-connectors/setup/observability/appdynamics) | API token | Automated compliance tests |
| [**Better Stack**](/docs/compliance-connectors/setup/observability/better-stack) | API token | Automated compliance tests |
| [**Bugsnag**](/docs/compliance-connectors/setup/observability/bugsnag) | API token | Connection record |
| [**Checkmk**](/docs/compliance-connectors/setup/observability/checkmk) | API token | Connection record |
| [**Chronosphere**](/docs/compliance-connectors/setup/observability/chronosphere) | API token | Automated compliance tests |
| [**Coralogix**](/docs/compliance-connectors/setup/observability/coralogix) | API token | Automated compliance tests |
| [**Cronitor**](/docs/compliance-connectors/setup/observability/cronitor) | API token | Automated compliance tests |
| [**Datadog**](/docs/compliance-connectors/setup/observability/datadog) | API token | Automated evidence collection |
| [**Datadog CSM**](/docs/compliance-connectors/setup/observability/datadog-csm) | API token | Automated evidence collection |
| [**Dynatrace**](/docs/compliance-connectors/setup/observability/dynatrace) | API token | Automated compliance tests |
| [**Elastic Observability**](/docs/compliance-connectors/setup/observability/elastic-observability) | API token | Automated compliance tests |
| [**Google Cloud Operations**](/docs/compliance-connectors/setup/observability/google-cloud-operations) | API token | Connection record |
| [**Grafana**](/docs/compliance-connectors/setup/observability/grafana) | API token | Automated compliance tests |
| [**Honeycomb**](/docs/compliance-connectors/setup/observability/honeycomb) | API token | Connection record |
| [**Instana**](/docs/compliance-connectors/setup/observability/instana) | API token | Automated compliance tests |
| [**LogicMonitor**](/docs/compliance-connectors/setup/observability/logicmonitor) | API token | Automated compliance tests |
| [**Logz.io**](/docs/compliance-connectors/setup/observability/logz-io) | API token | Automated compliance tests |
| [**Nagios**](/docs/compliance-connectors/setup/observability/nagios) | API token | Connection record |
| [**Netdata**](/docs/compliance-connectors/setup/observability/netdata) | API token | Connection record |
| [**New Relic**](/docs/compliance-connectors/setup/observability/new-relic) | API token | Automated compliance tests |
| [**OpenTelemetry**](/docs/compliance-connectors/setup/observability/opentelemetry) | API token | Connection record |
| [**Pingdom**](/docs/compliance-connectors/setup/observability/pingdom) | API token | Automated compliance tests |
| [**Prometheus**](/docs/compliance-connectors/setup/observability/prometheus) | API token | Automated compliance tests |
| [**Raygun**](/docs/compliance-connectors/setup/observability/raygun) | API token | Connection record |
| [**Rollbar**](/docs/compliance-connectors/setup/observability/rollbar) | API token | Automated compliance tests |
| [**Sentry**](/docs/compliance-connectors/setup/observability/sentry) | API token, MCP server | Automated compliance tests |
| [**SigNoz**](/docs/compliance-connectors/setup/observability/signoz) | API token | Automated compliance tests |
| [**Site24x7**](/docs/compliance-connectors/setup/observability/site24x7) | API token | Automated compliance tests |
| [**Splunk**](/docs/compliance-connectors/setup/observability/splunk) | API token | Automated compliance tests |
| [**Splunk SOAR**](/docs/compliance-connectors/setup/observability/splunk-soar) | API token | Automated compliance tests |
| [**Sumo Logic**](/docs/compliance-connectors/setup/observability/sumo-logic) | API token | Automated compliance tests |
| [**Uptime Robot**](/docs/compliance-connectors/setup/observability/uptime-robot) | API token | Automated compliance tests |
| [**VictoriaMetrics**](/docs/compliance-connectors/setup/observability/victoriametrics) | API token | Automated compliance tests |
| [**Zabbix**](/docs/compliance-connectors/setup/observability/zabbix) | API token | Automated compliance tests |
## Cloud Storage Provider (21)
Confidentiality of stored data (C1).
| Connector | Connect with | Evidence |
| --------------------------------------------------------------------------------------------------------- | ---------------------------- | ----------------------------- |
| [**Amazon S3**](/docs/compliance-connectors/setup/cloud-storage-provider/amazon-s3) | API token | Automated evidence collection |
| [**Azure Blob Storage**](/docs/compliance-connectors/setup/cloud-storage-provider/azure-blob-storage) | API token | Connection record |
| [**Backblaze**](/docs/compliance-connectors/setup/cloud-storage-provider/backblaze) | API token | Automated compliance tests |
| [**Box**](/docs/compliance-connectors/setup/cloud-storage-provider/box) | API token, MCP server | Automated compliance tests |
| [**Citrix ShareFile**](/docs/compliance-connectors/setup/cloud-storage-provider/citrix-sharefile) | API token | Automated compliance tests |
| [**Dropbox**](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox) | API token | Automated compliance tests |
| [**Dropbox Sign**](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox-sign) | API token | Automated compliance tests |
| [**Egnyte**](/docs/compliance-connectors/setup/cloud-storage-provider/egnyte) | API token, MCP server | Automated compliance tests |
| [**Google Cloud Storage**](/docs/compliance-connectors/setup/cloud-storage-provider/google-cloud-storage) | OAuth, API token | Automated evidence collection |
| [**Google Drive**](/docs/compliance-connectors/setup/cloud-storage-provider/google-drive) | OAuth, API token, MCP server | Automated evidence collection |
| [**Hack The Box**](/docs/compliance-connectors/setup/cloud-storage-provider/hack-the-box) | API token | Connection record |
| [**iCloud**](/docs/compliance-connectors/setup/cloud-storage-provider/icloud) | API token | Connection record |
| [**IDrive**](/docs/compliance-connectors/setup/cloud-storage-provider/idrive) | API token | Connection record |
| [**MinIO**](/docs/compliance-connectors/setup/cloud-storage-provider/minio) | API token | Automated compliance tests |
| [**Nextcloud**](/docs/compliance-connectors/setup/cloud-storage-provider/nextcloud) | API token | Automated compliance tests |
| [**OneDrive**](/docs/compliance-connectors/setup/cloud-storage-provider/onedrive) | API token | Automated evidence collection |
| [**ownCloud**](/docs/compliance-connectors/setup/cloud-storage-provider/owncloud) | API token | Automated compliance tests |
| [**pCloud**](/docs/compliance-connectors/setup/cloud-storage-provider/pcloud) | API token | Connection record |
| [**SharePoint**](/docs/compliance-connectors/setup/cloud-storage-provider/sharepoint) | API token | Automated evidence collection |
| [**Storj**](/docs/compliance-connectors/setup/cloud-storage-provider/storj) | API token | Connection record |
| [**Wasabi**](/docs/compliance-connectors/setup/cloud-storage-provider/wasabi) | API token | Automated compliance tests |
## Compliance As Code (22)
GRC platforms and policy evidence.
| Connector | Connect with | Evidence |
| --------------------------------------------------------------------------------------------- | --------------------- | -------------------------- |
| [**Anecdotes**](/docs/compliance-connectors/setup/compliance-as-code/anecdotes) | API token | Connection record |
| [**Apptega**](/docs/compliance-connectors/setup/compliance-as-code/apptega) | API token | Connection record |
| [**Archer**](/docs/compliance-connectors/setup/compliance-as-code/archer) | API token | Connection record |
| [**AuditBoard**](/docs/compliance-connectors/setup/compliance-as-code/auditboard) | API token | Connection record |
| [**Confluence**](/docs/compliance-connectors/setup/compliance-as-code/confluence) | API token | Automated compliance tests |
| [**Drata**](/docs/compliance-connectors/setup/compliance-as-code/drata) | API token | Connection record |
| [**First Advantage**](/docs/compliance-connectors/setup/compliance-as-code/first-advantage) | API token | Connection record |
| [**Google Docs**](/docs/compliance-connectors/setup/compliance-as-code/google-docs) | OAuth, API token | Connection record |
| [**Hyperproof**](/docs/compliance-connectors/setup/compliance-as-code/hyperproof) | API token | Connection record |
| [**LogicGate**](/docs/compliance-connectors/setup/compliance-as-code/logicgate) | API token | Connection record |
| [**MetricStream**](/docs/compliance-connectors/setup/compliance-as-code/metricstream) | API token | Connection record |
| [**NAVEX PolicyTech**](/docs/compliance-connectors/setup/compliance-as-code/navex-policytech) | API token | Connection record |
| [**Notion**](/docs/compliance-connectors/setup/compliance-as-code/notion) | API token, MCP server | Automated compliance tests |
| [**PowerDMS**](/docs/compliance-connectors/setup/compliance-as-code/powerdms) | API token | Connection record |
| [**Scrut Automation**](/docs/compliance-connectors/setup/compliance-as-code/scrut-automation) | API token | Connection record |
| [**Secureframe**](/docs/compliance-connectors/setup/compliance-as-code/secureframe) | API token | Connection record |
| [**Sprinto**](/docs/compliance-connectors/setup/compliance-as-code/sprinto) | API token | Connection record |
| [**Strike Graph**](/docs/compliance-connectors/setup/compliance-as-code/strike-graph) | API token | Connection record |
| [**Thoropass**](/docs/compliance-connectors/setup/compliance-as-code/thoropass) | API token | Connection record |
| [**TrustCloud**](/docs/compliance-connectors/setup/compliance-as-code/trustcloud) | API token | Connection record |
| [**Tugboat Logic**](/docs/compliance-connectors/setup/compliance-as-code/tugboat-logic) | API token | Connection record |
| [**Vanta**](/docs/compliance-connectors/setup/compliance-as-code/vanta) | API token | Connection record |
## Vendor Procurement (33)
Vendor risk and third-party management (CC9).
| Connector | Connect with | Evidence |
| ----------------------------------------------------------------------------------------------------------- | --------------------- | -------------------------- |
| [**Airbase**](/docs/compliance-connectors/setup/vendor-procurement/airbase) | API token | Connection record |
| [**BitSight**](/docs/compliance-connectors/setup/vendor-procurement/bitsight) | API token | Automated compliance tests |
| [**Brex**](/docs/compliance-connectors/setup/vendor-procurement/brex) | API token | Automated compliance tests |
| [**Conveyor**](/docs/compliance-connectors/setup/vendor-procurement/conveyor) | API token | Connection record |
| [**Coupa**](/docs/compliance-connectors/setup/vendor-procurement/coupa) | API token | Automated compliance tests |
| [**CyberGRX**](/docs/compliance-connectors/setup/vendor-procurement/cybergrx) | API token | Connection record |
| [**Gatekeeper**](/docs/compliance-connectors/setup/vendor-procurement/gatekeeper) | API token | Connection record |
| [**Gatekeeper OPA**](/docs/compliance-connectors/setup/vendor-procurement/gatekeeper-opa) | API token | Automated compliance tests |
| [**HyperComply**](/docs/compliance-connectors/setup/vendor-procurement/hypercomply) | API token | Connection record |
| [**Loopio**](/docs/compliance-connectors/setup/vendor-procurement/loopio) | API token | Automated compliance tests |
| [**OneTrust Questionnaire**](/docs/compliance-connectors/setup/vendor-procurement/onetrust-questionnaire) | API token | Connection record |
| [**OneTrust Vendorpedia**](/docs/compliance-connectors/setup/vendor-procurement/onetrust-vendorpedia) | API token | Automated compliance tests |
| [**Order.co**](/docs/compliance-connectors/setup/vendor-procurement/order-co) | API token | Connection record |
| [**Panorays**](/docs/compliance-connectors/setup/vendor-procurement/panorays) | API token | Connection record |
| [**Precoro**](/docs/compliance-connectors/setup/vendor-procurement/precoro) | API token | Connection record |
| [**Prevalent**](/docs/compliance-connectors/setup/vendor-procurement/prevalent) | API token | Connection record |
| [**ProcessUnity**](/docs/compliance-connectors/setup/vendor-procurement/processunity) | API token | Connection record |
| [**Ramp**](/docs/compliance-connectors/setup/vendor-procurement/ramp) | API token, MCP server | Automated compliance tests |
| [**Responsive**](/docs/compliance-connectors/setup/vendor-procurement/responsive) | API token | Connection record |
| [**RiskRecon**](/docs/compliance-connectors/setup/vendor-procurement/riskrecon) | API token | Connection record |
| [**SafeBase**](/docs/compliance-connectors/setup/vendor-procurement/safebase) | API token | Connection record |
| [**SAP Ariba**](/docs/compliance-connectors/setup/vendor-procurement/sap-ariba) | API token | Connection record |
| [**Sastrify**](/docs/compliance-connectors/setup/vendor-procurement/sastrify) | API token | Connection record |
| [**SecurityScorecard Atlas**](/docs/compliance-connectors/setup/vendor-procurement/securityscorecard-atlas) | API token | Automated compliance tests |
| [**Setyl**](/docs/compliance-connectors/setup/vendor-procurement/setyl) | API token | Automated compliance tests |
| [**Spendflo**](/docs/compliance-connectors/setup/vendor-procurement/spendflo) | API token | Connection record |
| [**Tropic**](/docs/compliance-connectors/setup/vendor-procurement/tropic) | API token | Connection record |
| [**UpGuard Vendor Risk**](/docs/compliance-connectors/setup/vendor-procurement/upguard-vendor-risk) | API token | Automated compliance tests |
| [**Vendict**](/docs/compliance-connectors/setup/vendor-procurement/vendict) | API token | Connection record |
| [**Vendr**](/docs/compliance-connectors/setup/vendor-procurement/vendr) | API token | Connection record |
| [**Venminder**](/docs/compliance-connectors/setup/vendor-procurement/venminder) | API token | Connection record |
| [**Whistic**](/docs/compliance-connectors/setup/vendor-procurement/whistic) | API token | Connection record |
| [**Zip**](/docs/compliance-connectors/setup/vendor-procurement/zip) | API token | Connection record |
## User Access Review (13)
Access governance and periodic review (CC6).
| Connector | Connect with | Evidence |
| ----------------------------------------------------------------------------------------- | ------------ | -------------------------- |
| [**BetterCloud**](/docs/compliance-connectors/setup/user-access-review/bettercloud) | API token | Connection record |
| [**ConductorOne**](/docs/compliance-connectors/setup/user-access-review/conductorone) | API token | Connection record |
| [**Josys**](/docs/compliance-connectors/setup/user-access-review/josys) | API token | Connection record |
| [**Lumos**](/docs/compliance-connectors/setup/user-access-review/lumos) | API token | Connection record |
| [**Omada Identity**](/docs/compliance-connectors/setup/user-access-review/omada-identity) | API token | Connection record |
| [**Opal**](/docs/compliance-connectors/setup/user-access-review/opal) | API token | Automated compliance tests |
| [**Rezonate**](/docs/compliance-connectors/setup/user-access-review/rezonate) | API token | Connection record |
| [**Sonrai Access**](/docs/compliance-connectors/setup/user-access-review/sonrai-access) | API token | Connection record |
| [**Torii**](/docs/compliance-connectors/setup/user-access-review/torii) | API token | Automated compliance tests |
| [**Trelica**](/docs/compliance-connectors/setup/user-access-review/trelica) | API token | Connection record |
| [**Veza**](/docs/compliance-connectors/setup/user-access-review/veza) | API token | Automated compliance tests |
| [**Zilla Security**](/docs/compliance-connectors/setup/user-access-review/zilla-security) | API token | Connection record |
| [**Zluri**](/docs/compliance-connectors/setup/user-access-review/zluri) | API token | Connection record |
## Security Training (24)
Security awareness training (CC1/HR).
| Connector | Connect with | Evidence |
| ---------------------------------------------------------------------------------------------------------------------- | ------------ | -------------------------- |
| [**360Learning**](/docs/compliance-connectors/setup/security-training/360learning) | API token | Automated compliance tests |
| [**Cornerstone**](/docs/compliance-connectors/setup/security-training/cornerstone) | API token | Connection record |
| [**Coursera**](/docs/compliance-connectors/setup/security-training/coursera) | API token | Connection record |
| [**Curricula**](/docs/compliance-connectors/setup/security-training/curricula) | API token | Connection record |
| [**CybSafe**](/docs/compliance-connectors/setup/security-training/cybsafe) | API token | Connection record |
| [**Docebo**](/docs/compliance-connectors/setup/security-training/docebo) | API token | Automated compliance tests |
| [**Hoxhunt**](/docs/compliance-connectors/setup/security-training/hoxhunt) | API token | Connection record |
| [**Immersive Labs**](/docs/compliance-connectors/setup/security-training/immersive-labs) | API token | Automated compliance tests |
| [**Infosec IQ**](/docs/compliance-connectors/setup/security-training/infosec-iq) | API token | Connection record |
| [**KnowBe4**](/docs/compliance-connectors/setup/security-training/knowbe4) | API token | Connection record |
| [**Lessonly**](/docs/compliance-connectors/setup/security-training/lessonly) | API token | Automated compliance tests |
| [**Living Security**](/docs/compliance-connectors/setup/security-training/living-security) | API token | Connection record |
| [**Mimecast Awareness**](/docs/compliance-connectors/setup/security-training/mimecast-awareness) | API token | Connection record |
| [**NINJIO**](/docs/compliance-connectors/setup/security-training/ninjio) | API token | Connection record |
| [**Pluralsight**](/docs/compliance-connectors/setup/security-training/pluralsight) | API token | Connection record |
| [**Proofpoint Security Awareness**](/docs/compliance-connectors/setup/security-training/proofpoint-security-awareness) | API token | Automated compliance tests |
| [**Riot**](/docs/compliance-connectors/setup/security-training/riot) | API token | Automated compliance tests |
| [**SANS Security Awareness**](/docs/compliance-connectors/setup/security-training/sans-security-awareness) | API token | Connection record |
| [**Secure Code Warrior**](/docs/compliance-connectors/setup/security-training/secure-code-warrior) | API token | Connection record |
| [**TalentLMS**](/docs/compliance-connectors/setup/security-training/talentlms) | API token | Automated compliance tests |
| [**Terranova Security**](/docs/compliance-connectors/setup/security-training/terranova-security) | API token | Connection record |
| [**TryHackMe**](/docs/compliance-connectors/setup/security-training/tryhackme) | API token | Connection record |
| [**Udemy Business**](/docs/compliance-connectors/setup/security-training/udemy-business) | API token | Automated compliance tests |
| [**Wizer**](/docs/compliance-connectors/setup/security-training/wizer) | API token | Connection record |
## Background Check Providers (19)
Pre-employment screening (HR).
| Connector | Connect with | Evidence |
| --------------------------------------------------------------------------------------------------------------------------------- | ------------ | -------------------------- |
| [**Accurate**](/docs/compliance-connectors/setup/background-check-providers/accurate) | API token | Connection record |
| [**Certn**](/docs/compliance-connectors/setup/background-check-providers/certn) | API token | Connection record |
| [**Checkr**](/docs/compliance-connectors/setup/background-check-providers/checkr) | API token | Connection record |
| [**Cisive**](/docs/compliance-connectors/setup/background-check-providers/cisive) | API token | Connection record |
| [**ClearChecks**](/docs/compliance-connectors/setup/background-check-providers/clearchecks) | API token | Connection record |
| [**GoodHire**](/docs/compliance-connectors/setup/background-check-providers/goodhire) | API token | Connection record |
| [**HireRight**](/docs/compliance-connectors/setup/background-check-providers/hireright) | API token | Connection record |
| [**IDenfy**](/docs/compliance-connectors/setup/background-check-providers/idenfy) | API token | Connection record |
| [**Jumio**](/docs/compliance-connectors/setup/background-check-providers/jumio) | API token | Connection record |
| [**Onfido**](/docs/compliance-connectors/setup/background-check-providers/onfido) | API token | Connection record |
| [**Persona**](/docs/compliance-connectors/setup/background-check-providers/persona) | API token | Connection record |
| [**Socure**](/docs/compliance-connectors/setup/background-check-providers/socure) | API token | Connection record |
| [**Sterling**](/docs/compliance-connectors/setup/background-check-providers/sterling) | API token | Connection record |
| [**Truework**](/docs/compliance-connectors/setup/background-check-providers/truework) | API token | Connection record |
| [**Universal Background Screening**](/docs/compliance-connectors/setup/background-check-providers/universal-background-screening) | API token | Connection record |
| [**Veremark**](/docs/compliance-connectors/setup/background-check-providers/veremark) | API token | Connection record |
| [**Vetty**](/docs/compliance-connectors/setup/background-check-providers/vetty) | API token | Connection record |
| [**Yardstik**](/docs/compliance-connectors/setup/background-check-providers/yardstik) | API token | Automated compliance tests |
| [**Zinc**](/docs/compliance-connectors/setup/background-check-providers/zinc) | API token | Connection record |
## CSPM (23)
Cloud security posture management (CC6/CC7).
| Connector | Connect with | Evidence |
| ----------------------------------------------------------------------------------------------------------- | ------------ | ----------------------------- |
| [**Aqua Security**](/docs/compliance-connectors/setup/cspm/aqua-security) | API token | Connection record |
| [**AWS Security Hub**](/docs/compliance-connectors/setup/cspm/aws-security-hub) | API token | Automated evidence collection |
| [**Check Point CloudGuard**](/docs/compliance-connectors/setup/cspm/check-point-cloudguard) | API token | Automated compliance tests |
| [**Cloudanix**](/docs/compliance-connectors/setup/cspm/cloudanix) | API token | Connection record |
| [**CoreStack**](/docs/compliance-connectors/setup/cspm/corestack) | API token | Connection record |
| [**Cyscale**](/docs/compliance-connectors/setup/cspm/cyscale) | API token | Connection record |
| [**Ermetic**](/docs/compliance-connectors/setup/cspm/ermetic) | API token | Connection record |
| [**Google Security Command Center**](/docs/compliance-connectors/setup/cspm/google-security-command-center) | API token | Connection record |
| [**Kion**](/docs/compliance-connectors/setup/cspm/kion) | API token | Connection record |
| [**Lacework**](/docs/compliance-connectors/setup/cspm/lacework) | API token | Automated compliance tests |
| [**Microsoft Defender for Cloud**](/docs/compliance-connectors/setup/cspm/microsoft-defender-for-cloud) | API token | Connection record |
| [**Orca Security**](/docs/compliance-connectors/setup/cspm/orca-security) | API token | Connection record |
| [**Prisma Cloud**](/docs/compliance-connectors/setup/cspm/prisma-cloud) | API token | Automated compliance tests |
| [**Rapid7 InsightCloudSec**](/docs/compliance-connectors/setup/cspm/rapid7-insightcloudsec) | API token | Connection record |
| [**Sonrai Security**](/docs/compliance-connectors/setup/cspm/sonrai-security) | API token | Connection record |
| [**Stream Security**](/docs/compliance-connectors/setup/cspm/stream-security) | API token | Connection record |
| [**Sweet Security**](/docs/compliance-connectors/setup/cspm/sweet-security) | API token | Connection record |
| [**Sysdig**](/docs/compliance-connectors/setup/cspm/sysdig) | API token | Connection record |
| [**Trend Micro Cloud One**](/docs/compliance-connectors/setup/cspm/trend-micro-cloud-one) | API token | Automated compliance tests |
| [**Turbot**](/docs/compliance-connectors/setup/cspm/turbot) | API token | Automated compliance tests |
| [**Uptycs**](/docs/compliance-connectors/setup/cspm/uptycs) | API token | Connection record |
| [**Wiz**](/docs/compliance-connectors/setup/cspm/wiz) | API token | Automated compliance tests |
| [**Zscaler Posture Control**](/docs/compliance-connectors/setup/cspm/zscaler-posture-control) | API token | Connection record |
## Security Automation (20)
SOAR and security automation (CC7).
| Connector | Connect with | Evidence |
| -------------------------------------------------------------------------------------------------------- | --------------------- | -------------------------- |
| [**Blink Ops**](/docs/compliance-connectors/setup/security-automation/blink-ops) | API token | Connection record |
| [**Cortex XSOAR**](/docs/compliance-connectors/setup/security-automation/cortex-xsoar) | API token | Automated compliance tests |
| [**Cyware**](/docs/compliance-connectors/setup/security-automation/cyware) | API token | Connection record |
| [**D3 Security**](/docs/compliance-connectors/setup/security-automation/d3-security) | API token | Automated compliance tests |
| [**Google Chronicle SOAR**](/docs/compliance-connectors/setup/security-automation/google-chronicle-soar) | API token | Automated compliance tests |
| [**IBM QRadar SOAR**](/docs/compliance-connectors/setup/security-automation/ibm-qradar-soar) | API token | Automated compliance tests |
| [**Make**](/docs/compliance-connectors/setup/security-automation/make) | API token | Automated compliance tests |
| [**Mindflow**](/docs/compliance-connectors/setup/security-automation/mindflow) | API token | Connection record |
| [**n8n**](/docs/compliance-connectors/setup/security-automation/n8n) | API token | Automated compliance tests |
| [**Palo Alto XSOAR**](/docs/compliance-connectors/setup/security-automation/palo-alto-xsoar) | API token | Connection record |
| [**Pipedream**](/docs/compliance-connectors/setup/security-automation/pipedream) | API token | Connection record |
| [**Rapid7 InsightConnect**](/docs/compliance-connectors/setup/security-automation/rapid7-insightconnect) | API token | Connection record |
| [**Shuffle**](/docs/compliance-connectors/setup/security-automation/shuffle) | API token | Automated compliance tests |
| [**Swimlane**](/docs/compliance-connectors/setup/security-automation/swimlane) | API token | Connection record |
| [**ThreatConnect**](/docs/compliance-connectors/setup/security-automation/threatconnect) | API token | Automated compliance tests |
| [**Tines**](/docs/compliance-connectors/setup/security-automation/tines) | API token | Automated compliance tests |
| [**Torq**](/docs/compliance-connectors/setup/security-automation/torq) | API token | Automated compliance tests |
| [**Tray.io**](/docs/compliance-connectors/setup/security-automation/tray-io) | API token | Automated compliance tests |
| [**Workato**](/docs/compliance-connectors/setup/security-automation/workato) | API token | Automated compliance tests |
| [**Zapier**](/docs/compliance-connectors/setup/security-automation/zapier) | API token, MCP server | Connection record |
## Infrastructure (29)
Infrastructure-as-code, policy-as-code and secrets (CC7/CC8).
| Connector | Connect with | Evidence |
| ----------------------------------------------------------------------------------------------- | --------------------- | -------------------------- |
| [**Ansible**](/docs/compliance-connectors/setup/infrastructure/ansible) | API token | Automated compliance tests |
| [**Bridgecrew**](/docs/compliance-connectors/setup/infrastructure/bridgecrew) | API token | Connection record |
| [**Checkov**](/docs/compliance-connectors/setup/infrastructure/checkov) | API token | Connection record |
| [**Cloud Custodian**](/docs/compliance-connectors/setup/infrastructure/cloud-custodian) | API token | Connection record |
| [**CloudQuery**](/docs/compliance-connectors/setup/infrastructure/cloudquery) | API token | Connection record |
| [**Conftest**](/docs/compliance-connectors/setup/infrastructure/conftest) | API token | Connection record |
| [**Docker**](/docs/compliance-connectors/setup/infrastructure/docker) | API token | Automated compliance tests |
| [**env0**](/docs/compliance-connectors/setup/infrastructure/env0) | API token | Automated compliance tests |
| [**Fairwinds Polaris**](/docs/compliance-connectors/setup/infrastructure/fairwinds-polaris) | API token | Connection record |
| [**Firebase**](/docs/compliance-connectors/setup/infrastructure/firebase) | API token | Automated compliance tests |
| [**HashiCorp Terraform**](/docs/compliance-connectors/setup/infrastructure/hashicorp-terraform) | API token | Connection record |
| [**HashiCorp Vault**](/docs/compliance-connectors/setup/infrastructure/hashicorp-vault) | API token | Automated compliance tests |
| [**Infisical**](/docs/compliance-connectors/setup/infrastructure/infisical) | API token | Automated compliance tests |
| [**Kyverno**](/docs/compliance-connectors/setup/infrastructure/kyverno) | API token | Automated compliance tests |
| [**MongoDB Atlas**](/docs/compliance-connectors/setup/infrastructure/mongodb-atlas) | API token | Automated compliance tests |
| [**Open Policy Agent**](/docs/compliance-connectors/setup/infrastructure/open-policy-agent) | API token | Connection record |
| [**PlanetScale**](/docs/compliance-connectors/setup/infrastructure/planetscale) | API token | Automated compliance tests |
| [**Prowler**](/docs/compliance-connectors/setup/infrastructure/prowler) | API token | Automated compliance tests |
| [**Pulumi**](/docs/compliance-connectors/setup/infrastructure/pulumi) | API token | Automated compliance tests |
| [**Pulumi Cloud**](/docs/compliance-connectors/setup/infrastructure/pulumi-cloud) | API token | Automated compliance tests |
| [**Redis Cloud**](/docs/compliance-connectors/setup/infrastructure/redis-cloud) | API token | Automated compliance tests |
| [**Regula**](/docs/compliance-connectors/setup/infrastructure/regula) | API token | Connection record |
| [**Sentinel**](/docs/compliance-connectors/setup/infrastructure/sentinel) | API token | Connection record |
| [**Spacelift**](/docs/compliance-connectors/setup/infrastructure/spacelift) | API token | Automated compliance tests |
| [**Steampipe**](/docs/compliance-connectors/setup/infrastructure/steampipe) | API token | Connection record |
| [**Supabase**](/docs/compliance-connectors/setup/infrastructure/supabase) | API token, MCP server | Automated compliance tests |
| [**Terraform Cloud**](/docs/compliance-connectors/setup/infrastructure/terraform-cloud) | API token | Automated compliance tests |
| [**Terrascan**](/docs/compliance-connectors/setup/infrastructure/terrascan) | API token | Connection record |
| [**tfsec**](/docs/compliance-connectors/setup/infrastructure/tfsec) | API token | Connection record |
## Digital Signature (30)
E-signature and contract lifecycle (CC1/CC9).
| Connector | Connect with | Evidence |
| ------------------------------------------------------------------------------------------------ | ------------ | -------------------------- |
| [**Adobe Acrobat Sign**](/docs/compliance-connectors/setup/digital-signature/adobe-acrobat-sign) | API token | Automated compliance tests |
| [**BoldSign**](/docs/compliance-connectors/setup/digital-signature/boldsign) | API token | Automated compliance tests |
| [**Concord**](/docs/compliance-connectors/setup/digital-signature/concord) | API token | Connection record |
| [**Contractbook**](/docs/compliance-connectors/setup/digital-signature/contractbook) | API token | Connection record |
| [**ContractSafe**](/docs/compliance-connectors/setup/digital-signature/contractsafe) | API token | Connection record |
| [**Documenso**](/docs/compliance-connectors/setup/digital-signature/documenso) | API token | Connection record |
| [**DocuSign**](/docs/compliance-connectors/setup/digital-signature/docusign) | API token | Automated compliance tests |
| [**DocuSign CLM**](/docs/compliance-connectors/setup/digital-signature/docusign-clm) | API token | Connection record |
| [**Eversign**](/docs/compliance-connectors/setup/digital-signature/eversign) | API token | Connection record |
| [**Evisort**](/docs/compliance-connectors/setup/digital-signature/evisort) | API token | Connection record |
| [**Foxit eSign**](/docs/compliance-connectors/setup/digital-signature/foxit-esign) | API token | Connection record |
| [**GetAccept**](/docs/compliance-connectors/setup/digital-signature/getaccept) | API token | Connection record |
| [**Ironclad**](/docs/compliance-connectors/setup/digital-signature/ironclad) | API token | Automated compliance tests |
| [**Juro**](/docs/compliance-connectors/setup/digital-signature/juro) | API token | Connection record |
| [**Lexion**](/docs/compliance-connectors/setup/digital-signature/lexion) | API token | Connection record |
| [**LinkSquares**](/docs/compliance-connectors/setup/digital-signature/linksquares) | API token | Connection record |
| [**Oneflow**](/docs/compliance-connectors/setup/digital-signature/oneflow) | API token | Automated compliance tests |
| [**OneSpan Sign**](/docs/compliance-connectors/setup/digital-signature/onespan-sign) | API token | Automated compliance tests |
| [**PandaDoc**](/docs/compliance-connectors/setup/digital-signature/pandadoc) | API token | Automated compliance tests |
| [**PandaDoc NDA**](/docs/compliance-connectors/setup/digital-signature/pandadoc-nda) | API token | Connection record |
| [**RightSignature**](/docs/compliance-connectors/setup/digital-signature/rightsignature) | API token | Connection record |
| [**Signable**](/docs/compliance-connectors/setup/digital-signature/signable) | API token | Connection record |
| [**Signeasy**](/docs/compliance-connectors/setup/digital-signature/signeasy) | API token | Connection record |
| [**SignNow**](/docs/compliance-connectors/setup/digital-signature/signnow) | API token | Automated compliance tests |
| [**SignRequest**](/docs/compliance-connectors/setup/digital-signature/signrequest) | API token | Automated compliance tests |
| [**SignWell**](/docs/compliance-connectors/setup/digital-signature/signwell) | API token | Connection record |
| [**Skribble**](/docs/compliance-connectors/setup/digital-signature/skribble) | API token | Connection record |
| [**SpotDraft**](/docs/compliance-connectors/setup/digital-signature/spotdraft) | API token | Connection record |
| [**Yousign**](/docs/compliance-connectors/setup/digital-signature/yousign) | API token | Automated compliance tests |
| [**Zoho Sign**](/docs/compliance-connectors/setup/digital-signature/zoho-sign) | API token | Connection record |
## Communications Platforms (25)
Incident channels and communication context.
| Connector | Connect with | Evidence |
| ------------------------------------------------------------------------------------------------- | ---------------------------- | ----------------------------- |
| [**8x8**](/docs/compliance-connectors/setup/communications-platforms/8x8) | API token | Connection record |
| [**Aircall**](/docs/compliance-connectors/setup/communications-platforms/aircall) | API token | Automated compliance tests |
| [**Dialpad**](/docs/compliance-connectors/setup/communications-platforms/dialpad) | API token | Automated compliance tests |
| [**Discord**](/docs/compliance-connectors/setup/communications-platforms/discord) | API token | Connection record |
| [**Front**](/docs/compliance-connectors/setup/communications-platforms/front) | API token | Automated compliance tests |
| [**Google Meet**](/docs/compliance-connectors/setup/communications-platforms/google-meet) | OAuth, API token | Connection record |
| [**GoTo Connect**](/docs/compliance-connectors/setup/communications-platforms/goto-connect) | API token | Automated compliance tests |
| [**Intercom**](/docs/compliance-connectors/setup/communications-platforms/intercom) | API token, MCP server | Automated compliance tests |
| [**Mailgun**](/docs/compliance-connectors/setup/communications-platforms/mailgun) | API token | Automated compliance tests |
| [**Mattermost**](/docs/compliance-connectors/setup/communications-platforms/mattermost) | API token | Automated compliance tests |
| [**MessageBird**](/docs/compliance-connectors/setup/communications-platforms/messagebird) | API token | Connection record |
| [**Microsoft Teams**](/docs/compliance-connectors/setup/communications-platforms/microsoft-teams) | API token | Connection record |
| [**Miro**](/docs/compliance-connectors/setup/communications-platforms/miro) | API token | Automated compliance tests |
| [**Nextiva**](/docs/compliance-connectors/setup/communications-platforms/nextiva) | API token | Connection record |
| [**OpenPhone**](/docs/compliance-connectors/setup/communications-platforms/openphone) | API token | Automated compliance tests |
| [**Plivo**](/docs/compliance-connectors/setup/communications-platforms/plivo) | API token | Connection record |
| [**Postmark**](/docs/compliance-connectors/setup/communications-platforms/postmark) | API token | Connection record |
| [**Rocket.Chat**](/docs/compliance-connectors/setup/communications-platforms/rocket-chat) | API token | Automated compliance tests |
| [**SendGrid**](/docs/compliance-connectors/setup/communications-platforms/sendgrid) | API token | Automated compliance tests |
| [**Slack**](/docs/compliance-connectors/setup/communications-platforms/slack) | OAuth, API token, MCP server | Automated evidence collection |
| [**Telnyx**](/docs/compliance-connectors/setup/communications-platforms/telnyx) | API token | Automated compliance tests |
| [**Twilio**](/docs/compliance-connectors/setup/communications-platforms/twilio) | API token | Connection record |
| [**Vonage**](/docs/compliance-connectors/setup/communications-platforms/vonage) | API token | Connection record |
| [**Webex**](/docs/compliance-connectors/setup/communications-platforms/webex) | API token | Automated compliance tests |
| [**Zoom**](/docs/compliance-connectors/setup/communications-platforms/zoom) | API token | Automated compliance tests |
## Data Export (18)
Warehouse and ETL data governance.
| Connector | Connect with | Evidence |
| ------------------------------------------------------------------------------------ | ---------------- | ----------------------------- |
| [**Airbyte**](/docs/compliance-connectors/setup/data-export/airbyte) | API token | Automated compliance tests |
| [**Amazon Redshift**](/docs/compliance-connectors/setup/data-export/amazon-redshift) | API token | Connection record |
| [**Amplitude**](/docs/compliance-connectors/setup/data-export/amplitude) | API token | Automated compliance tests |
| [**Census**](/docs/compliance-connectors/setup/data-export/census) | API token | Automated compliance tests |
| [**ClickHouse**](/docs/compliance-connectors/setup/data-export/clickhouse) | API token | Automated compliance tests |
| [**Databricks**](/docs/compliance-connectors/setup/data-export/databricks) | API token | Automated compliance tests |
| [**dbt Cloud**](/docs/compliance-connectors/setup/data-export/dbt-cloud) | API token | Automated compliance tests |
| [**Fivetran**](/docs/compliance-connectors/setup/data-export/fivetran) | API token | Automated compliance tests |
| [**Google BigQuery**](/docs/compliance-connectors/setup/data-export/google-bigquery) | OAuth, API token | Automated evidence collection |
| [**Hevo Data**](/docs/compliance-connectors/setup/data-export/hevo-data) | API token | Automated compliance tests |
| [**Hightouch**](/docs/compliance-connectors/setup/data-export/hightouch) | API token | Automated compliance tests |
| [**Looker**](/docs/compliance-connectors/setup/data-export/looker) | API token | Automated compliance tests |
| [**Matillion**](/docs/compliance-connectors/setup/data-export/matillion) | API token | Connection record |
| [**Mixpanel**](/docs/compliance-connectors/setup/data-export/mixpanel) | API token | Automated compliance tests |
| [**RudderStack**](/docs/compliance-connectors/setup/data-export/rudderstack) | API token | Connection record |
| [**Segment**](/docs/compliance-connectors/setup/data-export/segment) | API token | Automated compliance tests |
| [**Snowflake**](/docs/compliance-connectors/setup/data-export/snowflake) | API token | Automated compliance tests |
| [**Stitch**](/docs/compliance-connectors/setup/data-export/stitch) | API token | Connection record |
## CRM (21)
Customer systems: business context, low direct evidence value.
| Connector | Connect with | Evidence |
| ------------------------------------------------------------------------------------------ | --------------------- | -------------------------- |
| [**ActiveCampaign**](/docs/compliance-connectors/setup/crm/activecampaign) | API token | Automated compliance tests |
| [**Affinity**](/docs/compliance-connectors/setup/crm/affinity) | API token | Connection record |
| [**Attio**](/docs/compliance-connectors/setup/crm/attio) | API token, MCP server | Automated compliance tests |
| [**Capsule**](/docs/compliance-connectors/setup/crm/capsule) | API token | Automated compliance tests |
| [**Close**](/docs/compliance-connectors/setup/crm/close) | API token, MCP server | Automated compliance tests |
| [**Copper**](/docs/compliance-connectors/setup/crm/copper) | API token | Automated compliance tests |
| [**folk**](/docs/compliance-connectors/setup/crm/folk) | API token | Automated compliance tests |
| [**Freshsales**](/docs/compliance-connectors/setup/crm/freshsales) | API token | Connection record |
| [**GoHighLevel**](/docs/compliance-connectors/setup/crm/gohighlevel) | API token | Automated compliance tests |
| [**HubSpot**](/docs/compliance-connectors/setup/crm/hubspot) | API token, MCP server | Automated compliance tests |
| [**Insightly**](/docs/compliance-connectors/setup/crm/insightly) | API token | Automated compliance tests |
| [**Keap**](/docs/compliance-connectors/setup/crm/keap) | API token | Automated compliance tests |
| [**Microsoft Dynamics 365**](/docs/compliance-connectors/setup/crm/microsoft-dynamics-365) | API token | Automated compliance tests |
| [**Nutshell**](/docs/compliance-connectors/setup/crm/nutshell) | API token | Automated compliance tests |
| [**Pipedrive**](/docs/compliance-connectors/setup/crm/pipedrive) | API token | Automated compliance tests |
| [**Salesflare**](/docs/compliance-connectors/setup/crm/salesflare) | API token | Automated compliance tests |
| [**Salesforce**](/docs/compliance-connectors/setup/crm/salesforce) | API token | Automated compliance tests |
| [**Streak**](/docs/compliance-connectors/setup/crm/streak) | API token | Automated compliance tests |
| [**SugarCRM**](/docs/compliance-connectors/setup/crm/sugarcrm) | API token | Automated compliance tests |
| [**Vtiger**](/docs/compliance-connectors/setup/crm/vtiger) | API token | Automated compliance tests |
| [**Zoho CRM**](/docs/compliance-connectors/setup/crm/zoho-crm) | API token | Automated compliance tests |
## Cyber Insurance (18)
Cyber insurance carriers and brokers.
| Connector | Connect with | Evidence |
| ------------------------------------------------------------------------------------------ | ------------ | ----------------- |
| [**AIG**](/docs/compliance-connectors/setup/cyber-insurance/aig) | API token | Connection record |
| [**Aon**](/docs/compliance-connectors/setup/cyber-insurance/aon) | API token | Connection record |
| [**At-Bay**](/docs/compliance-connectors/setup/cyber-insurance/at-bay) | API token | Connection record |
| [**AXA XL**](/docs/compliance-connectors/setup/cyber-insurance/axa-xl) | API token | Connection record |
| [**Beazley**](/docs/compliance-connectors/setup/cyber-insurance/beazley) | API token | Connection record |
| [**Chubb**](/docs/compliance-connectors/setup/cyber-insurance/chubb) | API token | Connection record |
| [**Coalition**](/docs/compliance-connectors/setup/cyber-insurance/coalition) | API token | Connection record |
| [**Corvus Insurance**](/docs/compliance-connectors/setup/cyber-insurance/corvus-insurance) | API token | Connection record |
| [**Cowbell Cyber**](/docs/compliance-connectors/setup/cyber-insurance/cowbell-cyber) | API token | Connection record |
| [**Embroker**](/docs/compliance-connectors/setup/cyber-insurance/embroker) | API token | Connection record |
| [**Hiscox**](/docs/compliance-connectors/setup/cyber-insurance/hiscox) | API token | Connection record |
| [**Marsh**](/docs/compliance-connectors/setup/cyber-insurance/marsh) | API token | Connection record |
| [**Munich Re**](/docs/compliance-connectors/setup/cyber-insurance/munich-re) | API token | Connection record |
| [**Resilience**](/docs/compliance-connectors/setup/cyber-insurance/resilience) | API token | Connection record |
| [**Travelers**](/docs/compliance-connectors/setup/cyber-insurance/travelers) | API token | Connection record |
| [**Vouch**](/docs/compliance-connectors/setup/cyber-insurance/vouch) | API token | Connection record |
| [**Woodruff Sawyer**](/docs/compliance-connectors/setup/cyber-insurance/woodruff-sawyer) | API token | Connection record |
| [**Zurich**](/docs/compliance-connectors/setup/cyber-insurance/zurich) | API token | Connection record |
## Business Applications (23)
Business and productivity tools: connected to be searched, not to prove a control.
| Connector | Connect with | Evidence |
| ---------------------------------------------------------------------------------------------------------- | --------------------- | -------------------------- |
| [**Apollo IO**](/docs/compliance-connectors/setup/business-applications/apollo-io) | API token, MCP server | Automated compliance tests |
| [**Canva**](/docs/compliance-connectors/setup/business-applications/canva) | API token, MCP server | Automated compliance tests |
| [**Carta**](/docs/compliance-connectors/setup/business-applications/carta) | API token | Search only |
| [**ChatGPT**](/docs/compliance-connectors/setup/business-applications/chatgpt) | API token | Automated compliance tests |
| [**Claude (Anthropic)**](/docs/compliance-connectors/setup/business-applications/claude-anthropic) | API token | Automated compliance tests |
| [**Cohere**](/docs/compliance-connectors/setup/business-applications/cohere) | API token | Attested evidence |
| [**DeepSeek**](/docs/compliance-connectors/setup/business-applications/deepseek) | API token | Attested evidence |
| [**ElevenLabs**](/docs/compliance-connectors/setup/business-applications/elevenlabs) | API token | Automated compliance tests |
| [**Figma**](/docs/compliance-connectors/setup/business-applications/figma) | API token, MCP server | Automated compliance tests |
| [**Fireworks AI**](/docs/compliance-connectors/setup/business-applications/fireworks-ai) | API token | Automated compliance tests |
| [**Groq**](/docs/compliance-connectors/setup/business-applications/groq) | API token | Attested evidence |
| [**Hugging Face**](/docs/compliance-connectors/setup/business-applications/hugging-face) | API token | Automated compliance tests |
| [**LinkedIn**](/docs/compliance-connectors/setup/business-applications/linkedin) | API token | Search only |
| [**Microsoft 365 Copilot**](/docs/compliance-connectors/setup/business-applications/microsoft-365-copilot) | API token | Attested evidence |
| [**Mistral AI**](/docs/compliance-connectors/setup/business-applications/mistral-ai) | API token | Automated compliance tests |
| [**OpenAI API Platform**](/docs/compliance-connectors/setup/business-applications/openai-api-platform) | API token | Automated compliance tests |
| [**OpenRouter**](/docs/compliance-connectors/setup/business-applications/openrouter) | API token | Automated compliance tests |
| [**Perplexity**](/docs/compliance-connectors/setup/business-applications/perplexity) | API token | Attested evidence |
| [**Replicate**](/docs/compliance-connectors/setup/business-applications/replicate) | API token | Attested evidence |
| [**Stripe**](/docs/compliance-connectors/setup/business-applications/stripe) | API token, MCP server | Search only |
| [**Together AI**](/docs/compliance-connectors/setup/business-applications/together-ai) | API token | Attested evidence |
| [**xAI**](/docs/compliance-connectors/setup/business-applications/xai) | API token | Automated compliance tests |
| [**Z.ai (Zhipu GLM)**](/docs/compliance-connectors/setup/business-applications/z-ai-zhipu-glm) | API token | Attested evidence |
# Continuous Scanning (/docs/continuous-scanning)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Continuous Scanning
Scanning at build time tells you the state of an artifact the moment it was built. That's not enough. A dependency you shipped on Monday can become vulnerable on Thursday when a new CVE is published. Continuous scanning closes that gap.
Safeguard re-evaluates every asset in your inventory — SBOMs, container images, AI models, source repositories, vendor SBOMs — every time the world changes.
## What "Continuous" Means in Safeguard
Three signals drive rescans:
1. **Vulnerability feed updates** — when a new CVE, GHSA, OSV entry, CISA KEV addition, or EPSS score change affects a component you use.
2. **Safeguard zero-day publication** — when the research team publishes an `SG-YYYY-NNNNN` advisory.
3. **Asset change** — when a repository gets a new commit, a registry gets a new image tag, or a vendor uploads a new SBOM.
Rescan latency is measured in seconds to minutes, not hours:
| Trigger | Median latency from trigger → scored findings in your UI |
| ------------------------------ | -------------------------------------------------------- |
| New CVE in NVD | \< 2 minutes |
| CISA KEV addition | \< 60 seconds |
| EPSS score delta > 0.1 | \< 5 minutes |
| Safeguard zero-day publication | instant (pre-staged) |
| New asset pushed to registry | \< 3 minutes |
## What Gets Scanned, Continuously
| Asset | Frequency | Mechanism |
| ------------------------------------------- | -------------------------------------------------- | --------------------------------------------------- |
| **Source repositories** | Every push + hourly pull | Git webhook + scheduled pull for missed hooks |
| **Container images** | On push + every 4 hours for running images | Registry webhook + runtime collector reconciliation |
| **Packaged artifacts (jars, wheels, etc.)** | On publish + on vulnerability-feed delta | Registry listener + feed-driven rescoring |
| **AI models** | On publish + weekly re-validation | Model registry listener + Eagle reclassification |
| **SBOMs (yours and vendors)** | On upload + hourly feed-driven rescoring | Portal ingestion + feed-driven evaluator |
| **Kubernetes workloads** | On admission + every 15 min runtime reconciliation | Admission controller + runtime collector |
| **Vendors** | On SBOM upload + on SLA expiry (configurable) | TPRM scheduler |
## Feed-Driven Re-Scoring
The expensive part of scanning is not extraction — it's comparing every component to every known advisory. Safeguard inverts this:
* Components are stored as searchable nodes in the Safeguard knowledge graph.
* New advisories are matched to components via purl, version range, and CPE resolution.
* Only affected assets get rescored; unaffected assets are never re-traversed.
This lets Safeguard rescan a fleet of 50,000 SBOMs in seconds when a new advisory lands, instead of minutes or hours.
## Notifications
When a continuous scan produces a new or escalated finding, Safeguard routes the alert by:
* **Owner** (from CODEOWNERS, container labels, or manual assignment).
* **Severity band** (critical / high / medium / low).
* **Exploitation status** (KEV-listed, EPSS > 0.7, PoC available).
* **Environment** (production flows differently than dev sandboxes).
Configure routes in **Settings → Notifications**:
* Slack / Teams / Discord channels.
* Jira / Linear / Azure Boards ticket creation.
* Email digests (per-user, daily or weekly).
* PagerDuty / OpsGenie on-call pages for critical-KEV findings in production.
* Generic webhook for custom integrations.
## Runtime Continuous Scanning
In addition to SBOM-level scanning, the runtime collector (DaemonSet or host agent) continuously observes:
* Loaded shared libraries and running processes.
* Image digests of running containers.
* Open network ports and egress destinations.
* Anomalous behavior scored by Eagle (see [AI Models](/docs/ai-models)).
Runtime scans catch components that aren't in any SBOM — for example, a debug tool that got baked into a production image by mistake.
## Air-Gapped Continuous Scanning
For air-gapped environments, continuous scanning uses signed, incremental vulnerability database snapshots:
* Snapshots ship on a schedule (hourly, daily, weekly — you pick) as signed tarballs.
* A helper downloads snapshots and applies deltas to the on-prem instance.
* Rescans run locally the moment the delta is applied.
See the [air-gapped deployment guide](/docs/compliance#data-residency) for details.
## Rescan History and Diffs
Every asset shows a **Timeline** of scans:
* When each scan ran and what triggered it.
* The diff of findings from the previous scan (added, resolved, changed severity).
* Griffin-narrated summaries: *"3 new high-severity findings since last scan; 2 are in production-reachable code paths."*
This makes postmortems straightforward — you can see exactly when a finding entered or left the system.
## Tuning Scan Frequency
Most teams should leave defaults on. For specialized needs:
* **Sensitive production workloads** — set `scan.interval: 5m` on the asset label `criticality:sensitive`.
* **Dev / sandbox environments** — set `scan.interval: 24h` to reduce noise.
* **Vendor SBOMs with SLA windows** — set SLA-driven rescans in TPRM.
Settings are in **Policies → Scan Policies**.
## Performance Impact
Continuous scanning is designed to be invisible to your systems:
* Agentless scans pull metadata from registries and Git providers; no compute runs on your side.
* The runtime collector uses eBPF where possible (Linux hosts, Kubernetes) — \~1% CPU overhead at p99.
* Feed-driven rescoring runs in Safeguard cloud; no customer-side work.
## API
Trigger an on-demand scan:
```bash
safeguard scan --asset
safeguard scan --project --all
```
Subscribe to scan events via webhook:
```
POST /v1/webhooks
{
"event": "scan.finding.created",
"url": "https://your-endpoint/webhook",
"filter": { "severity": ["critical", "high"], "env": "production" }
}
```
## Related
* [Vulnerability Prioritization (Reachability)](/docs/reachability-analysis) — how findings get scored after they're detected.
* [Asset Discovery](/docs/asset-discovery) — what gets scanned in the first place.
* [Zero-Day Discovery](/docs/zero-day-discovery) — how Safeguard's own research feeds into scans.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — how scan results drive policy.
# CTEM & EASM (/docs/ctem-easm)
# CTEM & EASM
> **Roadmap — not yet available.** CTEM and EASM are planned capabilities documented here for direction. They are an orchestration layer over engines that ship today; the layer itself is not yet available.
CTEM (Continuous Threat Exposure Management) and EASM (External Attack Surface Management) are the connective tissue planned to make the platform greater than the sum of its engines: an outside-in sensor that discovers your external footprint, feeding a five-stage exposure-management program that unifies findings from every engine into one prioritized, validated backlog. Almost all of its value is orchestration — it *calls* the shipped engines, it does not re-implement them.
## EASM — external attack surface (planned)
EASM will continuously discover and monitor your internet-facing footprint using safe, rate-limited, non-destructive probing:
| Discovery step | Method |
| --------------- | ----------------------------------------------------------------------------------------- |
| Subdomains | Passive DNS + certificate-transparency log mining |
| Hosts | A/AAAA/CNAME resolution |
| Services | Bounded connect scan of common ports, banner-grab only — no exploit payloads |
| Technology | Passive fingerprinting from response headers and banners |
| TLS posture | Certificate expiry, weak ciphers, misissuance, host sprawl |
| Cloud edges | Public buckets, load balancers, gateways, and functions (reusing cloud-exposure checks) |
| Leaked / shadow | Exposed credentials and documents from breach and dark-web signals, with secrets redacted |
Discovered assets are attributed to your org with a confidence score and must pass **ownership verification** (DNS-TXT challenge, cert SAN, cloud IAM, or manual confirm) before they can ever be actively validated — the safety rail against probing assets you don't own. Exposures surface as external attack-surface findings in the [unified findings model](/docs/unified-findings).
## CTEM — the five-stage program (planned)
CTEM will drive a repeatable cycle over your exposures:
1. **Scope** — define crown-jewel assets, in-scope surfaces, and whether active validation is permitted.
2. **Discover** — fold the EASM surface plus every engine's findings (SAST/DAST, SCA, cloud, K8s, secrets, API, AI, Red Team) into one exposure set, collapsing correlated findings.
3. **Prioritize** — rank by reachability to crown jewels using the platform's shared attack-path graph and unified risk score.
4. **Validate** — safely confirm exploitability by driving the [Red Team](/docs/red-team) engine, exclusively through its rules-of-engagement safety kernel; a confirmed exposure gets an exploitability proof.
5. **Mobilize** — assign an owner, open a ticket with an SLA, notify, and re-validate on fix to close the loop.
## Validation safety (planned)
Active validation is the only attack path in the design, and it is heavily gated. Every precondition must hold or it is refused and audited: validation is allowed for the scope, the target's ownership is verified, a signed rules-of-engagement document exists, rate/blast caps are configured with human approval for high-impact steps, and the global kill-switch is not engaged. There is no new offensive code — validation drives the existing Red Team engine within its kernel, with safe, bounded probes only.
## When it ships
CTEM/EASM will be gated by the `ff.easm` and `ff.ctem` feature flags, server-side enforced, with exposures in the single findings store and full air-gap parity (passive feeds served from an on-prem mirror).
## Related
* [Red Team](/docs/red-team) — the validation engine CTEM drives, available today.
* [Asset Discovery](/docs/asset-discovery) — internal asset discovery.
* [Reachability Analysis](/docs/reachability-analysis) — the prioritization signal CTEM reuses.
* [Vulnerability & Exposure Management](/docs/vuln-exposure-management) — the internal remediation-orchestration counterpart (roadmap).
* [Unified Findings & Feature Flags](/docs/unified-findings) — where exposures land.
# Deep Dependency Scanning (100 Levels) (/docs/deep-dependency-scanning)
# Deep Dependency Scanning
Most SCA tools stop at dependency depth 50-60. Real applications have transitive chains that go much deeper — and attackers know that. Safeguard scans to depth **100 levels**, which is enough to reach the bottom of every real-world production codebase we've seen.
## Why Depth Matters
Consider a typical Node.js service:
* `your-app` → 30 direct dependencies
* Each direct → 5-15 transitive → \~300 packages at level 2
* Level 3: \~1,500 packages
* Level 4-6: tens of thousands of unique components
* Level 7+: long tail — utility packages, build tools, shims
The vulnerable code in a real attack — SolarWinds SUNBURST, the xz-utils backdoor, many npm malware campaigns — was almost always several levels deep. Tools that only scan shallow trees missed them.
## What Safeguard Does
Safeguard walks every edge in the resolved dependency graph up to level 100. At each node:
* Resolves purl and version against the vulnerability knowledge graph.
* Computes license and provenance.
* Feeds the node into reachability analysis (see [Reachability](/docs/reachability-analysis)).
* Captures the full path from root to leaf so you can trace why a dependency is present.
Performance optimizations:
* Shared subgraphs are deduplicated (a library used by 100 dependencies is resolved once, not 100 times).
* Negative caches for "no known vulnerabilities" paths.
* Feed-driven rescoring so depth 100 scans don't re-traverse on every CVE update.
Typical scan times:
* Small project (\< 500 nodes): **\< 1 second**
* Medium project (5,000 nodes): **3-5 seconds**
* Large monorepo (50,000+ nodes): **15-45 seconds**
## Supported Ecosystems
Deep scanning works across:
* **npm / pnpm / Yarn** — resolves workspaces, peer deps, optional deps.
* **PyPI** — resolves `requirements.txt`, `pyproject.toml`, `Pipfile`, `uv.lock`, `poetry.lock`.
* **Maven / Gradle** — resolves `pom.xml`, `build.gradle`, lockfiles.
* **Go modules** — resolves `go.mod` and `go.sum`.
* **Cargo** — resolves `Cargo.toml` and `Cargo.lock`.
* **NuGet** — resolves `packages.lock.json` and `.csproj`.
* **Composer** — resolves `composer.lock`.
* **Ruby Bundler** — resolves `Gemfile.lock`.
* **Container layers** — reads binaries and package metadata inside layers.
## Transitive Path Visualization
In the ESSCM UI, click a finding to see the full transitive path:
```
your-app
└─ @company/tools @2.1.0
└─ lodash @4.17.21 ← vulnerable here (CVE-2021-23337)
```
The UI explains:
* The chain of imports that pulls in the vulnerable package.
* Whether the chain is reachable (from [reachability analysis](/docs/reachability-analysis)).
* Whether any alternative path exists.
* What the safe version would be, and what other transitive changes that version would introduce.
## Dependency-Confusion Detection
Deep scanning cross-references every resolved package against:
* Your internal package registries.
* The top-N public registries.
* Known typosquat patterns (via Eagle, see [AI Models](/docs/ai-models)).
If a public package masquerades as an internal one, or an install pulled from the wrong registry, you get a finding tagged `dependency-confusion`.
## Unused Dependency Detection
Deep scanning also produces a reverse signal: packages present in your dependency tree but never imported. These are candidates for removal — every removed package reduces attack surface without code changes.
There is no CLI command for this yet.
## Policy Hooks
Depth is available as a policy signal:
```yaml
rules:
- id: no-dep-below-level-50
condition: any(components, depth > 50 AND vulnerabilities.critical > 0)
effect: BLOCK
```
Or enforce a maximum total depth for new additions:
```yaml
- id: warn-on-deepening
condition: delta.max_depth > prev.max_depth + 10
effect: WARN
```
## CLI
A local scan can resolve transitive dependencies to a chosen depth:
```bash
safeguard scan --dir . --resolve-transitive --transitive-depth 100
```
There is no CLI command for querying the dependency graph yet.
## Comparison With Other Tools
| Tool | Typical max depth |
| ------------------------ | ---------------------------------------------- |
| Safeguard | **100** |
| Snyk | \~60 |
| Dependabot | 10 (direct + one-level transitive) |
| GitHub Advanced Security | varies; typically 50 |
| npm audit | resolves full tree; reports by top-level chain |
Depth alone isn't the goal — the goal is not missing CVEs that hide deep. 40 extra levels catches the edge cases that real supply chain attacks exploit.
## Related
* [Reachability Analysis](/docs/reachability-analysis) — combine depth with call-graph filtering.
* [Continuous Scanning](/docs/continuous-scanning) — scans re-run on every feed update.
* [Vulnerabilities](/docs/esscm/vulnerabilities) — the UI surface for findings.
* [OSM](/docs/osm) — open-source intelligence over the dependency graph.
# Desktop Application (/docs/desktop-app)
# Desktop Application
The Safeguard desktop app is a cross-platform Electron application for macOS, Windows, and Linux. It doesn't replace the web app — it wraps it. One window is split into two views: the familiar Safeguard web app on the left, and a local panel on the right that can reach things a browser tab never can, like your filesystem, a local shell, and MCP servers.
## Architecture
The main window renders two independent views side by side:
* **Web view** (\~75% of the width) — loads `https://app.safeguard.sh` directly, through a minimal preload script that exposes a small `window.desktopAPI` (panel control and detection only). This is the same web app described in [Web Application](/docs/web-app); nothing about it is modified for desktop.
* **Panel view** (\~25% of the width) — a local Vite + React single-page app, served from files bundled with the app rather than fetched from the network. It gets a full preload API (`window.panelAPI`) with IPC access to native capabilities: filesystem, shell, scanner, MCP, agent tasks, screen, and updater.
Toggle the panel with **Ctrl+Shift+S** (**Cmd+Shift+S** on macOS), or from the **View** menu. The split is resizable by dragging the divider, with minimum widths enforced on both sides; your preferred width is remembered between launches.
| Shortcut | Action |
| ------------------------------ | ---------------------------- |
| `Ctrl+Shift+S` / `Cmd+Shift+S` | Toggle panel |
| `Ctrl+N` / `Cmd+N` | New scan |
| `Ctrl+O` / `Cmd+O` | Open project (folder picker) |
| `Ctrl+,` / `Cmd+,` | Open settings |
The app also registers a `safeguard://` deep-link protocol — `safeguard://scan`, `safeguard://terminal`, `safeguard://mcp`, `safeguard://tasks`, `safeguard://files`, and `safeguard://settings` open the panel directly on that tab; `safeguard://dashboard` navigates the web view. For example, a link or shell command like:
```bash
open "safeguard://scan" # macOS
start "" "safeguard://scan" # Windows
xdg-open "safeguard://scan" # Linux
```
brings the app to the front with the panel already open on the **Scan** tab.
## Download
The current release is ****. Downloads are also listed on [safeguard.sh/download](https://safeguard.sh/download), which reads the same release feed this page does.
> **Windows builds are not yet code-signed.** SmartScreen will show "Windows protected your PC" — choose **More info → Run anyway**. This is expected until code signing is completed, not a sign the file is corrupt; verify the checksum below if you want certainty. macOS builds are signed and notarized, so they install without warnings.
### Verifying a download
The release publishes a `SHA256SUMS` manifest beside the installers, in that release's folder under [sg-downloads/o/desktop/](https://objectstorage.ap-mumbai-1.oraclecloud.com/n/bmbnem1ecuy4/b/sg-downloads/o/desktop/) — the path carries the version, so follow the one matching the file you downloaded:
```bash
# macOS / Linux (with SHA256SUMS in the same directory)
shasum -a 256 -c SHA256SUMS
# Windows — compare the output against SHA256SUMS by eye
certutil -hashfile Safeguard-.exe SHA256
```
On macOS you can additionally confirm Apple's notarization after installing:
```bash
spctl -a -vvv -t exec /Applications/Safeguard.app
# expect: accepted, source=Notarized Developer ID
```
## First Run
1. Install and open the app. The left pane loads the Safeguard web app and you sign in exactly as you would in a browser.
2. Press **Ctrl+Shift+S** / **Cmd+Shift+S** to open the panel, or leave it closed if you only need the web app for now.
3. The panel opens on its **Files** tab, where you grant folder access through your OS's native file picker. The app can only read folders you've explicitly granted — every file operation is checked against that list, and path traversal (`../`) out of a granted folder is rejected.
4. From there, use the other panel tabs (**Scan**, **Terminal**, **MCP**, **Tasks**, **Settings**) as needed — nothing requires an install step beyond the app itself.
> The web view and the panel are isolated from each other. The web app only ever sees a minimal detection/panel-control API — it cannot read your files, run shell commands, or drive the panel's native capabilities directly.
## Capabilities
The panel is organized into tabs, each backed by its own service in the Electron main process.
| Tab | What it does |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Scan** | Add local projects, run vulnerability scans against them, view results by severity, and toggle auto-scan per project. |
| **Terminal** | Run allowlisted CLI commands (`safeguard-cli`, `git`, `docker`, `npm`, and other common dev-tool binaries — full list below) with their output shown in-app. |
| **MCP** | Start and stop MCP servers, including a one-click Safeguard MCP server, connect external MCP servers, and browse/invoke tools directly. |
| **Tasks** | Submit natural-language tasks, watch agent progress, approve or deny destructive actions before they run, and schedule recurring tasks. |
| **Files** | Grant and revoke folder access, and browse the file trees you've granted. |
| **Settings** | Auto-update mode, theme, minimize-to-tray, action-approval mode, prompt-injection detection, and version/platform info. |
### Local scanning
Point the **Scan** tab at a granted local folder to run a vulnerability scan without pushing the project anywhere first. Choose **quick** (searches shallower into the folder tree for manifests and runs the CLI in its faster mode) or **full** (searches deeper into subdirectories for a more thorough pass) per project, then re-run on demand, or flip a project's auto-scan toggle on. Results are grouped by severity — **critical**, **high**, **medium**, **low**, and **unknown** — the same tiers used elsewhere in Safeguard. Scanning is orchestrated locally and can fall back to manifest-based analysis if the bundled Safeguard CLI binary isn't available for your platform yet.
### Terminal
Commands run through the **Terminal** tab are restricted to a fixed allowlist of binaries, grouped by purpose:
| Category | Allowed binaries |
| ---------------- | ----------------------------------------------------------------------------- |
| Safeguard tools | `safeguard-cli`, `safeguard`, `sg`, `safeguard-agent` |
| Version control | `git`, `gh` |
| Containers | `docker`, `docker-compose`, `podman` |
| Package managers | `npm`, `yarn`, `pnpm`, `bun`, `pip`, `pip3`, `go`, `cargo`, `mvn`, `gradle` |
| Runtimes | `python`, `python3`, `node`, `deno` |
| System utilities | `curl`, `wget`, `ssh`, `scp`, `rsync`, `tar`, `unzip`, `zip`, `make`, `cmake` |
Anything outside this list is rejected before it runs, with an error naming the command and the full allowlist. The working directory for a command must also be inside a folder you've granted access to — a `cwd` outside every granted folder is rejected the same way, even if the command itself is allowed.
```bash
# Runs — git is on the allowlist, and the cwd is a granted folder
git status
# Rejected — perl is not on the allowlist
perl -e 'print "hi"'
```
### MCP hosting
The **MCP** tab manages the lifecycle of MCP servers running alongside the app — starting and stopping them, connecting to external servers, and letting you browse and invoke their tools directly from the panel. The bundled Safeguard MCP server exposes the tools enabled for your tenant (a new workspace starts with a small read-only set); see [MCP Integrations](/docs/mcp) for what those tools cover and [Tool Gating](/docs/mcp/tool-gating) for controlling which ones an agent can call.
Besides the one-click Safeguard server, the tab lets you **connect an external server** by name and URL, for MCP servers that speak HTTP/SSE rather than stdio.
Each running server shows a status of `starting`, `running`, `stopped`, or `crashed`, and its tool count; expand it in the panel to browse and manually invoke individual tools.
### Agentic tasks
The **Tasks** tab is where the desktop app's agentic layer lives. Submit a task in natural language and the app matches it against a set of built-in workflows — local repo scan, MCP configuration audit, dependency watch, container scan, or IDE extension check — or falls back to a generic multi-step breakdown if nothing matches. Each subtask runs in sequence, and progress is surfaced live, including each subtask's status and result. You can cancel a running task at any point.
**Approvals.** When a subtask is about to take a destructive action, the task pauses and raises an approval request with a description of what it's about to do; you approve or deny it before execution continues.
**Recurring tasks.** Rather than re-submitting a task, schedule it to run on a fixed interval. Intervals are a number plus a unit — seconds, minutes, hours, or days:
```text
30s → every 30 seconds
5m → every 5 minutes
1h → every hour
24h → every 24 hours
```
For example, scheduling the description "Re-scan the granted project folders and flag any new critical findings" with an interval of `24h` re-runs that task once a day; each scheduled task can be individually enabled, disabled, or deleted from the Tasks tab.
### System tray and native menu
The app installs a native menu bar and a system tray icon for quick access to panel tabs and app controls without bringing the main window to the front.
## Privacy and Security
* **Renderer isolation** — both the web view and the panel run with `nodeIntegration: false`, `contextIsolation: true`, and `sandbox: true`. Neither renderer has direct Node.js access; everything native goes through IPC.
* **Two-preload model** — the web view's preload (`window.desktopAPI`) only exposes panel detection and control. The panel's preload (`window.panelAPI`) exposes the full native surface (filesystem, shell, scanner, MCP, agent, screen, updater) and runs in its own session partition with its own Content Security Policy.
* **Filesystem scoping** — folder access is granted per-folder through the OS file picker, every file operation is validated against the granted-folder list, and path traversal outside a granted folder is rejected.
* **Shell allowlist** — programmatic command execution is restricted to a fixed set of binaries (listed above), and each command's working directory must be inside a folder you've explicitly granted; nothing else can be run through the app.
* **Navigation lockdown** — the web view will only navigate within `*.safeguard.sh`; external links open in your default browser instead of inside the app. The panel view only ever loads its own local, bundled content.
* **Computer-use safety** — for the screen-control features, per-app permission is required before the app can take mouse/keyboard control, banking/crypto/password-manager/trading apps are blocked by default, actions are logged with before/after screenshots, and screen content is checked for prompt-injection patterns before the agent acts on it.
## Auto-Update
The app checks for updates on launch and every four hours, using `electron-updater` against GitHub Releases. You control what happens when an update is found, under **Settings**:
* **Auto-install** — downloads and installs automatically on quit.
* **Ask before install** (default) — notifies you and waits for confirmation.
* **Manual** — only checks when you click "Check for Updates."
## System Requirements
The desktop app is a standard Electron application; if your machine comfortably runs other modern desktop apps built the same way, it will run Safeguard Desktop. A few capabilities depend on tools already being present on your machine rather than on the app itself:
* **Container scanning** needs a local Docker or Podman daemon to connect to.
* **Terminal commands** that invoke `git`, `npm`, `python`, etc. need those binaries installed and on your `PATH`.
* Everything else — the web view, panel, scanning UI, and MCP hosting — works out of the box with no additional install.
## Uninstall
Uninstalling follows the normal convention for each platform's installer format:
* **macOS** (`.dmg`): drag the app to Trash.
* **Windows** (NSIS installer): **Settings → Apps → Installed apps**, then uninstall Safeguard.
* **Linux** (`.AppImage`): simply delete the `.AppImage` file.
## Common errors
**Left side of the window is blank / white.** The web view couldn't reach `app.safeguard.sh` — check your internet connection. The panel on the right works independently and isn't affected.
**The panel won't open.** Press `Ctrl+Shift+S` (`Cmd+Shift+S` on macOS), or use **View → Toggle Panel** from the menu bar.
**Scan tab shows "CLI not available."** The bundled `safeguard-cli` binary isn't present for your platform in this build. Scanning falls back to manifest-based analysis automatically; functionality is reduced but not blocked.
**A command I expect to run in Terminal is rejected.** Only the binaries in the [allowlist above](#terminal) can be executed from the panel, and its working directory must be inside a folder you've granted access to. Both checks run before the command starts, and neither is configurable per user — the error message names the command or path that failed and, for a disallowed binary, the full current allowlist.
**An MCP server I started shows status "Crashed."** The server process exited on its own after starting — the panel just reports the process's exit, it doesn't diagnose why. Confirm the command runs correctly on its own outside the app with the same arguments and environment variables, then try starting it again from the **MCP** tab.
**Scheduling a recurring task fails with "Invalid interval format."** The interval must be a number immediately followed by `s`, `m`, `h`, or `d` (seconds/minutes/hours/days) — e.g. `30s`, `5m`, `1h`, `24h`. Other formats, including cron expressions, aren't accepted.
## Related
* [Web Application](/docs/web-app) — the hosted app the desktop client's left pane loads.
* [MCP Integrations](/docs/mcp) — what the bundled Safeguard MCP server's tools cover.
* [Tool Gating](/docs/mcp/tool-gating) — controlling which MCP tools an agent is allowed to call.
* [CLI](/docs/cli) — the standalone Safeguard CLI bundled with the desktop app's scanner.
* [Runner](/docs/runner) — local workflow execution outside the desktop app.
# Digital Risk Protection & Threat Intel (/docs/drp-tip)
# Digital Risk Protection & Threat Intel
> **Roadmap — not yet available.** DRP and TIP are planned capabilities documented here for direction. They extend the shipped IOC/feed/actor/hunt store; the new pipeline stages and DRP monitors are not yet available.
Two pillars on one substrate. **TIP** (Threat Intelligence Platform) turns scattered intel into a real ingest → normalize → dedup → enrich → score → age → correlate → disseminate pipeline. **DRP** (Digital Risk Protection) is the outward-facing footprint monitor that produces external findings and consumes TIP enrichment. Neither builds a parallel store, and collection is passive and authorized only — no unauthorized access, no scraping behind auth, no offensive action.
## TIP — threat intelligence pipeline (planned)
| Stage | What it does |
| --------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Ingest** | STIX 2.1 / TAXII 2.1 collections plus authorized OSINT feeds, polled incrementally |
| **Normalize** | Canonicalize indicators (lowercase punycode domains, canonical IPs, defang→refang) |
| **Dedup** | Merge the same indicator across feeds, keeping per-source provenance |
| **Score** | Confidence from feed reliability, corroboration, recency, and enrichment; actionability from confidence × freshness |
| **Age** | Exponential decay per indicator type; expired indicators are excluded from dissemination but retained for history |
| **Enrich** | Geo/ASN, WHOIS, passive DNS, reputation, related campaigns (fail-open on enricher timeout) |
| **Map** | Indicator → campaign → threat actor; TTP → ATT\&CK |
| **Correlate** | Match live indicators against your assets, findings, and telemetry |
| **Disseminate** | A one-directional pull view consumed by SecOps (real-time IOC match), Package Firewall, and Red Team |
The `Indicator` model extends the existing IOC record rather than forking a new store, and dissemination is pull-only — TIP never writes into a consumer's store.
## DRP — digital risk protection (planned)
DRP will continuously monitor your external footprint through authorized sources and emit `drp` findings:
* **Leaked credentials** — dark-web, paste-site, and public-repo exposure, with rotation recommended.
* **Look-alike domains** — typosquat, homoglyph, TLD-swap, and combosquat candidates, confirmed via passive DNS and certificate-transparency logs.
* **Brand impersonation** — spoof pages, fake mobile apps, and impersonating social accounts.
* **Exposed documents** — sensitive documents leaked publicly.
* **Actor chatter** — org-targeted discussion from authorized feeds.
### Secret redaction (planned invariant)
A raw secret value never enters the store, a log, an export, or a finding. On any leaked-credential or exposed-document hit, DRP computes a non-reversible fingerprint (for dedup and re-detection), stores redacted evidence only (type, masked preview, source, timestamps), and recommends rotation. A collector that cannot redact a value drops it rather than storing it.
### Takedown (planned, gated)
Takedown will prepare and submit **authorized, human-approved** requests only — never automated attacks. A request cannot advance to submitted without a policy pass, a human approver, and non-empty authorization evidence; a kill-switch halts all submissions and every transition is audited.
## When it ships
DRP findings will land in the single [findings store](/docs/unified-findings) (`drp`), with sensitive findings under elevated ACL. Gated by the `ff.drp` and `ff.tip` feature flags, with on-prem/air-gap parity via self-hosted feeds.
## Related
* [SecOps (SIEM)](/docs/secops) — consumes TIP indicators for real-time IOC matching.
* [Package Firewall](/docs/package-firewall) — consumes malicious-package intel.
* [Red Team](/docs/red-team) — consumes adversary TTPs for emulation.
* [Secrets Scanning](/docs/secrets-scanning) — internal secret detection.
* [Unified Findings & Feature Flags](/docs/unified-findings) — where DRP findings land.
# Data Security Posture Management (DSPM) (/docs/dspm)
# Data Security Posture Management (DSPM)
DSPM finds where sensitive data lives so you can govern it. It classifies data across your assets and — critically — **never stores the raw sensitive values it finds**. Only redacted snippets are retained.
## Sensitive-data classification
DSPM identifies and classifies:
| Category | How it's detected |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------- |
| **PII** | Personally identifiable information — names, emails, national identifiers, and similar patterns. |
| **PHI** | Protected health information patterns. |
| **Payment data (PCI)** | Candidate card numbers are checksum-validated to cut false positives before they're classified as payment data. |
| **Secrets** | Credentials and keys are validated to filter out ordinary strings that merely look secret-shaped, reducing noise. |
## The redaction mandate
DSPM enforces a hard rule: **raw sensitive data is never stored.** When a match is found, the value is redacted at the point of detection, and only a redacted snippet (enough to locate and understand the finding) is persisted. This keeps the platform itself from becoming a secondary store of the very data it's protecting, and keeps findings safe to view within your tenant.
## Connectors and discovery
DSPM classifies a filesystem store out of the box and connects to live cloud data stores, **S3 and RDS first**:
| Connector | Discovers | Samples | Posture recorded |
| -------------- | ------------------------------------ | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| **Amazon S3** | Lists buckets, then objects (capped) | A small, bounded read from each object | Encryption status and public exposure (access controls, public-access settings, and bucket policy) |
| **Amazon RDS** | Enumerates tables | A small, bounded sample of rows from text columns | Encryption status and public exposure (storage encryption, public accessibility, and network access) |
Connectors are agentless where possible and use credentials from your existing cloud-account integrations (the approved secret store) — never persisted, never logged. Sampling is hard-capped (default 1000 objects/rows per store, 1 MiB per object, 10 s per call); DSPM never reads an entire object or table. Discovery also flags **shadow stores** — a store present in a cloud account but absent from your managed inventory.
## Access fusion — who can reach the crown jewels
DSPM joins each data store with **CIEM effective permissions** to build access edges: every identity with a read/write/delete/admin path to a sensitive store, flagged external if the principal sits outside your tenant boundary. Access breadth feeds the risk score, so a sensitive store readable by many identities — or by any external principal — ranks far above one only its owning service can reach. An over-privileged or external principal with read access on a sensitive store also raises an access finding.
## Exposure and runtime detection
* **Exposure detection** surfaces stores that are **public**, **unencrypted**, **over-shared** (read granted too widely, or to an external principal), and **cross-boundary** (readable across tenant, region, or account) exposures. A public, unencrypted PII bucket scores near the top; a private, encrypted, low-sensitivity store scores low.
* **Data detection & response (DDR)** tails access and query logs to catch anomalies against a per-store, per-identity baseline — mass reads, first-time sensitive access, anomalous queries, and exfiltration patterns. DDR records only the *shape* of the anomaly (counts, never the data read); alerting is always on, while quarantine/deny response is opt-in per policy.
## Compliance mapping
Classified data, exposure, and residency map to regulatory obligations — GDPR (encryption and residency), HIPAA (encryption and access controls), PCI (stored cardholder data), and CCPA — producing compliance findings and a data-inventory report that lists sensitive stores, locations, classes, and residency per framework.
## Findings produced
Findings record the data category, the asset and location, and the redacted snippet, flowing into the [unified findings model](/docs/unified-findings) as data-security findings, tenant/org-scoped end to end. Each finding names what fired:
* **Exposure** — a classified store that is public, unencrypted, over-shared, or readable across a boundary (for example, a public bucket holding PII).
* **Access** — an over-privileged or external identity with a path to sensitive data.
* **Data flow** — sensitive data moving across a boundary.
* **Runtime anomaly** — an unusual access or query pattern against a store's baseline.
* **Compliance** — a regulatory obligation that isn't met.
Because DSPM findings reveal where crown jewels sit and who can reach them, they are held under **elevated access control** — tighter than normal findings — and every read is audited.
## Configuration
DSPM is **admin-toggleable** via the `ff.dspm` [feature flag](/docs/unified-findings#feature-flags), enforced server-side. Once enabled, assets are classified as they're scanned through the standard integration and pipeline flow. Scan a cloud store from the CLI:
```bash
safeguard dspm scan --connector s3 --account [
safeguard dspm risks
safeguard dspm compliance --framework pci
```
Sampling caps, access fusion, exposure thresholds, DDR response mode (alert/quarantine/deny), and compliance frameworks are configured per tenant.
## Related
* [Secrets Scanning](/docs/secrets-scanning) — dedicated detection of committed and configured secrets.
* [ITDR & DLP](/docs/itdr-dlp) — data-loss prevention reuses this classifier for data in motion (roadmap).
* [Unified Findings & Feature Flags](/docs/unified-findings) — where DSPM findings land and how the engine is toggled.
* [Compliance](/docs/compliance) — using data classification as evidence for privacy and regulatory frameworks.
# Endpoint Security (EDR/EPP) (/docs/endpoint-security)
# Endpoint Security (EDR/EPP)
> **Roadmap — not yet available.** Endpoint Security is a planned capability. This page documents the intended design so you can evaluate direction; it is not a shipping feature and should not be planned against as one. It sequences after the [SecOps](/docs/secops) event store, which is its telemetry sink.
Endpoint Security is planned as a single lightweight, cross-OS agent (EDR, EPP/NGAV, and device control in one) that feeds the SecOps SIEM and XDR. The guiding constraint is safety: the agent must never take down the host, so the design builds the lowest-risk pieces first and gates kernel-level components behind proven safety guarantees.
## Planned capabilities
| Area | What it will do |
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **Telemetry (EDR)** | Stream process, file, network, module, and auth events with full process-tree context; Linux eBPF and user-mode collectors first |
| **Behavioral detection** | Run the existing detection-rule engine plus Sigma endpoint packs (reverse shell, LOLBin, credential dumping, persistence) with ATT\&CK tagging |
| **IOC sweep + hunting** | Sweep endpoints for known-bad hashes/paths/registry/network indicators, live and retrospective |
| **Response (gated)** | Isolate, kill, quarantine, block-hash, and rollback — policy-gated, with high-impact actions requiring human approval |
| **Device control** | USB, host-firewall, application allow/block, and disk-encryption posture |
| **Inventory** | Endpoint and installed-software inventory (feeding vuln management) plus unmanaged-device discovery |
| **Prevention (NGAV/EPP)** | Later phase — pre-execution ML classification, exploit mitigation, and ransomware protection with a strict false-positive guard |
## Safety model (planned)
Because an endpoint agent runs everywhere, six guarantees are designed in as non-negotiable before any telemetry ships on a real OS:
* **Safe-fail** — a failed collector, enforcement, or response never crashes the host.
* **Resource governor** — hard CPU and memory caps; shed telemetry before the hard cap.
* **Watchdog** — a supervisor that restarts the agent on crash and *disarms* (telemetry-only) after repeated crashes, so it never becomes a boot loop.
* **Global kill-switch** — a server-pushed control that halts all enforcement and response fleet-wide instantly.
* **Tamper protection** — self-protection for the agent process and config.
* **Signed / notarized binaries** — Authenticode, macOS notarization, and Linux package signing, enforced in the build pipeline.
Kernel components (Windows minifilter, macOS EndpointSecurity, Linux eBPF/LSM enforcement) are the highest-risk items and land last, only after these guarantees are proven in staged rollout. The endpoint agent is deliberately distinct from the [Runtime Protection](/docs/runtime-protection) workload agent — shared detection concepts, different form factor.
## Response actions (planned, gated)
Response will be delivered through the SecOps SOAR connector registry as well as directly:
* **Isolate / release** — host network isolation, allowing only the agent-to-server channel.
* **Kill** — terminate an offending process (approval-gated unless a specific high-confidence rule is tenant-opted into auto).
* **Quarantine / block-hash / rollback** — contain files and restore journaled changes, approval-gated.
Every action is tenant-scoped, audit-logged, and safe-fail; the kill-switch overrides all policy.
## When it ships
Endpoint findings and detections will flow into the [unified findings model](/docs/unified-findings), and each endpoint event will also land in the SecOps event store as a `SecEvent` (source `edr`), making it SIEM-queryable and XDR-correlatable. The engine will be gated by the `ff.endpoint` feature flag.
## Related
* [SecOps (SIEM)](/docs/secops) — the event store and detection the endpoint agent feeds.
* [Runtime Protection (CWPP & CNAPP)](/docs/runtime-protection) — the distinct workload-protection agent, available today.
* [Vulnerability & Exposure Management](/docs/vuln-exposure-management) — consumes endpoint software inventory (roadmap).
* [Unified Findings & Feature Flags](/docs/unified-findings) — where findings land and how engines are toggled.
# Gold Open Source (/docs/gold-open-source)
# Gold Open Source
**Gold Open Source** is Safeguard's free, no-login public directory of open-source software and what is publicly known about its security, available at [gold.safeguard.sh](https://gold.safeguard.sh). Anyone can look up a component's known vulnerabilities without an account.
## What "Gold Certified" means
A component shows as **Gold Certified** when Gold knows of **no vulnerabilities** in the version it indexed and the component is **not deprecated**. That is the whole rule: it describes what is publicly known about the upstream release. Gold does not rebuild, sign or attest components, and the labels on a component's verification panel follow from this rule and from whether the component links a source repository; they are not separate scans.
Each component page shows the evidence behind its status: the known vulnerabilities with their advisories, the license and the release details.
## What it covers
Gold Open Source spans the modern software (and AI) supply chain:
| Section | What's in it |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Packages** | Verified open-source packages across 20+ ecosystems (npm, PyPI, Maven, Go, Cargo, and more) with vulnerability counts, license, and version data. |
| **Container Images** | Docker images in the index, with their known vulnerabilities and license. |
| **Vulnerabilities (CVEs)** | A real-time CVE database searchable by package, severity or ecosystem, with CVSS, affected and fixed versions, and remediation. |
| **CWE Index** | Every Common Weakness Enumeration class with related CVEs. |
| **MITRE ATT\&CK®** | Tactics, techniques and sub-techniques, mitigations, threat-actor groups, malware/tools, and campaigns across the Enterprise, Mobile, and ICS matrices. |
| **AI Models** | Open-weight models sourced from the Hugging Face Hub (with live download and star counts) plus notable frontier models. |
| **MCP Servers** | Thousands of Model Context Protocol servers from the official registry. |
| **Agent Skills** | Official Anthropic Agent Skills and notable community skills. |
| **Chip Manufacturers** | Semiconductor companies from fabless designers to foundries and equipment makers. |
## Chrome extension
Gold Open Source is available as a Chrome extension so lookups happen without leaving the browser. Install it from the [Chrome Web Store](https://chromewebstore.google.com/detail/gold-open-source/dddibcdhblnpookmdpamdjcodfdlaoal).
## Remediation guidance
Every CVE page includes an **"Am I affected?"** check: enter the version you're running and get an immediate verdict against the advisory's affected and fixed versions. Every package page with known vulnerabilities shows a **recommended safe version**: the lowest version that clears the most advisories, with a copy-ready upgrade command for your ecosystem.
## CI gate: GitHub Action and CLI (planned)
**Not yet published.** The Gold Scan action and its command-line form are built but not yet released: `safeguard-sh/gold-scan-action` is not on the GitHub Marketplace and there is no Gold Scan package on npm, so the workflow below does not run yet. It shows how it will work once it ships.
Gate your pipeline on Gold intelligence for free: no account, no API key, and your source never leaves the runner (only dependency names are sent to the public read API). Add `.github/workflows/gold-scan.yml`:
```yaml
name: Gold Scan
on: [push, pull_request]
jobs:
gold-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: safeguard-sh/gold-scan-action@v1
with:
fail-on: kev # kev = actively exploited only | vuln = any known CVE | none = report only
```
A command-line form for pre-commit hooks, GitLab CI, Jenkins or a local run is planned for the same release. Until this page gives its install command, there is no Safeguard package to install: don't install a package that claims to be Gold Scan.
It discovers npm, PyPI, crates.io, Go, RubyGems, and Packagist manifests, flags dependencies that are actively exploited (CISA KEV) or known-vulnerable, and writes a summary to the run. It **fails open** if the API is unreachable, so a Gold outage never blocks your build. See [Developers](https://gold.safeguard.sh/developers) for the full API and README badge.
## Data sources
Gold Open Source aggregates, normalizes, and enriches public data. Attribution for every source is listed on the [Credits page](https://gold.safeguard.sh/credits): NVD (NIST), the CVE and CWE programs (MITRE), OSV.dev, GitHub Security Advisories, OWASP, the Hugging Face Hub, the MCP registry, and the open-source package and container registries.
*MITRE ATT\&CK® is a registered trademark of The MITRE Corporation.*
# Gold (/docs/gold-registry)
# Gold
**Safeguard Gold** is Safeguard's public open-source security intelligence site, at [gold.safeguard.sh](https://gold.safeguard.sh). It is free and needs no account. Search a package, container image or CVE to see what is known about it: its known vulnerabilities with severity and fixed versions, whether a CVE is actively exploited (on the CISA Known Exploited Vulnerabilities list), and its license, maintainer and release details. The full tour is on [Gold Open Source](/docs/gold-open-source).
## What "Gold Certified" means
A package or image shows as **Gold Certified** when Gold knows of **no vulnerabilities** in the version it indexed and the package is **not deprecated**. That is the whole rule. It describes what is publicly known about the upstream release; Gold does not rebuild, sign or attest packages, and it does not host a package or image registry.
Fixes come from the upstream project's own releases: each package page with known vulnerabilities shows the version that clears them where one exists, and each CVE page has an **Am I affected?** check for the version you run.
## Requesting a Gold version in Safeguard
In **Open Source Manager › Inventory**, you can ask the Safeguard team to source a Gold version of a vulnerable package:
1. Open **Open Source Manager › Inventory**.
2. For one package, select **Request Gold** on its row. Safeguard confirms with **Gold Request Submitted**, and the row then shows **Gold Requested** (the marker is kept in your browser).
3. For every vulnerable package at once, select **Source Gold** above the table, review the packages and the risks listed, then select **Submit Request**. **Request Premium Gold** works the same way for Premium Gold versions.
Each request reaches the Safeguard team as a task to source a Gold version for that package. Request Gold, Source Gold and Request Premium Gold appear only if your plan includes them; ask your Safeguard administrator if you don't see them.
## Gold from your AI assistant
The Safeguard MCP server can search Gold and read a package's known vulnerabilities for an assistant such as Claude or ChatGPT, once your administrator switches those tools on. See [MCP](/docs/mcp).
## Related
* [Gold Open Source](/docs/gold-open-source): everything gold.safeguard.sh covers, its browser extension and its data sources.
* [Open Source Manager](/docs/osm): where Request Gold lives.
* [Software composition analysis](/docs/sca): how Safeguard finds vulnerable packages in your own projects.
# Griffin AI (/docs/griffin-ai)
# Griffin AI
Griffin AI is Safeguard's purpose-built large language model designed specifically for software supply chain security. Unlike general-purpose AI, Griffin is trained on security data, vulnerability databases, and software composition patterns.
Griffin is one model. It does not come in sizes: there is no Griffin Lite, S, M, L or XL. Its parameters, context window and price are on [AI Models](/docs/ai-models#lineup-facts), with Eagle, Lino and Zero.
## Capabilities
### Natural Language Search
Query your SBOMs using plain English:
```
"Show me all critical vulnerabilities in production services"
```
```
"Find components affected by Log4Shell"
```
```
"What GPL-licensed packages are we using?"
```
### Intelligent Prioritization
Griffin AI analyzes vulnerabilities considering:
* **Reachability** - Is the vulnerable code actually called?
* **Exploitability** - How likely is exploitation?
* **Context** - Production vs development environment
* **Business Impact** - What systems are affected?
### AI Remediate Generation
Griffin generates remediation:
* Upgrade recommendations
* Dependency conflict resolution
* Breaking change analysis
* Pull request generation
### Security Analysis
Deep analysis capabilities:
* Component behavior analysis
* Anomaly detection
* Supply chain risk assessment
* Attack path identification
## Using Griffin AI
### Search Interface
Access Griffin from the search bar:
1. Click the search icon or press `/`
2. Type your query in natural language
3. Griffin returns relevant results
4. Click to explore details
### AI Remediate
Enable Griffin for remediation:
1. Navigate to a vulnerability
2. Click **AI Remediate**
3. Review the proposed fix
4. Apply or modify as needed
### Chat Interface
Direct conversation with Griffin:
1. Click the Griffin icon
2. Ask questions about your security posture
3. Request analysis or reports
4. Get recommendations
## Example Queries
| Query | Griffin Response |
| ---------------------------- | ----------------------------------- |
| "What's our biggest risk?" | Prioritized list of critical issues |
| "Explain CVE-2024-1234" | Detailed vulnerability analysis |
| "How do I fix this?" | Step-by-step remediation guide |
| "Compare last two scans" | Diff analysis with changes |
| "Generate executive summary" | High-level security report |
## Privacy & Security
* Griffin runs on Safeguard infrastructure
* Your code is never stored or used for training
* Analysis is performed in isolated environments
* Architecture designed for FedRAMP HIGH and IL5
* Complete tenant isolation
## Availability
Griffin AI is included with all Safeguard products:
* Enterprise ESCM
* Portal
* Third Party Risk Manager
* Open Source Manager
# Audit Trail & Alerts (/docs/guard-audit-alerts)
# Audit Trail & Alerts
Every request Guard evaluates — allow, deny, or monitor — is written to an append-only audit trail. Guard rolls those events up into hourly and daily aggregates for reporting and trend analysis. Guard also defines an alert-rule schema — thresholds on signals like a rising jailbreak score or an elevated ratio of blocked requests that are meant to fire a webhook — though as covered below, rule creation and evaluation aren't wired up yet. This page covers what's recorded, how to query it, and the alert-rule reference.
## Every decision is an audit event
Each time Guard evaluates a request, it writes an `audit_events` row recording the decision and the signals behind it:
| Column | Description |
| ------------------------------------------------------- | ------------------------------------------------------------------------ |
| `id`, `org_id`, `agent_id`, `server_id`, `proxy_url_id` | Identifiers for the event and the agent/server/proxy URL it relates to |
| `request_id`, `method`, `tool_name` | Which request this was and which tool it targeted |
| `action` | The decision Guard made: `allow`, `deny`, or `monitor` |
| `rule_id`, `rule_name`, `deny_reason` | Which policy rule matched, and why, when the action wasn't a plain allow |
| `risk_score`, `jailbreak_score`, `anomaly_score` | The scores Guard's analysis produced for this request |
| `input_params`, `output_result` | The request's input parameters and the resulting output, stored as JSON |
| `pii_detected`, `fields_redacted` | Any PII types detected and any fields redacted from the payload |
| `latency_ms`, `status_code`, `error_message` | Timing and outcome of the underlying call |
| `created_at` | When the event occurred |
Note that `action` is a three-way decision, not a simple allow/block: `monitor` covers requests Guard let through but flagged for visibility, distinct from an outright `deny`.
A denied request looks like this once it lands in the audit trail:
```json
{
"id": "b6e1c2b0-3e4a-4f1b-9c2d-1a2b3c4d5e6f",
"org_id": "3fa0e6d2-...",
"agent_id": "9c1e4a2b-...",
"server_id": "7d2f5b3c-...",
"request_id": "req_01HZX...",
"method": "tools/call",
"tool_name": "run_sql_query",
"action": "deny",
"rule_id": "2f8a...",
"rule_name": "Block raw SQL from untrusted agents",
"deny_reason": "input matched block_pattern rule",
"risk_score": 0.83,
"jailbreak_score": 0.12,
"anomaly_score": 0.91,
"pii_detected": ["email", "credit_card"],
"fields_redacted": ["customer.email", "customer.card_number"],
"latency_ms": 4,
"status_code": 403,
"created_at": "2026-07-07T14:02:31Z"
}
```
`input_params` and `output_result` are also present on every event (omitted above for brevity) — they carry the request's parameters and the tool's response as JSON, subject to whatever output filters your policy applies before the response reaches the audit trail.
The `audit_events` table is partitioned by month on `created_at`. A background worker task keeps roughly the current month plus three months of future partitions created ahead of time, and a separate daily job deletes events older than the retention window — 90 days by default (`AUDIT_RETENTION_DAYS` on a self-hosted [Guard Proxy](/docs/guard-proxy) deployment) — so old data ages out automatically rather than accumulating indefinitely. This is a high-volume, append-only log designed to hold every decision Guard makes, not just the ones that get blocked.
> Audit writes are asynchronous and non-blocking. Guard publishes each event onto a Redis Stream on the request's hot path and returns immediately; a background worker consumes that stream and batches events into Postgres — flushing every 100 events or every 1 second, whichever comes first, by default (`AUDIT_BATCH_SIZE` / `AUDIT_BATCH_TIMEOUT`). A slow or temporarily unavailable audit store does not add latency to, or block, the underlying policy decision — but it also means a just-made request can take up to roughly a second to show up when you query the trail immediately afterward.
## Querying the audit trail
Two endpoints back the audit views, both under your Guard deployment's management API:
### `GET /api/v1/audit`
Lists individual audit events for your organization, newest first.
| Query param | Required | Notes |
| ------------ | -------- | --------------------------------------------------------------------------------------------------------- |
| `action` | No | Exact match against `allow`, `deny`, or `monitor`. Omit to return all three. |
| `method` | No | Exact match against the JSON-RPC method, e.g. `tools/call`. |
| `from`, `to` | No | Date range filter on `created_at`. Either or both may be omitted — an omitted bound simply isn't applied. |
| `page` | No | Zero-indexed page number. Defaults to `0`. |
| `page_size` | No | Defaults to `50`, capped at `200`. |
```bash
curl "https:///api/v1/audit?action=deny&from=2026-07-01&to=2026-07-07&page=0&page_size=50" \
-H "Authorization: Bearer "
```
```json
{
"data": [
{ "id": "b6e1c2b0-...", "action": "deny", "tool_name": "run_sql_query", "risk_score": 0.83, "created_at": "2026-07-07T14:02:31Z", "...": "..." }
],
"total": 214,
"page": 0,
"page_size": 50,
"has_more": true
}
```
There's no `agent_id` or `server_id` query parameter today, even though both are recorded on every event — filter client-side on the returned events, or narrow by `method`/`action`/date range instead, if you need to isolate one agent or server.
### `GET /api/v1/audit/timeline`
Returns event counts bucketed by hour or day, computed live over the raw events in the window you ask for — useful for trend charts without pulling every event.
| Query param | Required | Notes |
| ------------ | -------- | ------------------------------------------------------------------------------------------------------------------------ |
| `period` | No | `hour` or `day`. Defaults to `hour` if omitted. |
| `from`, `to` | **Yes** | Unlike `GET /audit`, both bounds are required — the underlying query uses them directly and errors if either is missing. |
```bash
curl "https:///api/v1/audit/timeline?period=day&from=2026-07-01&to=2026-07-07" \
-H "Authorization: Bearer "
```
```json
[
{
"period_start": "2026-07-06T00:00:00Z",
"total_requests": 4820,
"allowed_requests": 4510,
"denied_requests": 260,
"monitored_requests": 50,
"avg_latency_ms": 38.4,
"avg_risk_score": 0.11,
"pii_detections": 37,
"jailbreak_detections": 3
}
]
```
> `GET /audit/timeline` is unpaginated and returns one row per bucket in the window — a wide `from`/`to` range with `period=hour` can return a lot of rows. Prefer `period=day` for anything wider than a week or two.
## Aggregates for reporting and trends
Separately from the live `GET /audit/timeline` endpoint above, an hourly and a daily background job roll `audit_events` up into a persisted `audit_aggregates` table — one row per organization, per period (`hour` or `day`), per `period_start`:
| Column | Description |
| ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `total_requests`, `allowed_requests`, `denied_requests`, `monitored_requests` | Request counts by outcome for the period |
| `avg_latency_ms`, `avg_risk_score` | Averages across the period |
| `pii_detections` | Count of requests where at least one PII type was detected |
| `jailbreak_detections` | Count of requests where `jailbreak_score` exceeded a fixed `0.5` cutoff in the rollup job — this is a different, hard-coded threshold from whatever `jailbreak_score` value you use in a policy rule or an alert rule |
| `top_tools`, `top_agents` | Reserved fields for the most-active tools and agents in the period |
`(org_id, period, period_start)` is unique, so re-running the rollup for a period upserts in place rather than duplicating rows.
> `top_tools` and `top_agents` are present in the schema but are not populated by the aggregation job today — don't rely on them being non-empty.
> **`audit_aggregates` and `GET /audit/timeline` are two independent things today.** The rollup job writes to `audit_aggregates` on a schedule, but `GET /audit/timeline` doesn't read from that table at all — it computes the same shape of summary live, directly from `audit_events`, for whatever window you pass in. In practice this means the timeline endpoint is always fresh (no rollup lag) but scans raw events for the requested range, and the persisted `audit_aggregates` table isn't currently exposed through any documented endpoint. If you need the exact rollup numbers rather than a live equivalent, query `GET /audit/timeline` with the same period and window — the values match, aside from the `jailbreak_detections` cutoff note above and the always-empty `top_tools`/`top_agents` fields, which the timeline response doesn't include at all.
## Alert rules
> **This capability isn't reachable through the product yet.** The `alert_rules` schema, trigger types, and message strings below exist in Guard's codebase, but as of this writing there's no `/api/v1/...` endpoint to create, list, or update an alert rule, and no running Guard process (proxy, API, or worker) evaluates live traffic against `alert_rules` rows or dispatches a notification when one matches — the trigger-matching and message-building logic isn't currently called from anywhere in the request path or a background job. Treat the rest of this section as a reference for the rule shape and message format rather than a feature you can configure and rely on today.
An alert rule watches a specific signal and fires when it crosses a threshold within a rolling window:
| Column | Description |
| --------------------- | ---------------------------------------------------------------------------------------------------------- |
| `name`, `description` | How the rule identifies itself |
| `trigger_type` | What the rule watches: `jailbreak_score`, `blocked_ratio`, `server_down`, `anomaly_score`, or `rate_limit` |
| `threshold` | The value that must be met or exceeded to trigger |
| `window_seconds` | The rolling window the threshold is evaluated over (defaults to 300 seconds) |
| `severity` | `low`, `medium`, `high`, or `critical` |
| `is_active` | Whether the rule is currently enabled |
| `last_triggered_at` | When the rule last fired |
Each `trigger_type` maps to a specific comparison, and produces a specific message string when it fires:
| `trigger_type` | Fires when | `message` sent in the alert |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `jailbreak_score` | A request's jailbreak score meets or exceeds `threshold` | `Jailbreak score 0.91 exceeded threshold 0.80` |
| `anomaly_score` | A request's anomaly score meets or exceeds `threshold` | `Anomaly score 0.87 exceeded threshold 0.75` |
| `blocked_ratio` | The ratio of denied requests meets or exceeds `threshold`, evaluated over the rule's window — not a raw count of denials from one specific agent | `Blocked request ratio 0.62 exceeded threshold 0.50` |
| `server_down` | The connected MCP server is unreachable | `MCP server is unreachable` |
| `rate_limit` | A request's *risk score* (not literally a request-per-second rate) meets or exceeds `threshold` | `Alert triggered: ` — unlike the other trigger types, the message doesn't include the risk score or threshold value, so give a descriptive `name` to a `rate_limit` rule if you want the alert itself to convey what tripped it |
`blocked_ratio` is the rule to use for something like "an agent is getting blocked repeatedly" — again, it's an org-wide ratio over the window, not scoped to one agent.
> The `rate_limit` name is a bit of a misnomer: it doesn't watch requests-per-second directly, it compares against `risk_score` — a composite Guard computes per request as a weighted blend of `jailbreak_score` (60%) and `anomaly_score` (40%), capped at `1.0`. If you want an alert that's purely about jailbreak or anomaly signal, use the `jailbreak_score` or `anomaly_score` trigger types instead; use `rate_limit` when you want to watch the blended score.
> There isn't a dedicated "tool poisoning" trigger type, and tool poisoning findings don't appear in the audit trail at all. Tool poisoning is a separate, on-demand static analysis of a registered server's tool definitions (its name and description) — distinct from the per-request `jailbreak_score`/`anomaly_score` signals on `audit_events`, which are computed from request content, not tool metadata. See [Tool-poisoning detection](/docs/guard-sdk#tool-poisoning-detection) for how that check works.
## How alerts are delivered
The intended flow is: when a rule's condition is met, Guard sends the alert to every active webhook configured for your organization that's subscribed to the `alert.triggered` event (or subscribed to all events with `*`) — see the note above on evaluation not being wired up yet. The payload is built like this:
```json
{
"event": "alert.triggered",
"data": {
"id": "...",
"org_id": "...",
"rule": { "name": "...", "trigger_type": "blocked_ratio", "severity": "high", "...": "..." },
"severity": "high",
"message": "Blocked request ratio 0.62 exceeded threshold 0.50",
"triggered_at": "2026-07-07T00:00:00Z"
}
}
```
Each delivery is signed the same way as any other Guard webhook — an HMAC-SHA256 signature over a timestamp-prefixed payload, sent as a `sha256=` header value — so you can verify it came from Guard before acting on it. See [Webhooks](/docs/guard-webhooks) for the full delivery, signing, and retry behavior.
> Alerts, once evaluation is wired up, are delivered via webhook only — there's no separate email or in-app notification channel described anywhere in the codebase today. If you have no active webhook subscribed to `alert.triggered` (or `*`), a triggered rule would still update `last_triggered_at` but there'd be nowhere for the notification to go.
## FAQ & Troubleshooting
**Does every allowed request get logged, or only blocks?**
Every request Guard evaluates is logged, regardless of `action`. Filtering the audit trail to `action=deny` is a query you apply on top of a complete record, not a separate log.
**I don't see any alert rule management in the API — how do I create one?**
There isn't a documented way to today. The `alert_rules` table and the trigger/message logic described above exist in Guard's codebase, but no `/api/v1/...` route creates, lists, or updates them, and no running Guard process evaluates traffic against them yet — so this section documents the rule shape and message format for when that lands, not a feature you can configure right now.
**Can I alert on a single agent's block count instead of an org-wide ratio?**
The `blocked_ratio` trigger type evaluates a ratio over the rule's window, not a per-agent denial count. If you need to watch one agent specifically, scope your monitoring around that agent's activity in the audit trail rather than expecting the alert rule itself to isolate it.
**Why don't `top_tools` / `top_agents` show up in `audit_aggregates`?**
Those columns exist in the schema for future use but aren't populated by the current aggregation job — use `GET /audit` with your own filters to identify top tools or agents in the meantime.
**How long is audit data retained?**
90 days by default (`AUDIT_RETENTION_DAYS` on a self-hosted deployment). A daily job deletes events older than the cutoff, and the underlying table is partitioned by month so the deletes stay cheap as data ages out.
**I just made a request — why isn't it showing up in `GET /audit` yet?**
Audit writes are asynchronous: the event is published to a Redis Stream on the hot path and a background worker batches it into Postgres, flushing every 100 events or every 1 second by default. Query again after a second or two — this isn't a bug, it's the tradeoff that keeps audit logging from adding latency to the underlying request.
**Can I filter `GET /audit` by `agent_id` or `server_id`?**
Not today. Both are recorded on every event, but the endpoint only exposes `action`, `method`, `from`/`to`, and pagination as query parameters. Filter client-side on the returned page, or narrow by `method`/date range if you need to zero in on one agent or server.
**`GET /audit/timeline` returns an error — what am I missing?**
Unlike `GET /audit`, both `from` and `to` are required for the timeline endpoint; leaving either one out causes the underlying query to fail rather than defaulting to "everything." Always pass an explicit date range.
**Is this the same "audit trail" as the one under Settings → Audit Logs in the portal?**
No — [Portal Audit Trails](/docs/portal/audit-trails) logs administrative and workspace activity (who changed a policy, exported an SBOM, invited a user) for compliance purposes. This page covers Guard's separate, high-volume log of individual MCP request decisions (`allow`/`deny`/`monitor`). They're stored differently, queried through different endpoints, and retained on different schedules — don't expect one to show up in the other.
## Related
* [Policies](/docs/guard-policies) — define the rules whose allow/deny/monitor decisions populate the audit trail.
* [Webhooks](/docs/guard-webhooks) — configure delivery, signing, and retries for `alert.triggered` and other events.
* [Guard SDK](/docs/guard-sdk) — embeds Guard in your MCP server/agent process; also covers the separate tool-poisoning detection check, which doesn't write to the audit trail.
* [Guard Proxy Deployment](/docs/guard-proxy) — self-hosted deployment whose `worker` service runs the audit rollup, retention, and batch-writer jobs described on this page.
* [Servers & Agents](/docs/guard-servers-agents) — the `agent_id` and `server_id` inventory that every audit event and alert is scoped to.
* [Portal Audit Trails](/docs/portal/audit-trails) — the separate, workspace-activity audit log; not to be confused with the request-level trail on this page.
# Guard Policies (/docs/guard-policies)
# Guard Policies
A Guard policy is the set of rules that Guard evaluates against every MCP request flowing through the [Guard SDK](/docs/guard-sdk) or a [Guard proxy](/docs/guard-proxy) deployment. Each rule says, in effect, "when a request looks like this, take this action" — allow it through, deny it outright, or let it through while flagging it for monitoring. This page covers how policies are structured, what they can match on, and how a change you make reaches every running instance of your agents.
> This is a different mechanism from [Guardrails & Enforcement](/docs/guardrails-enforcement), which gates CI/CD, registries, admission, and runtime against SBOM/CVE/license/signing rules using `BLOCK` / `WARN` / `AUTO_FIX` effects. Guard policies instead govern live MCP tool calls at request time, with `allow` / `deny` / `monitor` actions. If you're looking for supply-chain policy-as-code for your pipeline, see that page instead.
## Where policies are managed
You author and edit Guard policies from your Safeguard workspace — there's no local policy file to write or check into source control. Whatever the SDK or a proxy is enforcing at any moment is a live pull of whatever's currently saved in your workspace. A policy is scoped to your organization and made up of an ordered list of rules, each of which can be edited, reordered, or removed independently.
Under the hood, a policy is its own record with an `id`, `name`, `description`, an `is_default` flag, and a top-level `priority`, on top of its list of rules. Your organization can have more than one policy record stored, but at any moment **exactly one** — the one with `is_default: true` — is the policy Guard actually loads and enforces. The SDK's background sync and the proxy both resolve to that same default policy; a policy you create or edit without marking it default is saved but never evaluated against live traffic. The Safeguard workspace UI manages this for you when you edit "your policy," but it matters if you're also driving policies through the [API](#managing-policies-via-the-api) below.
> Keep exactly one policy per organization marked as the default. The lookup Guard uses to resolve "the" default policy doesn't apply any tie-breaking order across multiple `is_default: true` rows for the same org — if more than one exists, which one gets loaded isn't guaranteed to be consistent.
A policy's own top-level `priority` field is separate from the `priority` on each of its rules — it only affects the order policies are listed in (for example, in the dashboard or a `GET /api/v1/policies` call), not which policy is active. Rule-level priority, covered next, is what determines match order within the active policy.
## Managing policies via the API
Most day-to-day edits happen in the Safeguard workspace UI, but the same CRUD operations are available as a REST API if you want to manage policy from a script or your own tooling. Requests are authenticated the same way as other dashboard API calls — a bearer JWT from your Safeguard session (see [RBAC, Teams & Organizations](/docs/rbac-teams#api-keys-and-tokens)).
```bash
# List policies for your organization
curl https:///api/v1/policies \
-H "Authorization: Bearer "
# Fetch a single policy
curl https:///api/v1/policies/ \
-H "Authorization: Bearer "
# Create a policy
curl -X POST https:///api/v1/policies \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
-d '{
"name": "Production policy",
"description": "Default enforcement for the prod org",
"is_default": true,
"priority": 0,
"rules": []
}'
# Update a policy (replaces its fields, including the full rules list)
curl -X PUT https:///api/v1/policies/ \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
-d '{ "name": "Production policy", "is_default": true, "priority": 0, "rules": [] }'
# Delete a policy
curl -X DELETE https:///api/v1/policies/ \
-H "Authorization: Bearer "
```
`POST` and `PUT` both take the full policy object, including its complete `rules` array — there's no separate endpoint for adding or editing a single rule, so send the whole rule list each time. Fields your JSON body doesn't recognize are silently ignored rather than rejected, so a typo'd field name (like `match_tool` instead of `match_tools`) won't surface as a validation error — it just won't do anything. Check field names against the [example policy](#example-policy) below if a rule doesn't seem to be having the effect you expect.
## How a request is evaluated
When a request comes in, Guard checks it against your policy's rules in priority order, highest priority first. The **first rule that matches wins** — its action is applied and evaluation stops there. If no rule matches, Guard falls back to a default decision, which flags the request for monitoring rather than silently allowing or blocking it.
If your organization doesn't have any policy marked default yet, the same fallback applies at the whole-policy level — Guard flags all traffic for monitoring rather than allowing or blocking it, until you create a policy and mark it as the default.
> If two or more rules share the same priority value, Guard doesn't guarantee a stable order between them — treat equal priorities as "order unspecified," not "evaluated in the order I wrote them in." Give rules distinct priority values whenever their relative order matters.
## What a rule can match on
A rule can combine any of the following conditions. All conditions on a rule must be satisfied for it to match; if a rule doesn't specify a given condition at all, that condition is treated as "matches anything."
| Match on | Behavior |
| ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Method** | Matches the MCP JSON-RPC method exactly (case-insensitive) — for example, restricting a rule to `tools/call` requests only. |
| **Tool name** | Matches the name of the tool being called, using glob-style wildcards (`*` for any sequence of characters, `?` for a single character), case-insensitive. A rule with a tool-name match only ever applies to requests that actually carry a tool name — it's skipped for requests where a tool name isn't part of the payload. |
| **Agent ID** | Matches an exact agent identifier, letting you scope a rule to a specific calling agent rather than every agent in your org. |
Beyond these top-level match conditions, a rule's **input filters** give you finer-grained content matching against the request body itself — for example, blocking a request whose parameters match a given pattern, rejecting oversized input, or catching malformed encoding. See [Input and output filters](#input-and-output-filters) below.
> There's currently no separate "server name" match condition distinct from tool name and agent ID. If you need to scope a rule to tools exposed by a particular MCP server, match on the tool names (or naming convention) that server exposes, or scope by agent ID if that server is only ever called by a specific agent.
## Actions
Each rule resolves to exactly one of three actions:
| Action | Effect |
| ----------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **allow** | The request proceeds normally. |
| **deny** | The request is blocked before it reaches the tool. You can attach a reason that's surfaced back to the caller explaining why. |
| **monitor** | The request proceeds, but is flagged so you can review it later — useful for rules you're still tuning, or traffic you want visibility into without blocking it yet. |
A rule can also carry a **rate limit** (a request count over a time window) and **jailbreak** / **anomaly detection thresholds**, which feed into Guard's request analysis independently of the match conditions above:
```json
{
"rate_limit": { "limit": 100, "window_sec": 60 },
"jailbreak_threshold": 0.75,
"anomaly_threshold": 0.80
}
```
Both thresholds are scores Guard's analysis compares an incoming request against — the higher the value, the more confident Guard has to be before treating a request as a jailbreak attempt or an anomaly. If a rule doesn't set one of these thresholds, it inherits the organization-wide default (0.75 for jailbreak, 0.80 for anomaly, unless your deployment is configured with different values) rather than being left unset.
## Input and output filters
Filters are attached to a rule and run when that rule matches — input filters against the incoming request, output filters against the tool's response.
**Input filters** run before the tool call executes:
| Type | What it does |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `block_pattern` | Denies the request if its parameters match a given regular expression. |
| `max_length` | Denies the request if its parameters exceed a configured length. |
| `encoding_check` | Denies the request if its parameters contain invalid encoding. |
| `jailbreak_check` | Denies the request if its parameters match known prompt-injection / jailbreak phrasing (for example, "ignore previous instructions," "you are now in DAN mode," attempts to reveal a system prompt, and similar patterns). |
**Output filters** run on the tool's response before it's returned to the caller:
| Type | What it does |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `pii_mask` | Detects and masks common PII patterns in the response — email addresses, SSNs, credit card numbers, phone numbers, IP addresses, API keys, JWTs, and bearer tokens. |
| `column_redact` | Redacts specific named columns/fields from structured (tabular) output. |
| `row_limit` | Caps the number of rows returned. |
| `regex_mask` | Masks any part of the response matching a given regular expression. |
> Filter behavior is defined generically by type — exactly which filter types and parameters are available to you may expand over time. Treat the tables above as the concepts currently supported rather than an exhaustive, frozen schema.
## Example policy
Putting the pieces above together, here's what a policy with two rules looks like as the underlying JSON object — the same shape the workspace UI (and the API described above) is ultimately editing:
```json
{
"id": "8f14e45f-ceea-4d2f-8b5b-3f1a2c9e9a1b",
"org_id": "3fa0e6d2-2c1a-4b9b-9a2e-8e0c1d6f7a90",
"name": "Production policy",
"description": "Default enforcement for the prod org",
"is_default": true,
"priority": 0,
"rules": [
{
"id": "block-jailbreak-support-tools",
"name": "Block jailbreak attempts against support tools",
"description": "Deny anything that looks like a prompt-injection attempt on customer-support tool calls",
"action": "deny",
"deny_reason": "Request blocked: matched jailbreak/prompt-injection pattern",
"match_methods": ["tools/call"],
"match_tools": ["support_*"],
"input_filters": [
{ "type": "jailbreak_check" },
{ "type": "max_length", "max_length": 8000 }
],
"jailbreak_threshold": 0.75,
"priority": 100
},
{
"id": "default-pii-mask",
"name": "Mask PII and limit exported rows",
"action": "allow",
"match_methods": ["tools/call"],
"match_tools": ["export_*", "query_*"],
"output_filters": [
{ "type": "pii_mask" },
{ "type": "column_redact", "columns": ["ssn", "internal_notes"] },
{ "type": "row_limit", "limit": 500 }
],
"priority": 10
}
],
"created_at": "2026-06-01T12:00:00Z",
"updated_at": "2026-07-01T09:30:00Z"
}
```
A few things worth noting in this shape:
* Rules are evaluated **highest rule `priority` first** — the jailbreak rule (`100`) is checked before the PII-masking rule (`10`).
* `match_tools` uses glob patterns (`support_*`, `export_*`, `query_*`) rather than exact tool names.
* `deny_reason` is only meaningful on `deny` rules — it's surfaced back to the caller and recorded on the resulting audit event as `rule_id` / `rule_name` / `deny_reason`. See [Audit Trail & Alerts](/docs/guard-audit-alerts).
* Input filters and output filters are independent lists — a rule can carry either, both, or neither.
## How policy changes propagate
Policy changes you make in your Safeguard workspace don't need to be pushed or deployed anywhere. Both the Guard SDK and Guard proxy deployments continuously pull the live policy for your organization in the background, so an edit you save reaches every running SDK instance and proxy within moments — no restart, redeploy, or config reload required on your side.
If a running instance temporarily can't reach Safeguard to refresh its policy, it keeps enforcing the last policy it successfully fetched rather than failing open (allowing everything) or failing closed (blocking everything) while it retries.
## FAQ & Troubleshooting
**Do I need to write policy files or check anything into source control?**
No. Policies live in your Safeguard workspace and are pulled live by the SDK and proxy — there's nothing to author or deploy in your own repo.
**What happens if no rule in my policy matches a request?**
It falls through to a default decision that flags the request for monitoring rather than silently allowing it, so unmatched traffic doesn't go unnoticed while you're still building out rules.
**Why isn't a rule with a tool-name match doing anything on non-tool requests?**
A rule that matches on tool name only ever applies to requests that carry a tool name in the first place (like `tools/call`). It's intentionally skipped for other request types rather than matching everything when the tool name is empty.
**Can two rules match the same request?**
Only the highest-priority matching rule applies — evaluation stops at the first match. If you expect both rules to fire, check their priority ordering.
**How is this different from the guardrails described elsewhere in the docs?**
[Guardrails & Enforcement](/docs/guardrails-enforcement) governs your software supply chain — CI, registries, admission, and runtime — using YAML policy-as-code with `BLOCK` / `WARN` / `AUTO_FIX` effects. Guard policies are a separate system that governs live MCP tool calls at request time, with `allow` / `deny` / `monitor` actions.
**I created a second policy, but its rules don't seem to be enforced.**
Only the policy marked `is_default: true` for your org is the one Guard actually loads and evaluates — other policies you create via the API are stored but inert until you make them the default. See [Where policies are managed](#where-policies-are-managed).
**Two of my rules have the same `priority` — which one wins?**
Don't rely on it being consistent. Guard sorts rules by priority but doesn't guarantee a stable tie-break order between rules that share the same value — give the rules distinct priorities if their relative order matters.
**I added a field to my rule's JSON and nothing happened.**
Unrecognized fields in a policy create/update request are silently ignored rather than rejected, so a misspelled field name (like `match_tool` instead of `match_tools`) won't error — it just won't take effect. Compare your rule against the [example policy](#example-policy) above if a change doesn't seem to be doing anything.
**What are the jailbreak and anomaly thresholds actually comparing against?**
They're the minimum score Guard's request analysis has to produce before that signal counts as a match — set per rule, or inherited from your org's defaults (0.75 for jailbreak, 0.80 for anomaly) when a rule doesn't specify its own. See [Audit Trail & Alerts](/docs/guard-audit-alerts) for where these scores show up on individual requests, and [Guard Webhooks](/docs/guard-webhooks) for alerting on them.
## Related
* [Guard SDK](/docs/guard-sdk) — embed policy enforcement directly in your MCP server or agent process.
* [Guard Proxy](/docs/guard-proxy) — enforce policy for MCP traffic without modifying your agent's code.
* [Servers & Agents](/docs/guard-servers-agents) — register the agents that `match_agent_ids` targets by ID; there's no separate server match condition, so scoping a rule to a server's tools works by tool name instead (see the note above).
* [Audit Trail & Alerts](/docs/guard-audit-alerts) — every rule match is recorded here, with the `rule_id` / `rule_name` / `deny_reason` behind each decision.
* [Guard Webhooks](/docs/guard-webhooks) — get notified when jailbreak/anomaly scores or blocked-request ratios cross a threshold.
* [RBAC, Teams & Organizations](/docs/rbac-teams) — the JWT used to authenticate calls to the policies API.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — the separate policy-as-code system for CI/CD, registries, admission, and runtime.
# Guard Proxy Deployment (/docs/guard-proxy)
# Guard Proxy Deployment
Guard doesn't have to live inside your agent process. You can instead run it as a standalone reverse-proxy gateway that sits between your agents/clients and your MCP server(s), applying your Safeguard policy to every JSON-RPC call as it passes through — without touching the MCP server's code at all. This page covers the proxy deployment: when to choose it, how the pieces fit together, and how to bring it up with Docker Compose.
## When to use the proxy instead of the SDK
| Choose | When |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **[Guard SDK](/docs/guard-sdk)** | You control the MCP server or agent process's code and can add a few lines of setup directly inside it. |
| **Guard Proxy** | You want centralized enforcement in front of one or more MCP servers you *don't* control the code of (third-party or vendor-hosted MCP servers), or a server written in a language without a Guard SDK yet. It also lets you enforce policy for many MCP servers from one place instead of instrumenting each one individually. |
The two modes enforce the same underlying Safeguard policy — the difference is purely *where* enforcement happens: inside the process (SDK) or in front of it on the network (proxy). You can also run both at once: for example, the SDK inside servers you own, and the proxy in front of the ones you don't.
## Architecture
```
Agent / MCP client
│
▼
Guard Proxy ──▶ applies policy to each JSON-RPC call
│
▼
Your MCP server(s) (upstream)
```
Instead of pointing your agent or MCP client directly at an MCP server, you point it at a Guard proxy URL. The proxy receives every request, evaluates it against your live Safeguard policy, and forwards allowed calls on to the real (upstream) MCP server — returning the response back through the same path so it can be filtered or logged on the way out too. Requests the policy blocks never reach the upstream server at all.
A full Guard proxy deployment is made up of several services, all present under `deployments/` in the Guard repo:
| Service | Role | Built from |
| ---------- | ----------------------------------------------------------------------------------------------------------------------- | ---------------------------------- |
| `proxy` | The reverse proxy itself — accepts agent/client connections and forwards allowed JSON-RPC calls to upstream MCP servers | `Dockerfile.proxy` (`cmd/proxy`) |
| `api` | Dashboard/management REST API — register MCP servers, manage agents and policies, view audit history | `Dockerfile.api` (`cmd/api`) |
| `worker` | Background processing (audit event aggregation and related async jobs) | `Dockerfile.worker` (`cmd/worker`) |
| `postgres` | Primary datastore for servers, agents, policies, and audit data | `postgres:16-alpine` |
| `redis` | Caching and background job coordination | `redis:7-alpine` |
| `nginx` | Optional reverse proxy in front of `proxy` and `api`, handling routing and rate limiting | `nginx:alpine` |
## Register an MCP server
Before anything can flow through the proxy, tell Guard about the upstream MCP server it should forward to. This is done through the management API (the `api` service), authenticated with your dashboard session:
```bash
curl -X POST https:///api/v1/servers \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
-d '{
"name": "billing-mcp",
"upstream_url": "https://internal-mcp.example.com",
"transport": "http",
"auth_type": "none"
}'
```
| Field | Notes |
| -------------- | ------------------------------------------------------------------------------------------- |
| `name` | A label for the server, shown in the dashboard |
| `upstream_url` | The real address of the MCP server the proxy should forward allowed calls to |
| `transport` | `http` or `sse` |
| `auth_type` | How the proxy authenticates to the upstream server: `none`, `bearer`, `basic`, or `api_key` |
| `auth_config` | Credentials matching `auth_type`, see below |
`auth_config` is a small JSON object whose shape depends on `auth_type` — this is what the proxy attaches to every request it forwards upstream:
| `auth_type` | `auth_config` shape | Header sent upstream |
| ----------- | ---------------------------------------- | ------------------------------------------------------------------------------ |
| `none` | omit, or `{}` | — |
| `bearer` | `{"token": "..."}` | `Authorization: Bearer ` |
| `basic` | `{"username": "...", "password": "..."}` | HTTP Basic auth |
| `api_key` | `{"header": "X-API-Key", "key": "..."}` | The named header (defaults to `X-API-Key` if `header` is omitted) set to `key` |
A successful create returns `201` with the stored server record:
```json
{
"id": "b6e6b0f2-2f9a-4d3e-9f1a-8c2e6a1f0abc",
"org_id": "3f1a9c2e-...",
"name": "billing-mcp",
"description": "",
"upstream_url": "https://internal-mcp.example.com",
"transport": "http",
"auth_type": "none",
"auth_config": {},
"status": "active",
"last_health_at": null,
"health_status": "unknown",
"created_at": "2026-07-07T00:00:00Z",
"updated_at": "2026-07-07T00:00:00Z"
}
```
> `status` and `health_status` are always created as `active` and `unknown` respectively, regardless of what (if anything) you send for those fields — the same pattern Guard uses for agents. Neither field can be changed through a `PUT` update either; `health_status` is meant to be maintained by Guard's own upstream monitoring rather than set by the caller. See [Servers & Agents](/docs/guard-servers-agents) for the full inventory model, including tool discovery and agent lifecycle actions.
Registering a server only creates the inventory record — it does **not** by itself give you a `/p/{slug}/...` path. That path comes from a separate resource, covered next.
## Proxy URLs: binding a slug to a server, agent, and policy
The `{slug}` in `/p/{slug}/message` and `/p/{slug}/sse` identifies a **proxy URL** record, not the server directly. A proxy URL is what actually makes a registered server reachable through the proxy, and it carries more than just routing information:
| Field | Notes |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `server_id` | Which registered MCP server this proxy URL forwards to (required) |
| `agent_id` | Optionally binds this proxy URL to one specific registered agent, so calls through it are attributed to that agent for policy targeting, risk scoring, and audit — otherwise calls are unattributed to any specific agent |
| `policy_id` | Optionally pins this proxy URL to one specific policy, overriding your org's default policy for every call that comes through this slug |
| `slug` | The unique path segment used in `/p/{slug}/...` |
| `label` | A human-readable name for the proxy URL (e.g. `claude-dev`, `gpt-prod`) |
| `status` | `active` or `revoked` |
This split is what lets one MCP server sit behind several different proxy URLs at once — for example, a shared `db-tools` server exposed through one slug bound to a lenient policy for a trusted internal agent, and a second slug bound to a stricter policy for everything else, both pointing at the same `upstream_url`.
> In the current release, proxy URLs are provisioned as their own record (distinct from the `/api/v1/servers` CRUD endpoints covered above) rather than being created automatically when you register a server. If you don't see a proxy URL for a server you just registered, that's expected — reach out to your Guard admin/deployment owner to have one created and bound to the right agent and policy before pointing traffic at it.
Revoking a proxy URL (`status: revoked`) immediately stops new requests from resolving against it, without touching the underlying server or agent records — useful for rotating a leaked slug or decommissioning one integration without affecting others that share the same server.
## Point your agent at the proxy
Once a proxy URL exists for a server, route your agent's traffic to its slug-based path instead of calling the upstream MCP server directly:
* `POST /p/{slug}/message` — send a JSON-RPC request through the proxy
* `GET /p/{slug}/sse` — open an SSE stream through the proxy
Every proxy request must include a bearer API key scoped to your organization:
```bash
curl -X POST https:///p/billing-mcp/message \
-H "Authorization: Bearer sg_live_..." \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"..."}}'
```
A call the policy allows returns the upstream MCP server's own JSON-RPC response, unmodified except for any output filters (like PII masking) your policy applies:
```json
{
"jsonrpc": "2.0",
"id": 1,
"result": { "content": [{ "type": "text", "text": "..." }] }
}
```
> Guard API keys are prefixed `sg_live_...` in production and `sg_test_...` in test/staging. Treat them like credentials — store them in a secrets manager or environment variable, not in source control.
Because the proxy speaks the same HTTP + SSE transport MCP already defines, most MCP clients need nothing more than a URL and header change to start routing through Guard — no SDK, no code change inside the agent.
### What happens to a denied or blocked call
A call the policy denies, rate-limits, or otherwise blocks still comes back as an HTTP response with a JSON-RPC error body, not a bare HTTP error page — so a standard JSON-RPC client can parse it the same way it would any other error:
```json
{
"jsonrpc": "2.0",
"id": 1,
"error": {
"code": -32000,
"message": "request denied by policy: destructive tool calls require monitor review"
}
}
```
| HTTP status | JSON-RPC `error.code` | When |
| ----------- | --------------------- | ------------------------------------------------------------------------------------------------------- |
| `400` | `-32700` | The request body isn't valid JSON-RPC |
| `403` | `-32000` | A policy rule denied the request (`error.message` includes the rule's deny reason) |
| `403` | `-32002` | The calling agent's status is `blocked` |
| `403` | `-32003` | The request (or, on the way back, the tool's response) tripped the jailbreak/prompt-injection threshold |
| `429` | `-32001` | The request was rate-limited by the matching policy rule |
| `502` | `-32004` | The proxy reached the slug fine, but the upstream MCP server itself errored or was unreachable |
Every one of these outcomes — allow, deny, or monitor — is written to the audit trail asynchronously, so a blocked call still shows up in [Audit & Alerts](/docs/guard-audit-alerts) even though the agent never reached the upstream server.
> The `/p/{slug}/sse` stream applies output filtering (like PII masking) to server-sent events as they pass through, but it does not run the full request-time policy pipeline (deny rules, rate limiting, jailbreak detection) that `/p/{slug}/message` does — that enforcement happens on the JSON-RPC calls your agent posts to `/message`, not on the event stream itself. If your MCP client uses SSE for server-initiated messages alongside `POST /message` for requests, the request-time checks still apply where they matter.
## Deploy with Docker Compose
The Guard repo ships a ready-to-use Compose file at `deployments/docker-compose.yml`, along with `Dockerfile.api`, `Dockerfile.proxy`, `Dockerfile.worker`, and an `nginx.conf`. From the `deployments/` directory:
```bash
docker compose up -d
```
This brings up:
| Service | Container | Port(s) |
| ---------- | ------------------- | ------------------- |
| `postgres` | `mcpguard-postgres` | `5432` |
| `redis` | `mcpguard-redis` | `6379` |
| `proxy` | `mcpguard-proxy` | `8080` |
| `api` | `mcpguard-api` | `8081` |
| `worker` | `mcpguard-worker` | — (no exposed port) |
| `nginx` | `mcpguard-nginx` | `80`, `443` |
`proxy`, `api`, and `worker` all wait for `postgres` and `redis` to report healthy before starting, and restart automatically (`unless-stopped`) if they crash.
### Environment variables
| Variable | Used by | Default in Compose |
| -------------- | ------------------ | --------------------------------------------------------------------- |
| `DATABASE_URL` | proxy, api, worker | `postgres://postgres:postgres@postgres:5432/mcpguard?sslmode=disable` |
| `REDIS_URL` | proxy, api, worker | `redis://redis:6379` |
| `JWT_SECRET` | proxy, api | `dev-secret-change-in-production` |
| `ENV` | proxy, api, worker | `production` |
> The bundled `JWT_SECRET` default is explicitly a placeholder (`dev-secret-change-in-production`). Override it by setting a `JWT_SECRET` environment variable before running `docker compose up` in any environment other than local testing — Compose picks it up automatically via `${JWT_SECRET:-dev-secret-change-in-production}`.
### nginx routing
The bundled `nginx.conf` fronts both the `proxy` and `api` services on ports 80/443 and applies per-route rate limiting:
| Path | Forwarded to | Rate limit | Notes |
| --------- | ------------------- | --------------------- | ----------------------------------------------------------------------------------------- |
| `/p/` | `proxy:8080` | 300 req/min, burst 50 | SSE-aware (`proxy_buffering off`, 3600s read timeout) for long-lived streamed connections |
| `/health` | `proxy:8080/health` | — | Unauthenticated health check |
| `/api/` | `api:8081` | 60 req/min, burst 20 | Dashboard/management API |
> This `nginx.conf` only defines a `listen 80` server block — it does not terminate TLS on port 443 out of the box, even though the `nginx` service in Compose exposes it. If you need HTTPS, terminate TLS in front of this stack (e.g. a load balancer or your own nginx/TLS config) rather than assuming port 443 is already secured.
You can also skip nginx entirely and point clients straight at the `proxy` service's port (`8080`) — nginx is there for routing and rate limiting convenience, not a hard requirement of the proxy itself.
## FAQ & Troubleshooting
**Do I need the `api` and `worker` services just to proxy traffic?**
`api` is how you register MCP servers, agents, and policies in the first place, so you'll need it at least once to configure the deployment. `worker` handles background audit processing; the proxy itself will still forward and enforce policy on traffic without it, but you'll lose the async audit/aggregation pipeline.
**A request to `/p/{slug}/message` returns 401.**
Check that you're sending a valid `Authorization: Bearer ` header with a key that starts with `sg_live_` or `sg_test_`, and that the key belongs to the same organization the server/slug was registered under.
**A request to `/p/{slug}/...` returns 404 with `"proxy URL not found"`.**
The proxy returns the same generic 404 whether the slug never existed or exists but has been **revoked** — it doesn't distinguish the two in the response body, so you can't tell which case you're in from the error alone. Check the proxy URL's `status` for that slug (it should be `active`), and double-check for typos in the slug itself.
**I revoked (or just created) a proxy URL, but the old/new behavior doesn't seem to take effect right away.**
Slug resolution is cached for 5 minutes to avoid a database round-trip on every call. A revoked slug can keep resolving from cache for up to 5 minutes after revocation, and a brand-new slug can take a moment to be picked up if it happens to collide with a recently-failed lookup. If you need a revocation to take effect immediately for something like a leaked key, treat the 5-minute window as part of your incident response time, not as instantaneous.
**A request to `/p/{slug}/message` returns 403 with `"agent is blocked"` even though my policy allows the call.**
Agent status (`active` / `blocked` / `quarantined`) is checked before policy evaluation and short-circuits it entirely — a blocked agent is rejected regardless of what any policy rule would have decided. Unblock the agent (see [Servers & Agents](/docs/guard-servers-agents#agent-status)) if the block was unintentional; otherwise this is working as designed.
**SSE connections through the proxy drop or buffer oddly.**
If you're running behind the bundled nginx, confirm you haven't overridden `proxy_buffering` or `proxy_read_timeout` on the `/p/` location — they're deliberately set to keep long-lived streamed connections open. If you're running your own reverse proxy in front of Guard, mirror those settings.
**Can I run the proxy in front of multiple MCP servers?**
Yes — register each one via the API, provision a proxy URL for each, and route each agent/client to that server's own slug-based path. A single Guard proxy deployment can front many MCP servers at once, and a single server can sit behind more than one proxy URL (for example, one per calling agent).
**My upstream MCP server requires auth, but calls through the proxy are getting rejected by it (not by Guard).**
That means the request made it past Guard's own policy check and the proxy tried to forward it, but the credentials it attached from `auth_config` were wrong or missing — a `502` with an upstream-error message is the signal to check `auth_type`/`auth_config` on the server record, not your Safeguard API key (which only authenticates you to the proxy itself, not to the upstream server).
## Related
* [Guard SDK](/docs/guard-sdk) — embed the same policy enforcement directly inside your MCP server or agent process instead of running a standalone proxy.
* [Guard Policies](/docs/guard-policies) — how policies are defined and what they can enforce.
* [Servers & Agents](/docs/guard-servers-agents) — how MCP servers and agents are registered, health-checked, and how agent status (block/quarantine) is managed.
* [Audit Trail & Alerts](/docs/guard-audit-alerts) — every allow/deny/monitor decision made by the proxy, including the proxy URL and agent it came through, and how to alert on it.
# Guard SDK (/docs/guard-sdk)
# Guard SDK
**Not available yet.** The Guard SDK is not published. There is no Guard SDK package for Python, TypeScript or Go on PyPI, npm or the Go module proxy.
Earlier revisions of this page gave install commands and code for SDK packages that were never published. Don't install a package that claims to be the Safeguard Guard SDK: Safeguard has not published one, so whoever did is not Safeguard.
The Guard SDK is a library for enforcing your organization's Guard policy inside your own MCP server or agent process: it keeps a copy of the policy you manage in Safeguard and checks each request against it before the request runs. This page will document installing and configuring it once it is published.
## Generate a secret key
The Guard SDK will authenticate with an organization secret key from **Settings → Developer**. Don't create one for it yet: until the SDK is published there is nothing to use the key with, and an unused credential is only risk. [RBAC & Teams](/docs/rbac-teams#managing-and-revoking-secret-keys) covers how secret keys are scoped and revoked.
## Tool-poisoning detection
Checking an MCP tool's own name and description for hidden instructions aimed at the calling agent (tool poisoning) is part of the Guard SDK, so it is not available yet either.
## FAQ & Troubleshooting
**Is there a Guard SDK package I can install?**
No. Nothing is published on PyPI, npm or the Go module proxy, so any package that claims to be the Safeguard Guard SDK did not come from Safeguard.
**I followed an older version of this page. What now?**
The install commands it gave fail, because those packages do not exist. If one ever succeeded, the package came from someone other than Safeguard: remove it, and review the machine the way you would after running any untrusted code.
**I need in-process enforcement now.**
Email [hi@safeguard.sh](mailto:hi@safeguard.sh) with your MCP server's language and how you run it.
## Related
* [Guard Policies](/docs/guard-policies): the allow, deny and monitor rules Guard evaluates.
* [Guard Proxy](/docs/guard-proxy): enforcing policy in front of MCP servers instead of inside them.
* [Audit Trail & Alerts](/docs/guard-audit-alerts): what Guard records for each request it evaluates.
* [RBAC & Teams](/docs/rbac-teams): organization secret keys and how they are revoked.
* [SDKs](/docs/sdks): Safeguard's language SDKs, also not published yet.
* [MCP Integrations](/docs/mcp): connect an AI assistant to Safeguard's hosted MCP server.
# Servers & Agents (/docs/guard-servers-agents)
# Servers & Agents
Guard enforces policy against traffic flowing between AI agents and MCP servers — but to do that precisely, it first needs to know which servers and agents actually exist in your environment. Guard keeps an inventory of both as first-class records: **MCP servers** (the tool-providing backends your agents call) and **agents** (the AI clients making those calls). This page covers why that inventory matters, how records get created, and how Guard learns about the tools a registered server exposes.
## Why Guard needs an inventory
Without a record of a server or agent, Guard has no name to target. Registering a server or agent gives Safeguard something concrete to reference elsewhere in the product:
* **Scoped policy.** Rules can be written against a specific server or agent rather than applying blindly to every request in the org. See [Guard Policies](/docs/guard-policies) for how targeting works once a server or agent exists.
* **Lifecycle control.** Agents can be individually blocked, unblocked, or quarantined (see [Agent status](#agent-status) below) — actions that only make sense once Guard has a durable record of the agent to act on.
* **Health and activity tracking.** Each server carries a health status, and each agent accumulates request counts, a risk score, and an anomaly score over time, all attached to that inventory record.
* **Audit context.** Alerts and audit trails reference servers and agents by their registered name and ID, rather than by raw upstream URLs or ephemeral connection details. See [Audit Trail & Alerts](/docs/guard-audit-alerts).
## Registering an MCP server
An MCP server is registered explicitly — there is currently no mechanism that scans your network or environment and creates server records automatically. You (or your integration) create the record via the API, supplying the server's identifying details: a name and description, its upstream URL, which transport it speaks, and how Guard should authenticate to it.
| Field | Notes |
| ---------------- | -------------------------------------------------------------------------------------------------------------- |
| **Name** | A human-readable identifier for the server. |
| **Description** | Optional free-text context. |
| **Upstream URL** | The address Guard calls to reach the server — used both for tool discovery and health checks. |
| **Transport** | `sse` or `http`. |
| **Auth type** | `none`, `bearer`, `basic`, or `api_key`. |
| **Auth config** | Credentials/config matching the chosen auth type. |
| **Status** | `active`, `inactive`, or `error` — controls whether the server is included in scheduled discovery (see below). |
Once created, a server also carries a **health status** (`healthy`, `unhealthy`, or `unknown`) and a timestamp of the last health check, both maintained by Guard rather than set by you directly.
> **New servers always start as `active` with health status `unknown`.** Whatever value you send for `status` on the create request is ignored — Guard forces every newly created server to `active` (and `health_status` to `unknown`), the same way agent creation forces `active` (see [Registering an agent](#registering-an-agent) below). If you need a server excluded from scheduled discovery and health checks right away, create it and then follow up with a `PUT` to set `status: "inactive"` — unlike create, update does respect whatever `status` you send.
### `auth_config` by auth type
The keys Guard reads out of `auth_config` when it calls the server depend on `auth_type`:
| `auth_type` | Expected `auth_config` keys | Sent upstream as |
| ----------- | --------------------------- | --------------------------------------------------------------- |
| `none` | — | No `Authorization` header. |
| `bearer` | `token` | `Authorization: Bearer ` |
| `basic` | `username`, `password` | HTTP Basic auth |
| `api_key` | `key`, `header` (optional) | `: ` — `header` defaults to `X-API-Key` if omitted |
### Example: register a server
```bash
curl -X POST https:///api/v1/servers \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
-d '{
"name": "billing-mcp",
"description": "Internal billing tools server",
"upstream_url": "https://internal-mcp.example.com",
"transport": "http",
"auth_type": "bearer",
"auth_config": { "token": "upstream-service-token" }
}'
```
Guard responds `201 Created` with the full record, including the fields it fills in itself:
```json
{
"id": "5b6b1e3a-2f36-4b8b-9b8a-6f2a2c9e6b41",
"org_id": "a3d2f9c1-...",
"name": "billing-mcp",
"description": "Internal billing tools server",
"upstream_url": "https://internal-mcp.example.com",
"transport": "http",
"auth_type": "bearer",
"auth_config": { "token": "upstream-service-token" },
"status": "active",
"health_status": "unknown",
"last_health_at": null,
"created_at": "2026-07-07T00:00:00Z",
"updated_at": "2026-07-07T00:00:00Z"
}
```
Servers support full CRUD: list (`GET /api/v1/servers`), fetch by ID (`GET /api/v1/servers/{id}`), update (`PUT /api/v1/servers/{id}`), or delete (`DELETE /api/v1/servers/{id}`) — for example, to rotate credentials or change the upstream URL.
> **`PUT` replaces the whole record — it isn't a partial patch.** The request body is decoded straight into the server's fields and written back as-is, so a `PUT` containing only `{"name": "new-name"}` overwrites every other field (including `upstream_url` and `auth_config`) with empty values. `GET` the current record first, change only what you need in that object, and send the complete object back.
> Deleting a server removes its inventory record. Make sure no policy still depends on targeting that server before deleting it, and expect prior audit history to continue referencing the server's ID even after removal.
## Registering an agent
Agents are also registered explicitly, by supplying a name and description. There's no equivalent of server tool-discovery for agents — Guard does not automatically detect new agents on the network; an agent record must be created before Guard can associate activity, risk scoring, or lifecycle actions with it.
When an agent is created, Guard always sets its status to **active**, regardless of what status value (if any) is supplied in the request. From there, an agent accumulates:
| Field | Notes |
| ------------------------------------- | ---------------------------------------------- |
| **Status** | `active`, `blocked`, or `quarantined`. |
| **Risk score** | A running score maintained by Guard. |
| **Anomaly score** | A running score maintained by Guard. |
| **Total requests / Blocked requests** | Counters maintained by Guard. |
| **Last seen at** | Timestamp of the agent's most recent activity. |
| **Metadata** | Free-form key/value data. |
### Example: register an agent
```bash
curl -X POST https:///api/v1/agents \
-H "Authorization: Bearer " \
-H "Content-Type: application/json" \
-d '{
"name": "checkout-assistant",
"description": "Customer-facing checkout agent",
"metadata": { "team": "commerce", "env": "prod" }
}'
```
```json
{
"id": "9e1c2a4d-8f21-4a3e-9b2f-3e5d7c1a9b02",
"org_id": "a3d2f9c1-...",
"name": "checkout-assistant",
"description": "Customer-facing checkout agent",
"status": "active",
"risk_score": 0,
"anomaly_score": 0,
"total_requests": 0,
"blocked_requests": 0,
"last_seen_at": null,
"metadata": { "team": "commerce", "env": "prod" },
"created_at": "2026-07-07T00:00:00Z",
"updated_at": "2026-07-07T00:00:00Z"
}
```
Sending `"status": "blocked"` in that same request body has no effect — the response still comes back with `"status": "active"`.
### Agent status
Agent status is changed through dedicated lifecycle actions rather than a general update endpoint:
* **Block** — `POST /api/v1/agents/{id}/block` — sets the agent's status to `blocked`.
* **Unblock** — `POST /api/v1/agents/{id}/unblock` — sets the agent's status back to `active`.
* **Quarantine** — `POST /api/v1/agents/{id}/quarantine` — sets the agent's status to `quarantined`.
Each takes no request body and returns the new status:
```bash
curl -X POST https:///api/v1/agents/9e1c2a4d-8f21-4a3e-9b2f-3e5d7c1a9b02/block \
-H "Authorization: Bearer "
```
```json
{ "status": "blocked" }
```
Agents can also be listed (`GET /api/v1/agents`), fetched individually (`GET /api/v1/agents/{id}`), and deleted (`DELETE /api/v1/agents/{id}`).
> Blocking or quarantining an agent is a status change on the agent's inventory record itself — it's a different mechanism from writing a policy rule that targets the agent. Use lifecycle actions for an immediate, direct response to a specific agent; use policy for standing rules. See [Guard Policies](/docs/guard-policies).
> For a live, per-request history of an agent's risk, jailbreak, and anomaly scores — rather than the single running numbers on the agent record — query the audit trail filtered by that agent's ID. See [Audit Trail & Alerts](/docs/guard-audit-alerts).
## How discovery works
"Discovery" in Guard refers specifically to **tool discovery for a server that is already registered** — Guard does not discover and auto-create new server or agent inventory records on its own.
Once a server exists and is reachable, Guard queries it for the tools it exposes:
1. Guard sends a JSON-RPC `tools/list` request to the server's upstream URL:
```json
{ "jsonrpc": "2.0", "method": "tools/list", "id": 1 }
```
2. The server responds with its available tools, each with a name, description, and input schema:
```json
{
"result": {
"tools": [
{
"name": "get_invoice",
"description": "Fetch an invoice by ID",
"inputSchema": { "type": "object", "properties": { "invoice_id": { "type": "string" } } }
}
]
}
}
```
3. Guard upserts those tools into its own store, associated with that server's ID and your org.
This runs automatically, on a schedule: a background worker process iterates over active servers and re-runs discovery for each on a fixed interval — 5 minutes by default (`DISCOVERY_INTERVAL`), configurable per deployment — running once immediately when the worker starts and then repeating. **There is currently no API call to trigger a one-off discovery run for a single server on demand.** If a server's tool list needs to be refreshed sooner than the next scheduled pass, the practical options are waiting for the interval to elapse or, for self-hosted deployments, lowering `DISCOVERY_INTERVAL`.
Separately, the same background worker periodically checks each server's reachability on its own interval — 1 minute by default (`HEALTH_CHECK_INTERVAL`) — with a plain HTTP request to the server's upstream URL, and records the result as `health_status`: `healthy` if the request succeeds with a non-5xx response, `unhealthy` if the request fails outright or the server responds with a 5xx. This health check is about whether the server is up, not about discovering new servers or tools, and it runs independently of tool discovery.
> Tool discovery only runs for servers with `active` status, and requires the server to be reachable at its configured upstream URL. If a server was just registered, just switched to `active`, or its upstream URL just changed, its tool list may be stale for up to one discovery interval until the next scheduled pass completes.
## FAQ & Troubleshooting
**Does Guard automatically find MCP servers running in my environment?**
No. Server records are created explicitly, with their upstream URL and connection details. What Guard automates is discovering the *tools* a server exposes, once that server is registered.
**Does Guard automatically find agents talking to my servers?**
Not from these inventory endpoints — agents are created explicitly. Guard doesn't currently create agent records on its own.
**Why did a newly created agent come back as `active` even though I sent a different status?**
Agent creation always forces status to `active`; any status field in the create request is ignored. Use the block/unblock/quarantine actions to change it afterward.
**I registered a server with `"status": "inactive"`, but it came back `active`.**
Creating a server always forces `status` to `active` and `health_status` to `unknown` — the same way agent creation forces `active` — so any `status` you send on create is ignored. `PUT`, unlike `POST`, does respect whatever `status` you send: set it to `inactive` in a follow-up update if you need the server excluded from scheduled discovery and health checks right away.
**I sent a `PUT` with only the one field I wanted to change, and the rest of the server's config got wiped.**
`PUT /api/v1/servers/{id}` replaces the whole record — it isn't a partial patch. Fields you omit from the request body are written back as empty. `GET` the current server first, change only what you need in that object, and send the complete object back in the `PUT`.
**My server's tool list looks out of date. What's happening?**
Tool discovery only runs for servers with `active` status, on a fixed background schedule (5 minutes by default) rather than instantly on every change — there's no on-demand "discover now" call today. If a server is `inactive` or `error`, it's skipped entirely until you set it back to `active`.
**Can I target a policy at one server or agent instead of all of them?**
Yes — that's the main reason to register servers and agents individually rather than relying on org-wide defaults. See [Guard Policies](/docs/guard-policies) for how targeting is configured.
## Related
* [Guard Policies](/docs/guard-policies) — write rules that target specific servers or agents.
* [Audit Trail & Alerts](/docs/guard-audit-alerts) — see activity and alerts tied to a server or agent's inventory record.
* [Guard SDK](/docs/guard-sdk) — embed policy enforcement directly inside an MCP server or agent process.
* [Guard Proxy](/docs/guard-proxy) — run Guard in front of MCP servers you don't control the code of, using the same server-registration API described on this page.
# Guard Webhooks (/docs/guard-webhooks)
# Guard Webhooks
Guard has its own, dedicated webhook system, separate from the general-purpose [Webhooks & Events](/docs/webhooks-events) pipeline that covers findings, scans, remediation, and the rest of the Safeguard platform. If you're building an integration that only cares about Guard — policy enforcement signals, jailbreak/anomaly scoring, or server reachability — register a Guard webhook directly rather than filtering the general event stream for Guard-related events.
> Guard webhooks and the platform-wide webhooks described in [Webhooks & Events](/docs/webhooks-events) are two different systems with different signature schemes, retry schedules, and event catalogs. Don't assume the two are interchangeable, and don't reuse verification code written for one against the other — see [How this differs from the general webhook system](#how-this-differs-from-the-general-webhook-system) below.
## What triggers a Guard webhook
Guard webhooks fire when an **alert rule** matches. Alert rules watch live signals coming off your MCP servers and agents as Guard analyzes traffic, including:
| Signal | What it reflects |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Jailbreak score | How strongly a request resembles a jailbreak / prompt-injection attempt. This is a per-request signal, distinct from the separate, on-demand [tool-poisoning detection](/docs/guard-sdk#tool-poisoning-detection) check, which analyzes a tool's own definition rather than request content. |
| Anomaly score | How unusual a request looks relative to a server or agent's normal behavior. |
| Blocked-request ratio | The share of recent requests your policy has blocked outright — a spike here usually means a policy is actively stopping something, or a client is misbehaving. |
| Server reachability | Whether an MCP server Guard monitors has gone unreachable. |
| Risk score | Guard's overall risk assessment of a request. This is the signal behind an alert rule whose `trigger_type` is `rate_limit` — despite the name, that rule type compares risk score against a threshold, not a raw request count. Don't confuse it with the `rate_limit` throttle you can attach to a policy rule (see [Guard Policies](/docs/guard-policies#actions)); the two are unrelated settings that happen to share a name. |
When one of these crosses the threshold configured on an alert rule, Guard fires the rule, and that firing is what dispatches the webhook. In other words, Guard webhooks don't have separate event types for "policy block" or "tool poisoning" — those conditions feed into the scoring above, and it's the resulting **alert** that reaches your endpoint. For how to define thresholds, severities, and which signals map to which rules, see [Audit Trail & Alerts](/docs/guard-audit-alerts).
Every Guard webhook you register subscribes to one or more event names from its `events` list, or to `*` to receive everything. Today, alert firings are published under a single event name:
| Event | When |
| ----------------- | ----------------------------------------------------------------------------- |
| `alert.triggered` | An alert rule's threshold condition is met for a server or agent in your org. |
## Registering an endpoint
Guard webhooks are configured per organization from your Safeguard workspace, alongside your [Guard policies](/docs/guard-policies) and alert rules. Each registered webhook has:
| Field | Description |
| ---------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | A label to help you tell endpoints apart. |
| **URL** | Where Guard sends the signed POST request. |
| **Secret** | Used to sign every delivery to this endpoint via HMAC — see [Verifying deliveries](#verifying-deliveries). |
| **Events** | Which event names this endpoint receives (currently `alert.triggered`, or `*` for all Guard events). |
| **Active** | Whether the endpoint currently receives deliveries. Deactivate an endpoint instead of deleting it if you want to pause delivery temporarily. |
Each webhook record also has `last_delivered_at` and `failure_count` fields. A registered webhook, with its secret omitted, looks like this:
```json
{
"id": "b6e1c2b0-3e4a-4f1b-9c2d-1a2b3c4d5e6f",
"org_id": "3fa0e6d2-2c1a-4b9b-9a2e-8e0c1d6f7a90",
"name": "PagerDuty bridge",
"url": "https://example.com/hooks/guard",
"events": ["alert.triggered"],
"is_active": true,
"last_delivered_at": null,
"failure_count": 0,
"created_at": "2026-06-01T12:00:00Z",
"updated_at": "2026-06-01T12:00:00Z"
}
```
The secret is deliberately not one of those fields. Like other write-only credentials in Safeguard, it's set (or reset) when you create or rotate the webhook, but it's never shown back to you afterward — not in the dashboard, not in any export. If you lose track of it, rotate the secret and update your verification code, rather than trying to retrieve the old value.
> Rotate a webhook's secret if you suspect it's leaked. Because the secret is used to sign every payload, an old secret left in place after rotation will simply stop validating — there's no grace period, so update your verification code and the value stored in Safeguard at the same time.
## What gets delivered
Each delivery is a JSON body describing the event, plus the alert itself:
```json
{
"event": "alert.triggered",
"data": {
"id": "b6e1c2b0-3e4a-4f1b-9c2d-1a2b3c4d5e6f",
"org_id": "3fa0e6d2-2c1a-4b9b-9a2e-8e0c1d6f7a90",
"rule": {
"id": "2f8a1c3d-...",
"name": "Jailbreak score spike",
"trigger_type": "jailbreak_score",
"threshold": 0.8,
"window_seconds": 300,
"severity": "high",
"is_active": true
},
"severity": "high",
"message": "Jailbreak score 0.91 exceeded threshold 0.80",
"triggered_at": "2026-07-07T14:02:31Z"
}
}
```
* **`event`** is the event name — `alert.triggered` today.
* **`data`** is the triggered alert: its `id`, the full `rule` object that matched (the same shape described in [Audit Trail & Alerts](/docs/guard-audit-alerts#alert-rules)), a top-level `severity` and human-readable `message`, and `triggered_at`.
> The alert model has a `context` field reserved for per-request detail like the matching `agent_id` or `server_id`, but it isn't populated on `alert.triggered` deliveries today — don't build parsing logic that expects it to be present, and don't assume it can be joined back to a specific audit event by ID. For score- and ratio-based alerts (`jailbreak_score`, `anomaly_score`, `blocked_ratio`, `rate_limit`), the closest you can get is using the alert's `triggered_at` timestamp and severity to narrow down the relevant window in [Audit Trail & Alerts](/docs/guard-audit-alerts) — an approximate correlation by time and signal, not an exact key. For `server_down` alerts there's no single underlying request to look up at all; the reachability check runs independently of request traffic.
**What counts as a successful delivery.** Guard treats any HTTP response with a status code below `400` as delivered — 2xx and 3xx both count, so redirecting or returning `202 Accepted` from an async handler is fine. Each attempt has a 15-second timeout; a slow response counts the same as a `5xx` or a connection error. If your handler does real work before responding (calling out to PagerDuty, writing to a queue, etc.), acknowledge the webhook first and do that work asynchronously so a slow downstream dependency doesn't turn a successful delivery into a retried one.
**Retries.** A failed attempt is retried up to three more times, with increasing delay between attempts — 1 second, 5 seconds, then 30 seconds — for four attempts total (the original plus three retries). If the last retry also fails, Guard gives up on that delivery; it does not queue the event for hours or days the way the general-purpose webhook system does. Because each attempt resends the identical payload, treat `data.id` as an idempotency key on your end if you can't tell from your own side whether a prior attempt was actually processed before it appeared to fail.
If you have more than one active webhook subscribed to an event, Guard notifies all of them concurrently and independently — one endpoint being slow or down has no effect on delivery (or retries) to your other endpoints.
If your endpoint needs a durable record of every alert regardless of delivery outcome, treat [Audit Trail & Alerts](/docs/guard-audit-alerts) as the source of truth and your webhook as a low-latency notification on top of it.
## Verifying deliveries
Every Guard webhook request carries three headers:
| Header | Value |
| ----------------------- | ---------------------------------------------------------------------------------- |
| `X-Safeguard-Event` | The event name, e.g. `alert.triggered`. |
| `X-Safeguard-Timestamp` | Unix timestamp (seconds) at the time of signing. |
| `X-Safeguard-Signature` | `sha256=`, computed as `HMAC-SHA256(secret, "." + raw_body)`. |
Verify the signature by recomputing the HMAC over the timestamp and raw request body, and compare it to the header using a constant-time comparison:
```python
import hmac, hashlib
def verify(secret: str, timestamp: str, signature: str, body: bytes) -> bool:
mac = hmac.new(secret.encode(), timestamp.encode() + b"." + body, hashlib.sha256)
expected = "sha256=" + mac.hexdigest()
return hmac.compare_digest(expected, signature)
```
```typescript
import { createHmac, timingSafeEqual } from "crypto";
export function verify(secret: string, timestamp: string, signature: string, body: Buffer): boolean {
const mac = createHmac("sha256", secret).update(`${timestamp}.`).update(body).digest("hex");
const expected = `sha256=${mac}`;
return timingSafeEqual(Buffer.from(expected), Buffer.from(signature));
}
```
> Always verify against the **raw** request body, before any JSON parsing or re-serialization — re-encoding the payload can change byte-for-byte formatting (key order, whitespace) and cause a correctly-signed request to fail verification.
### Testing your verification code without waiting for a real alert
There's no synthetic "send a test event" action for Guard webhooks the way there is for the general-purpose [webhooks system](/docs/webhooks-events#testing). To exercise your endpoint before a real alert rule fires, sign a sample payload yourself with the same construction Guard uses and send it with `curl`:
```bash
BODY='{"event":"alert.triggered","data":{"id":"test","message":"test alert","severity":"low"}}'
TS=$(date +%s)
SECRET=""
SIG="sha256=$(printf '%s.%s' "$TS" "$BODY" | openssl dgst -sha256 -hmac "$SECRET" | sed 's/^.* //')"
curl -i -X POST https://your-endpoint.example.com/guard-webhook \
-H "Content-Type: application/json" \
-H "X-Safeguard-Event: alert.triggered" \
-H "X-Safeguard-Timestamp: $TS" \
-H "X-Safeguard-Signature: $SIG" \
-d "$BODY"
```
A `test` payload built this way isn't distinguishable from a real one by any field Guard adds — it's a signed request that happens to carry data you made up — so treat it as a way to validate your signature check and response handling, not as evidence a real alert rule works end to end. To confirm the whole path, including rule evaluation, trigger a real alert rule instead (for example, by sending a request that you know will exceed a low `jailbreak_score` or `blocked_ratio` threshold on a test rule).
## How this differs from the general webhook system
If you already integrated with the platform-wide [Webhooks & Events](/docs/webhooks-events) system, note the differences before reusing that code for Guard:
| | Guard Webhooks | Webhooks & Events (general) |
| ------------------------------ | ------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------- |
| Signature header | `X-Safeguard-Signature: sha256=` plus a separate `X-Safeguard-Timestamp` header | Single `X-Safeguard-Signature: v1,t=,s=` header |
| Event scope | Guard alert firings only | Findings, scans, remediation, attestations, workflows, policy, assets, vendors, audit |
| Retries | 4 attempts total: the original send plus retries at 1s, 5s, and 30s, then abandoned | Exponential backoff over 11 attempts across 24 hours, with a dead-letter queue |
| Event catalog | Currently one event name, `alert.triggered` (or `*`) | Many namespaced events (`..`) |
| Per-request detail (`context`) | Not populated today — correlate against [Audit Trail & Alerts](/docs/guard-audit-alerts) instead | Full `data` object scoped to the event (finding, asset, workflow run, etc.) |
If you need both platform-wide events and Guard alerts in one place, register endpoints in both systems rather than assuming one covers the other.
## FAQ & Troubleshooting
**My endpoint isn't receiving any deliveries.**
Confirm the webhook is marked active, and that its `events` list includes `alert.triggered` (or `*`). Then confirm at least one alert rule is configured and would actually match the traffic you expect — a webhook with no matching alert rule never fires. See [Audit Trail & Alerts](/docs/guard-audit-alerts) for rule configuration.
**Signature verification keeps failing.**
Make sure you're signing the raw request body exactly as received (no re-serialization), and that you're concatenating the timestamp header, a literal `.`, and the body — in that order — before computing the HMAC. Also confirm you're using the current secret; a rotated secret invalidates verification immediately with no grace period.
**Can I subscribe to policy blocks directly, without going through alerts?**
Not as a distinct event type today — a spike in blocked requests is exposed through the blocked-ratio signal on an alert rule, so configure a rule against that threshold if you want a webhook to fire on it.
**Is delivery guaranteed?**
No — like most webhook systems, delivery is best-effort with a small number of retries. Don't rely on a Guard webhook as your only record of an alert; use it as a low-latency trigger and treat [Audit Trail & Alerts](/docs/guard-audit-alerts) as the durable log.
**My payload's `data` object doesn't have a `context` key — where did the agent/server detail go?**
`context` is reserved in the underlying alert model but isn't populated on deliveries today, so it's simply absent from the JSON rather than present-but-empty. For score- and ratio-based alerts, the alert's `triggered_at` and severity can narrow down a time window to check in [Audit Trail & Alerts](/docs/guard-audit-alerts), which does carry `agent_id`, `server_id`, and per-request scores — but that's an approximate correlation by time, not a direct join, since the alert itself doesn't reference a specific audit event ID. `server_down` alerts aren't tied to a single request at all.
**My endpoint returns `200` eventually, but Guard still logged a failed/retried delivery.**
Each delivery attempt times out after 15 seconds. If your handler does synchronous work — calling a downstream API, writing to a database — before responding, a slow dependency can push you past that window even though you would have eventually returned success. Acknowledge the webhook immediately with a `2xx`/`3xx` response and do the slow work after you respond (a queue, a background job, etc.).
**Is the `rate_limit` alert trigger the same thing as the `rate_limit` setting on a policy rule?**
No, despite sharing a name. A policy rule's `rate_limit` (see [Guard Policies](/docs/guard-policies#actions)) is a request-count throttle — a limit and a time window — that's part of request enforcement. An alert rule with `trigger_type: rate_limit` is unrelated: it compares a request's overall risk score against a threshold. Don't assume configuring one affects the other.
**I got the same alert delivered twice — is that a bug?**
Not necessarily. If your endpoint processed a delivery but didn't respond quickly enough (or returned a non-2xx status), Guard has no way to know the work already happened and will retry with the identical payload. Dedupe on `data.id` if repeated processing of the same alert would cause problems on your end.
## Related
* [Audit Trail & Alerts](/docs/guard-audit-alerts) — configure the alert rules and thresholds that trigger Guard webhooks, and look up the request-level detail behind an alert.
* [Guard Policies](/docs/guard-policies) — the policies whose enforcement outcomes feed Guard's blocked-ratio and scoring signals.
* [Servers & Agents](/docs/guard-servers-agents) — the server and agent inventory that audit events (and, indirectly, alerts) are scoped to.
* [Webhooks & Events](/docs/webhooks-events) — the general-purpose, platform-wide webhook and event system.
# Guardrails & Enforcement (/docs/guardrails-enforcement)
# Guardrails & Enforcement
A guardrail is a rule that Safeguard enforces on your behalf. Unlike a scanner that only reports, a guardrail blocks, gates, or auto-remediates — at the moment a risk appears in your pipeline.
## Enforcement Points
Guardrails can be enforced at six points in the software lifecycle:
| Point | What's enforced | Mechanism |
| ------------- | --------------------------------------------------------------------- | ------------------------------------------------------------ |
| **IDE** | Pre-commit checks for vulnerable packages, secrets, insecure patterns | Safeguard IDE extension |
| **Commit** | Server-side checks via API / webhook before merge | GitHub / GitLab checks API |
| **CI** | Gate on SBOM, license, CVE, signing, SLSA level | Platform policy gates on the scans of connected repositories |
| **Registry** | Block pushes that violate policy | Registry webhook + Notation/Cosign policy |
| **Admission** | Block Kubernetes deployments of non-compliant images | Admission controller (Kyverno / Sigstore policy-controller) |
| **Runtime** | Detect drift from approved baseline | eBPF runtime collector |
Every guardrail produces a signed audit record. Auditors can replay any enforcement decision.
## The Policy Language
Guardrails are defined in YAML. Each policy has a target (what it applies to), one or more rules, and an effect.
```yaml
apiVersion: safeguard.sh/v1
kind: Policy
metadata:
name: block-critical-cves-in-prod
spec:
targets:
- kind: Image
labels:
env: production
rules:
- id: no-known-exploited-critical
description: Block production images containing KEV-listed CVEs.
condition: |
any(
vulnerabilities,
severity == "critical" AND kev == true
)
effect: BLOCK
exception:
allowed: false
approvers: ["security-leads@company.com"]
- id: requires-sbom-attestation
condition: attestations.sbom == null
effect: BLOCK
- id: requires-slsa-l3
condition: slsa.level < 3
effect: WARN
```
Rules evaluate against a document that combines SBOM, vulnerability, license, signature, provenance, and reachability data. Effects are `BLOCK`, `WARN`, or `AUTO_FIX`.
## Built-In Guardrails
Safeguard ships with curated guardrails you can enable with one click:
* **KEV in production** — block images with any CVE on CISA's Known Exploited Vulnerability list.
* **EO 14028 SBOM required** — require a CycloneDX SBOM attestation signed in the last 90 days.
* **SLSA level 3 provenance** — require a Sigstore-verifiable provenance attestation.
* **License allow-list** — block deployment of any component with a non-allow-listed license.
* **Abandoned package** — block deployment of any package with zero commits in 365 days and a CVE open > 180 days.
* **Unsigned container** — block pods pulling images without a valid Cosign or Notation signature.
* **Typosquat detected** — block any package whose name is within edit-distance 2 of a top-1000 package but not owned by the expected publisher.
* **AI model provenance** — block loading model weights that do not have a signed model card.
## Auto-Fix Guardrails
With Griffin AI integrated, certain guardrails can auto-remediate instead of blocking.
Example: a CI guardrail detects that a dependency upgrade introduces a CVE. Instead of failing the build, Griffin opens a PR that pins the dependency to the last safe version, updates the lockfile, and re-runs tests.
Auto-fix guardrails require a pre-approved scope (which repos, which package ecosystems, which severity bands). See [Auto-Fix](/docs/esscm/auto-fix).
## Exceptions and Breakglass
Every blocking guardrail supports time-boxed exceptions:
* An approver with the right role can grant an exception for a specific asset for a specific duration.
* Exceptions appear in the audit log and expire automatically.
* Emergency breakglass exceptions require two-person approval and trigger alerts in the security channel.
## Enforcement at Admission
**Not available yet.** The Kubernetes admission controller is not published: Safeguard has no Helm chart repository, so there is nothing to install. Earlier revisions of this page showed a `helm install` command for a chart that does not exist. Don't install a chart that claims to be Safeguard's admission controller.
The admission controller is designed to validate every pod spec against the image policy:
1. Resolve the image digest.
2. Fetch SBOM and signature from the registry or Safeguard Portal.
3. Evaluate applicable policies.
4. Admit, warn, or deny.
## CI Gate
Gates are evaluated by the platform on the scans it runs for your connected
repositories, not by a command in your pipeline. The CLI has no `gate`
command, and `safeguard scan` reports findings without failing the build on
them. See [CI/CD Integration](/docs/cicd-integration) for what a pipeline can
run today.
## Procurement Guardrails
TPRM extends guardrails to vendor intake:
* Require a signed SBOM from the vendor before contract signing.
* Block vendors whose SBOMs contain components with active critical CVEs.
* Require attestation of NIST SSDF practices for vendors handling regulated data.
See [TPRM](/docs/tprm) for procurement-specific policies.
## Observability
Every guardrail decision is:
* Logged to the Safeguard audit stream.
* Emitted as OpenTelemetry span for SIEM ingestion.
* Counted in the **Enforcement** dashboard (allow/warn/block trends by policy, team, asset class).
Use this to measure guardrail health — a policy that fires a BLOCK thousands of times per week probably needs either auto-fix or a policy refinement.
## Related
* [Policies and Gates](/docs/esscm/policies-gates) — UI for creating and managing policies.
* [Auto-Fix](/docs/esscm/auto-fix) — Griffin AI auto-remediation capabilities.
* [CI/CD Integration](/docs/cicd-integration) — adding the gate to pipelines.
* [Attestation](/docs/esscm/attestation) — signed evidence that guardrails consume.
# IDE Support (/docs/ide-support)
# IDE Support
Safeguard ships an IDE extension for VS Code and Cursor, and a separate plugin for JetBrains IDEs. Both scan your dependency manifests as you work, surface vulnerabilities inline, and offer AI-assisted fixes without leaving the editor. They're independently built and versioned, so feature coverage differs slightly between the two — this page calls out where.
## Supported IDEs
| IDE | Distribution | Current version |
| ------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| **VS Code** | [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=Safeguard-sh-Inc.SafeguardshIdeExtension) | (requires VS Code ^1.85.0) |
| **Cursor** | [Open VSX Registry](https://open-vsx.org/extension/Safeguard-sh-Inc/SafeguardshIdeExtension) — same extension package as VS Code | |
| **JetBrains IDEs** (IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, Rider, GoLand, RubyMine, CLion, DataGrip, Android Studio) | [JetBrains Marketplace](https://plugins.jetbrains.com/plugin/com.safeguard.intellij) | , requires IDE 2023.3 or later and JDK 17+ |
> The VS Code/Cursor extension and the JetBrains plugin are separate codebases with independent release cadences and version numbers — a version bump on one doesn't imply anything about the other.
## Installation
### VS Code
```bash
code --install-extension Safeguard-sh-Inc.SafeguardshIdeExtension
```
Or open **Extensions** (`Ctrl+Shift+X` / `Cmd+Shift+X`), search **"Safeguard"**, and click **Install**.
### Cursor
Cursor installs through Open VSX rather than the VS Code Marketplace:
```bash
cursor --install-extension Safeguard-sh-Inc.SafeguardshIdeExtension
```
Or open **Extensions** in Cursor, search **"Safeguard"**, and click **Install**.
### JetBrains IDEs
1. Open **Settings/Preferences → Plugins**.
2. Search **"Safeguard"** and click **Install**.
3. Restart the IDE.
You can also download the plugin ZIP from the JetBrains Marketplace page and install it via the gear icon → **Install Plugin from Disk**.
## Authentication
Both the extension and the plugin authenticate with **OAuth 2.0 device flow** — there's no manual tenant ID entry required.
1. Run **Safeguard: Login** (Command Palette in VS Code/Cursor, or **Tools → Safeguard → Login** in JetBrains).
2. A browser tab opens at `app.safeguard.sh/activate` showing a verification code.
3. Sign in and approve the device.
4. Return to the IDE — your tenant ID is populated automatically and tokens are stored in the IDE's secure/encrypted credential storage.
Device codes expire after a fixed window (10 minutes per the extension's own documentation) — if authentication times out, just re-run **Safeguard: Login**. Public-package scanning works without logging in; some backend-dependent features require it — backend-verified Package Firewall verdicts (`safeguard.packageFirewallUseBackend`) and backend-sourced notifications (`safeguard.surfaceBackendNotifications`) are silently disabled or fall back to local/offline behavior when you aren't logged in.
The activation link carries the device code and IDE type as query parameters, for example:
```
https://app.safeguard.sh/activate?device_code=abc123&user_code=WXYZ&ide_type=vscode
```
You can copy this URL out of the login notification and open it on another machine or browser profile if the one the IDE launched isn't where you're signed in — approving it there completes authentication back in the original IDE. You can also be logged in on multiple IDE instances or devices at once: each holds its own token, so logging out of one doesn't affect the others.
Run **Safeguard: Logout** (or **Tools → Safeguard → Logout** in JetBrains) to clear stored credentials from the IDE's secure storage.
## Supported package managers
Both the VS Code/Cursor extension and the JetBrains plugin scan the same manifest families:
| Ecosystem | Package manager | Manifest files |
| ------------------ | ------------------- | ------------------------------------------------ |
| JavaScript/Node.js | npm, Yarn, pnpm | `package.json`, `package-lock.json`, `yarn.lock` |
| Python | pip, Poetry, Pipenv | `requirements.txt`, `pyproject.toml`, `Pipfile` |
| Java/JVM | Maven, Gradle | `pom.xml`, `build.gradle`, `build.gradle.kts` |
| Go | Go Modules | `go.mod`, `go.sum` |
| Rust | Cargo | `Cargo.toml`, `Cargo.lock` |
| Ruby | Bundler | `Gemfile`, `Gemfile.lock` |
In VS Code/Cursor, the presence of any of `package.json`, `requirements.txt`, `pom.xml`, `go.mod`, `Cargo.toml`, or `Gemfile` in your workspace activates the extension automatically.
## Manual scanning
Both `autoScan` and `scanOnSave` default to on, but you can trigger a scan on demand:
* **VS Code/Cursor:** open the Command Palette (`Ctrl+Shift+P` / `Cmd+Shift+P`) and run **Safeguard: Scan Project for Vulnerabilities** (`Ctrl+Shift+V` / `Cmd+Shift+V`) for the whole workspace, **Safeguard: Scan Current File** for the open manifest, or **Safeguard: Scan Selected Code for Vulnerabilities** for a highlighted block.
* **JetBrains:** right-click a manifest file in the project tree and choose **Safeguard → Scan File for Vulnerabilities**, or use **Tools → Safeguard → Scan Project** for the whole project.
## Viewing scan results
* **VS Code/Cursor:** open the **Safeguard** view from the activity bar for the Vulnerabilities, SBOM, Compliance, and Recommendations panels, or hover a flagged dependency inline for a quick summary and lightbulb fix. Right-click any panel and choose **Export Report** to save findings for an audit.
* **JetBrains:** open the **Safeguard** tool window (bottom panel) for a hierarchical vulnerability tree — expand a package to see its individual CVEs, and double-click one for full CVSS/CWE details. Vulnerable lines are also highlighted inline, color-coded by severity (red/critical, orange/high, yellow/medium, blue/low); hovering one shows a quick summary.
## Package Firewall inline checks (VS Code / Cursor)
As you edit a manifest file, the extension checks each dependency you add against Safeguard's Package Firewall and flags anything that would be warned on or blocked — before you ever run install. This is a lighter-weight, editor-native companion to the install-time proxy described in [Package Firewall](/docs/package-firewall); it evaluates the package name as you type it rather than intercepting a real install.
It catches three things:
* **Typosquats** — a name one or two edits away from a popular package (for example `expres` instead of `express`) triggers a "did you mean…" suggestion.
* **Dependency / namespace confusion** — a scoped package that shadows a popular unscoped name under an unrecognized scope is flagged.
* **Known-malicious packages** — names matching documented malicious packages are blocked inline.
Flags appear as `⛔`/`⚠` badges next to the dependency line, with a hover card and a full verdict in the details panel — the same annotation surface used for vulnerability findings.
Two settings control it:
| Setting | Default | Effect |
| ------------------------------------- | ------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| `safeguard.enablePackageFirewall` | `true` | Turns inline Package Firewall checks on or off. |
| `safeguard.packageFirewallUseBackend` | `false` | When enabled, queries Safeguard's backend for verdicts (requires login). When disabled, an offline local heuristic runs entirely client-side. |
> This feature is documented for the VS Code/Cursor extension only. The JetBrains plugin's published documentation does not mention inline Package Firewall checks.
To require backend-verified verdicts (rather than the offline heuristic) for every dependency you add, set this in `settings.json`:
```json
{
"safeguard.enablePackageFirewall": true,
"safeguard.packageFirewallUseBackend": true
}
```
Note that `packageFirewallUseBackend` requires you to be logged in — see [Authentication](#authentication).
## AI-powered remediation
Both the extension and the plugin generate fix suggestions via one of three remediation strategies, set with `safeguard.remediationStrategy` (VS Code/Cursor) or the equivalent picker in the JetBrains quick-fix flow:
| Strategy | Behavior |
| ---------------------- | ------------------------------------------------------ |
| **Safe** | Minor version updates only — minimal risk of breakage. |
| **Balanced** (default) | Minor and patch updates. |
| **Aggressive** | Updates to the latest available version. |
* **VS Code/Cursor:** hover a flagged dependency, open the lightbulb menu (`Ctrl+.` / `Cmd+.`), and choose a suggested fix, or run **Safeguard: Auto-Fix Vulnerability (Bump Version)** / **Safeguard: Fix All Vulnerabilities**. You can also set a default strategy in `settings.json`:
```json
{
"safeguard.remediationStrategy": "safe"
}
```
* **JetBrains:** place the cursor on a flagged dependency, press `Alt+Enter` (`⌥↩` on Mac), select **"Fix with Safeguard AI"**, pick a strategy, and review the change in the diff view before applying. To fix an entire package or project at once, open the **Safeguard** tool window, right-click the package or project node, and choose **Fix All Vulnerabilities**.
## Interactive AI assistant (VS Code / Cursor)
The extension includes a chat panel (in the Safeguard activity-bar view) for asking security questions in natural language, analyzing selected code, and inserting suggested code at the cursor. Relevant commands and shortcuts:
| Command | Shortcut | Purpose |
| ---------------------------------- | ----------------------------------------------------- | ---------------------------------------------------- |
| `Safeguard: Open AI Assistant` | `Ctrl+Shift+S` / `Cmd+Shift+S` | Opens the chat view. |
| `Safeguard: Ask AI Assistant` | `Ctrl+Shift+A` / `Cmd+Shift+A` | Quick query using current file/selection as context. |
| `Safeguard: Analyze Selected Code` | `Ctrl+Shift+C` / `Cmd+Shift+C` (requires a selection) | Runs a security analysis on the selected code. |
| `Safeguard: Open Inline Chat` | `Ctrl+Shift+I` / `Cmd+Shift+I` | Opens chat inline at the cursor. |
| `Safeguard: New Conversation` | `Ctrl+L` / `Cmd+L` | Starts a new conversation, clearing prior context. |
Conversation history is tracked automatically, and the commands above let you start fresh, export, or clear a conversation, or insert a suggested snippet at the cursor. Example questions the assistant is designed to answer:
* "Why is this package vulnerable?"
* "What's the safest way to fix CVE-2024-12345?"
* "Should I upgrade React to v19?"
> The JetBrains plugin's published documentation describes quick-fix intention actions and a vulnerability tool window, but not an equivalent interactive chat assistant.
## Feature comparison
| Feature | VS Code / Cursor | JetBrains |
| --------------------------------------------- | :--------------: | :-----------------------: |
| Real-time manifest scanning | ✅ | ✅ |
| Inline vulnerability warnings | ✅ | ✅ |
| Scan on save / on project open | ✅ | ✅ |
| Package Firewall inline checks | ✅ | Not documented |
| AI remediation (Safe / Balanced / Aggressive) | ✅ | ✅ (via intention actions) |
| Interactive AI chat assistant | ✅ | Not documented |
| SBOM export (CycloneDX / SPDX) | ✅ | Not documented |
| OAuth 2.0 device-flow login | ✅ | ✅ |
## Commands reference (VS Code / Cursor)
All commands are registered under the **Safeguard** category in the Command Palette (`Ctrl+Shift+P` / `Cmd+Shift+P`). This is the full list contributed by the extension manifest:
**Authentication**
| Command |
| -------------------------- |
| `Safeguard: Login` |
| `Safeguard: Logout` |
| `Safeguard: Set Tenant ID` |
**Scanning**
| Command |
| --------------------------------------------------- |
| `Safeguard: Scan Project for Vulnerabilities` |
| `Safeguard: Scan Current File` |
| `Safeguard: Scan Entire File for Vulnerabilities` |
| `Safeguard: Scan Selected Code for Vulnerabilities` |
| `Safeguard: Show Vulnerability Details` |
**Remediation**
| Command |
| -------------------------------------------------- |
| `Safeguard: Auto-Fix Vulnerability (Bump Version)` |
| `Safeguard: Fix All Vulnerabilities` |
| `Safeguard: Ignore Vulnerability` |
| `Safeguard: Set Remediation Strategy` |
**AI assistant**
| Command |
| ---------------------------------- |
| `Safeguard: Open AI Assistant` |
| `Safeguard: Ask AI Assistant` |
| `Safeguard: Open Inline Chat` |
| `Safeguard: Analyze Selected Code` |
| `Safeguard: New Conversation` |
| `Safeguard: Clear Conversation` |
| `Safeguard: Export Conversation` |
| `Safeguard: Insert Code at Cursor` |
**SBOM, compliance, and posture**
| Command |
| ------------------------------------------------ |
| `Safeguard: Generate SBOM` |
| `Safeguard: Export SBOM` |
| `Safeguard: Compare SBOM with Previous` |
| `Safeguard: Check Compliance (OWASP, EU AI Act)` |
| `Safeguard: Check Code Quality` |
| `Safeguard: Check Security Posture` |
| `Safeguard: View Dependency Graph` |
**Other**
| Command |
| --------------------------------------------------------------------------------------------------------------------------- |
| `Safeguard: Check Staged Commit for Secrets` — see [Secrets Scanning](/docs/secrets-scanning) for the underlying capability |
| `Safeguard: Review Pull Request` |
| `Safeguard: Discover Assets` — see [Asset Discovery](/docs/asset-discovery) |
| `Safeguard: Export Security Report` |
| `Safeguard: Open Notifications` |
| `Safeguard: Configure Settings` |
> This command list comes from the extension's own manifest. The JetBrains plugin does not publish an equivalent full command list — its documented entry points are the **Tools → Safeguard** menu, the intention-action quick fixes (`Alt+Enter`), and the **Safeguard** tool window described above.
## Settings reference (VS Code / Cursor)
Open **Settings** (`Ctrl+,` / `Cmd+,`) and search **"Safeguard"**, or edit `settings.json` directly.
| Setting | Default | Description |
| ------------------------------------------ | ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `safeguard.authServiceUrl` | `https://api.safeguard.sh/auth` | Auth Service endpoint. Only change for a self-hosted/custom deployment. |
| `safeguard.dataServiceUrl` | `https://dev.api.safeguard.sh/data` | Data Service endpoint. |
| `safeguard.goldApiUrl` | `https://dev.api.safeguard.sh/gpt` | AI/remediation service endpoint. |
| `safeguard.tenantId` | `""` | Your Safeguard tenant ID. Populated automatically by **Safeguard: Login** — set manually only if you need to override it. |
| `safeguard.mcpServerUrl` | `https://mcp.safeguard.sh` | MCP server used for IDE auth and AI features. |
| `safeguard.notificationServiceUrl` | `""` | Notification Service endpoint. Leave empty to derive it automatically from the Data Service URL. |
| `safeguard.autoScan` | `true` | Scan the project automatically on open. |
| `safeguard.scanOnSave` | `true` | Re-scan manifest files on save. |
| `safeguard.scanDebounceDelay` | `2000` (ms) | Delay before scanning after you stop typing. |
| `safeguard.showInlineWarnings` | `true` | Show inline decorations for vulnerable dependencies. |
| `safeguard.showCodeLens` | `true` | Show a CodeLens with fix actions above vulnerable dependencies. |
| `safeguard.severityThreshold` | `low` | Minimum severity shown (`low`/`medium`/`high`/`critical`). |
| `safeguard.includeDevDependencies` | `true` | Include dev dependencies in scans. |
| `safeguard.enablePackageFirewall` | `true` | Enable inline Package Firewall checks. |
| `safeguard.packageFirewallUseBackend` | `false` | Use backend verdicts instead of the offline heuristic. |
| `safeguard.remediationStrategy` | `balanced` | Default fix strategy (`safe`/`balanced`/`aggressive`). |
| `safeguard.autoFixOnSave` | `false` | Automatically apply fixes on save — off by default; enable with caution. |
| `safeguard.enableAIAssistant` | `true` | Enable the AI assistant chat features. |
| `safeguard.showRecommendations` | `true` | Show AI-powered security recommendations. |
| `safeguard.enableSBOM` | `true` | Enable SBOM generation/tracking. |
| `safeguard.showDependencyGraph` | `true` | Show the dependency-graph visualization. |
| `safeguard.enableCompliance` | `true` | Enable compliance-standard checks. |
| `safeguard.complianceStandards` | `["OWASP", "CWE", "NIST"]` | Standards checked against. |
| `safeguard.cacheDuration` | `3600000` (ms) | How long scan results are cached (1 hour). |
| `safeguard.batchSize` | `10` | Packages scanned in parallel. |
| `safeguard.excludePatterns` | `["**/node_modules/**", "**/dist/**", "**/build/**"]` | Paths excluded from scanning. |
| `safeguard.notifyOnNewVulnerabilities` | `true` | Notify when new vulnerabilities are detected. |
| `safeguard.surfaceBackendNotifications` | `true` | Show server-side Safeguard events (critical findings, scan complete, approvals) as native IDE notifications with click-through. Silently disabled when not logged in. |
| `safeguard.backendNotificationPollSeconds` | `60` | How often, in seconds, to poll for new backend notifications (minimum `15`). |
| `safeguard.enableTelemetry` | `false` | Send anonymous usage data — opt-in, off by default. |
A minimal `settings.json` override for a stricter, self-directed setup — no backend Package Firewall, safe-only fixes, medium+ severity only:
```json
{
"safeguard.remediationStrategy": "safe",
"safeguard.severityThreshold": "medium",
"safeguard.autoFixOnSave": false,
"safeguard.packageFirewallUseBackend": false
}
```
## Common errors
**Browser doesn't open for login.** Copy the activation URL from the notification and open it manually.
**"Authentication timeout" / device code expired.** Device codes expire after a fixed window; just re-run **Safeguard: Login** and complete the browser approval before it lapses.
**Scan completes with 0 vulnerabilities unexpectedly.** Confirm the manifest file is syntactically valid and check that the configured service URLs are reachable, then trigger a manual scan — **Safeguard: Scan Project for Vulnerabilities** / **Scan Current File** in VS Code/Cursor, or right-click the file → **Safeguard → Scan File for Vulnerabilities** in JetBrains. In JetBrains you can also inspect **Help → Show Log in Explorer/Finder** for scan errors.
**JetBrains plugin doesn't appear under Tools after installing.** Restart the IDE fully, confirm the plugin's declared IDE-version compatibility under **Settings → Plugins → Safeguard**, and confirm JDK 17+ is configured under **File → Project Structure → SDK**.
**Package Firewall isn't flagging anything.** Confirm `safeguard.enablePackageFirewall` is `true`. If you expect backend-sourced verdicts rather than the offline heuristic, also confirm `safeguard.packageFirewallUseBackend` is `true` and that you're logged in.
**Scans feel slow on a large project.** Increase `safeguard.cacheDuration` (or the equivalent JetBrains cache-duration setting) so repeated scans hit the cache instead of re-querying, disable `safeguard.autoScan`/`scanOnSave` in favor of manual scans while doing bulk edits, and confirm the IDE can reach the configured Data Service URL — a slow or blocked network path is a common cause.
**"Authentication expired" / "Invalid token" after working for a while.** Log out and back in (**Safeguard: Logout** then **Safeguard: Login**, or the equivalent **Tools → Safeguard** menu items in JetBrains) to force a fresh OAuth exchange, and make sure your system clock is synchronized — OAuth tokens are time-sensitive.
## Related
* [Package Firewall](/docs/package-firewall) — the install-time proxy and enforcement model the IDE's inline checks are a lightweight companion to.
* [Griffin AI](/docs/griffin-ai) — the remediation and assistant engine behind IDE fix suggestions.
* [Software Composition Analysis (SCA)](/docs/sca) — the broader vulnerability/license/malicious-package scanning the IDE extensions surface inline.
* [Secrets Scanning](/docs/secrets-scanning) — the capability behind the VS Code/Cursor **Check Staged Commit for Secrets** command.
* [Asset Discovery](/docs/asset-discovery) — the capability behind the VS Code/Cursor **Discover Assets** command.
* [SDKs](/docs/sdks): no language SDKs are published yet; the page lists what to use from your own tooling instead.
# About Safeguard (/docs)
# About Safeguard
## What's in Your Software?
95% of enterprise software contains third-party components. 742% increase in supply chain attacks last year. Average breach cost: $4.45 million. Your vendors, your open source, your CI/CD pipeline—every component is an attack vector.
Safeguard.sh Inc delivers complete visibility in minutes with continuous scanning, AI Remediate capabilities, and Griffin AI-powered intelligence. **Architecture designed for FedRAMP HIGH and IL5; SOC2 Type 2 audit in progress.**
Secure software. Secure business. Secure future.
## Who Needs Safeguard?
* **Chief Information Security Officer** who needs complete visibility into all software the organization builds, buys, sells, and uses.
* **Chief Product Security Officer** who must ensure FedRAMP, EO 14028, and other compliance standards are met across the software supply chain.
* **Security Engineers** who need to identify and remediate vulnerabilities before attackers exploit them.
* **Software Procurement Officers** who need to assess and validate SBOMs from third-party vendors.
* **DevSecOps Teams** who want to integrate security into CI/CD pipelines with AI Remediate capabilities.
* **Open Source Program Offices** who need Gold-verified packages with zero critical CVEs.
## Safeguard Products
Five products. Complete visibility. Absolute control. Zero compromise.
* [**Enterprise Software Supply Chain Manager (ESSCM)**](/docs/esscm) - Complete visibility for code, containers, AI models, and CI/CD pipelines
* [**Portal**](/docs/portal) - Centralized SBOM management with secure third-party sharing
* [**Third Party Risk Manager (TPRM)**](/docs/tprm) - Transform vendor risk from blind spot to strategic advantage
* [**Open Source Manager (OSM)**](/docs/osm) - Open source security intelligence and vulnerability database
* [**API Platform (Console)**](/docs/console) - One OpenAI-compatible API for model inference, with API keys, spend limits and usage tracking (early access)
## Compliance Coverage
Safeguard's framework library covers national data-protection, cybersecurity and sector laws, industry standards and Safeguard's own supply-chain policies. Connectors bring evidence in from the systems you use, by OAuth, API token or MCP server, and many of them feed automated compliance tests.
* [**Compliance frameworks**](/docs/frameworks) - how Safeguard covers each framework, with a page for every one
* [**All Frameworks**](/docs/all-frameworks) - the full list, grouped by region
* [**Connectors**](/docs/connectors) - every integration, grouped by category, with the evidence each produces
* [**Compliance connectors**](/docs/compliance-connectors) - how to connect them, with step-by-step guides
* [**Compliance**](/docs/compliance) - certifications, regulatory frameworks, and how scoring works
# Integrations (/docs/integrations)
# Integrations
Safeguard is useful only if it sees your environment. This page catalogs every supported integration across nine categories, how each one connects, and what scopes it needs.
Every integration:
* Authenticates with the minimum privileges required.
* Uses short-lived workload identity where the provider supports it.
* Logs every action to the Safeguard audit stream.
* Can be disconnected and its data purged in one click.
Add and manage integrations under **Settings → Integrations**.
## Source Control (SCM)
| Provider | Auth | Notes |
| ------------------------------------------- | ---------------------- | ---------------------------------------------- |
| **GitHub (Cloud + Enterprise Server 3.7+)** | GitHub App + OAuth | Organization-wide install; per-repo enablement |
| **GitLab (SaaS + Self-managed 15.0+)** | GitLab App + OAuth | Supports groups, sub-groups |
| **Bitbucket (Cloud + Data Center 7.0+)** | OAuth + App Password | Workspace-wide install |
| **Azure DevOps** | Azure DevOps App + PAT | Org or project scope |
| **Gitea / Forgejo** | OAuth App | Self-hosted |
| **AWS CodeCommit** | IAM role | OIDC federation supported |
| **Google Cloud Source Repositories** | Workload Identity | |
| **Gerrit** | Service account | REST API |
What Safeguard does with SCM access:
* Reads repository metadata, commits, PRs, CODEOWNERS, GitHub Advanced Security findings.
* Opens pull requests for Griffin auto-fix and self-healing.
* Writes commit status / check runs with pass/fail results.
* Subscribes to push, PR, tag, and release webhooks.
Write scopes are never enabled without explicit per-repo consent.
## Container Registries
| Registry | Auth | Notes |
| --------------------------------------- | ------------------------------------ | --------------------------------------------- |
| **Docker Hub** | OAuth / Token | Read only unless push is enabled for auto-fix |
| **GitHub Container Registry (GHCR)** | GitHub App or PAT | OIDC supported |
| **Amazon ECR / ECR Public** | IAM role | Roles Anywhere supported |
| **Azure Container Registry (ACR)** | Managed Identity / Service Principal | |
| **Google Artifact Registry (GAR)** | Workload Identity Federation | |
| **Google Container Registry (GCR)** | Workload Identity Federation | Deprecated by Google; migrate to GAR |
| **Harbor** | Robot account | On-prem + SaaS |
| **JFrog Artifactory** | Token | |
| **Sonatype Nexus** | Token | |
| **Quay.io / Red Hat Quay** | Robot account | On-prem + SaaS |
| **Red Hat OpenShift internal registry** | Kubeconfig | |
| **GitLab Container Registry** | GitLab App | |
| **AWS Public ECR** | Anonymous read | |
| **Custom OCI-compliant** | Token | Any OCI-distribution-compatible registry |
Capabilities:
* Enumerate images, tags, and digests.
* Pull image metadata for layer analysis without pulling the full image.
* Verify Sigstore / Notation signatures.
* Push signed attestations alongside images.
## Cloud Providers
| Provider | Auth | Use |
| ------------------------------- | -------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| **AWS** | IAM role, Roles Anywhere, OIDC WIF | Asset inventory (EKS, ECS, Lambda, ECR, S3, CodeBuild), VPC deployment for runners/admission |
| **Azure** | Managed Identity / Service Principal / Workload Identity | Asset inventory (AKS, ACI, Functions, ACR, Container Apps), VNet deployment |
| **Google Cloud** | Workload Identity Federation | Asset inventory (GKE, Cloud Run, Cloud Functions, GAR, Cloud Build), VPC deployment |
| **Oracle Cloud Infrastructure** | Instance principal | OKE + ADB scans |
| **IBM Cloud** | IAM token | Kubernetes Service + Code Engine |
| **DigitalOcean** | API token | |
| **Linode / Akamai Cloud** | Personal access token | |
| **Hetzner** | API token | |
| **Kubernetes (any)** | Kubeconfig or in-cluster service account | Admission controller, runtime collector |
## CI / CD
| System | Integration |
| ------------------------------- | ------------------------------------- |
| **GitHub Actions** | Marketplace actions + OIDC federation |
| **GitLab CI** | Docker image + JWT authentication |
| **Azure Pipelines** | Task extension |
| **Jenkins** | Plugin (2.346+) |
| **CircleCI** | Orb |
| **Buildkite** | Plugin |
| **TeamCity** | Plugin |
| **Bitbucket Pipelines** | Pipe |
| **Travis CI** | Container image |
| **Drone CI** | Plugin |
| **Tekton / Jenkins X** | Task |
| **Argo Workflows** | WorkflowTemplate |
| **Spacelift / Terraform Cloud** | Integration |
See [CI/CD Integration](/docs/cicd-integration) for installation snippets.
## Identity (SSO / SCIM)
| Provider | Protocols | Notes |
| --------------------------------- | ------------------------ | ---------------------------- |
| **Okta** | SAML 2.0, OIDC, SCIM 2.0 | Reference implementation |
| **Microsoft Entra ID (Azure AD)** | SAML 2.0, OIDC, SCIM 2.0 | Conditional Access supported |
| **Google Workspace** | OIDC, SAML 2.0 | Directory sync supported |
| **JumpCloud** | SAML 2.0, SCIM | |
| **OneLogin** | SAML 2.0, OIDC, SCIM | |
| **Ping Identity** | SAML 2.0, OIDC | |
| **Duo** | SAML 2.0 | |
| **Keycloak** | OIDC, SAML 2.0 | Self-hosted |
| **Authentik / authelia** | OIDC, SAML 2.0 | Self-hosted |
| **AWS IAM Identity Center** | SAML 2.0, SCIM | |
## Secret Managers
| System | Use |
| -------------------------------- | ------------------------------------------------------------------ |
| **HashiCorp Vault** | Rotate leaked secrets, fetch short-lived credentials for workflows |
| **AWS Secrets Manager** | Auto-rotate on secret detection |
| **Azure Key Vault** | Rotate + retrieve |
| **GCP Secret Manager** | Rotate + retrieve |
| **Doppler** | Rotate on secret detection |
| **Infisical** | Rotate on secret detection |
| **1Password Secrets Automation** | Rotate on secret detection |
| **CyberArk Conjur** | Rotate + retrieve |
## Ticketing & Work Tracking
| System | Capabilities |
| ------------------------------------ | ---------------------------------------------------------------------------------------------- |
| **Jira (Cloud + Data Center 8.20+)** | Create / update / comment / transition; custom field mapping; auto-close on finding resolution |
| **Linear** | Create issue, assign, update status |
| **Azure Boards** | Work item create / update |
| **Asana** | Task create / update |
| **ClickUp** | Task create / update |
| **GitHub Issues** | Issue create / close on merge |
| **GitLab Issues** | Issue create / close |
| **ServiceNow ITSM** | Incident / Change / Problem records |
| **Zendesk** | Ticket create |
| **FreshService** | Ticket create |
## Notifications & ChatOps
| Channel | Notes |
| --------------------- | --------------------------------------------------------------------------------- |
| **Slack** | Per-channel routing + slash commands (`/safeguard triage`, `/safeguard suppress`) |
| **Microsoft Teams** | Adaptive cards; per-channel routing |
| **Discord** | Webhook-based |
| **Google Chat** | Chatbot integration |
| **Mattermost** | Webhook-based |
| **Email** | Per-user digest + escalation routes |
| **SMS** (Twilio) | Critical-KEV-in-prod pages only, opt-in |
| **Webhook (generic)** | JSON or plain-text templates |
## On-Call & Incident
| System | Use |
| ------------------------------ | ----------------------------------------------------------------------- |
| **PagerDuty** | Page on critical in-production findings, workflow failures, missed SLAs |
| **OpsGenie** | Same as PagerDuty |
| **VictorOps / Splunk On-Call** | Same as PagerDuty |
| **incident.io** | Open incident channel on qualifying findings |
| **FireHydrant** | Open incident |
| **Rootly** | Open incident |
## SIEM, Logging & Observability
| System | Data |
| --------------------------------------------------------------------- | ------------------------------------------------ |
| **Splunk** | HEC (findings, audit, telemetry) + Splunk ES app |
| **Datadog** | Logs + Metrics + Events API |
| **New Relic** | OpenTelemetry |
| **Elastic (ECS)** | Logs + Metrics |
| **Chronicle (Google SecOps)** | Direct integration |
| **Microsoft Sentinel** | Native connector |
| **Exabeam / LogRhythm / Securonix / Arctic Wolf / Rapid7 InsightIDR** | Syslog + JSON webhook |
| **Honeycomb** | OpenTelemetry |
| **Grafana Cloud** | OpenTelemetry |
| **Prometheus + Loki + Tempo** | Self-hosted OpenTelemetry |
| **AWS CloudWatch / S3** | Log ship |
| **Azure Monitor / Log Analytics** | Log ship |
| **Google Cloud Logging** | Log ship |
## Package Managers & Registries (Non-Container)
| Ecosystem | Integration |
| ------------------------------------------------------ | ------------------------ |
| **npm Registry / GitHub Packages / internal npm** | Token-authenticated read |
| **PyPI / private PyPI (devpi / Gemfury)** | Token-authenticated read |
| **Maven Central / Sonatype Nexus / JFrog Artifactory** | Token-authenticated read |
| **NuGet Gallery / Azure Artifacts / GitHub Packages** | Token-authenticated read |
| **RubyGems** | API key |
| **Packagist / Composer** | Token |
| **crates.io / private Cargo** | Token |
| **Go modules / GOPROXY** | GOPROXY endpoint |
| **Conda / Anaconda Cloud / mamba** | Token |
## AI / ML Registries
| System | Integration |
| -------------------------------- | ------------------------------------ |
| **Hugging Face** | User / org / private; OAuth or token |
| **MLflow** | REST API token |
| **AWS SageMaker Model Registry** | IAM role |
| **Vertex AI Model Registry** | Workload Identity Federation |
| **Azure ML Model Registry** | Managed Identity |
| **Databricks Model Serving** | PAT |
| **Kubeflow / KServe** | In-cluster service account |
## Data Warehouses / Lakes (for audit log + metric export)
| System | Mode |
| ---------------------------------- | --------------------------------------- |
| **Snowflake** | Secure data sharing / pull subscription |
| **BigQuery** | Dataset export |
| **Redshift / Redshift Serverless** | Direct load |
| **Databricks (Unity Catalog)** | Delta share |
| **Clickhouse Cloud / self-hosted** | JSON over HTTP |
## Compliance & GRC Platforms
| System | Integration |
| ---------------------------------------- | ------------- |
| **Drata** | Evidence push |
| **Vanta** | Evidence push |
| **SecureFrame** | Evidence push |
| **Tugboat Logic / OneTrust** | Evidence push |
| **Hyperproof** | Evidence push |
| **Archer / MetricStream / LogicManager** | Export bundle |
## How to Add an Integration
Most integrations follow the same flow:
1. **Settings → Integrations → Add integration**.
2. Pick the provider.
3. Authenticate (OAuth redirect, workload identity, or paste a token).
4. Pick the scope (which repos / clusters / projects to include).
5. Confirm.
Integrations are scoped to a team or organization, with team-level overrides where relevant.
## API and Terraform
There is no CLI command for creating integrations yet. They can be declared through the Terraform provider:
```hcl
resource "safeguard_integration" "github_acme" {
type = "github"
org = "acme"
token = var.github_token
}
```
## Related
* [ESSCM Integrations](/docs/esscm/integrations) — product-scoped view.
* [CI/CD Integration](/docs/cicd-integration) — CI-specific setup.
* [MCP Connectors](/docs/mcp/connectors) — AI-client connectors.
* [Webhooks & Events](/docs/webhooks-events) — event stream for custom integrations.
# Identity Threat Detection (ITDR) & DLP (/docs/itdr-dlp)
# Identity Threat Detection (ITDR) & DLP
> **Roadmap — not yet available.** ITDR and DLP are planned capabilities documented here for direction. They extend the shipped detection/response spine, DSPM classifier, and safety kernel, but the engines themselves are not yet available.
Two pillars on one spine. **ITDR** detects identity attacks and responds only through policy, approval, and the safety kernel — never auto-disabling an account. **DLP** prevents sensitive data in motion, reusing the [DSPM](/docs/dspm) classifier and enforcing at the AI gateway, API, and export paths without ever persisting raw content.
## ITDR — identity threat detection (planned)
ITDR detectors will consume identity signals from the SecOps event store and emit identity-threat findings. Planned detections:
| Category | Signal |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| **Impossible travel** | Two logins whose implied velocity exceeds a physical threshold |
| **Anomalous login** | New geo, ASN, device, or atypical time versus the identity's behavioral baseline |
| **MFA fatigue / bombing** | A burst of denied/ignored MFA pushes — critical if immediately followed by an approval (post-fatigue success) |
| **Privilege escalation** | Admin-role assignment, elevated group adds, policy widening, new keys on privileged principals |
| **Dormant / over-privileged** | Reactivated idle accounts; behaviorally over-broad privileges (via reused CIEM) |
| **Service-account anomaly** | A non-human principal deviating from its narrow baseline |
| **Token theft / session hijack** | A session or refresh token replayed from a new device/ASN/geo; concurrent geo-disjoint sessions |
| **Risky OAuth** | High-scope consent to an unverified app; illicit-consent-grant patterns |
### Response (planned, gated)
Every ITDR response will be a SOAR connector action executed only through the safety kernel — never a direct identity-provider call from detection code. **High-impact actions (disable account, revoke token, disable session) never auto-execute** — they are held for human approval. Low-impact actions (force re-auth, require step-up) may auto-run per policy. Rate and blast caps prevent mass-disable, a kill-switch aborts everything in flight, and reversible actions are preferred.
## DLP — data-loss prevention (planned)
DLP is deliberately designed **not** to be a second classifier — it is a set of enforcement points that call the shipped DSPM classifier on data in motion:
| Channel | What it inspects |
| -------------------------- | ----------------------------------------------------------------------------------------- |
| **AI gateway** | Prompts, responses, and tool I/O (extends the [AI Gateway](/docs/ai-gateway) egress path) |
| **API responses** | Sensitive data in API output |
| **Export / bulk download** | Sensitive data leaving through export paths |
| **SaaS sharing** | Over-broad shares and public links containing sensitive data |
Each channel supports **monitor**, **redact**, and **block** modes (enforce modes default-off), with policy defined per channel and category. Classification and redaction always route through the DSPM classifier — never a second implementation.
## Safety model (planned)
* **Fail-open DLP.** On any classifier or enforce error, traffic is allowed and an alert is raised — a DLP failure never breaks the protected app.
* **Never persist raw sensitive content.** Violations record the matched category and a DSPM-redacted span only; there is no raw-content field by construction.
* **Elevated access control.** ITDR/DLP findings are highly sensitive — tenant-scoped with tighter ACLs than normal findings, and every read is audited.
## When it ships
ITDR findings and DLP violations will flow into the single [findings store](/docs/unified-findings) under elevated access control, fuse into SecOps XDR incidents, and map to SOC2 / ISO / PCI / HIPAA controls. Gated by the `ff.itdr` and `ff.dlp` feature flags.
## Related
* [DSPM](/docs/dspm) — the data classifier DLP reuses, available today.
* [AI Gateway (LLM Firewall)](/docs/ai-gateway) — the egress path DLP extends.
* [SecOps (SIEM)](/docs/secops) — the identity-signal source and XDR fusion point.
* [Unified Findings & Feature Flags](/docs/unified-findings) — where findings land.
# License Compliance (/docs/license-compliance)
# License Compliance
Open-source license obligations are as real as security obligations. A copyleft license in the wrong place can force you to open-source proprietary code, lose a deal, or fail due diligence. Safeguard identifies every component's license, classifies its obligations, and enforces your license policy at every point in the lifecycle.
## License Detection
Safeguard identifies licenses from multiple sources with reconciliation:
* **Package metadata** — `license` field in `package.json`, `pyproject.toml`, `Cargo.toml`, `` in Maven POMs, etc.
* **SPDX identifiers** — recognized per the SPDX license list.
* **Full-text matching** — scans `LICENSE`, `LICENCE`, `COPYING`, `NOTICE` files and matches against known license texts.
* **Header detection** — reads source file headers for license declarations.
* **Binary extraction** — parses `/usr/share/doc/*/copyright` in container layers and embedded license strings.
When signals disagree (`package.json` says MIT but LICENSE file is AGPL), Safeguard raises a `license-discrepancy` finding — typically the sign of a packaging mistake or license relabeling.
## Classifications
Every license is classified by obligation category:
| Category | Examples | Risk |
| ------------------------------ | ------------------------------------ | ----------------------------- |
| **Permissive** | MIT, BSD-2/3, Apache-2.0, ISC | Low |
| **Weak copyleft** | MPL-2.0, LGPL-2.1, LGPL-3.0, EPL-2.0 | Medium |
| **Strong copyleft** | GPL-2.0, GPL-3.0 | High for proprietary products |
| **Network copyleft** | AGPL-3.0, SSPL-1.0 | High for SaaS |
| **Commercial / proprietary** | Custom, vendor-specific | Depends |
| **Public domain / dedication** | CC0-1.0, Unlicense | Low |
| **Unknown / unidentified** | — | Review required |
Classifications include deep-linked explanations of obligations (attribution, source disclosure, patent grants, etc.).
## License Policies
Declare your allow / deny policy in YAML:
```yaml
apiVersion: safeguard.sh/v1
kind: LicensePolicy
metadata:
name: default
spec:
allow:
- MIT
- BSD-2-Clause
- BSD-3-Clause
- Apache-2.0
- ISC
- MPL-2.0
deny:
- GPL-3.0-or-later
- AGPL-3.0-or-later
- SSPL-1.0
require_review:
- GPL-2.0-only
- LGPL-3.0-or-later
- "Custom/*"
context_overrides:
- apply_to: { env: sdk }
deny:
- LGPL-3.0-or-later # LGPL tricky in SDK distribution
- apply_to: { env: server }
allow:
- LGPL-3.0-or-later # fine for a service binary
```
Policies can be scoped to asset labels — a policy for your open-core distribution can differ from your SaaS backend.
## Enforcement
License policies plug into [Guardrails](/docs/guardrails-enforcement):
* At CI time — builds fail if a denied license appears in the dependency tree.
* At admission — images containing denied licenses can't deploy to production.
* At PR time — a new direct dependency with a deny-listed license gets a blocking Safeguard check.
Findings show the transitive path for quick triage.
## Attribution Generation
For redistributed artifacts, Safeguard auto-generates:
* `NOTICE` / `THIRD-PARTY-NOTICES.txt` with required attributions.
* `licenses/` directory with copies of each required license text.
* A machine-readable SPDX document for each release.
There is no CLI command for generating these yet.
## Vendor SBOM License Analysis
For vendor software, Safeguard runs the same classification on the vendor's SBOM:
* Are their licenses compatible with your product?
* Does any component in their SBOM trigger a deny-listed license for you?
* Has license set changed between versions (a sign of unexpected re-licensing)?
This flows into TPRM assessments automatically.
## Dual-Licensed and Compound Expressions
Safeguard understands full SPDX expression syntax:
* `MIT OR Apache-2.0` — dual-licensed, pick one.
* `(MIT AND Apache-2.0)` — compound; both apply.
* `GPL-2.0-only WITH Classpath-exception-2.0` — with exception.
Policies evaluate correctly against expressions; for `OR`, the most permissive option that matches your policy is chosen automatically.
## Exceptions
Temporary license exceptions follow the same exception workflow as vulnerability exceptions:
* Named approver.
* Expiry date.
* Documented business justification.
* Auto-expire and re-evaluate at expiry.
## Reports
The **Licenses** dashboard shows:
* License distribution across your fleet.
* New-license introductions over time (new obligations adopted).
* Policy violation count and trend.
* Per-asset license manifest for export (Excel, CSV, SPDX, CycloneDX).
## CLI
There is no CLI command for license listing, reports or policy evaluation yet. `safeguard scan` writes a `license.json` with the licenses it found alongside its other results.
## Related
* [SBOM (ESSCM)](/docs/esscm/explore-sbom) — license data lives in the SBOM view.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — enforce license policies at gates.
* [Suppliers & Licenses](/docs/esscm/suppliers-licenses) — vendor- and supplier-scoped license reporting.
* [Compliance](/docs/compliance) — OpenChain and other license-related frameworks.
# Malware Detection (/docs/malware-detection)
# Malware Detection
Supply chain attackers ship malicious code as packages, container layers, or model weights. Traditional antivirus and signature-based tooling miss most of them. Safeguard uses **Eagle** — our classification model trained on confirmed-malicious artifacts — to classify every artifact your organization pulls or publishes.
## What Eagle Looks For
Eagle scores each artifact across seven indicator classes:
| Indicator | What it means |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Install-script behavior** | Post-install hooks that contact unusual hosts, install additional packages, or write outside the package's own directory. |
| **Obfuscated code** | Dense eval / Function / base64 / zlib-wrapped payloads; string encoding patterns known from real incidents. |
| **Egress patterns** | Hard-coded URLs matching known C2 infrastructure, Discord / Telegram exfiltration, Pastebin, etc. |
| **Credential harvesting** | Reads from `~/.aws`, `~/.ssh`, `~/.npmrc`, browser profiles, clipboard. |
| **Typosquat similarity** | Name within edit-distance 2 of a top-1000 package, owned by a different publisher. |
| **Metadata anomalies** | Newly-published package with aggressive versioning, unusual author history, no repository URL. |
| **Behavior divergence from prior versions** | New network / file system / process activity that didn't exist in the previous release. |
The output per artifact:
* **Score** 0-100.
* **Classification** — benign / suspicious / malicious.
* **Indicators fired** — specific rules that contributed.
* **Griffin-authored explanation** — plain-English summary of what was unusual.
## Coverage
Eagle classifies artifacts in:
| Ecosystem | Coverage |
| --------------------------------------- | --------------------------------------------------------------- |
| **npm** | Every publish, retroactive scan of the last 10 years |
| **PyPI** | Every publish, retroactive scan |
| **Maven Central** | Every publish + historical scan |
| **RubyGems** | Every publish |
| **NuGet** | Every publish |
| **crates.io** | Every publish |
| **Go modules** | Every publish |
| **Composer** | Every publish |
| **Docker Hub / GHCR / ECR / ACR / GCR** | Every tag push, plus configured periodic scan of running images |
| **Hugging Face** | Every model, every fine-tune, every config change |
## Enforcement Points
Eagle's classification feeds into policy at multiple points:
### Inline at Install
Via the [Safeguard runner](/docs/runner) or a pre-install hook:
```yaml
# .safeguard/malware-policy.yaml
malware:
block: [malicious]
warn: [suspicious]
confirm_ttl: 300 # how long a classification is trusted before re-check
```
If `npm install` pulls a package classified `malicious`, the install aborts with an explanation.
### At Registry
For your own internal registry, enable inline classification on pushes so internal publishes get scored.
### At CI
```yaml
- uses: safeguard/malware-scan@v2
with:
fail-on: malicious
```
### At Admission
The Kubernetes admission controller refuses pods with an image layer containing malicious content.
## Historical Scans
When Eagle is updated, it re-scores the entire corpus retroactively. If a package you depend on is reclassified as malicious because of a signal Eagle previously missed, you get a finding within seconds of the re-scoring pass.
The finding includes:
* When the package was installed / deployed.
* What specifically triggered the new classification.
* Recommended remediation (rollback, Gold substitution, or quarantine).
## Real Examples
Eagle has publicly surfaced malicious activity in:
* npm packages with hidden post-install scripts exfiltrating `~/.aws/credentials`.
* PyPI typosquats of popular ML packages.
* Compromised model repositories on Hugging Face distributing `pickle`-based payloads.
* OCI images with layers that dropped cryptominers on container start.
See the [Incident Analysis blog category](/resources/blog?category=incident-analysis) for writeups.
## False Positives
Eagle is tuned for precision — the classification band-widths are:
* Score \< 30: benign, released silently.
* Score 30-70: suspicious, surfaces as a warning with the indicator list.
* Score > 70: malicious, blocked by default policy.
Reported false-positive rate for score > 70 is approximately 1 in 10,000. Reporting a suspected false positive via `research@safeguard.sh` triggers human review within 24 hours.
## Bypass Attempts
When attackers try to evade detection, Eagle flags the evasion itself:
* String splitting / concatenation of known malicious identifiers.
* Delayed-execution payloads that only run weeks after install.
* Package trust "warm-up" — publishing a few benign versions before the malicious one.
* Typosquat rotation (publish under many similar names to defeat allowlists).
## AI Model Malware
For AI artifacts specifically:
* **Pickle payload detection** — model weight files that embed executable Python via `pickle`.
* **Hidden backdoors** — statistical tests for neurons or prompt-triggered behaviors that produce attacker-controlled output.
* **Config-level injection** — `transformers` config files that reference external code with arbitrary URLs.
## CLI
To get the allow, block or warn decision for one package install on your own machine:
```bash
safeguard pkgfw check --ecosystem npm --name react --version 19.0.0
```
To scan a directory of model files for unsafe deserialization or embedded code:
```bash
safeguard aisec scan --dir ./models
```
There is no CLI command for scanning an image for malware or for a package's malware history yet.
## Related
* [AI Models](/docs/ai-models) — Eagle model versions and capabilities.
* [Gold](/docs/gold-registry): known vulnerabilities in open-source packages, at gold.safeguard.sh.
* [Zero-Day Discovery](/docs/zero-day-discovery) — how malware findings feed Safeguard's research pipeline.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — enforcing malware policy at every point.
# Model Capabilities (/docs/model-capabilities)
# Model Capabilities
This page is the practical reference for what Safeguard's models can do: what you can ask them, what inputs they accept, what outputs they promise, and where their limits are.
For version history and deployment options, see [AI Models](/docs/ai-models).
## Griffin — Reasoning and Remediation
### Capability matrix
| Capability | Input | Output | Latency (p50) |
| ----------------------------- | --------------------------- | -------------------------------------------------------------------- | ------------- |
| **Vulnerability explanation** | CVE ID + affected component | Plain-English writeup with attack scenarios and exploit requirements | \~3s |
| **Remediation plan** | CVE ID + repo context | Ranked list of upgrade paths with breakage risk | \~6s |
| **Auto-fix PR** | Repo + target CVE(s) | Git branch with changes, test run log, PR description | 30s – 5min |
| **Multi-repo PR** | Target CVE across N repos | N coordinated PRs | 2 – 20 min |
| **Reachability reasoning** | Finding + call graph | "reachable" / "unreachable" / "conditional" + justification | \~4s |
| **SBOM diff narration** | Two SBOMs | Summary of what changed and why it matters | \~5s |
| **Natural-language query** | Free text question | Answer with linked data | \~3s |
| **Agentic execution** | Goal + scope | Plan → execute → verify loop | variable |
### Agentic mode
Griffin runs a tool-use loop with the same tool surface exposed via the MCP server. A typical session:
```
Goal: "Resolve all reachable KEV-listed CVEs in the payments service this sprint."
Iteration 1:
tool: safeguard_find_vulnerabilities { project: payments, kev: true, reachable: true }
result: 7 findings
Iteration 2:
tool: safeguard_get_remediation_plan { finding_ids: [...] }
result: 6 upgradeable, 1 requires fork
Iteration 3:
tool: safeguard_remediate_npm + safeguard_open_pull_request × 6
result: 6 PRs open
Iteration 4:
tool: safeguard_jira_create { severity: high, title: "Fork lodash for CVE-X" }
result: ticket SEC-1234 opened
Summary: 6 auto-fixes, 1 ticket for manual fork.
```
You can scope Griffin's tool surface — read-only triage versus full write access — per role or per workflow.
### Input limits
* Context window: 1.1 million tokens (1,100,000) for Griffin. Eagle's is 1 million tokens and Lino's 128K tokens; see [AI Models](/docs/ai-models#lineup-facts).
* Max code bundle per pass: \~150k tokens; larger repos are chunked.
* Request-level budget per tenant: configurable soft caps + hard ceiling.
### Output guarantees
* Structured outputs validated against JSON schemas before being returned to the client.
* Claims about files / functions / lines reference the actual repository state at call time; stale references auto-refresh.
* When Griffin is uncertain, the response includes an explicit confidence band and suggested next steps.
### Example prompts
```
"Give me a remediation plan for CVE-2024-3094 across every Go service in the 'platform' team."
"Explain why CVE-2023-44487 (HTTP/2 Rapid Reset) appears in services that don't expose HTTP/2."
"Show the dependency path from my-api@main to a reachable log4j-core 2.17.0."
"Open PRs to pin all transitive dependencies on KEV-listed CVEs in production services; flag anything that would require a major version bump."
"What would happen if I upgraded spring-boot-starter-web from 2.7 to 3.2 in billing-service?"
```
## Eagle — Classification and Anomaly Detection
### Capability matrix
| Capability | Input | Output |
| ---------------------------------- | ---------------------------------- | --------------------------------------------------------- |
| **Package classification** | Package + version | Benign / suspicious / malicious + score + indicators |
| **Container layer classification** | Image digest + layer | Same |
| **Model weight classification** | Weight file (safetensors / pickle) | Same + pickle-opcode analysis |
| **Runtime anomaly scoring** | Runtime telemetry stream | Per-workload anomaly score over time |
| **Typosquat detection** | Package name | Nearest top-1000 neighbors + confidence that it's a squat |
| **Behavioral divergence** | Two versions of an artifact | Differences with risk assessment |
### How Eagle answers
Every Eagle output includes:
* Score (0-100).
* Classification.
* Contributing indicators (which rules fired).
* Confidence (based on training-data coverage of similar artifacts).
* Recommended action (allow / review / block / quarantine).
### Example usage
Inline at `npm install`:
```bash
$ npm install @
# Eagle classification runs via Safeguard's install-hook.
Safeguard: @ classified MALICIOUS (score 94)
Indicators:
- post-install script contacts unusual host (tox-xxxx.run)
- base64-encoded payload in index.js
- package metadata created < 48h ago
- author has one prior malicious upload
Install aborted.
```
### False positive handling
* Verified false positives are added to an allowlist layer that doesn't change Eagle's model.
* If you believe a classification is wrong, report it with `safeguard support bug`.
## Lino — Compliance and Policy
### Capability matrix
| Capability | Input | Output |
| ------------------------- | ------------------------------------ | ----------------------------------------------------- |
| **Framework mapping** | Framework (FedRAMP, CRA, SSDF, etc.) | Control-by-control evidence map from your environment |
| **SBOM QA** | CycloneDX or SPDX document | Quality score + list of missing minimum elements |
| **Policy authoring** | Plain-English intent | Policy YAML ready to apply |
| **Policy explanation** | Policy YAML | Plain-English summary + effects |
| **Attestation reasoning** | In-toto / SLSA attestation | Does it meet claimed level? why / why not |
| **Gap analysis** | Current state + target framework | What to do, in priority order |
### Example: generate a policy from intent
```
Input: "For production workloads handling PCI data, block any container
whose SBOM is older than 7 days OR contains any KEV-listed vulnerability."
Output:
---
apiVersion: safeguard.sh/v1
kind: Policy
metadata:
name: pci-prod-strict
spec:
targets:
- kind: Image
labels:
env: production
data_class: pci
rules:
- id: sbom-fresh
condition: age(attestations.sbom) > "7d" OR attestations.sbom == null
effect: BLOCK
- id: no-kev
condition: any(vulnerabilities, kev == true)
effect: BLOCK
```
### Example: framework gap analysis
```
Input: "Gap analysis for CRA for our 'widget-cloud' product."
Output:
Coverage summary: 61 / 84 requirements met
Critical gaps:
- Annex I (1) coordinated vulnerability disclosure policy not published
- Annex I (9) SBOM not delivered with product releases
- Annex II (2) security support period not documented
Medium gaps: ...
Low gaps: ...
Recommended next steps (in order):
1. Publish SECURITY.md with VDP; template linked
2. Attach CycloneDX SBOM to each release; one-click workflow below
3. Document support window in product docs
```
## Shared Properties
### Privacy
* Customer code, SBOMs, and telemetry are never used to train shared models.
* Per-tenant fine-tunes stay inside the tenant boundary.
* Inference request bodies are retained 24 hours by default; configurable 0–365 days for Enterprise.
### Inference endpoints
* **Shared cloud** — hosted in Safeguard's shared environment, designed to FedRAMP HIGH requirements. Default.
* **Dedicated tenancy** — single-tenant inference cluster.
* **Self-hosted** — quantized builds on customer GPUs for air-gapped / IL5.
### Versioning
Pin a model version for reproducibility:
```yaml
ai_models:
griffin: "3.0" # or "3.1-preview"
eagle: "3.0"
lino: "2.0"
```
Model outputs are reproducible when:
* Version is pinned.
* Temperature = 0 (the default for tool-use workflows).
* The underlying knowledge graph is at the same snapshot (audit via `X-SG-Knowledge-Snapshot` response header).
### API
```bash
# Chat with the assistant in this workspace
safeguard agent "Summarize this repository's dependency risk"
# One-shot, non-interactive task
safeguard exec "Fix the critical KEV CVEs in this repository"
```
There is no CLI command for Eagle classification or Lino policy generation yet. The models are also reachable through the [MCP Server](/docs/mcp).
## Evaluation Datasets
For Enterprise tenants:
* **Custom benchmark creation** — upload your own eval set (prompts + expected outputs) to validate model behavior on your codebase.
* **Per-tenant regression gates** — a new model version is rolled out only if it scores ≥ current on your benchmark.
* **Model selection per workflow** — different workflows can pin different model versions.
Enterprise customers who want Safeguard to fine-tune Griffin on their internal security incident corpus can open a conversation with the support team; this is a structured engagement, not a one-click feature.
## Related
* [AI Models](/docs/ai-models) — version history, deployment modes, privacy.
* [Griffin AI](/docs/griffin-ai) — Griffin-specific feature guide.
* [MCP Server](/docs/mcp) — exposing model capabilities to external AI clients.
* [Workflows](/docs/workflows) — building model-driven automations.
# Package Firewall (/docs/package-firewall)
# Package Firewall
The Package Firewall moves dependency protection to **install time**. Instead of finding a bad package after it's already in your tree, it evaluates each dependency as it's installed and can allow, warn on, or block it inline.
## How it works
The firewall runs as an **install-time proxy** fronting **npm** and **pip**. Package managers fetch through the proxy instead of hitting the upstream registry directly, so every request is evaluated before the package ever reaches your machine or build.
Because the proxy sits on the fetch path, coverage is **transitive by construction** — it sees *every* fetch, including transitive dependencies pulled in by your direct dependencies. There is no separate lockfile-parsing step to keep in sync; if a package is downloaded, it is checked.
## What it checks
| Threat | How it's detected |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Typosquatting** | Package names that closely resemble a well-known package — including swapped or transposed characters — are flagged as likely impersonations (typo / look-alike detection). |
| **Dependency / namespace confusion** | Names that could resolve to a public package in place of an intended internal one — or that squat on an internal namespace — are caught. |
| **Malware / blocklist** | Packages matching known-malicious signatures or an explicit blocklist are stopped. |
| **Behavioral analysis** | A behavioral analyzer inspects the package archive statically — **introspecting its contents without executing any code** — to surface suspicious indicators before install. |
## Enforcement modes
The firewall runs inline with three outcomes:
* **Allow** — the package passes and installs normally.
* **Warn** — the install proceeds but the decision is recorded and surfaced.
* **Block** — the install is refused.
It also supports:
* **Audit mode** — evaluate and record decisions without blocking, so you can measure impact before enforcing.
* **Quarantine mode** — hold a flagged package aside pending review rather than installing or hard-blocking it.
### Auto-release loop
A quarantined package doesn't have to stay quarantined forever. The firewall re-evaluates held packages and **auto-releases** one once its verdict clears — for example, when a false-positive signal is corrected or a package is no longer flagged. Packages that never clear are aged out after a configurable window (default **14 days**), so quarantine doesn't accumulate stale entries.
Every decision is recorded to the audit trail with the package, the rule that fired, the mode, and the outcome — tenant/org-scoped.
## Findings produced
Every non-allow decision becomes a dependency finding in the [unified findings model](/docs/unified-findings), categorized by what fired (for example typosquat or behavioral). Each finding carries the ecosystem, package name and version, the category that fired, the mode, and — in audit mode — the verdict that *would* have been enforced. Transitive fetches are marked as such. Confirmed-malware and namespace-confusion decisions are the highest-severity outcomes; behavioral and novel-package signals are held in quarantine pending review.
## Configuration
The Package Firewall is **admin-toggleable** via a [feature flag](/docs/unified-findings#feature-flags), enforced server-side. Start in **audit** mode to baseline, then move to **warn** or **block** as confidence grows.
You enforce at whichever point fits your workflow — a local/CI proxy, a registry-fronting proxy in front of your Nexus or Artifactory, or the server-side runner — all sharing the same decision core. From the CLI:
```bash
# Local / CI proxy for npm and pip (modes: audit, quarantine)
safeguard pkgfw start --mode quarantine --port 8899
# One-shot check, printed as JSON (exit 1 on block)
safeguard pkgfw check --ecosystem npm --name left-pad --version 1.3.0
```
There is no CLI command for fronting an existing repository manager yet.
## Related
* [Malware Detection](/docs/malware-detection) — Eagle-based classification behind the malware check.
* [Deep Dependency Scanning](/docs/deep-dependency-scanning) — transitive dependency analysis after install.
* [Unified Findings & Feature Flags](/docs/unified-findings) — how engines are toggled across the platform.
# PR Guard (/docs/pr-guard)
# PR Guard
PR Guard is Safeguard's AI code review feature for pull requests. Point it at a pull request and it analyzes the diff, then returns a scored summary plus a list of comments — each tied to a specific file and line, categorized by severity and type, and optionally accompanied by a suggested fix. Results are shown in the Safeguard UI, and can also be posted directly onto the pull request on the provider side so reviewers see them inline where they already work.
PR Guard appears as its own tab, labeled **PR Guard**, on every project's detail page, alongside tabs like Findings — though review actions are only enabled once the project's connected repository is on GitHub (see below).
## How it fits into a project
A project's **PR Guard** tab has two views:
* **Pull request list** — every pull request Safeguard can see for the project's repository, with a state filter and pagination.
* **Review workflow** — pick a pull request, run a review against it, watch it progress, and read the results across Overview, Files, Comments, and History tabs. Opening a specific pull request from the list takes you straight into this view for that PR.
> PR Guard's current implementation is wired to GitHub pull requests. If a project's connected repository provider isn't GitHub, the tab shows a **GitHub project required** notice and review actions are disabled for that project.
## The pull request list
The list view shows the pull requests Safeguard has fetched for the project's repository, with:
| Column | What it shows |
| ------- | --------------------------------------------------------------------------------------------------------- |
| PR / MR | The pull request number |
| Title | The PR title, with a link out to the PR on the provider |
| Status | **Draft**, **Merged**, **Open**, or **Closed**, derived from the PR's `draft` / `merged` / `state` fields |
| Branch | Source branch → target branch |
| Author | The PR author |
| Updated | Last-updated timestamp |
| Changes | Additions/deletions across the PR (`+N / -N`) |
Above the table, a **State** selector filters the list to `open`, `closed`, or `all` pull requests (defaults to `open`). Clicking a row opens that pull request's review workflow.
Under the hood this list comes from `AiPullRequestSummary` records — `number`, `title`, `repositoryName`, `url`, `state`, `draft`, `merged`, `sourceBranch`, `targetBranch`, `headSha`, `baseSha`, `author`, `createdAt`, `updatedAt`, `changedFiles`, `additions`, `deletions` — paginated per project (page is 1-indexed, 5 rows per page in the list view).
## Triggering a review run
From the review workflow view, pick a pull request and click **Run Review**. A run request carries whatever the backend needs to identify and analyze the PR: the project, repository name/URL, pull request number (the only strictly required field), title and URL, source and target branch, head and base commit SHA, provider, language, and either a pre-supplied file/diff payload or nothing (in which case PR Guard fetches the diff itself from the provider). An `options` block controls run behavior:
| Option | Purpose |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `maxComments` | Caps how many comments the review returns |
| `useSampleFallback` | Lets the run fall back to sample output if live analysis can't complete |
| `publishToProvider` | When true, PR Guard also posts its comments onto the pull request on the provider (see [Publishing back to the provider](#publishing-back-to-the-provider)) |
In the UI, this last option is the **Post to GitHub** checkbox next to the Run Review button — check it before running if you want comments posted to the PR itself, not just shown in Safeguard.
### Example: a run request
Clicking **Run Review** for PR #128 with **Post to GitHub** checked sends a request shaped like this (the UI only populates the fields it already knows — `projectId`, the PR number, and `options` — and lets PR Guard resolve the rest, including fetching the diff itself):
```json
{
"projectId": "482",
"pullRequestNumber": "128",
"options": {
"maxComments": 16,
"publishToProvider": true
}
}
```
The response returned immediately from this call is the freshly created run — typically still `QUEUED`, with empty `files` and `comments` arrays until analysis progresses.
## Run lifecycle and live progress
A review run moves through a status returned on every poll:
| Status | Meaning |
| ------------------------- | ------------------------------------------------- |
| `QUEUED` | The run has been accepted and is waiting to start |
| `RUNNING` | Analysis is in progress |
| `COMPLETED` / `completed` | The run finished successfully |
| `FAILED` / `failed` | The run did not complete; check `errorMessage` |
Both upper- and lowercase forms of the completed/failed statuses exist on the type — the UI normalizes whatever it receives to uppercase before comparing, so you don't need to worry about casing when reading a status back; just don't assume one case is authoritative.
While a run is `QUEUED` or `RUNNING`, Safeguard polls it (about every 2.5 seconds) and shows:
* **`currentStep`** — a short label for what the run is doing right now. The UI's pipeline view maps `currentStep` against an illustrative sequence — `FETCHING_PR`, `FETCHING_FILES`, `ANALYZING`, `PERSISTING_RESULTS`, `PUBLISHING_PROVIDER` (shown only when publishing was requested), `COMPLETED` — but `currentStep` is a free-form string on the type, not a closed enum, so treat this as the shape of progress reporting rather than a guaranteed set of values.
* **`progressPercentage`** — a 0–100 completion estimate, rendered as a progress bar.
A run also carries `jobId` / `runId` (identifiers for the run itself), and `createdAt` / `startedAt` / `completedAt` timestamps.
### Example: a run's progression across polls
A single run's `status`/`currentStep`/`progressPercentage` might look like this across successive polls (illustrative values — exact steps and percentages aren't guaranteed):
| Poll | `status` | `currentStep` | `progressPercentage` |
| --------------------- | ----------- | --------------------- | -------------------- |
| 1 | `QUEUED` | `null` | `0` |
| 2 | `RUNNING` | `FETCHING_PR` | `10` |
| 3 | `RUNNING` | `FETCHING_FILES` | `25` |
| 4 | `RUNNING` | `ANALYZING` | `60` |
| 5 | `RUNNING` | `PERSISTING_RESULTS` | `90` |
| 6 (publish requested) | `RUNNING` | `PUBLISHING_PROVIDER` | `95` |
| 7 | `COMPLETED` | `COMPLETED` | `100` |
If a run instead ends `FAILED`, the last poll carries `errorMessage` explaining why, and `score`/`summary`/`comments` are typically absent or empty — see [Common errors](#faq--troubleshooting).
## Run results
Once a run completes, it returns:
* **`score`** — an overall numeric score for the PR.
* **`summary`** — a short natural-language summary of the review.
* **`files`** — per-file results.
* **`comments`** — the individual review comments.
* **`warnings`** — any non-fatal issues encountered while producing the review (shown as inline alerts).
* **`source`** — where the reviewed content came from: `github` (PR Guard fetched the diff itself), `provided_diff` / `provided_files` (the request supplied `diff` or `files` directly), or `sample_fallback` / `fallback` (live analysis couldn't complete and, because `useSampleFallback` was set, PR Guard returned sample output instead of failing the run outright).
### Files
Each entry in `files` is an `AiCodeReviewFileResult`:
| Field | Description |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| `path` | File path |
| `status` | `pending`, `analyzed`, or `skipped` (the field isn't a strictly closed enum on the type, so treat other values as possible) |
| `changeType` | e.g. added/modified/removed, as reported by the provider |
| `additions` / `deletions` | Line counts for the file |
| `patch` | The unified diff for the file, rendered in the Files tab's diff viewer |
| `reason` | Present when `status` is `skipped` — why the file wasn't analyzed (also shown when no patch content is available) |
### Comments
Each entry in `comments` is an `AiCodeReviewComment`, scoped to a file and (optionally) a line:
| Field | Description |
| ------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| `severity` | `critical`, `high`, `medium`, `low`, or `info` |
| `category` | `security`, `bug`, `reliability`, `performance`, `maintainability`, `test`, `documentation`, or `architecture` |
| `path` / `line` | The file (and, if applicable, line) the comment applies to |
| `title` / `body` | The finding's headline and detail |
| `suggestedFix` | An optional proposed code change, shown as a distinct block under the comment |
| `confidence` | An optional confidence score for the finding |
| `publishedToProvider` / `providerCommentId` | Set once this individual comment has been posted to the provider (see below) |
The Overview tab rolls these up into a score, comment count, file count, a "High Risk" count (critical + high), and a risk breakdown by severity. The Comments tab lists every comment; the Files tab shows the diff for a selected file with that file's comments inline.
#### Example: a review comment
A `critical`-severity security finding on a specific line, with a suggested fix and provider publish state, looks like this:
```json
{
"id": 4821,
"severity": "critical",
"category": "security",
"path": "src/api/auth/session.ts",
"line": 47,
"title": "Session token compared with non-constant-time equality",
"body": "The `===` comparison on the session token leaks timing information an attacker could use to guess valid tokens byte-by-byte. Use a constant-time comparison instead.",
"suggestedFix": "if (!crypto.timingSafeEqual(Buffer.from(token), Buffer.from(expected))) {\n throw new UnauthorizedError();\n}",
"confidence": 0.86,
"publishedToProvider": true,
"providerCommentId": "PRRC_10293"
}
```
A lower-severity, informational comment with no fix and nothing published yet is just as valid — `suggestedFix`, `confidence`, `publishedToProvider`, and `providerCommentId` are all optional, so a minimal comment may only carry `severity`, `category`, `path`, `title`, and `body`.
## Publishing back to the provider
By default, PR Guard results only appear in Safeguard. Checking **Post to GitHub** (setting `options.publishToProvider: true` on the run request) tells PR Guard to also post its comments directly onto the pull request on the provider, so reviewers see them inline where they already work rather than needing to visit Safeguard.
Publishing is asynchronous and best-effort relative to the run itself:
* The response carries `publishToProvider` (whether publishing was requested for this run) and `providerReviewId` (set once the review has actually been posted to the provider).
* Individual comments carry their own `publishedToProvider` and `providerCommentId` once posted.
* In the UI, a run with publishing requested shows **"GitHub publish requested"** until `providerReviewId` is populated, then flips to **"Posted to GitHub"** — the publish step can complete after the rest of the analysis, so don't assume a `COMPLETED` run has already published.
* Because the run-level `providerReviewId` and each comment's `publishedToProvider` are set independently, it's possible for the run to show as posted while a handful of individual comments still show `publishedToProvider: false` (or vice versa, briefly, while the publish step is in flight) — check the field at the level you actually care about rather than assuming they always flip together.
## Review history
The History tab lists past runs for the project — pull request number and title, run date, comment count, status, and score — pulled from `listAiCodeReviewRuns` (paginated, 0-indexed, 10 per page by default). Selecting a past run loads its full result (via `getAiCodeReviewRun`) back into the Overview/Files/Comments tabs, so you can revisit an earlier review without re-running it.
## FAQ & Troubleshooting
**The tab shows "GitHub project required" and I can't run a review.**
PR Guard's current implementation is wired to GitHub pull requests. This appears when the project's connected repository provider isn't GitHub — connect the project via a GitHub-backed integration to use PR Guard.
**A run says `COMPLETED` but I don't see it on the pull request on GitHub.**
Check whether you enabled **Post to GitHub** for that run — publishing only happens when `publishToProvider` was set on the run request. If it was set, publishing can finish slightly after analysis; look for `providerReviewId` on the run (shown as "Posted to GitHub" vs. "GitHub publish requested" in the UI) before assuming it failed.
**A run is stuck in `RUNNING` or `QUEUED`.**
The UI polls active runs automatically; give it a few cycles. If a run ends in `FAILED`, check the `errorMessage` field surfaced in the run's progress panel for why it didn't complete.
**Why do some files show no diff?**
A file's `status` may be `skipped` (see its `reason`) or the provider may not have returned patch content for it — both are shown directly in the Files tab instead of an empty diff.
**I set `publishToProvider: true` and the run shows a `providerReviewId`, but a comment I'm looking at still has `publishedToProvider: false`.**
The run-level `providerReviewId` and each comment's `publishedToProvider` / `providerCommentId` are set independently — the review-level post to the provider and the per-comment posts aren't guaranteed to complete in lockstep. Treat the run as "posted" only for what `providerReviewId` covers, and check each comment's own `publishedToProvider` before assuming every comment made it onto the provider PR.
**A completed run's `source` is `sample_fallback` (or `fallback`) instead of `github`.**
This means live analysis couldn't complete and, because the request had `options.useSampleFallback: true`, PR Guard returned sample output instead of failing the run outright. Treat the `score`, `summary`, and `comments` on that run as illustrative rather than a real analysis of the PR's diff — rerun once the underlying issue (e.g. a diff PR Guard couldn't fetch) is resolved, or drop `useSampleFallback` if you'd rather the run fail loudly (`FAILED` with `errorMessage`) than return sample content.
## Related
* [Application Security Testing (SAST & DAST)](/docs/application-security-testing) — first-party static and dynamic scanning, distinct from PR Guard's diff-scoped AI review.
* [Unified Findings & Feature Flags](/docs/unified-findings) — how PR Guard's findings relate to the rest of Safeguard's consolidated findings model.
* [AutoTriage](/docs/autotriage) — cross-scanner deduplication and noise reduction for findings volume.
* [Griffin AI](/docs/griffin-ai) — the purpose-built LLM underpinning Safeguard's AI-driven analysis features.
* [CI/CD Integration](/docs/cicd-integration) — wiring Safeguard into your pipelines alongside pull-request-level review.
* [GitHub Integration](/docs/esscm/integrations/source-code/github) — connect the GitHub-backed repository a project needs before PR Guard's review actions are enabled for it.
# Product Offering (/docs/product-offering)
# Safeguard Product Offering
We're building AI models like OpenAI and Anthropic—but purpose-built for software supply chain security. Griffin AI delivers intelligent analysis and automated remediation. Multi-tenant architecture. Cloud agnostic. Architecture designed for FedRAMP HIGH and IL5.
## Enterprise Software Supply Chain Manager (ESSCM)
Your code, containers, AI models, and CI/CD pipelines—all potential attack vectors. Enterprise ESSCM delivers complete visibility with continuous scanning, intelligent prioritization, and AI Remediate capabilities. Know what's in your software before attackers do.
**Key Capabilities:**
* Source code analysis and SBOM generation
* Container image scanning
* AI model dependency tracking
* CI/CD pipeline security
* Continuous monitoring and alerting
* AI Remediate automated remediation
[Learn more about Enterprise ESSCM →](/docs/esscm)
## Portal
Scattered SBOMs mean scattered security. Portal centralizes SBOM management with secure third-party sharing, EO 14028 compliance verification, and complete audit trails. One platform. Total control. Zero compliance gaps.
**Key Capabilities:**
* Centralized SBOM repository
* Secure third-party sharing
* EO 14028 compliance verification
* Complete audit trails
* Version management
* Export in 30+ formats
[Learn more about Portal →](/docs/portal)
## Third Party Risk Manager (TPRM)
95% of breaches originate from third-party software. TPRM transforms vendor risk from blind spot to strategic advantage. Request, validate, and monitor supplier SBOMs with integrated remediation workflows.
**Key Capabilities:**
* Supplier SBOM requests
* Automated validation
* Continuous monitoring
* Risk scoring and prioritization
* Remediation workflows
* Compliance tracking
[Learn more about TPRM →](/docs/tprm)
## Open Source Manager (OSM)
Open source is everywhere—and so are its vulnerabilities. OSM provides comprehensive open source security intelligence with vulnerability tracking, attestation verification, and license compliance analysis. Make informed decisions about your dependencies.
**Key Capabilities:**
* Open source vulnerability database
* Package security intelligence
* Attestation verification
* License compliance
* Dependency health monitoring
* Security advisory tracking
[Learn more about OSM →](/docs/osm)
## API Platform (Console)
**Early access.** The API Platform is one OpenAI-compatible API for model inference: your applications send chat completion requests to Safeguard with an API key, and each request is metered against prepaid credit at the provider's list price, with no markup on third-party models. The inference API is deployed and switched off; Safeguard turns it on per workspace for customers who choose **Use with Safeguard** at [safeguard.sh/models](https://safeguard.sh/models).
**In the Console:**
* API keys issued by Safeguard's servers, with the secret shown once, and an optional monthly spend limit and rate limit per key
* A workbench to try a model and see each run's tokens, cost and latency
* Usage: requests, tokens and cost by model and by key, and a metadata-only request log
* Credit, the credit ledger and the workspace's monthly spend limit
[Learn more about the API Platform →](/docs/console)
## Griffin AI
Purpose-built LLM for software supply chain management with natural language search, intelligent analysis, and automated remediation recommendations.
[Learn more about Griffin AI →](/docs/griffin-ai)
## Platform Capabilities
| Capability | Description |
| ---------------------- | --------------------------------------------- |
| **FedRAMP HIGH & IL5** | Enterprise-grade security architecture target |
| **30+ Export Formats** | CSV, JSON, Excel, SPDX, CycloneDX, and more |
| **API & MCP Server** | Full automation support |
| **Multi-tenant** | Complete tenant isolation |
| **Cloud Agnostic** | Deploy anywhere |
| **AI Remediate** | Automated remediation powered by Griffin AI |
## Add-on Modules
| Add-on | Description |
| ----------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **On-Prem Deployment** | Deploy Safeguard in your own infrastructure |
| **[IDE Extension](https://marketplace.visualstudio.com/items?itemName=Safeguard-sh-Inc.SafeguardshIdeExtension)** | Real-time vulnerability detection for VS Code, Cursor, and all JetBrains IDEs (IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, GoLand, RubyMine, CLion, Rider, DataGrip, AppCode, Android Studio). Available on [VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=Safeguard-sh-Inc.SafeguardshIdeExtension), [Open VSX](https://open-vsx.org/extension/Safeguard-sh-Inc/SafeguardshIdeExtension), and [JetBrains Marketplace](https://plugins.jetbrains.com/plugin/30031-safeguard-sh-ide-extension) |
| **Role Permission Based Tenant Control** | Advanced RBAC with hierarchical organization management |
# RBAC, Teams & Organizations (/docs/rbac-teams)
# RBAC, Teams & Organizations
Safeguard's identity and access layer is built for organizations that need clear ownership boundaries, tight least-privilege defaults, and a full audit trail.
## Hierarchy
```
Organization
└─ Team
└─ Project
└─ Asset
```
* **Organization** — the top-level tenant boundary. Billing, SSO, audit log, compliance configuration live here.
* **Team** — a group of users with shared access. Roles are scoped to a team or to the whole organization.
* **Project** — a unit of ownership inside a team (often one project per service or repository).
* **Asset** — concrete things (repositories, images, SBOMs, vendors, workloads) assigned to a project.
A user can belong to multiple teams and hold different roles in each.
## Roles
Built-in roles:
| Role | Scope | Permissions |
| --------------------- | ------------ | -------------------------------------------------------------------------------- |
| **Owner** | Organization | Everything, including billing and deletion. |
| **Admin** | Organization | Everything except billing and tenant deletion. |
| **Security Lead** | Org or Team | Manage policies, exceptions, workflows, integrations. |
| **Security Engineer** | Org or Team | Triage and remediate findings; cannot modify policy. |
| **Developer** | Team | View findings on assigned assets; run auto-fix against them; request exceptions. |
| **Auditor** | Org | Read-only access to all audit records, findings, and compliance evidence. |
| **Viewer** | Any | Read-only access within scope. |
Custom roles are composed from a permissions matrix:
```yaml
apiVersion: safeguard.sh/v1
kind: Role
metadata:
name: production-responder
spec:
permissions:
- findings:read
- findings:triage
- policies:evaluate
- workflows:run
restrictions:
environments: ["production"]
severity_max: "critical"
```
## SSO
Safeguard supports:
* **SAML 2.0** — all major IdPs (Okta, Entra ID, Google Workspace, OneLogin, Duo, JumpCloud, PingID, Authentik, Keycloak).
* **OpenID Connect** — any OIDC 1.0 provider.
* **SCIM 2.0** — automated user provisioning and deprovisioning.
* **Just-in-time provisioning** — users are created on first SSO login with a default role you configure.
Enterprise tenants can require SSO for every login (no local passwords) and require re-authentication for sensitive actions (policy changes, approving exceptions).
See [SSO Authentication Setup](/docs/sso-authentication) for step-by-step configuration instructions per provider, including Google Workspace, Microsoft Entra ID, Okta, and OneLogin.
## MFA
* WebAuthn / passkeys (preferred).
* TOTP via authenticator apps.
* Hardware security keys (FIDO2).
* Phone/SMS MFA is disabled by default and not available in FedRAMP tenancies.
Policies can require a specific MFA level for specific actions (e.g., "promoting a self-heal to production requires a passkey re-auth").
## API Keys and Tokens
Safeguard has two distinct families of long-lived credential: **user API keys** (and the related service tokens / workload identities), which all act as something scoped under a user or service identity, and **organization secret keys**, which act as the organization itself. They're easy to confuse because both let something authenticate against Safeguard programmatically, but they're generated in different places, used for different purposes, and revoked with different effects — see [User API keys vs. organization secret keys](#user-api-keys-vs-organization-secret-keys) below before deciding which one you need.
### User API keys
* **User API keys** — bound to a user, inherit the user's role. Revoked if the user is deprovisioned.
* **Service tokens** — bound to a service identity, used for CI / automation. Scoped to specific permissions.
* **Workload identities** — OIDC-federated tokens from GitHub, GitLab, AWS, Azure, GCP. No long-lived secrets.
All tokens are short-lived by default (max 1 hour unless explicitly extended), and their usage is auditable.
Generate at **Settings → API Keys**. There is no CLI command for this yet.
### Organization secret keys
A secret key is scoped to your **organization**, not to any individual user — it's the credential the [Guard SDK](/docs/guard-sdk) uses to pull your organization's live policy into an embedded agent or MCP server process. Because it belongs to the organization rather than a person, a secret key keeps working across individual user offboarding: revoking a user's account (see [Deprovisioning](#deprovisioning) below) has no effect on any secret key, since the key was never tied to that user in the first place.
Secret keys are generated from **Settings → Developer**. The generation flow (naming a purpose, copying the one-time key value, and wiring it into your agent process via the `SG_SECRET_KEY` environment variable) is already covered step-by-step in [Guard SDK: Generate a Secret Key](/docs/guard-sdk#generate-a-secret-key) — follow that page rather than re-deriving the steps here.
> The **Developer** tab is currently only visible under the ESSCM product context. If you don't see it under Settings, check that you're viewing Settings from within ESSCM.
#### Managing and revoking secret keys
Existing keys are listed on the Developer tab, where each key can be revoked or deleted individually.
> Revoking a secret key takes effect immediately. Any Guard SDK instance still configured with that key will fail to pull fresh policy on its next background sync — treat revocation as an immediate, org-wide cutoff, not a graceful rollover.
#### User API keys vs. organization secret keys
| | User API key | Organization secret key |
| --------------------- | ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- |
| **Scope** | An individual user; inherits that user's role | The organization itself — not tied to any one user |
| **Where generated** | Settings → API Keys | Settings → Developer (currently only visible under the ESSCM product context) |
| **Used for** | Calling the Safeguard API as that user | Authenticating the [Guard SDK](/docs/guard-sdk) so it can pull organization policy into an embedded agent/MCP server process |
| **Revocation effect** | Automatically revoked when that user is deprovisioned | Revoked on demand from the Developer tab; takes effect immediately and invalidates every Guard SDK instance still using it |
**Common errors:** a Guard SDK instance suddenly failing to refresh its policy is expected behavior if its secret key was recently revoked or deleted from the Developer tab — generate a new key and reconfigure the affected instance rather than treating it as an outage. For SDK-side connection and startup issues unrelated to key revocation, see the Guard SDK [FAQ & Troubleshooting](/docs/guard-sdk#faq--troubleshooting).
## Audit Log
Every action that mutates state is recorded:
* Who (user, service, workload identity).
* What (action + before/after where applicable).
* When (UTC + timezone).
* Where (IP, session ID, client type).
* Why (linked ticket / PR / policy exception if provided).
Audit log is append-only, cryptographically chained, and retained for the period your tenancy allows (90 days default; up to 7 years configurable for Enterprise).
A single entry follows the same who/what/when/where/why shape described above; illustratively:
```json
{
"id": "audit_01J9K...XYZ",
"actor": { "type": "user", "id": "usr_4f2a", "email": "jane@acme.com" },
"action": "role.assigned",
"before": { "role": "Viewer" },
"after": { "role": "Security Engineer" },
"target": { "type": "team", "id": "team_payments" },
"occurred_at": "2026-06-14T18:22:41.003Z",
"ip": "203.0.113.42",
"session_id": "sess_9c1d",
"client": "web",
"reason": { "type": "exception_link", "ref": "exc_7781" }
}
```
> Field names above illustrate the who/what/when/where/why shape, not a literal fixed export schema — treat this as the concept, not an exact field reference.
> This is the RBAC/organization audit log — the record of who changed what in Safeguard itself (role grants, key revocations, settings changes). It's distinct from Guard's own request-level audit trail, which records every `allow` / `deny` / `monitor` decision Guard makes on agent traffic. See [Audit Trail & Alerts](/docs/guard-audit-alerts) if you're looking for that instead.
### Audit streaming
Stream the audit log to your SIEM in real time via:
* Webhook (JSON per event).
* S3 with scheduled batch export.
* OpenTelemetry logs.
* Splunk HEC.
To stream via webhook, subscribe to the `audit.action` event — the same event catalog and delivery mechanism (signed payloads, retries, DLQ) described in [Webhooks & Events](/docs/webhooks-events) applies here. Create the subscription on the **Webhooks** page; there is no CLI command for this yet.
## Approval Workflows
Sensitive actions can require multi-party approval:
* Policy changes.
* Large exception grants.
* Production-impacting auto-fix merges.
* Service-token creation.
* Org-level configuration changes.
Configure under **Settings → Approvals**.
This is the RBAC side of who is *allowed* to approve. The approver list for a specific guardrail exception is configured at the policy level, as part of the rule itself — for example, the `exception.approvers` field on a blocking rule:
```yaml
rules:
- id: no-known-exploited-critical
effect: BLOCK
exception:
allowed: true
approvers: ["security-leads@company.com"]
```
See [Guardrails & Enforcement: Exceptions and Breakglass](/docs/guardrails-enforcement#exceptions-and-breakglass) for the full policy-level mechanics — this page covers the org's role and approval model that governs who can act in that capacity.
## Break-Glass
Emergency access for incident response:
* A break-glass role grants elevated permissions for a time-boxed window.
* Break-glass invocations require two approvers and notify the entire security team.
* Every break-glass action is separately labeled in the audit log and reviewed post-incident.
This is the same "emergency breakglass exception" mechanism described from the guardrail-enforcement side in [Guardrails & Enforcement](/docs/guardrails-enforcement#exceptions-and-breakglass): a two-person approval requirement backed by a role grant, applied to a specific blocking guardrail rather than to the whole organization.
## Per-Asset Permissions
Permissions can be sliced by asset labels:
```yaml
- role: Security Engineer
scope:
labels:
team: payments
env: [production, staging]
```
Useful for consultants and contractors who should only see a specific service.
## Deprovisioning
When a user is deprovisioned (SCIM or manual):
* All sessions revoked.
* All user API keys revoked.
* All pending approvals reassigned to their team.
* Actions they took remain in the audit log forever.
Service tokens, workload identities, and organization secret keys are **not** touched by deprovisioning — they're bound to a service identity or the organization, not to the departing user's account (see [User API keys vs. organization secret keys](#user-api-keys-vs-organization-secret-keys) above). If the person leaving was the one who created a CI service token or a Guard SDK secret key, revoke those separately as part of offboarding.
## FAQ & Troubleshooting
**I see different role names (Admin, Manager, Contributor, Viewer) somewhere else in Safeguard — is that the same RBAC system as this page?**
No. This page documents the core organization/team RBAC model (Owner, Admin, Security Lead, Security Engineer, Developer, Auditor, Viewer). Some product surfaces layer their own role vocabulary on top for that surface only — for example see [Portal User Roles](/docs/portal/user-roles) for Portal's Admin / Manager / Contributor / Viewer roles. If a permission looks wrong, check which role system the page you're on is actually describing before assuming it's a bug.
**I deprovisioned a user, but a service they set up (a CI job, an MCP server using the Guard SDK) is still authenticating successfully. Is that a bug?**
No — that's expected. Deprovisioning only revokes credentials tied to the user's own account (sessions, user API keys). Service tokens, workload identities, and organization secret keys are independent of any one user by design, so they keep working after that person leaves. Revoke them explicitly if they should no longer be trusted.
**We deprovisioned a user via SCIM but their access didn't disappear instantly — why?**
SCIM deprovisioning is triggered by your IdP pushing a deactivation event to Safeguard, not by Safeguard polling the IdP. If your IdP batches or schedules SCIM syncs (common with some group-based deprovisioning setups) rather than pushing immediately on offboarding, there can be a delay before Safeguard receives the event. For anything time-sensitive, deprovision manually from Safeguard as well rather than relying solely on SCIM timing.
**What's the difference between the "Audit Log" on this page and Guard's "Audit Trail"?**
This page's audit log records changes to Safeguard itself — role grants, key revocation, settings changes, approvals. [Guard's audit trail](/docs/guard-audit-alerts) is a separate, higher-volume log of every individual `allow` / `deny` / `monitor` decision Guard makes on agent/MCP traffic. Both are audited and both are exportable, but they answer different questions: "who changed what in Safeguard" versus "what did Guard do with this request."
**A custom role isn't granting the access I expect — where do I start debugging?**
Check the permissions list and any `restrictions` block on the role definition first (for example, a `severity_max` or `environments` restriction silently narrows an otherwise-broad permission, as in the `production-responder` example above). Then check whether the user's access is coming from the role you think it is — a user in multiple teams can hold a different role in each, so confirm which team scope the resource you're testing falls under.
## Related
* [Web Application](/docs/web-app) — SSO login flow.
* [Desktop Application](/docs/desktop-app) — per-user system-access consent.
* [Organization Management](/docs/esscm/organization-management) — org-level configuration surface.
* [Guard SDK](/docs/guard-sdk) — generate and use an organization secret key to embed live policy enforcement in an agent or MCP server.
* [SSO Authentication Setup](/docs/sso-authentication) — provider-by-provider SAML/OIDC/OAuth configuration.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — where exception approvers and breakglass are configured at the policy level.
* [Webhooks & Events](/docs/webhooks-events) — the full event catalog and delivery mechanics behind audit streaming.
* [Audit Trail & Alerts](/docs/guard-audit-alerts) — Guard's own per-request audit trail, distinct from the organization audit log on this page.
* [Portal User Roles](/docs/portal/user-roles) — Portal's separate, surface-specific role system.
* [Compliance](/docs/compliance) — how RBAC maps to compliance controls.
# Vulnerability Prioritization (Reachability Analysis) (/docs/reachability-analysis)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Vulnerability Prioritization
A typical enterprise application has 200–500 direct and transitive dependencies, and 5–15% of them have known CVEs at any moment. Most are unreachable in the context of how the application actually uses the library. Reachability analysis tells you which CVEs are actually relevant, so your team patches the ones that matter.
Safeguard's prioritization engine combines four signals: **reachability**, **exploitability (EPSS + KEV)**, **runtime context**, and **business context**. The result is a single ranked backlog that typically shrinks open findings by 60-80% without missing real risk.
## The Four Signals
### 1. Reachability
A CVE is "reachable" when your code actually calls the vulnerable function or triggers the vulnerable code path.
Safeguard performs three kinds of reachability analysis:
* **Static reachability** — builds a call graph from your source, lockfile, and bytecode, and checks whether any path leads to the vulnerable sink.
* **Dynamic reachability** — at runtime, the collector records which modules and functions are actually loaded and invoked in your production workloads. Flags never-executed vulnerable paths as cold.
* **Configuration reachability** — parses framework configuration (e.g., Spring bean definitions, Next.js route files) to determine if code is wired in at all.
A vulnerability is classified as:
* **Reachable** — a real call path exists and is instantiated at runtime.
* **Conditionally reachable** — path exists but requires a feature flag, route, or configuration not currently enabled.
* **Unreachable** — no call path exists in your compiled code.
* **Unknown** — the analyzer couldn't decide (e.g., dynamic dispatch, reflection, native code). Marked conservatively as potentially reachable.
### 2. Exploitability — EPSS and KEV
* **EPSS** (Exploit Prediction Scoring System) estimates the probability of exploitation within 30 days. Safeguard ingests the daily EPSS feed.
* **KEV** (CISA Known Exploited Vulnerabilities) lists vulnerabilities observed being exploited in the wild. If a CVE is on KEV, exploitation is not hypothetical.
* **Weaponization signal** — Safeguard tracks public PoC availability (exploit-db, GitHub PoC repos, Metasploit modules) as an additional exploit-availability signal.
### 3. Runtime Context
A vulnerability in code that only runs in a dev Docker compose file is not the same as a vulnerability in the production API. The runtime collector labels each asset with:
* `env`: production, staging, dev, sandbox.
* `exposure`: internet-facing, internal, air-gapped.
* `data_class`: customer PII, PHI, PCI, public.
* `criticality`: inferred from asset ownership and business tags.
These labels feed into the prioritization score.
### 4. Business Context
Via policy you can declare which assets are regulated (PCI, HIPAA, FedRAMP), which handle customer data, and which are on the critical path for revenue. Findings on those assets rank higher.
## The Unified Priority Score
Each finding gets a **Priority Score** from 0-100:
```
priority = f(
base_severity, // CVSS 3.1 base score
epss_probability, // 0.0 - 1.0
kev_listed, // boolean
poc_available, // boolean
reachability_class, // reachable | conditional | unreachable | unknown
env, // production > staging > dev
exposure, // internet-facing > internal
data_sensitivity, // regulated > public
business_criticality // policy-defined
)
```
The exact weights are configurable per tenant (**Settings → Prioritization**). Defaults map to the intuitive ordering:
1. Reachable + KEV-listed + production → Priority 90-100 (P0).
2. Reachable + EPSS > 0.5 + production → Priority 75-89 (P1).
3. Reachable + high CVSS + staging → Priority 50-74 (P2).
4. Unreachable + any severity → Priority 0-30 (backlog; auto-suppressed in some views).
## Typical Noise Reduction
Based on aggregate data across customer tenants:
| Source of reduction | % findings removed from "urgent" queue |
| ----------------------------------- | -------------------------------------- |
| Reachability filtering | 60-80% |
| EPSS \< 0.05 | additional 5-15% |
| Asset-class filtering (dev/sandbox) | additional 5-10% |
| Combined deduplication | additional 5-10% |
A typical mid-sized team sees an **open urgent queue of 20-60 CVEs per week instead of 200-500**.
## Language and Ecosystem Support
Reachability analysis quality varies by language. Current support:
| Language / Ecosystem | Static reachability | Dynamic reachability | Notes |
| ------------------------------- | ------------------- | -------------------- | ------------------------------------------------------ |
| **Java / Kotlin / Scala (JVM)** | GA | GA | High-fidelity analysis of compiled code. |
| **Python** | GA | GA | Handles virtualenv layouts. |
| **JavaScript / TypeScript** | GA | GA | Handles CommonJS, ESM, and webpack bundles. |
| **Go** | GA | GA | Module-aware, high-fidelity call paths. |
| **Rust** | GA | GA | Cargo-aware call-path extraction. |
| **C / C++** | GA | GA | Call-path reachability across common package managers. |
| **Ruby** | Preview | GA | Conservative resolution for metaprogramming. |
| **PHP** | Preview | GA | Composer-aware; Symfony / Laravel-aware. |
| **C# / .NET** | GA | GA | NuGet-aware. |
| **Swift / Objective-C** | Preview | Preview | Framework-aware. |
## How to View It
### Vulnerabilities Tab (ESSCM)
The vulnerabilities table has a **Priority** column and a **Reachability** column. Default sort is Priority descending.
Common filters:
* `reachable:true` — only reachable findings.
* `kev:true` — only KEV-listed findings.
* `epss:>0.3` — only probability above 30%.
* `env:production reachable:true kev:true` — the P0 backlog.
### Griffin Natural Language
Griffin understands the prioritization surface directly:
```
"Show my P0 findings in production that are reachable."
"Which of last week's new CVEs are reachable but not yet on KEV?"
"Summarize the top 10 priorities for the payments service."
```
### Dashboards
The **Prioritization** dashboard shows:
* Total finding volume vs. urgent queue (trend over time).
* Time-to-remediate by priority band.
* Drop rate for each signal (how much each layer filtered out).
* Backlog aging — how long findings sit before being patched, suppressed, or excepted.
## Integrating With Policy
Reachability feeds directly into guardrails. A production-admission policy might say:
```yaml
- id: no-reachable-kev-in-prod
condition: |
env == "production"
AND any(vulnerabilities,
reachability_class in ["reachable", "conditional"]
AND kev == true
)
effect: BLOCK
```
See [Guardrails & Enforcement](/docs/guardrails-enforcement) for the full policy language.
## When Reachability Doesn't Help
Reachability is not a silver bullet. It's weakest when:
* Code executes dynamically via reflection, eval, or unsafe dispatch. Safeguard marks these as `unknown` and does not suppress them.
* Vulnerabilities are data-driven (e.g., accepts a malicious input even though the function is unreachable by static analysis).
* The vulnerable code path runs only under specific configurations that the analyzer cannot enumerate.
For these cases, rely on the other signals (KEV, EPSS, runtime observation) and conservative defaults.
## Auto-Fix and Griffin Integration
Once a finding is prioritized, Griffin can:
* Propose a minimum-risk upgrade that resolves the vulnerability.
* Generate a safe-downgrade when a patched version doesn't yet exist.
* Explain *why* a finding was de-prioritized (essential for exception reviews).
* Auto-open PRs for the top-N priorities on a schedule.
See [Auto-Fix](/docs/esscm/auto-fix).
## API
There is no CLI command for querying findings by priority yet. Via API:
```bash
curl -H "Authorization: Bearer $SG_TOKEN" \
"https://api.safeguard.sh/v1/findings?asset=my-api&reachable=true&min_priority=75"
```
## Related
* [Continuous Scanning](/docs/continuous-scanning) — how findings get detected.
* [Vulnerabilities](/docs/esscm/vulnerabilities) — the ESSCM vulnerabilities UI.
* [Auto-Fix](/docs/esscm/auto-fix) — how Griffin remediates prioritized findings.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — enforcing policies on reachable findings.
* [AI Models](/docs/ai-models) — Griffin, Eagle, Lino and how they power prioritization.
# Red Team (Defensive Adversary Emulation) (/docs/red-team)
# Red Team (Defensive Adversary Emulation)
Safeguard's Red Team engine is a **defensive** capability: it emulates adversary behavior to validate that your detections fire and to map how an attacker could chain your existing exposures — **without** executing weaponized exploits. It is built for breach-and-attack simulation (BAS) and purple-teaming, not offense.
> **Defensive-only by design.** The engine emits benign detection canaries that map to MITRE ATT\&CK techniques. It does **not** ship, download, or run real exploit payloads, and it will not attempt to gain unauthorized access. Every active step is gated by controls enforced in code (see below).
## What it does
| Capability | What it means |
| -------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Breach-and-attack simulation (BAS)** | Safe simulators exercise ATT\&CK techniques by emitting **benign detection canaries** — observable-but-harmless signals designed to prove whether your monitoring detects the behavior. No real payloads are executed. |
| **Purple-teaming** | Pairs each simulated technique with the detection you expect, so gaps surface immediately: technique fired, but nothing alerted. |
| **Attack-path graph** | Builds a graph of how known exposures could chain together, then correlates them into a **unified risk** view so the highest-leverage paths rise to the top. |
| **Safe recon** | Read-only reconnaissance against in-scope, verified assets — enumeration and mapping only, never intrusive or state-changing. |
| **AI/LLM guardrail validation** | A harness that probes your AI guardrails (e.g. prompt-injection and jailbreak resistance) with benign test cases to confirm the guardrails hold. |
## The safety kernel
Every **active** step is gated by layered controls that are enforced in code — not as UI conveniences:
* **Signed rules of engagement (RoE).** Active emulation cannot start without a signed RoE defining what is authorized.
* **Verified + in-scope only.** Targets must be ownership-verified and fall inside an allow-listed scope. Out-of-scope actions are blocked and logged.
* **Rate & blast-radius caps.** Mandatory limits bound request rate, concurrency, and impact.
* **Human approval for high-impact steps.** Anything above a low-impact threshold requires explicit human sign-off before it runs.
* **Global kill-switch.** A single control halts all active emulation immediately.
* **Full audit trail.** Every step is recorded with actor, tenant, timestamp, and outcome.
## Unified risk correlation
Attack-path findings don't live in a silo. They flow into the [unified findings model](/docs/unified-findings) discriminated as `redteam`, and correlate with SAST, DAST, runtime, and SCA findings so that a reachable, exposed, exploitable path — confirmed by emulation — is prioritized above theoretical risk.
## Configuration
The Red Team engine is **admin-toggleable** via a [feature flag](/docs/unified-findings#feature-flags), enforced server-side. When enabled:
1. Register and verify the assets in scope.
2. Upload a signed rules-of-engagement document.
3. Choose the techniques/paths to exercise and the safety caps.
4. Review results in the unified findings view, correlated with your other engines.
## Related
* [Unified Findings & Feature Flags](/docs/unified-findings) — where Red Team findings land and how the engine is toggled.
* [Application Security Testing (SAST & DAST)](/docs/application-security-testing) — the source and dynamic engines Red Team paths correlate with.
* [Runtime Protection (CWPP & CNAPP)](/docs/runtime-protection) — runtime signals that confirm reachability.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — using validated findings as policy gates.
# Release Notes (/docs/release-notes)
# Release Notes
Stay up to date with the latest features, improvements, and fixes across all Safeguard products.
## July 2026
**First-party Security Engines**
Safeguard now ships a suite of first-party, defensive security engines, all reporting into one unified findings model and each independently admin-toggleable via server-enforced feature flags:
* **Application Security Testing (SAST & DAST)** - static source analysis and defensive, authorized dynamic testing.
* **Red Team (Defensive Adversary Emulation)** - breach-and-attack simulation and purple-teaming using benign ATT\&CK detection canaries (no weaponized payloads), attack-path graph with unified risk correlation, safe recon, and an AI/LLM guardrail-validation harness - gated by a signed rules-of-engagement, scope checks, rate/blast caps, human approval for high-impact steps, a global kill-switch, and full audit.
* **AI-SPM** - model-artifact malware scanning (pickle opcode disassembly, torch-zip walker, safetensors/GGUF validation).
* **DSPM** - sensitive-data classification (PII/PHI, Luhn-validated PCI, entropy-gated secrets) with an enforced redaction mandate.
* **Runtime Protection (CWPP & CNAPP)** - ATT\&CK-mapped runtime threat rules and cloud-native risk correlation. The eBPF runtime collector is a Linux follow-on, rolling out.
* **Package Firewall** - inline install-time allow/warn/block for dependencies, with audit and quarantine modes.
* **AutoTriage** - cross-scanner deduplication and noise reduction with a measured reduction metric; never suppresses malware or secrets findings.
***
## January 2026
### v3.0.0 - January 3, 2026
**Major Release: Griffin AI General Availability**
#### New Features
* **Griffin AI GA** - Purpose-built LLM for supply chain security now available to all customers
* **AI Remediate 2.0** - Enhanced automated remediation with multi-language support
* **MCP Server** - Model Context Protocol server for AI integrations
* **Container AI Analysis** - Deep learning-based container image analysis
#### Improvements
* 60% faster SBOM generation
* Enhanced natural language search capabilities
* Improved reachability analysis accuracy
* Better transitive dependency resolution
***
## December 2025
### v2.9.0 - December 15, 2025
#### New Features
* **IL5-Targeted Deployment** - Air-gapped deployment mode designed for Impact Level 5 workloads
* **Bulk AI Remediate** - Fix multiple vulnerabilities in one PR
* **Custom Export Templates** - Create branded SBOM reports
* **Vendor Portal** - Self-service portal for TPRM vendors
#### Improvements
* Updated vulnerability database coverage
* Improved Go module analysis
* Enhanced Rust crate support
* Better monorepo handling
***
## November 2025
### v2.8.0 - November 20, 2025
#### New Features
* **Third Party Risk Manager** - New product for vendor SBOM management
* **EPSS Integration** - Exploit prediction scoring
* **CISA KEV Alerts** - Known exploited vulnerability notifications
* **Scheduled Scans** - Automatic recurring SBOM generation
#### Improvements
* Redesigned dashboard
* Improved search performance
* Enhanced mobile experience
* Better notification management
***
## October 2025
### v2.7.0 - October 10, 2025
#### New Features
* **Open Source Manager** - New product with Gold Directory
* **Attestation Verification** - SLSA and Sigstore support
* **License Policy Engine** - Advanced license compliance
* **API v2** - New REST API with improved performance
#### Improvements
* 50% reduction in false positives
* Improved component identification
* Enhanced API rate limits
* Better error messages
***
## How to Update
### Cloud Users
All cloud deployments are automatically updated. No action required.
### On-Premises Users
1. Download the latest release from the customer portal
2. Review the upgrade notes
3. Follow the upgrade procedure in the deployment guide
## Feedback
We value your feedback! Share your thoughts:
* Email: [hi@safeguard.sh](mailto:hi@safeguard.sh)
* In-app feedback button
* Feature requests via customer portal
# Local Runner (/docs/runner)
# Local Runner
The runner is not a separate product. It is part of the `safeguard` CLI: open
the interactive terminal, sign in, and the machine starts polling the platform
for work assigned to it. It runs each scan job locally and uploads only the
resulting SBOM and findings, never your source code.
## When to use it
* Your repository is private and you can't (or won't) give a cloud service OAuth access.
* You're working in a restricted network, where only outbound HTTPS is allowed.
* You want the assistant to fix vulnerabilities in code you haven't pushed yet.
## Install
The runner ships with the CLI. Use the one-line installer:
```bash
# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash
```
```powershell
# Windows
irm https://cli.safeguard.sh/install.ps1 | iex
```
There is no Homebrew formula, winget package or container image for it. See
[CLI installation](/docs/cli/installation) for version pinning and checksums.
## First run
```bash
safeguard
```
Type `/login`. Your browser opens, you approve the session, and the runner
starts. The first run also downloads the scanner tools and the vulnerability
database. `safeguard runner` opens the same terminal.
## How it works
1. The runner sends a heartbeat and polls the platform for jobs assigned to
this machine. All traffic is outbound HTTPS that the runner opens; nothing
connects to it.
2. It executes a claimed job with its own local scan server.
3. It uploads the result files (SBOM and findings) and reports the job status.
Source code stays on the machine.
## Headless
```bash
# Start without the terminal UI and serve assistant turns for this workspace
safeguard runner start --workspace ./path/to/repo
# Is it running, and what is it doing
safeguard runner status
# Drain in-flight work and stop
safeguard runner stop
```
`runner start` long-polls by default. On a network that forbids held
connections, pass `--poll-wait 0` to poll at a fixed interval
(`SAFEGUARD_POLL_INTERVAL` seconds, default 10). `--permission-mode` sets how
much the assistant may do without asking, from `supervised` to `autonomous`.
## Assistant
```bash
# Interactive, in this workspace
safeguard agent "fix the critical CVEs in this repository"
# One turn, no prompts, for scripts and CI
safeguard exec "summarise the critical findings"
```
`safeguard exec` defaults to `strict` permissions, where nothing is asked and
anything the policy file has not pre-approved is denied.
## Updates
```bash
safeguard self-update
```
`safeguard update` is different: it refreshes the vulnerability databases, not
the binary.
# Runtime Protection (CWPP & CNAPP) (/docs/runtime-protection)
# Runtime Protection (CWPP & CNAPP)
Runtime protection watches workloads as they execute and correlates runtime signals with the rest of your posture, so risk that is actually live rises above theoretical risk.
## Runtime threat detection (CWPP)
Safeguard ships a runtime rule engine that detects suspicious workload behavior — shells spawned in containers, sensitive file access, unexpected network activity, privilege changes — and maps each rule to the relevant **MITRE ATT\&CK** technique so alerts arrive with adversary context.
> **Rollout note.** Runtime protection is available, with the **eBPF runtime collector** rolling out. The collector is a **Linux follow-on** and is decoupled from the rule engine, so detection is available independently of the collector's rollout. eBPF-based collection is **not** claimed as generally available yet.
### Detection rule packs
Managed rule packs each map to an ATT\&CK technique:
| Rule pack | Triggers on | ATT\&CK |
| ------------------------ | ----------------------------------------------------------------------------------------------- | ------- |
| **Reverse shell** | A shell whose input/output is wired to a network connection | T1059 |
| **Crypto-miner** | Connection to a known mining pool, or sustained high CPU with miner-class arguments | T1496 |
| **Container escape** | Known container-escape techniques — namespace breakout, privileged mounts, and host-root access | T1611 |
| **Fileless / in-memory** | Execution of a payload that runs from memory without ever touching disk | T1620 |
| **Privilege escalation** | Escalation to root, and anomalous `sudo` / `pkexec` use | T1548 |
| **LOLBin chain** | Download tools piped into a shell; scheduled-task writes from a workload | T1105 |
Per-workload allow-lists suppress benign shells (for example in interactive dev containers), and tenants can add custom rules in the same schema, tenant-scoped and audited on load.
### Runtime SCA / reachability
From library-load events, the engine records which packages actually load and which functions execute per workload, and feeds this to [AutoTriage](/docs/autotriage): a statically-reachable CVE gets upgraded to runtime-confirmed (priority up), and a never-loaded package is demoted (priority down). Reachability only *re-ranks* CVE/SCA findings — it **never suppresses a malware finding**.
## Gated runtime response
Beyond detection, runtime protection can respond — always policy-gated and safe-fail:
| Action | Mechanism | Gate |
| -------------- | -------------------------------------------------- | ----------------------- |
| **Alert** | Emit event/finding only | Default, always allowed |
| **Block** | Drop the offending connection | Policy |
| **Kill** | Terminate the offending process | Policy + approval |
| **Quarantine** | Cordon the pod and apply a deny-all network policy | Policy + approval |
| **Isolate** | Full network isolation of the workload | Policy + approval |
The default policy is detect-and-alert only until a tenant explicitly opts in. Destructive actions require human approval unless a specific high-confidence rule is opted into auto-response. Responses are **safe-fail** — a failed action is recorded and never crashes the protected workload — rate-capped (a storm degrades to alert-only), and reversible where applicable. `kill` only ever targets the offending process, precisely identified so no other process is affected.
## Cloud-native risk correlation (CNAPP)
The CNAPP layer correlates findings across dimensions to identify the risks that matter most — a workload that is simultaneously:
* **Running** — actually executing, not just defined,
* **Reachable** — exposed on a network path,
* **Exposed** — accessible from an untrusted boundary, and
* **Over-privileged** — holding more permission than it needs.
A finding that lights up all four is prioritized far above one that lights up only one. This correlation flows into the [unified findings model](/docs/unified-findings) and shares correlation keys with SAST, DAST, and Red Team so a confirmed, reachable, exploitable issue is treated as such.
## Findings
Runtime findings land in the unified findings view as runtime findings, tenant/org-scoped end to end, with the ATT\&CK mapping and the correlation dimensions that fired.
## Configuration
Runtime protection is **admin-toggleable** via a [feature flag](/docs/unified-findings#feature-flags), enforced server-side. The rule engine is available today; deploy the runtime collector (rolling out for Linux) to feed it live events.
## Related
* [Unified Findings & Feature Flags](/docs/unified-findings) — where runtime findings land and how the engine is toggled.
* [Reachability Analysis](/docs/reachability-analysis) — the reachability dimension of the correlation.
* [Red Team](/docs/red-team) — emulation that validates whether runtime detections fire.
* [SecOps (SIEM)](/docs/secops) — runtime events feed the SIEM event store.
* [AutoTriage](/docs/autotriage) — consumes runtime reachability to re-rank findings.
# Safeguard Loop (/docs/safeguard-loop)
# Safeguard Loop
> **Roadmap — not yet available.** Safeguard Loop is not a new engine or a shipping feature — it's the intended umbrella name and unified view for a continuous cycle that today runs across several separate, already-shipped Safeguard capabilities. This page documents the direction; it is not something you can turn on, and it should not be planned against as a discrete feature yet.
Safeguard already detects issues continuously, prioritizes them, and — for a growing set of cases — fixes and re-verifies them automatically. Right now those steps live in distinct engines: continuous scanning finds things, [AutoTriage](/docs/autotriage) cuts the noise, [Griffin AI](/docs/griffin-ai) recommends and generates fixes, and engines like [Auto-Fix](/docs/esscm/auto-fix) and [Self-Healing Containers](/docs/self-healing-containers) apply and verify them. Safeguard Loop is the vision of naming and presenting that whole detect → prioritize → fix → verify → repeat cycle as one continuous life cycle, rather than as separate tools a team has to mentally stitch together.
## Today: the pieces that already exist
Nothing below is new — these are real, shipped capabilities that a future Loop view would tie together into a single life cycle.
| Stage | Capability | What it does today |
| -------------------------- | -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Detect / Prevent** | [Package Firewall](/docs/package-firewall) | Evaluates dependencies at install time and can allow, warn, block, or quarantine typosquats, dependency confusion, and known-malicious packages before they land — including a quarantine loop that re-evaluates and auto-releases packages once their verdict clears. |
| **Prioritize** | [AutoTriage](/docs/autotriage) | Deduplicates overlapping findings across scanners into a single correlated view and reports a measured reduction percentage, while guaranteeing malware and secrets findings are never suppressed. |
| **Prioritize / Recommend** | [Griffin AI](/docs/griffin-ai) | Safeguard's purpose-built LLM prioritizes findings by reachability, exploitability, context, and business impact, and generates remediation — upgrade recommendations, dependency conflict resolution, breaking-change analysis, and pull requests. |
| **Fix** | [Auto-Fix (AI Remediate)](/docs/esscm/auto-fix) | Griffin-powered analysis, solution generation, impact assessment, PR creation, and validation for vulnerable dependencies, across single, bulk, and page-level remediation. |
| **Fix / Verify** | [Self-Healing Containers](/docs/self-healing-containers) | Already runs its own four-step loop — Detect, Plan, Rebuild, Promote — driven by continuous scanning, with Griffin planning and verifying each heal. |
Each of these already closes part of the loop on its own. What doesn't exist yet is a single place that shows the cycle running end to end across all of them.
## Roadmap: what Loop would add
Safeguard Loop, as envisioned, is a continuous life cycle for security: find issues, fix them, and remediate — including auto-fix — on a repeating basis, rather than as one-off scans and one-off fixes. Directionally, that means:
* **A single umbrella view of the cycle** — seeing detection, prioritization, and remediation as stages of one continuous loop instead of separate screens per engine.
* **Cross-engine progress tracking** — following an issue as it moves from detected, to triaged, to a proposed fix, to a verified and promoted fix, regardless of which engine (Package Firewall, Griffin AI, Auto-Fix, Self-Healing Containers, or others) is doing the work at each stage.
* **Repeat, not one-shot** — reinforcing that the cycle runs continuously rather than stopping once a given fix ships.
To make this concrete: imagine a vulnerable dependency is caught by continuous scanning, deduplicated and prioritized by AutoTriage, given a Griffin AI-generated fix, and turned into a pull request by Auto-Fix. Today, following that one issue end to end means checking three separate places — AutoTriage's findings view, Griffin AI's recommendation, and Auto-Fix's PR status. A Loop view, as envisioned, would show that same issue as a single row moving through detected → triaged → fix proposed → fix verified, without hopping between engines. No such combined view, cross-engine issue ID, or UI exists today — this is an illustration of the goal, not a description of anything built.
None of this changes what the underlying engines above do today. Treat this section as direction, not a specification — the mechanics of a unified Loop view have not been designed or committed to a release yet.
## Questions we expect
* **Can I turn Loop on today?** No. There's no feature flag, setting, or dashboard called Loop anywhere in the product. It's a name and a view being considered for a cycle that already runs across separate, already-shipped engines.
* **Does "Loop doesn't exist yet" mean the engines don't work together today?** No — Griffin AI already drives both Auto-Fix and Self-Healing Containers directly, and Package Firewall's quarantine step already re-evaluates and releases packages on its own. What's missing is a single view that shows one issue's status across all of those engines at once, not the underlying capabilities.
* **Will Loop replace Package Firewall, AutoTriage, Griffin AI, Auto-Fix, or Self-Healing Containers?** No, as described — Loop is envisioned as a unifying name and view layered on top of those engines, not a replacement for any of them.
* **When will Loop ship, and what will the interface look like?** Not committed and not designed yet. This page reflects the product owner's stated direction — a single umbrella view, cross-engine progress tracking, continuous repeat — not a specification or timeline.
* **Where can I track an issue end-to-end in the meantime?** Through each engine's own view: AutoTriage's correlated finding, Griffin AI's recommendation, Auto-Fix's PR status, the Self-Healing dashboard's heal-cycle status, or Package Firewall's quarantine state. Stitching across them is manual until a unified view exists.
## Related
* [Griffin AI](/docs/griffin-ai) — the model behind prioritization and remediation generation, available today.
* [AutoTriage](/docs/autotriage) — cross-scanner deduplication and prioritization, available today.
* [AI Remediate](/docs/esscm/auto-fix) — automated fix generation and PR creation, available today.
* [Package Firewall](/docs/package-firewall) — install-time prevention with a quarantine re-evaluation loop, available today.
* [Self-Healing Containers](/docs/self-healing-containers) — the existing detect-plan-rebuild-promote loop for container images, available today.
# Safeguard Tag (/docs/safeguard-tag)
# Safeguard Tag
> **Roadmap — not yet available.** Safeguard Tag is a concept, not a shipping feature. This page documents the intended direction so you can evaluate it; it is not built and should not be planned against as one. It would build on the inbound-command hook already present in Safeguard's [ChatOps integrations](/docs/chatops-integrations) data model.
The idea behind Safeguard Tag is simple: instead of leaving a Slack, Teams, or Discord conversation to open Safeguard and act on something, you'd tag or @-mention Safeguard directly in the message — for example, on a thread flagging a suspicious dependency, or with an inline question — and have that count as a direct input to Safeguard, without a separate slash-command syntax or context switch. Nothing described on this page exists in the product today; it is a direction, not a spec.
## Why this is plausible, not pure speculation
Safeguard's ChatOps integrations are documented today as **outbound-only** in the UI — Safeguard posts findings and events into a channel, but there's no way to talk back to Safeguard from inside Slack, Teams, or Discord. However, the underlying data model already has a hook for the inbound direction. As [Bidirectional input (slash commands)](/docs/chatops-integrations#bidirectional-input-slash-commands) documents, both the Slack and Discord integration configuration types (`SlackConfiguration` / `CreateSlackConfigurationRequest` and `DiscordConfiguration` / `CreateDiscordConfigurationRequest`) already include a `slashCommandEnabled` field. That field isn't exposed anywhere in the Settings connection flow, and there is no self-service way to turn it on — but its presence means Safeguard's integration model was architected to support a user sending something back into Safeguard from within a Slack or Discord conversation, not just receiving notifications.
Safeguard Tag, if built, would most likely build on that same foundation rather than a new integration path. That's the entire basis for calling this plausible: an existing field in the data model, not an announcement, a design doc, or a committed timeline. As the ChatOps page puts it, "the field being present doesn't guarantee a shipped, supported command surface yet" — and that caveat applies fully here.
A few things worth being precise about, since it's easy to over-read the connection:
* The `slashCommandEnabled` field is a boolean toggle for enabling some inbound command surface — it says nothing about an @-mention-based trigger specifically. Tag, as the name and this page describe it, is about tagging Safeguard in a message rather than typing a slash command, and no such mention-triggered mechanism exists in the data model today.
* The only @-mention-related fields that currently exist in the ChatOps data model (`mentionUsers` / `mentionGroups`, Slack-only) are for **outbound** notifications — they let a channel mapping ping a person or group when a finding fires. They are unrelated to Tag's proposed use of an @-mention as an inbound trigger, and should not be read as early evidence of one.
* **Microsoft Teams has no equivalent hook.** Neither `TeamsConfiguration` nor `CreateTeamsConfigurationRequest` has a `slashCommandEnabled` field or anything like it — Teams is notification-only at both the UI and data-model level. Of the three platforms, Teams is the weakest candidate for Tag, and any future design would need to solve inbound Teams interaction from scratch rather than extending an existing field.
## Planned capabilities
Nothing below is built. This table sketches the kind of interaction the concept is aiming at, based on how it's been described, not a committed feature list.
| Area | What it's aiming at |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Inline tagging** | Tag or @-mention Safeguard on an existing message in Slack, Teams, or Discord and have that count as a direct input, instead of switching tools |
| **Ask a question inline** | Pose a question about a flagged dependency, finding, or event in the same thread it appeared in, and get a response back in-channel |
| **Act on a finding inline** | Point Safeguard at something already posted to a channel (e.g. a suspicious dependency alert) as a command target, rather than pasting an identifier into a separate interface |
To make the direction concrete rather than abstract: imagine a vulnerability alert lands in `#security-alerts` from an existing Safeguard notification, and a teammate replies in that same thread tagging Safeguard with something like "is this actually reachable in our checkout service?" instead of copying the package name into a separate Safeguard search. That is the shape of interaction Tag is aiming at — it is **not** a real command, syntax, or supported flow today; no such reply is understood by Safeguard in any channel right now.
## What's unclear or unresolved
This is a name and a direction, not a specification. In particular, none of the following are decided or documented anywhere:
* What exact trigger syntax would be used — an @-mention, a reaction, a thread reply, or something else.
* What commands or questions Tag would actually support, or how responses would be scoped to a tenant, project, or user's permissions.
* Whether Tag would extend the existing `slashCommandEnabled` hook as-is, replace it, or require new data-model fields entirely.
* Whether Microsoft Teams would ever get an inbound path, given it currently has no equivalent field to build on.
If inbound, in-chat interaction with Safeguard matters to your workflow, ask your Safeguard account team about the current status — this page describes the reasoning for why it's plausible, not a delivery commitment.
## Questions we expect
**Does the `slashCommandEnabled` field mean Slack or Discord already support this?**
No. The field exists in the `SlackConfiguration` and `DiscordConfiguration` data models, but it isn't exposed anywhere in the Settings connection drawer, and there's no self-service way to turn it on. It's evidence the data model was built to support inbound interaction eventually — not a working feature you can enable today.
**Can I enable Safeguard Tag for my workspace right now?**
No. Nothing on this page is built. There is no UI, trigger, command, or setting for it in Safeguard today, in Slack, Teams, or Discord.
**Will this work in Microsoft Teams?**
Unclear, and it's the weakest case of the three platforms. Teams' configuration model (`TeamsConfiguration` / `CreateTeamsConfigurationRequest`) has no `slashCommandEnabled` field or equivalent — any inbound path for Teams would need to be designed from scratch rather than extending something that already exists.
**Isn't this basically the same as the Slack `mentionUsers`/`mentionGroups` fields ChatOps already has?**
No, and it's worth being precise about the difference: those fields are **outbound** only — they let a channel mapping @-mention a person or group when a finding fires. Tag's proposed use of an @-mention is the opposite direction, as an inbound trigger a user sends to Safeguard. The two aren't related beyond both involving the `@` symbol.
**Is there a release date or committed timeline?**
No. This page exists to document the reasoning for why the idea is plausible, not to announce a feature. If timing matters to your evaluation, ask your Safeguard account team for the current status rather than inferring one from this page.
## Related
* [Slack, Teams & Discord](/docs/chatops-integrations) — the existing ChatOps integrations, including the `slashCommandEnabled` data-model field this concept would likely build on.
* [Griffin AI](/docs/griffin-ai) — Safeguard's existing natural-language query interface (e.g. asking about vulnerabilities, affected components, or licenses across your SBOM); the kind of question Tag envisions asking inline is conceptually similar to what Griffin already answers inside the Safeguard UI today.
* [Guard SDK](/docs/guard-sdk) — embeds live Safeguard policy enforcement directly into your own agent or MCP server process, for teams who want programmatic rather than chat-based interaction today.
# Software Composition Analysis (SCA) (/docs/sca)
# Software Composition Analysis
Modern applications are mostly other people's code. Safeguard's SCA inventories every open-source component you ship — direct and transitive — resolves each against a continuously updated vulnerability knowledge graph, and prioritizes what actually matters using reachability and exploitability signals instead of drowning you in raw CVE counts.
## What it does
| Capability | What it means |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Full dependency inventory** | Resolves the complete dependency graph from your manifests and lockfiles, including deeply nested transitive dependencies. See [Deep Dependency Scanning](/docs/deep-dependency-scanning). |
| **Known-vulnerability matching** | Matches every resolved package + version against CVE/GHSA advisories, enriched with EPSS and CISA KEV so exploited-in-the-wild issues rise to the top. |
| **Reachability-aware triage** | Cross-references findings with function-level [reachability](/docs/reachability-analysis) so a CVE in code you never call is de-prioritized — not treated the same as a reachable sink. |
| **License governance** | Flags license obligations and incompatibilities across the graph. |
| **Malicious-package detection** | Surfaces typosquats, dependency confusion, and known-malicious packages. For inline, install-time blocking see the [Package Firewall](/docs/package-firewall). |
## How it fits together
SCA is one engine in Safeguard's unified platform. Its findings land in the same tenant-isolated findings model as every other engine, share one severity scale and status lifecycle, and flow through [AutoTriage](/docs/autotriage) for cross-scanner deduplication and noise reduction — with the standing guarantee that **malware and secret findings are never suppressed** by reachability.
## Supported ecosystems
npm / pnpm / Yarn, PyPI, Maven / Gradle, Go modules, Cargo, NuGet, Composer, and Ruby Bundler — plus components discovered inside container image layers. Manifests and lockfiles are both honored so resolution matches what actually installs.
## Findings produced
Each SCA finding carries the vulnerable component and version, the CVE/GHSA identifiers, severity (with EPSS/KEV context), the full transitive path from your project root to the vulnerable package, the reachability verdict where available, and the safe upgrade target. Findings are queryable in the app alongside every other engine's output.
## Enabling SCA
SCA runs as part of a project scan and is administrator-toggleable through Safeguard's feature-flag controls. Configure it from the integrations surface, then scan from CI, the CLI, or on a schedule.
```bash
safeguard scan --project my-api
```
## Related
* [Deep Dependency Scanning](/docs/deep-dependency-scanning) — 100-level transitive resolution.
* [Reachability Analysis](/docs/reachability-analysis) — is the vulnerable function actually called?
* [Package Firewall](/docs/package-firewall) — block malicious packages inline at install time.
* [AutoTriage](/docs/autotriage) — cross-scanner dedup and noise reduction.
* [Continuous Scanning](/docs/continuous-scanning) — re-scan on every advisory-feed update.
# SDKs (/docs/sdks)
# SDKs
**Not available yet.** Safeguard publishes no official SDK in any language. There is no Safeguard SDK package on npm, PyPI, the Go module proxy, Maven Central or crates.io, and Safeguard has published nothing under the `@safeguard` or `@safeguard-sh` npm scopes.
Earlier revisions of this page told you to install SDK packages for Python, TypeScript, Go, Java and Rust that were never published. Don't install a package that claims to be a Safeguard SDK: Safeguard has not published one, so whoever did is not Safeguard.
## What to use instead
**Query your findings, vulnerabilities, SBOMs and compliance data from code or an agent.** Use the hosted [MCP server](/docs/mcp) at `https://mcp.safeguard.sh/mcp`. There is nothing to install: clients connect by URL and sign in with OAuth, or send an MCP key from **Settings → Developer** as `Authorization: Bearer sg_sk_...`. Most agent frameworks speak MCP natively.
**Scan from a terminal or a CI job.** Use the [Safeguard CLI](/docs/cli). It installs from Safeguard's own installer:
```bash
curl -fsSL https://cli.safeguard.sh/install | bash
```
On Windows, in PowerShell:
```powershell
irm https://cli.safeguard.sh/install.ps1 | iex
```
**React to events in your own systems.** Use [webhooks](/docs/webhooks-events). Each delivery is signed; [Signature Verification](/docs/webhooks-events#signature-verification) shows how to check it without an SDK.
**Call models through the API Platform.** The inference API speaks OpenAI's Chat Completions format, so OpenAI's official Python and Node.js SDKs work with it. See [SDKs and clients](/docs/console/sdks-and-clients).
## The REST API
There is no public REST API yet either. See [API Reference](/docs/api-reference#rest-api). If you need a language SDK, or an API for something the MCP tools don't cover, email [hi@safeguard.sh](mailto:hi@safeguard.sh) and we will factor it into that design.
## Related
* [MCP Integrations](/docs/mcp): connect an AI assistant or your own tooling to the hosted MCP server.
* [CLI](/docs/cli): install and use the Safeguard CLI.
* [Webhooks & Events](/docs/webhooks-events): event types and signature verification.
* [API Reference](/docs/api-reference): what is and is not available programmatically.
* [Guard SDK](/docs/guard-sdk): not published yet either.
# Search Connectors (/docs/search-connectors)
# Search Connectors
Search connectors let [Griffin AI](/docs/griffin-ai) reach outside your Safeguard data during a conversation by calling tools on external MCP (Model Context Protocol) servers you've connected. This is different from the [Connectors](/docs/connectors) catalog, which pulls one-time (or scheduled) compliance evidence from cloud, identity, HR, and other systems into the compliance pipeline. A search connector isn't an evidence pull — it's a live tool source Griffin can invoke mid-conversation, the same way it would call any other tool.
You manage search connectors from the connector dialog in the search interface, which has two tabs: **Browse Directory** and **Custom MCP**.
## Browse Directory
The **Browse Directory** tab (the default when you open the dialog) shows a searchable grid of MCP servers from Safeguard's connector directory. Type in the search box to filter by name, description, or category — for example, typing "slack" filters the grid down to Slack-related entries.
Each entry shows a badge for its **auth kind** — **OAuth**, **API key**, **Basic**, or **Public** (no credentials needed) — and a **Featured** badge for curated entries. Entries that already have a ready-to-use MCP endpoint are sorted to the top of the grid.
Clicking **Connect** on an entry opens a small panel with up to three ways to connect, offered together so you can pick whichever fits:
| Method | What it does |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **MCP server** (recommended) | If the entry already has a known MCP endpoint, its URL is pre-filled and marked **Ready**. Optionally add an access token to send as a bearer credential. Submitting connects immediately; if you leave the token blank, Safeguard also attempts a background OAuth handshake with the server — this succeeds for servers that support OAuth-based MCP auth, and otherwise just adds the connector for you to authorize later from its detail page. |
| **OAuth 2.0** | Signs in with the provider's own OAuth app. This requires an admin to have already configured that provider's OAuth client in Safeguard — if it isn't configured, connecting fails with "OAuth needs a one-time admin setup for this provider." |
| **Personal access token** | Paste a token. If the entry has a known MCP URL, the token is sent to it as a `Bearer` credential; otherwise it's stored as that entry's `api_key` credential. |
For example, connecting a GitHub-style entry that ships a known MCP endpoint: choose **MCP server**, leave the access token blank, and click **Connect via MCP** — Safeguard registers the connector against the pre-filled URL and kicks off OAuth in a new tab for you to approve.
If an OAuth popup or tab is closed or blocked before it completes, or the authorization is denied on the provider's side, the connection attempt fails (or the connector is left needing authorization) — reopen the dialog and retry, or authorize from the connector's detail page.
## Registering a custom MCP server
If the MCP server you want isn't in the directory, use the **Custom MCP** tab to register it directly by URL.
| Field | Required | Notes |
| ------------------------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Yes | A label for the connector, up to 80 characters. |
| **Server URL** | Yes | The Streamable-HTTP or SSE endpoint of your MCP server; must be a full `http://` or `https://` URL. |
| **Authorization header** | No | Sent as the `Authorization` header on every request to your server, up to 2000 characters — for example a bearer token your server expects. |
Submit the form to register the connector. There's no separate "test connection" step shown in the dialog — submitting registers the server so Griffin can start calling its tools.
For example, to register a self-hosted MCP server that expects a bearer token:
* **Name**: `Internal Docs MCP`
* **Server URL**: `https://mcp.example.com/sse`
* **Authorization header**: `Bearer sk-live-…`
## Managing connections and tool permissions
Once a connector is connected, open it from the connectors list to review what it can do. Its tools are grouped into three categories — **Interactive tools**, **Read-only tools**, and **Write/delete tools** — based on what each tool does.
Each tool (and each category as a whole) has a permission:
| Permission | Effect |
| ---------------------------- | ------------------------------------------------ |
| **Always allow** | Griffin can call the tool without prompting you. |
| **Needs approval** (default) | Griffin asks you to confirm before each call. |
| **Deny** | The tool is never callable. |
Setting a category's permission applies it to every tool currently in that category; you can still override an individual tool's permission afterward. A connector's tools can also fail to load — for example if a stored credential has expired — in which case the detail page shows "Could not load tools" instead of the tool list; use **Refresh tools** from the connector's menu after fixing the credential.
A connected connector's detail page has a **Disconnect** button (marks it disconnected but keeps it in your list). Once disconnected, its **⋮** menu also shows a **Remove** option that deletes it entirely — removal is only available after disconnecting.
## Credential storage
Any token you paste for a directory entry's MCP server or Personal access token method, and any authorization header you set for a custom MCP server, are encrypted at rest server-side (Fernet encryption) before storage. Safeguard does not display stored credentials back to you after they're saved — a connected entry only shows as connected, not the credential value itself.
## Common errors
**The OAuth popup or tab closes but the connector never shows as connected.** The popup was closed manually, blocked by the browser, or the provider denied access before completing the handshake. Retry from **Browse Directory** (or from the connector's detail page if it was already added), and check that popups aren't blocked for the Safeguard app.
**Connecting with OAuth 2.0 fails with "OAuth needs a one-time admin setup for this provider."** That provider's OAuth client hasn't been configured in Safeguard yet — this is a one-time step an admin has to do before anyone can sign in with OAuth for that entry. Use the **MCP server** or **Personal access token** method in the meantime if either is available for that entry.
**Submitting a custom MCP server fails validation.** The URL field requires a full `http://` or `https://` URL — a bare hostname or path won't pass. Check the URL is complete and reachable, and that the name and authorization header are within their length limits.
**A connector connects but "Could not load tools" shows on its detail page.** The stored credential is usually expired or was revoked on the provider's side. For an OAuth or MCP-OAuth connector, click **Connect** again on its detail page to re-authorize; for a connector added with a personal access token, remove it and re-add it with a fresh token from **Browse Directory** or **Custom MCP**. Then use **Refresh tools** from the connector's menu to confirm it's fixed.
## Related
* [Connectors](/docs/connectors) — the integration catalog that feeds compliance evidence into Safeguard, distinct from search connectors.
* [Griffin AI](/docs/griffin-ai) — the assistant that calls search connectors' tools during a conversation.
* [MCP Integrations](/docs/mcp) — connect an external AI assistant to Safeguard's own MCP server (the reverse direction from search connectors, which connect Griffin out to other servers).
# Skills (/docs/search-skills)
# Skills
A Skill is a reusable system prompt — optionally paired with a whitelist of MCP tools — that you trigger by typing `/` in the Griffin AI Search input. When you invoke a skill, the LLM call for that turn is prefixed with the skill's `system_prompt`, and if the skill has a tool whitelist set, the tool registry for that turn is restricted to only those tools. Skills are a way to package a prompt you'd otherwise retype (and tool boundaries you'd otherwise have to remember to set) into something you can pull in with a few keystrokes.
A typical reason to create one: you always want CVE triage done the same way — the same criteria, the same output shape — so you write that once as a skill's system prompt, name it something like `triage-cve`, and from then on type `/triage-cve` instead of re-explaining your criteria in every conversation. If you also want to guarantee the model can't reach for anything outside a specific set of tools while triaging, you attach an MCP tool whitelist to the same skill so that turn's tool registry is scoped down accordingly.
## What a Skill is made of
| Field | Description |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | The identifier you type after `/` to invoke the skill. Up to 80 characters. |
| **Description** | Shown alongside the name in the management table and the `/` picker. Optional, up to 280 characters. |
| **System prompt** | Required. The text prepended to the LLM call for that turn whenever the skill is invoked. Up to 8,000 characters. |
| **Icon** | Part of the underlying data model, but not currently exposed as an input in the create dialog or the detail panel's Edit tab — there's no way to set one from the UI today, and skills are shown with a generic icon throughout. |
| **Allowed MCP tools** | Optional whitelist, entered as a comma-separated list of exact tool names (up to 2,000 characters of text). When set, the turn's tool registry is restricted to just these tools; when left empty, no additional restriction is applied. |
| **Public** | Whether the skill is shared tenant-wide (see [Public vs. private skills](#public-vs-private-skills) below). |
| **Enabled** | Defaults to on. A disabled skill is skipped at compose time — invoking it has no effect until it's re-enabled. |
### Example
A CVE-triage skill might be filled in like this:
* **Name:** `Vulnerability Triage`
* **System prompt:** `You are a vulnerability triage assistant. Respond in formal regulatory tone, cite frameworks.`
* **Allowed MCP tools:** `safeguard_find_vulnerabilities, safeguard_list_projects`
* **Public:** off, if this is just for your own workflow — on, if the whole team should triage the same way.
With this saved, typing `/` in Griffin AI Search and selecting **Vulnerability Triage** from the picker inserts `/Vulnerability Triage` as a token in your message and attaches that system prompt to the turn — restricting the tool registry to just those two tools, no matter what else is available.
## Creating and managing Skills
Skills are managed from the **Skills** tab on the **Integrations** page:
1. Go to **Integrations → Skills**.
2. Click **New skill** to open the create dialog, and fill in a name, an optional description, a required system prompt, and (optionally) an MCP tool whitelist and whether the skill should be public.
3. Save. The skill now appears in your Skills table and is available via `/` in Griffin AI Search.
The Skills table lists the skills you've created. Clicking a row (or the eye icon) opens the skill's detail panel inline, where you can view and edit every field, including the system prompt and tool whitelist. The detail panel has two tabs:
* **Overview** — a read-only summary: visibility (Public/Private), how many tools are whitelisted (or "Unrestricted" if none), created/updated timestamps, the full system prompt, the tool whitelist as a list of badges, and which conversations have used this skill.
* **Edit** — the same fields as the create dialog (name, description, system prompt, allowed MCP tools, public toggle), saved with **Save changes**.
From the detail panel you can also click **New conversation** to start a fresh chat in Griffin AI Search with this skill already attached — useful when you want to jump straight into using a skill without typing `/` yourself.
From the table you can also:
* **Toggle Enabled/Disabled** directly on a row — you'll see a confirmation toast ("Skill enabled" / "Skill disabled") and the change takes effect immediately.
* **Delete** a skill via the trash icon — this asks for confirmation (naming the skill, e.g. "Delete skill "Vulnerability Triage"? This cannot be undone.") before removing it permanently.
If you haven't created any skills yet, the table shows an empty state prompting you to create one to bundle a reusable system prompt.
Public skills created by other users in your tenant don't show up in this table — that list is scoped to skills you created yourself. Shared/public skills from others are surfaced separately (see below and in the `/` picker).
Note that the **Allowed MCP tools** field is currently a plain text list, not a picker against your connected MCP tools — you need to type each tool's exact name (comma-separated), matching what's registered on the [MCP Connectors](/docs/mcp/connectors) page. A typo or near-miss name is simply excluded from the whitelist rather than flagged as an error.
## Invoking a Skill with "/"
While typing in the Griffin AI Search input, type `/` to open the skill picker. It lists the skills available to you — both your own and any public skills shared tenant-wide — searchable by name, with each entry showing its name and description. A skill created by someone else and shared as public is labeled **Public** in the list; your own private skills show no such label.
From the picker you can:
* Type to filter the list down by name.
* Select a skill to attach it to your current turn — the model's response for that turn is generated using that skill's system prompt (and, if the skill has one, its restricted MCP tool set).
* Choose **Create new skill** if nothing existing fits, which opens the same create dialog described above without leaving the search box.
If you haven't created or been given access to any skills yet, the picker shows an empty state rather than a list.
## Public vs. private skills
Skills are **user-scoped by default** — a skill you create is visible only to you, in your own Skills table and your own `/` picker.
Setting a skill's **Public** flag shares it **tenant-wide**: everyone else in your tenant then sees it (marked **Public**) in their `/` picker, so they can invoke it the same way you do. Making a skill public shares the prompt and tool whitelist for others to *use* — it doesn't move ownership of the skill itself, which is why public skills created by others appear as a distinct set from the ones you manage directly in your Skills table.
Use a private skill for something personal to your own workflow, and a public skill for something you want your whole team invoking consistently — like a shared CVE-triage prompt everyone should be running the same way.
## FAQ & Troubleshooting
**I invoked a skill but the model still used a tool I expected it to avoid.**
Check the skill's **Allowed MCP tools** list in its detail panel. If that list is empty, no tool restriction is applied for that skill — the turn's tool registry is unrestricted. Add the specific tools you want available to narrow it down.
**I disabled a skill but can still see it in the picker.**
A disabled skill is skipped at compose time, not hidden from the UI — you can still see and re-enable it, but invoking it while disabled has no effect on the model's prompt or tool access. Re-enable it from the Skills table if you meant to keep using it.
**A teammate says they can't see a skill I created.**
Check whether the skill's **Public** flag is set. Skills are private by default and only visible to their creator; mark the skill public to share it tenant-wide.
**I deleted a skill by mistake.**
Deletion is permanent and confirmed via a dialog naming the skill before it proceeds — there's no undo, so recreate it with the same name, description, system prompt, and tool whitelist if you need it back.
**Why don't I see other people's private skills in my Skills tab?**
The Skills tab only lists skills you created. Public skills shared by others are surfaced separately — through the `/` picker in search, where they're labeled **Public** — rather than mixed into your own management table.
**I added a tool to the whitelist but the model still can't use it.**
Since the field is free text (see above), a misspelled or slightly-off name is silently dropped rather than flagged. Open the skill's **Edit** tab and re-check each entry against the exact tool names on the [MCP Connectors](/docs/mcp/connectors) page.
## Related
* [Griffin AI](/docs/griffin-ai) — the underlying model that Skills prompt and Griffin AI Search runs on.
* [Search](/docs/esscm/search) — the Griffin AI Search interface where `/` invokes a skill.
* [Integrations](/docs/integrations) — the Settings area, including the Skills tab, where connected systems and skills are managed.
* [MCP Connectors](/docs/mcp/connectors) — the MCP tools a skill's allowlist can restrict a turn to.
# Workspaces (/docs/search-workspaces)
# Workspaces
A Workspace is a Claude-style conversation grouping in Griffin AI Search. It bundles a system prompt, a default model, attached files, and a member list, so every conversation you start inside it shares the same context and configuration instead of you re-explaining it each time. Use a Workspace when a team or a project's worth of conversations should all draw on the same background — for example, a workspace pre-loaded with your compliance framework documents and a system prompt tuned for answering compliance questions.
## What belongs to a Workspace
| Field | What it does |
| ------------------ | -------------------------------------------------------------------------------------------------------------- |
| **Name** | Required, up to 80 characters. Identifies the workspace (e.g. "Q1 Security Review"). |
| **Description** | Optional, up to 280 characters. One-line summary shown in the workspace list. |
| **System prompt** | Optional, up to 8,000 characters. Instructions prepended to every conversation started in this workspace. |
| **Default model** | Optional model applied to conversations in this workspace unless overridden. |
| **Colour** | Optional accent colour (hex, e.g. `#6366f1`) shown next to the workspace in the sidebar and its detail header. |
| **Attached files** | Files associated with the workspace, available as context to its conversations. |
| **Skills** | Zero or more [Skills](/docs/search-skills) composed into every chat in this workspace. |
| **Members** | The users who have access to the workspace. |
| **Enabled** | Toggle to disable a workspace without deleting it. |
Only **Name**, **Description**, and **System prompt** are set in the initial **Create a workspace** panel (see below). **Default model**, **Colour**, and **Skills** are added afterward, from a created workspace's **Edit** tab — there's no way to set them at creation time.
A conversation belongs to at most one workspace at a time. When it does, the workspace's system prompt and default model apply to that conversation automatically — unless a Skill applied to the chat, or a setting on the conversation itself, overrides them.
**Example:** a workspace named "Q1 Compliance Review" with the system prompt `You are answering questions about our SOC2 Type 2 controls. Cite the specific control ID in every answer.`, default model set to `griffin-2o`, three attached policy documents, and a "3 members" badge — every conversation started under it inherits all four automatically.
## Why use a Workspace
Without a workspace, every new conversation starts from a blank system prompt and whatever model you happen to pick. A Workspace lets you set that context once and have it apply everywhere it's used:
* **Consistent framing** — a system prompt tuned for a specific kind of question (compliance, incident response, a particular audit) applies to every conversation in the workspace, not just the one where you typed it.
* **Consistent model** — set a default model once instead of choosing it per conversation.
* **Shared background material** — files attached to the workspace are available as context without re-uploading them into each new chat.
* **Shared access** — anyone added as a member can use the workspace and its conversations, rather than context being trapped in one person's chat history.
## Composing Skills into a Workspace
A Workspace can compose multiple [Skills](/docs/search-skills) — reusable prompts — that apply to every conversation started in it. This lets you layer a workspace's baseline context (system prompt, default model, attached files) with one or more Skills for more specific behaviors, without having to re-select those Skills in each new conversation. Where a Skill's own instructions conflict with the workspace's system prompt or default model, the Skill takes precedence for the conversation it's applied to.
Skills are attached from a workspace's **Edit** tab, not the create dialog — you create the workspace first, then open it and check off which of your Skills should compose into it. For example, a "Q1 Compliance Review" workspace could have a `soc2-controls` Skill and a `cite-sources` Skill both checked, so every conversation started in that workspace runs with the workspace's own system prompt plus both Skills' prompts layered on top.
## Creating a workspace
1. Click **New workspace** from the Workspaces tab, or select **Create new workspace** from the workspace picker in the conversation composer.
2. In the **Create a workspace** panel, fill in:
* **Name** (required, e.g. `Q1 Security Review`)
* **Description** (optional, e.g. `Vendor risk questions for the Q1 audit`)
* **System prompt** (optional) — instructions applied to every chat in this workspace, e.g. `Answer using our current vendor risk tiering. Flag anything above medium risk.`
3. Click **Create workspace**.
The dialog description sums up the idea directly: *"Group conversations under a shared system prompt and default model — like a project."*
## Managing workspaces
Workspaces are managed from the **Workspaces** tab. Since workspaces span products rather than belonging to one, the same workspace list is available regardless of which product you're working in. The table shows each workspace's name, description, default model, member count, and last-updated time, plus an **enabled** toggle and row actions to open a workspace's details or delete it.
Opening a workspace's details shows two tabs:
* **Overview** — a read-only summary: default model, member count, attached-file count, colour, created/updated timestamps, the full system prompt, and the list of composed Skills.
* **Edit** — where you can change the name, description, system prompt, default model, colour (with a colour-swatch picker), and which of your Skills are composed into the workspace. Click **Save changes** to apply.
If no workspaces exist yet, the tab shows: *"No workspaces yet — create your first one to group related chats."*
## Attaching a workspace to a conversation
From the conversation composer, type `>` to open the workspace picker (this mirrors the `/` picker used for [Skills](/docs/search-skills)). It lists your workspaces, showing each one's name and description, and filters the list by name as you keep typing — e.g. typing `>Q1` narrows the list down to workspaces whose name matches "Q1", such as "Q1 Security Review." Select one to attach it to the current conversation, or choose **Create new workspace** to open the create panel without leaving the composer.
## Member access
Each workspace has an owner and a list of members. Members have shared access to the workspace — its system prompt, default model, attached files, and composed Skills are available to them the same way they are to the owner. The Workspaces table and a workspace's Overview tab surface this as a member count badge (e.g. "3 members") rather than listing individuals inline.
## Attached files
A workspace's data model has a slot for attached files, which would make them available as background context to every conversation in the workspace — useful for grounding a workspace in reference material like a compliance framework, a policy document, or a runbook, without attaching the same files to each conversation individually. A workspace's Overview tab shows how many files are attached. Neither the Create panel nor a workspace's Edit tab currently exposes a control for attaching files, so populating this today requires the API.
## Common errors
**"Workspace API not available yet"** when trying to create a workspace — the backend workspace endpoints aren't available in your environment yet. Contact Safeguard support.
**"Missing session context"** when trying to create a workspace — your sign-in session is incomplete; reload the page and try again.
**"Name is required"** — shown both in the Create panel and when saving a workspace's Edit tab with an empty name.
**A name over 80 characters, a description over 280 characters, or a system prompt over 8,000 characters is rejected** — the **Create a workspace** panel validates these before submitting; shorten the field and resubmit. (These limits aren't enforced client-side when editing an existing workspace from its Edit tab.)
**"Failed to create workspace"** (Create panel) / **"Failed to save workspace"** (a workspace's Edit tab) / **"Failed to update workspace"** (the enabled/disabled toggle) / **"Failed to delete workspace"** — the request reached the backend but it returned an error; the toast's description shows the underlying message. Retry, and if it persists, contact Safeguard support.
**A workspace's system prompt doesn't seem to apply** — check whether the conversation has its own override, or whether a Skill applied to the chat is taking precedence; both can override the workspace's system prompt and default model for that conversation.
## Related
* [Griffin AI](/docs/griffin-ai) — the AI search and chat experience Workspaces organize conversations within.
* [Skills](/docs/search-skills) — the reusable prompts a Workspace can compose into every conversation it contains, and the model for the `/` mention picker that Workspaces' `>` picker mirrors.
* [Search](/docs/esscm/search) — the Griffin AI Search interface whose composer hosts the `>` workspace picker.
# SecOps (SIEM) (/docs/secops)
# SecOps (SIEM)
SecOps turns the security signals already flowing through Safeguard — plus your cloud and identity logs — into a normalized event spine with continuous detection on top. It is built to be the foundation an autonomous SOC eventually stands on, so it ships bottom-up: the event store and detection first, orchestration and the agentic analyst as clearly-marked roadmap.
> **What's available today.** Event **ingestion**, OCSF **normalization**, and continuous **detection + IOC matching** into deduplicated alerts are built (SIEM Wave 0 and Wave 1). The **SOC console UI is rolling out**. SOAR, XDR, and the agentic SOC analyst are on the roadmap (see below) and are not yet available.
## Event ingestion
Collectors feed a normalized event pipeline. Internal sources land first because they need no external credentials:
* **Internal** — runtime (CWPP) events, AppSec findings, and API traffic, adapted from the tenant-scoped streams already inside the platform.
* **Cloud** — AWS CloudTrail, Azure Activity, and GCP audit logs, pulled incrementally with a persisted per-account cursor.
* **Push** — a syslog/CEF listener and a generic webhook endpoint.
Ingestion protects itself under load: if events arrive faster than they can be processed, excess is shed with a recorded metric rather than blocking your systems or silently losing data — any loss is always surfaced, never hidden.
## Normalization (OCSF)
Every raw log is mapped to an **OCSF-aligned** event: a class (authentication, process, network, file, api, config, dns, …), the extracted actor / target / source and destination IPs, and ATT\&CK technique tags where the source event implies a technique. The full raw record is preserved at the hot tier so hunts can reach unmapped fields. Adding a new source is typically a configuration change, not custom development.
The event store is **retention-tiered**: a hot tier (full fidelity, days), a warm tier (downsampled), and a cold archive, moved automatically by lifecycle policy. Every read and write is tenant/org/descendant-scoped.
## Continuous detection and IOC matching
Detection runs continuously over the event stream:
* **Detection rules + Sigma** are executed against new events per tenant; each match produces an `Alert` carrying the rule, contributing event IDs, severity, and ATT\&CK tags.
* **Real-time IOC matching** checks every event's IPs, hashes, and domains against the threat-intel store; a hit raises an alert.
* **Deduplication** collapses identical alerts within a sliding window so a noisy condition produces one alert, not thousands.
## Alerts you get
Alerts are the built output surface. Each alert records the firing rule or IOC, the events that contributed to it, a severity, and ATT\&CK technique tags — queryable through the API and (as it rolls out) the SOC console. Example detections available today include Sigma "impossible travel" on authentication events and known-bad IOC matches on network events.
## Roadmap
These capabilities are designed and specified but **not yet available**. They are documented here so the intended shape is clear; do not plan against them as shipping features.
* **SOAR — workflow automation.** A DAG-based playbook runtime (enrich → condition → action → loop) with a typed connector registry. Destructive actions (isolate, quarantine, disable-account, revoke-key) are approval-gated by default and safe-fail.
* **Correlation and UEBA.** Stateful sequence/threshold correlation across a sliding window (for example, `failed logins → privilege change → sensitive-data access` collapsing into one account-takeover alert) and per-entity behavioral baselining with a cold-start guard.
* **XDR — cross-domain correlation.** Endpoint, workload, cloud, identity, and app signals fused into one ATT\&CK attack timeline on the shared attack-path graph.
* **Case management.** Related alerts aggregated into cases with a timeline, ownership, and severity-derived SLAs.
* **SIEM interop.** Bidirectional forwarding to and from Splunk, Microsoft Sentinel, Elastic, and Chronicle.
* **Agentic SOC analyst.** A triage → investigate → respond loop over production Safeguard AI, strictly advisory: it reads within a bounded tool budget and can only *propose* SOAR actions — destructive responses always require human approval, and it is granted no direct connector access.
## Configuration
The SecOps engine is gated by server-enforced feature flags (`ff.siem`, and the roadmap `ff.soar` / `ff.xdr` / `ff.agentic_soc`), fail-safe off. Internal collectors activate with the platform. There is no CLI command for registering a cloud collector yet.
Events, alerts, and every future action are tenant/org/descendant-scoped, access-controlled, and audit-logged, with per-tenant retention and residency.
## Related
* [Runtime Protection (CWPP & CNAPP)](/docs/runtime-protection) — a primary internal event source.
* [Endpoint Security (EDR/EPP)](/docs/endpoint-security) — roadmap telemetry source for the SIEM/XDR.
* [Digital Risk Protection & Threat Intel](/docs/drp-tip) — roadmap IOC/intel feeds for detection.
* [Unified Findings & Feature Flags](/docs/unified-findings) — how engines are toggled platform-wide.
# Secrets Scanning (/docs/secrets-scanning)
# Secrets Scanning
Secrets in source code and container images are one of the most common root causes of real breaches. Safeguard scans every asset in your inventory for known secret patterns, custom-defined patterns, and high-entropy anomalies — and verifies each finding against the issuing service before raising an alert.
## What Gets Scanned
| Surface | Mechanism |
| --------------------------------- | ----------------------------------------------------------- |
| **Source code (current HEAD)** | IDE extension, CLI, CI scan, continuous pull |
| **Git history** | Deep history scan on connect and on demand |
| **Container images (all layers)** | Layer extraction + entropy + pattern matching |
| **Packaged artifacts** | Inside jars, wheels, gems, etc. |
| **Build logs** | CI log tail ingestion with redaction at source |
| **Vendor SBOMs** | Secrets leaking via build-provenance fields |
| **Model weights** | Tokens and keys baked into fine-tunes (AI Security surface) |
## Detection Layers
Findings come from three overlapping layers:
1. **Issuer-specific patterns** — curated regex + metadata for 200+ cloud providers, SaaS vendors, and identity providers. Examples: AWS Access Key ID, GitHub PAT, Slack Bot Token, Stripe Live Key, Twilio Auth Token, OpenAI API Key, Anthropic API Key.
2. **Generic patterns** — RSA / EC / Ed25519 private keys, JWTs, Bearer tokens, OAuth refresh tokens, connection strings.
3. **Entropy / structural** — high-entropy strings flagged by Eagle, with classification to reduce noise from hashes and UUIDs.
## Verification — No False Positives at the API
For issuer-specific patterns, Safeguard **verifies** the secret by making a low-privilege API call to the issuer:
* AWS keys → `sts:GetCallerIdentity`
* GitHub PATs → `/user`
* Stripe keys → `/v1/balance` (read-only)
* Slack tokens → `auth.test`
* OpenAI → `/v1/models`
Unverified findings are still raised but marked `unverified`. Verified findings mean the secret is live and exploitable right now.
You can disable verification per-issuer if outbound calls are restricted (air-gapped environments, for example).
## Severity
* **Critical** — verified, high-privilege credential (cloud admin, root token).
* **High** — verified credential with lower privilege (read-only, CI scope).
* **Medium** — unverified pattern match for a known issuer.
* **Low** — generic pattern or entropy-based finding.
## Custom Patterns
For internal tokens (company-issued JWTs, on-prem service credentials), add patterns via YAML:
```yaml
custom_patterns:
- id: acme-internal-api-key
description: ACME internal service API key
regex: 'acme_(?:prod|stage)_[A-Za-z0-9]{32}'
severity: high
verifier:
type: http
url: https://internal.acme.com/v1/verify-key
method: POST
header:
Authorization: Bearer {{.secret}}
expect:
status: 200
```
Commit this to `.safeguard/secrets.yaml` or manage in the UI.
## Allowlisting
Real secrets sometimes look like placeholders (example keys in documentation). Allowlist with three scopes:
* **Inline** — a trailing `# safeguard:allow ` comment on the line.
* **Path-based** — glob patterns in `.safeguard/secrets-allow.yaml` (e.g., `docs/**`, `*.test.js`).
* **Issuer-based** — allowlist all unverified findings for a specific issuer if you trust the pattern's FP rate.
Allowlists are tracked in audit — you see who added each entry and when.
## Remediation Playbook
For every verified finding, Safeguard runs a playbook:
1. **Revoke** — call the issuer's revoke API if available (AWS IAM, GitHub, Slack, Stripe, etc. supported).
2. **Rotate** — open a PR with a placeholder and a `TODO: rotate via Safeguard` comment, or call your secret manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault) to rotate.
3. **Purge from history** — optional Git history rewrite with `git-filter-repo` or BFG, with a clear warning about the force-push implications.
4. **Notify** — alert the owner and any dependent services.
Each step is gated; you decide whether the auto-revoke / auto-rotate runs headlessly or requires approval.
## Pre-Push Prevention
The IDE extension blocks secrets from being pushed in the first place. There is no CLI command for installing a git hook yet. To scan a working tree for secrets locally:
```bash
safeguard detect --detect secrets
```
## Policy Integration
Make secrets a blocker at commit / build / admission:
```yaml
- id: no-verified-secrets
condition: any(secrets, verified == true)
effect: BLOCK
```
## Reports
The **Secrets** dashboard shows:
* Count and trend of secrets by issuer.
* Time-to-revoke distribution.
* Leaked-and-revoked vs. leaked-and-open stats.
* Git history heatmap — which branches and authors had the most historical leaks.
## CLI
There is no CLI command for listing, revoking or rotating secret findings yet; use the **Secrets** dashboard.
## Related
* [IDE Support](/docs/ide-support) — pre-commit secret scanning in the editor.
* [Continuous Scanning](/docs/continuous-scanning) — how secrets are rescanned over time.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — secrets as a policy signal.
* [Auto-Fix](/docs/esscm/auto-fix) — Griffin-assisted remediation.
# Self-Healing Containers (/docs/self-healing-containers)
# Self-Healing Containers
When a new CVE affects a base image or a package in your container, the usual response is a manual chain: someone notices, someone opens a PR, someone reviews, someone redeploys. Self-healing containers automate that chain so your production images are always patched — typically within an hour of a CVE being published.
## How It Works
Self-healing runs a four-step loop, driven by continuous scanning:
1. **Detect** — a new CVE affects a component in one of your container images.
2. **Plan** — Griffin generates a patch plan: upgrade, apply security patch, or swap to a Gold-hardened equivalent.
3. **Rebuild** — the runner rebuilds the image with the patch, running your existing test suite.
4. **Promote** — if tests pass and the image passes guardrails, the image is pushed to your registry under a new tag. An admission controller rollout picks it up.
Each step is pluggable; you decide where humans are in the loop.
## Modes
### Advisory
Safeguard detects, plans, and files a PR against your Dockerfile repo or a Kubernetes manifest repo. Humans review and merge. Best for teams just turning self-healing on.
### Autonomous (promotion gated)
Safeguard detects, plans, rebuilds, and promotes to a staging tag. Human approval required to promote to production tags. Default for most enterprise customers.
### Autonomous (continuous)
Safeguard detects, plans, rebuilds, and promotes to production — end to end. Policies still apply: a change that fails the production policy bundle is held for review. Recommended once you have confidence in your test coverage.
## Patch Strategies
Griffin picks a strategy per finding:
| Strategy | When |
| ------------------ | ------------------------------------------------------------------------------- |
| **Upstream bump** | A patched upstream version exists. |
| **Backport patch** | Upstream doesn't have a patched version, but a fix is in HEAD. |
| **Dependency pin** | A safe indirect dependency version exists but is not resolved; Griffin pins it. |
| **Defer** | No safe fix exists; the finding is left open with a time-boxed exception. |
## Base-Image Self-Healing
The common case: your `FROM node:20-alpine` picks up a new libcrypto CVE. Self-healing rebuilds the image against the latest `node:20-alpine` digest (or a hardened Gold equivalent) and redeploys.
For `FROM scratch` and distroless images, Safeguard tracks which binaries are baked in and rebuilds the layer for the affected binary only.
## Dependency-Level Self-Healing
Inside your image, `npm ci`, `pip install`, `cargo fetch`, etc. pull in hundreds of transitive deps. When a CVE lands on one of them:
* The lockfile is resolved to the minimum version that resolves the CVE.
* The image is rebuilt with the updated lockfile.
* The test suite runs.
* A diff of the lockfile is written into the resulting image as a provenance attestation.
## Test Integration
Self-healing calls your existing test suite before promoting. Supported harnesses:
* **Any CI provider**: the build and test are delegated to your pipeline and the result is watched. There is no CLI command for this yet.
* **Local runner** — if you have the [Safeguard runner](/docs/runner) self-hosted, tests run there.
* **Synthetic tests** — a lightweight smoke test (health endpoints, startup time, memory footprint) runs for every rebuild even if no full test suite is declared.
## Registry and Kubernetes Integration
### Registry
Self-healed images are pushed with clear tagging conventions:
* `/:-sg-heal-` for staging promotions.
* `/:` overwritten for continuous mode (with immutable digest pinning).
Every image carries:
* An SBOM attestation describing the patch.
* A Griffin explanation attestation — plain-English description of what was fixed.
* A signed provenance attestation referencing the source commit and build environment.
### Kubernetes
If the Safeguard Helm operator is installed, rolling out a self-healed image is automatic:
* The operator watches registry tags.
* New patched digests trigger a controlled rollout (one pod at a time, respecting PodDisruptionBudgets).
* The rollout is paused automatically if readiness probes fail.
## Observability
The **Self-Healing** dashboard shows:
* Images currently being watched.
* Pending, in-progress, and completed heal cycles.
* Time-to-heal histogram (CVE published → image deployed).
* Rollback count (heals that failed verification).
Representative numbers from customer tenants:
* Median time-to-heal: **20-45 minutes** (CVE published → production rollout).
* P95 time-to-heal: **2 hours**.
* Rollback rate: **\< 1%**.
## Rollback
Every heal is reversible:
* The previous image digest is preserved.
* A one-click rollback from the UI restores it.
* Automatic rollback triggers on: readiness probe failures, error-rate spikes, or policy violations detected on the new image.
## Air-Gapped Self-Healing
For air-gapped environments, self-healing runs entirely inside your infrastructure:
* The Safeguard operator bundles rebuild tooling and the required base images.
* Snapshot updates are delivered via signed tarballs.
* No egress required at runtime.
## Turning It On
```yaml
# .safeguard/self-heal.yaml
self_heal:
mode: autonomous-staging # advisory | autonomous-staging | continuous
test_command: "npm test"
notify:
slack: "#sec-ops"
strategy_overrides:
- package: log4j-core
prefer: upstream-bump
```
Or via the UI: **ESSCM → Asset → Self-Healing → Configure**.
## Related
* [Continuous Scanning](/docs/continuous-scanning) — detects the CVE that triggers self-healing.
* [Auto-Fix](/docs/esscm/auto-fix) — source-code auto-fix is the companion to container self-healing.
* [Workflows](/docs/workflows) — orchestrates self-healing at scale.
* [Griffin AI](/docs/griffin-ai) — the model that plans and verifies each heal.
# SaaS Security Posture Management (SSPM) (/docs/sspm)
# SaaS Security Posture Management (SSPM)
> **Roadmap — not yet available.** SSPM is a planned capability documented here for direction. It builds on the shipped connector framework, identity analysis, and compliance engine, but the SSPM engine itself is not yet available.
SSPM adds the business-SaaS pillar alongside cloud (CSPM/CIEM), data ([DSPM](/docs/dspm)), and AI ([AI-SPM](/docs/ai-spm)) posture. It is designed to connect read-only to your SaaS estate and surface misconfigurations, weak authentication, risky third-party app grants, and over-exposed data — with **OAuth-app and shadow-SaaS enumeration** as the headline capability.
## Planned coverage
Each SaaS provider will be a read-only connector on the existing framework. Planned providers include Microsoft 365 / Entra, Google Workspace, and Okta first, then Slack, GitHub org, Salesforce, Zoom, Atlassian, and Snowflake.
| Check family | Examples |
| ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Config posture** | External sharing defaults, legacy/basic auth allowed, weak session/token policy, audit-log enablement, admin-console hardening |
| **MFA / SSO gaps** | Admin without MFA (critical), users without MFA, SSO bypass allowed, legacy-auth MFA bypass |
| **OAuth apps / shadow-SaaS** | Over-scoped, dormant, unknown-publisher, high-risk-scope-combination, and non-admin-installed-tenant-wide app grants — the headline |
| **Identity risk** | Over-privileged and dormant admins (via reused CIEM analysis), orphaned/guest/stale accounts, cross-app admin view |
| **External exposure** | World/link-shared files, external Slack Connect, public Salesforce sites, public Zoom recordings, open Confluence spaces, external Snowflake shares |
## OAuth-app risk scoring (planned)
The headline capability scores every third-party OAuth grant in a connected provider on weighted factors — high-risk scope combinations, over-scoping, unknown publisher, non-admin tenant-wide installs, and dormancy. A dormant, tenant-wide, unknown-publisher app is the canonical high-risk case; high-scoring apps produce a finding with the exact provider admin path to revoke the grant. (Enumerating apps *within* connected providers is in scope; discovering entirely unconnected SaaS is a later extension.)
## Safety model (planned)
SSPM is designed read-only and least-privilege throughout:
* **Read-only scopes only** — a connector requesting any write/modify scope is refused at registration; requesting write scope is treated as a defect.
* **Credentials from the secret store** — never persisted, never logged, redacted in every log line.
* **OAuth consent is a documented user action** — the code never automates a grant.
* **No raw SaaS content stored** — evidence is a redacted setting name plus value class and a resource reference, never file or message content.
## When it ships
Posture issues will surface as `sspm` findings in the single [findings store](/docs/unified-findings), inventory in its own tenant-scoped indexes, and checks will map to SOC2, ISO 27001, and CIS-for-SaaS through the reused compliance engine. The engine will be gated by the `ff.sspm` feature flag.
## Related
* [DSPM](/docs/dspm) — the data-posture pillar, available today.
* [AI-SPM](/docs/ai-spm) — the AI-posture pillar, available today.
* [Connectors](/docs/connectors) — the connector framework SSPM extends.
* [Compliance](/docs/compliance) — the framework engine SSPM maps into.
* [Unified Findings & Feature Flags](/docs/unified-findings) — where SSPM findings land.
# Trusted Artifacts (/docs/trusted-artifacts)
# Trusted Artifacts
> **Roadmap — not yet available.** Trusted Artifacts is a planned capability documented here for direction. It reuses the shipped container scanner, SBOM engine, and signing/provenance primitives, but the catalog and factory are not yet available.
Trusted Artifacts is planned as a source of hardened, minimal, signed base images with full supply-chain attestation — so the artifacts you build on start clean and provable. It is phased: a curated golden-image catalog with attestation first, then a build-from-source factory and FIPS/STIG variants as demand-gated later phases.
## Phase 1 — curated catalog + attestation (planned first)
A curated set of hardened, minimal (distroless) base images — language runtimes and common services — each of which will carry:
* **CVE tracking** — scanned by the container scanner on ingest and rebuild, with recorded critical/high counts and a remediation SLA.
* **Build-time SBOM** — both SPDX 2.3 and CycloneDX 1.5, generated from image layers.
* **Signature** — a cosign/Sigstore signature over the image digest, with keys held in KMS/HSM only.
* **SLSA provenance** — an in-toto build-provenance attestation (builder identity, source ref, build params).
* **Golden-image recommendation** — given your current base image, the nearest hardened catalog equivalent and the CVE delta.
There is no CLI command for verifying an artifact yet.
## Phase 2 — build-from-source, rebuild, FIPS/STIG (planned, demand-gated)
* **Build-from-source factory** — a melange/apko-style pipeline building each package from source into a minimal, pinned, reproducible, distroless image.
* **Daily rebuild + CVE SLA** — a continuous rebuild loop that re-scans and republishes with a fresh SBOM, signature, and provenance, trending CVE counts toward zero. "Zero-CVE" is stated honestly as *no known CVEs at publish under SLA* — not a perpetual guarantee.
* **FIPS / STIG variants** — images embedding a CMVP-validated crypto module in approved-only mode and STIG-hardened builds, for FedRAMP/DoD buyers.
## How it connects
Trusted Artifacts is designed to bridge two other capabilities: an admission-control path can call the verify step to block unsigned, vulnerable, or non-attested images at deploy, and [AI-SPM](/docs/ai-spm) reuses the same signing and provenance machinery to sign and attest **model** artifacts (model SBOM + signature + provenance). It reuses the existing container scanner and SBOM engine rather than forking them.
## When it ships
Provenance records will be tenant-scoped, signing keys held in KMS/HSM only, every publish/sign/rebuild audit-logged, with on-prem/air-gap parity via keyed cosign and a self-hosted registry. Gated by the `ff.trusted_artifacts` feature flag.
## Related
* [Gold](/docs/gold-registry): open-source security intelligence at gold.safeguard.sh, available today.
* [Attestation & Signing](/docs/attestation-signing) — signing and provenance across artifacts.
* [Self-Healing Containers](/docs/self-healing-containers) — automated remediation of image CVEs.
* [AI-SPM](/docs/ai-spm) — reuses this signing/provenance for model artifacts.
# Unified Findings & Feature Flags (/docs/unified-findings)
# Unified Findings & Feature Flags
Safeguard's security engines don't each carry their own siloed inbox. Every engine reports into **one unified findings model**, that model is browsed from **one consolidated Findings tab** per project, and every engine is independently controllable through **feature flags**.
## One model, discriminated by finding\_type
All engine findings share a single model discriminated by a `finding_type` field, so you can view, filter, and correlate across engines in one place:
| `finding_type` | Scanner filter option | Source engine | Notes |
| --------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `sast` | SAST | [Application Security Testing](/docs/application-security-testing) | |
| `dast` | DAST | [Application Security Testing](/docs/application-security-testing) | |
| `secrets` | Secrets | [Secrets Scanning](/docs/secrets-scanning) | |
| `container` | Container | [Application Security Testing](/docs/application-security-testing) | Container image and base-layer vulnerabilities |
| `iac` | IaC | [Application Security Testing](/docs/application-security-testing) | Infrastructure-as-code misconfigurations |
| `redteam` | *(not in the Findings scanner filter — see the [Application Security panel](#the-application-security-panel))* | [Red Team](/docs/red-team) | Still a first-party engine and a valid `finding_type`; it has no dropdown option or Scanner Coverage card, but it does have its own sub-tab in the Application Security panel further down the same Findings tab |
| `sca` | *(not in the Findings scanner filter — see Vulnerabilities tab)* | [Software Composition Analysis](/docs/sca) | Already has its own dedicated Vulnerabilities tab, so it's intentionally left out of the scanner dropdown to avoid a duplicate view |
| `dspm` | DSPM | [DSPM](/docs/dspm) | |
| `aisec` | AI Security | [AI-SPM](/docs/ai-spm) | |
| `runtime` | Runtime | [Runtime Protection](/docs/runtime-protection) | |
| `pkgfw` | Package Firewall | [Package Firewall](/docs/package-firewall) | Package Firewall itself already blocks installs inline; this is the finding\_type for its findings-table view |
| `sspm` | SSPM | [SSPM](/docs/sspm) | See [Findings tied to roadmap engines](#findings-tied-to-roadmap-engines) below |
| `easm_exposure` | CTEM/EASM | [CTEM & EASM](/docs/ctem-easm) | Combines CTEM and EASM exposure signals under one filter option |
| `endpoint` | Endpoint | [Endpoint Security](/docs/endpoint-security) | See [Findings tied to roadmap engines](#findings-tied-to-roadmap-engines) below |
| `drp` | DRP | [Digital Risk Protection & Threat Intel](/docs/drp-tip) | See [Findings tied to roadmap engines](#findings-tied-to-roadmap-engines) below |
| `itdr` | ITDR | [ITDR & DLP](/docs/itdr-dlp) | Elevated access required — see [ITDR and DLP: elevated access](#itdr-and-dlp-elevated-access) |
| `dlp` | DLP | [ITDR & DLP](/docs/itdr-dlp) | Elevated access required — see [ITDR and DLP: elevated access](#itdr-and-dlp-elevated-access) |
> **`finding_type` vs. the dropdown's URL value.** The Scanner dropdown's *display name* and its underlying `finding_type` usually match, but the short id used in the `?scanner=` deep link (see [Scanner Coverage deep links](#scanner-coverage-deep-links)) doesn't always equal the `finding_type` itself. Three scanners diverge: **AI Security** is `?scanner=ai-security` but `finding_type: aisec`; **CTEM/EASM** is `?scanner=easm` but `finding_type: easm_exposure`; **Package Firewall** is `?scanner=package-firewall` but `finding_type: pkgfw`. If you're constructing a `?scanner=` link by hand (rather than clicking a Scanner Coverage card), use the dropdown/URL value from this list, not the `finding_type` — a mismatched value falls back to **All scanners** silently (see the callout under [Scanner Coverage deep links](#scanner-coverage-deep-links)).
Because findings share the model, they share **correlation keys**. A DAST-confirmed runtime issue can be linked to the SAST source-code sink that produced it and to the CNAPP correlation showing it's running, reachable, and exposed — so a confirmed, reachable, exploitable finding is prioritized together, across engines. See [AutoTriage](/docs/autotriage) for how cross-engine duplicates collapse into one canonical finding, and [Vulnerability Prioritization (Reachability Analysis)](/docs/reachability-analysis) for how the reachability signal referenced above is computed.
Every finding is tenant/org-scoped end to end (`X-Tenant-Id`, `X-Org-Id`, `X-Descendant-Org-Ids`).
## The Findings tab and the scanner filter
Findings for a project live in a single **Findings** tab (Info … **Findings** … Reports). Rather than a separate tab per scanner, the Findings tab has a compact **Scanner** dropdown at the top:
* **All scanners** (the default) shows the same unfiltered view the Findings tab has always shown — every `finding_type`, together, with no scoping applied.
* Selecting an individual scanner (SAST, DAST, DSPM, Runtime, and so on) scopes the table, the summary stats, and the underlying queries to that engine's `finding_type`. You're looking at the same Findings tab, just narrowed to one engine.
* Only scanners you have access to appear in the dropdown — today that's driven by the elevated-permission gate on ITDR/DLP (see [ITDR and DLP: elevated access](#itdr-and-dlp-elevated-access)); every other option is visible to anyone who can open the tab. The separate [Application Security panel](#the-application-security-panel) further down the same tab is where per-engine [feature flags](#feature-flags) currently apply.
### Findings tied to roadmap engines
A few scanner-filter options — currently **SSPM**, **CTEM/EASM**, **Endpoint**, and **DRP** — are wired all the way through the findings data model (each has a real `finding_type` and a normal entry in the Scanner dropdown), but the scanning engines that would actually populate them are still on the roadmap (see each engine's linked doc page above, all explicitly marked "Roadmap — not yet available"). Concretely, that means:
* They behave like any other scanner in the dropdown and in Scanner Coverage — no special badge, no dashed border. Selecting one scopes the Findings tab to that `finding_type` exactly like SAST or DSPM would.
* Because no engine is emitting `sspm`, `easm_exposure`, `endpoint`, or `drp` findings yet, what you'll actually see today is the same **empty-table state** any scanner shows when it has no data: `No findings found for this project.` This is not a fabricated "coming soon" placeholder — it's the ordinary empty state, because there's ordinarily nothing there yet.
* The product does have a dedicated, visually distinct "coming soon" placeholder (a muted card with a **Coming soon** badge) reserved for scanners that aren't wired into the findings model at all. None of today's scanner options trigger it — every entry in the Scanner dropdown already has a `finding_type` mapped, SSPM/CTEM-EASM/Endpoint/DRP included.
* Once the underlying engine ships and starts posting findings, the same filter option starts returning real rows and a nonzero count with no further UI changes required on your end.
> If you select SSPM, CTEM/EASM, Endpoint, or DRP and see an empty table instead of real findings, that's expected — it means the engine hasn't shipped yet, not that something is broken. Check the engine's own doc page (linked in the table above) for its current roadmap status before assuming a config or permissions problem.
## The Application Security panel
Every Findings-tab view — whatever you have selected in the Scanner dropdown — also renders an additive **Application Security** panel below the findings table: a single card with one sub-tab per first-party engine, scoped to the same project/product/component as the rest of the tab. This is a second, separate scanner surface on the same page, and it's gated differently from the dropdown above it:
| Sub-tab | `finding_type` | Feature flag |
| ------------------ | --------------- | -------------------------------------- |
| SAST | `sast` | `scanner:sast` |
| DAST | `dast` | `scanner:dast` |
| Red Team | `redteam` | `scanner:redteam` |
| AI-SPM | `aisec` | `scanner:aisec` |
| DSPM | `dspm` | `scanner:dspm` |
| Runtime | `runtime` | `scanner:runtime` |
| Package Firewall † | `sca` | `scanner:pkgfw` |
| Endpoint | `endpoint` | `scanner:endpoint` |
| CTEM ‡ | `ctem` | `scanner:ctem` |
| EASM | `easm_exposure` | `scanner:easm` |
| SSPM | `sspm` | `scanner:sspm` |
| ITDR | `itdr` | `scanner:itdr` (+ elevated permission) |
| DLP | `dlp` | `scanner:dlp` (+ elevated permission) |
| DRP | `drp` | `scanner:drp` |
| Threat Intel ‡ | `tip` | `scanner:tip` |
† In this panel, the Package Firewall sub-tab currently queries `finding_type: sca`, distinct from the main Scanner dropdown's Package Firewall option (which queries `pkgfw`, per the [`finding_type` table](#one-model-discriminated-by-finding_type) above). If the two ever show different counts for what looks like the same engine, this is why — treat it as a known quirk of the current wiring rather than a data-consistency bug on your end.
‡ CTEM and Threat Intel only appear as sub-tabs in this panel — neither has its own entry in the main Scanner dropdown. The dropdown folds CTEM's signal into the combined **CTEM/EASM** option (`easm_exposure`); Threat Intel (`tip`) has no dropdown or Scanner Coverage equivalent at all today.
* **The Scanner dropdown and Scanner Coverage cards are gated by permission only** — every option except ITDR/DLP is visible to anyone who can open the Findings tab at all, regardless of feature-flag configuration.
* **The Application Security panel is gated by both the feature flag and, for ITDR/DLP, the permission.** A sub-tab only appears if your tenant has that engine's flag enabled (and, for ITDR/DLP, your role holds `findings:view_sensitive`). If no engine qualifies for the current tenant/role, the entire panel is omitted rather than shown empty.
In other words: this panel, not the Scanner dropdown, is what the [Feature flags](#feature-flags) admin toggles below actually control day to day. Turning `scanner:dspm` off removes the DSPM sub-tab from this panel; it does not remove DSPM from the Scanner dropdown or its Scanner Coverage card, which are unaffected by feature flags in the current UI.
## Scanner Coverage deep links
The project **Info** page shows a **Scanner Coverage** section: one card per scanner you have access to, each showing a live finding count (zero until an engine has posted data — including for the roadmap engines described above, which show `0 findings` today rather than a "coming soon" badge). Clicking any card takes you straight into the Findings tab with that scanner preselected, via a query parameter:
```
.../findings?scanner=
```
For example, the DSPM card links to `.../findings?scanner=dspm`, and the Package Firewall card links to `.../findings?scanner=package-firewall`. Landing on that URL preselects the same dropdown described above — you can change it from there just like you would if you'd opened the tab directly and picked a scanner yourself.
> If a Scanner Coverage link points at a scanner you don't have access to (see [ITDR and DLP: elevated access](#itdr-and-dlp-elevated-access)), the Findings tab falls back to **All scanners** rather than showing an error. This also applies if the `scanner` value in the URL doesn't match a known scanner.
## ITDR and DLP: elevated access
**ITDR** (identity threat detection and response) and **DLP** (data loss prevention) surface identity- and data-exfiltration signals — categories of finding that need tighter access control than a typical scanner result. Both are gated behind an elevated permission rather than being on by default:
* The permission is enforced **server-side**: without it, the data service silently excludes the `itdr` and `dlp` finding types from every query and aggregation, regardless of what the client requests (see the query-level mechanics below).
* It's also enforced **client-side**: without the permission, the ITDR and DLP options don't appear in the Findings scanner dropdown, and their Scanner Coverage cards don't render on the project Info page at all — you won't see an empty result, you won't see the option in the first place.
This is deliberately stricter than the other scanners, in line with SOC2 expectations around access to identity and data-handling signals. If you believe your team should see ITDR or DLP findings and don't, ask an admin to grant the elevated findings-visibility permission for your role — see [RBAC, Teams & Organizations](/docs/rbac-teams) for how roles and permissions are managed.
Note that the access-control plumbing above (server-side default-deny plus client-side hiding) is live today, independently of whether the engines themselves have shipped. [ITDR & DLP](/docs/itdr-dlp) is currently marked **Roadmap — not yet available**: the `itdr` and `dlp` `finding_type`s are wired into the findings model and gated exactly as described, but the detection engines that would populate them haven't shipped yet. In practice this means: a user with the elevated permission sees the ITDR/DLP options and an empty table (per [Findings tied to roadmap engines](#findings-tied-to-roadmap-engines)); a user without it doesn't see the options at all. Neither user sees fabricated findings.
**What "default-deny" looks like server-side.** Every finding is stamped with a `sensitivity` discriminator at ingest — `elevated` for `itdr`/`dlp`, `standard` for everything else — derived server-side from `finding_type` and never trusted from the client. On every read of the `findings` entity, the data service checks whether the caller's permissions include `findings:view_sensitive` (any scope: own/org/tenant/all); if not, it appends an exclusion clause to the query before it runs:
```json
{
"bool": {
"must_not": [
{ "terms": { "sensitivity": ["elevated"] } },
{ "terms": { "sensitivity.keyword": ["elevated"] } },
{ "terms": { "finding_type": ["itdr", "dlp"] } },
{ "terms": { "finding_type.keyword": ["itdr", "dlp"] } }
]
}
}
```
This is additive on top of the normal tenant/org/product scoping — it can only remove documents, never widen access — and it's applied to the same query aggregations use, so `itdr`/`dlp` rows also drop out of severity counts and totals for unauthorized callers, not just the table rows. The practical effect: an unauthorized caller's response looks exactly like a tenant with zero ITDR/DLP findings — there's no distinct "permission denied" error to look for; the absence itself *is* the enforcement. The exclusion also covers findings ingested before the `sensitivity` field existed, by matching on `finding_type` directly, so there's no legacy-data gap.
## Feature flags
Each engine is **admin-toggleable** via a feature flag, independently of the scanner filter access rules above. Two things matter here:
* **Server-side enforcement.** Flags are enforced on the server — a disabled engine is genuinely off, not merely hidden in the UI. Disabling an engine stops it from running and from returning data, not just from being displayed.
* **Independent control.** You can enable AppSec (SAST/DAST) without enabling Red Team, run DSPM without Runtime, and so on — each engine is its own switch, named `scanner:` (see the full flag list in [The Application Security panel](#the-application-security-panel) above — for example `scanner:dspm`, `scanner:pkgfw`, `scanner:itdr`).
As covered above, these flags currently govern the [Application Security panel](#the-application-security-panel)'s sub-tabs, not the main Scanner dropdown or Scanner Coverage cards — those are gated by the elevated permission alone (ITDR/DLP) and are otherwise visible regardless of feature-flag state. Keep this distinction in mind if you disable an engine's flag and still see it as a dropdown option: that's expected under the current wiring, not a flag that failed to apply.
## Querying
Filter the unified view by engine type and the usual finding attributes. There is no CLI command for this yet.
## FAQ & Troubleshooting
**I picked a scanner in the dropdown and the table is empty. Is something broken?**
Not necessarily. If it's a roadmap engine — SSPM, CTEM/EASM, Endpoint, or DRP (see [Findings tied to roadmap engines](#findings-tied-to-roadmap-engines)) — an empty table is expected until the engine ships; there's no separate "coming soon" screen for these, just the ordinary empty state with zero rows. If it's a shipped engine (SAST, DAST, DSPM, AI-SPM, Runtime, Package Firewall, Secrets, Container, IaC) and the table is genuinely empty, no scan has posted findings for that `finding_type` on this project yet — check that a scan actually ran (see the engine's own doc page for how to trigger one).
**Why don't I see ITDR or DLP in the Scanner dropdown at all?**
Your role doesn't hold the elevated findings-visibility permission described in [ITDR and DLP: elevated access](#itdr-and-dlp-elevated-access). Ask an admin to grant it if you need to review those findings.
**Why isn't Red Team or SCA in the Findings scanner dropdown?**
SCA already has its own dedicated Vulnerabilities tab, so it's left out of the Findings scanner filter to avoid showing the same data twice. Red Team results are also a first-party `finding_type`, but there's no dropdown option or Scanner Coverage card for it — browse Red Team findings from its sub-tab in the [Application Security panel](#the-application-security-panel) instead.
**A Scanner Coverage card sent me to "All scanners" instead of the scanner I clicked.**
Today that only happens for one of two reasons: the `scanner` value in the URL doesn't match a known scanner id, or — for ITDR/DLP — your role lacks the elevated permission. The Findings tab falls back to the unfiltered view rather than erroring. (Feature-flag state doesn't affect this fallback in the current UI — see [The Application Security panel](#the-application-security-panel) for what flags actually gate.)
**Can I disable one engine without affecting the others?**
Yes, for the [Application Security panel](#the-application-security-panel): feature flags are per engine, so toggling `scanner:dspm` off, for instance, has no effect on any other engine's sub-tab. It doesn't remove that engine from the main Scanner dropdown or its Scanner Coverage card, though — see the note above if you were expecting it to disappear from there too.
**Why do I see two different ways to pick a scanner on the same Findings tab?**
The dropdown at the top and the **Application Security** panel below the table are two separate, additively-rendered surfaces that happen to live on the same tab. The dropdown scopes the whole tab (table + stats) to one `finding_type` and is gated by permission only; the panel adds its own per-engine sub-tabs beneath the table and is gated by feature flag (plus permission for ITDR/DLP). See [The Application Security panel](#the-application-security-panel) for the full comparison.
## Related
* [Application Security Testing (SAST & DAST)](/docs/application-security-testing)
* [Red Team](/docs/red-team)
* [AI-SPM](/docs/ai-spm) · [DSPM](/docs/dspm) · [Runtime Protection](/docs/runtime-protection)
* [Secrets Scanning](/docs/secrets-scanning) · [Software Composition Analysis (SCA)](/docs/sca)
* [Package Firewall](/docs/package-firewall) · [AutoTriage](/docs/autotriage) · [Vulnerability Prioritization (Reachability Analysis)](/docs/reachability-analysis)
* [SSPM](/docs/sspm) · [CTEM & EASM](/docs/ctem-easm) · [Endpoint Security](/docs/endpoint-security) · [Digital Risk Protection & Threat Intel](/docs/drp-tip) · [ITDR & DLP](/docs/itdr-dlp) — all currently Roadmap; see [Findings tied to roadmap engines](#findings-tied-to-roadmap-engines).
* [RBAC, Teams & Organizations](/docs/rbac-teams) — roles and the elevated permission ITDR/DLP require.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — using findings as policy gates.
# Vulnerability & Exposure Management (/docs/vuln-exposure-management)
# Vulnerability & Exposure Management
> **Roadmap — not yet available.** VEM is a planned capability documented here for direction. It is a management overlay on findings that ship today; the overlay itself is not yet available.
Vulnerability & Exposure Management is the single-pane orchestration layer planned over the [unified findings store](/docs/unified-findings). It is explicitly **not a scanner** — it produces no findings and adds no finding types. It overlays lifecycle, SLA, ownership, ticketing, exception, and reporting workflow on the canonical (AutoTriage-deduped) findings, reusing the existing prioritization, reachability, risk score, and correlation graph rather than recomputing any of them.
## Planned capabilities
| Capability | What it will do |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Unified backlog** | One deduplicated, risk-ranked list of remediation items across every finding type, using AutoTriage's priority score, reachability, and correlation grouping (one fix closes many) |
| **SLA policies** | Due dates by severity × asset criticality × finding type × environment, with at-risk and breach states and escalation |
| **Ownership routing** | Auto-route items to the owning team from the asset registry; manual reassignment, audited; per-owner workload views |
| **Bi-directional ticketing** | Jira / ServiceNow / GitHub sync — one ticket per canonical finding group, conflict-resolved and reconciled |
| **Risk exceptions** | Approval-gated, **expiring**, audited risk-acceptance that pauses the SLA clock and reliably re-opens on expiry |
| **Campaigns** | Bounded remediation drives over a saved filter, with burn-down tracking and auto-complete |
| **Metrics & reporting** | MTTR, aging, burn-down, SLA attainment, reopened-rate, and executive risk reports |
## Reuse, not recompute (design principle)
The core design constraint is that VEM references shipped outputs and never re-derives them: one AutoTriage, one reachability engine, one risk score, one correlation graph, one connector stack, one findings index. Every VEM entity references a canonical finding group; none copies a finding or extends the finding model. This keeps priority and risk consistent everywhere they appear.
## Malware and secrets are never suppressible
A hard guarantee carried over from [AutoTriage](/docs/autotriage): no VEM path — SLA de-prioritization, exception activation, or a backlog filter — can ever hide a malware or secrets finding. A shared guard is called before any suppression, and approving a risk exception on a malware group is refused and audited. An expired exception is an enforced invariant: expired-but-still-suppressed count is always zero.
## When it ships
VEM will be tenant-scoped and audit-logged, gated by the `ff.exposuremgmt` feature flag (with sub-flags for ticket sync, campaigns, and exceptions), and surfaced through the app, GPT, CLI, and MCP. Its external-facing counterpart is [CTEM & EASM](/docs/ctem-easm).
## Related
* [Unified Findings & Feature Flags](/docs/unified-findings) — the store VEM overlays.
* [AutoTriage](/docs/autotriage) — the deduplication and the never-suppress guarantee VEM inherits.
* [Reachability Analysis](/docs/reachability-analysis) — the prioritization signal VEM reads.
* [CTEM & EASM](/docs/ctem-easm) — the external exposure-management counterpart (roadmap).
# Web Application (/docs/web-app)
# Web Application
The Safeguard web app at [app.safeguard.sh](https://app.safeguard.sh) is the primary interface to every product. It runs in any modern browser and requires no installation.
## URL and Access
| Environment | URL |
| ------------------------- | ------------------------------------------------------ |
| Production (US) | `https://app.safeguard.sh` |
| Production (EU) | `https://eu.app.safeguard.sh` |
| Government (FedRAMP HIGH) | `https://gov.app.safeguard.sh` (authorized users only) |
| Documentation | `https://docs.safeguard.sh` |
| Status | `https://status.safeguard.sh` |
Single sign-on: SAML 2.0, OIDC, and OAuth "social" login (Google, Microsoft, GitHub) are supported for Enterprise tenants. Configure under **Settings → Authentication → Single Sign-On** — see [SSO Authentication Setup](/docs/sso-authentication) for provider-by-provider steps.
## What's in the Web App
Every product is a section of the same app:
* **ESSCM**: SBOM generation, vulnerabilities, policies, attestation, code quality, findings, auto-fix.
* **Portal**: centralized SBOM management and secure sharing with third parties.
* **TPRM**: vendor inventory, questionnaires, SBOM-backed vendor assessment.
* **OSM**: open source intelligence, Gold registry, package security.
* **API Platform (Console)**: one OpenAI-compatible API for model inference, with API keys, a workbench, usage and credit. It is in early access, and off unless Safeguard switches it on for your workspace. See [API Platform (Console)](/docs/console).
A global search bar (`/` shortcut) runs queries across all products using the asset graph (see [Asset Discovery](/docs/asset-discovery)). It accepts the same filter and boolean syntax as the ESSCM [Search](/docs/esscm/search) page, so a query like:
```
severity:critical AND reachable:true AND project:payments-service
```
narrows results to critical, reachable vulnerabilities in a specific project without leaving the bar. Plain text (a package name, a CVE ID) works too — see [Search](/docs/esscm/search#search-syntax) for the full operator list.
## Scanner Icons
Every Safeguard security engine now renders its own distinct icon instead of falling back to a generic Git icon. DAST, SAST, Red Team, AI-SPM, DSPM, Runtime, Package Firewall, Endpoint, CTEM/EASM, SSPM, ITDR, DLP, and DRP each get their own icon, shown consistently in scanner cards on project pages, in the integrations list, and in finding provider modals. Previously, a project connected only over Git could show the same generic Git icon for findings that actually came from unrelated engines (for example, a DAST finding); now the icon on a card or finding tells you at a glance which engine produced it, without needing to read the label. See [Unified Findings & Feature Flags](/docs/unified-findings) for how these engines' findings are combined into one model once produced.
## Supported Browsers
| Browser | Minimum version | Notes |
| ----------------- | --------------- | -------------------------------------------------- |
| Chrome / Chromium | 120+ | Recommended. Receives feature updates first. |
| Edge | 120+ | Full parity with Chrome. |
| Firefox | 125+ | Full parity except experimental WebGPU dashboards. |
| Safari | 17.4+ | Full parity on macOS 13+ and iOS 17+. |
The app is a Progressive Web App (PWA). On desktop, install it via the browser's "Install app" prompt for a standalone window and faster launch.
## Mobile Web
The app is responsive for tablets and phones. Mobile coverage is focused on review and notification workflows:
* Reviewing and approving Griffin-proposed remediations.
* Acknowledging alerts.
* Reading findings and advisories.
* Approving exceptions.
Heavy operations (writing workflows, editing policies, deep SBOM inspection) are best done on desktop.
## Authentication
* **Email + passkey** (default).
* **TOTP** or **hardware security keys** (WebAuthn) for high-assurance — see [MFA](/docs/rbac-teams#mfa).
* **SSO** (SAML, OIDC, or OAuth social login) for Enterprise — see [SSO Authentication Setup](/docs/sso-authentication).
* **Break-glass** local accounts for emergency access, disabled by default — see [Break-Glass](/docs/rbac-teams#break-glass).
Sessions expire after 8 hours (idle) or 24 hours (absolute) by default; Enterprise tenants can tighten these. Signing in through SSO doesn't change these session rules — the SSO handshake only establishes the session; expiry, idle timeout, and re-authentication for sensitive actions behave the same as a password/passkey session. Programmatic access (CI jobs, scripts, agents) uses a separate credential rather than a browser session — see [API Keys and Tokens](/docs/rbac-teams#api-keys-and-tokens).
## Real-Time Updates
The web app uses WebSocket and Server-Sent Events for live updates:
* New vulnerabilities appear without a reload.
* Griffin remediation progress streams as the model works.
* Workflow runs show step state in real time.
## Performance
* Initial bundle size \~180 KB gzipped for the shell; product modules lazy-load.
* P95 time-to-interactive under 2.5 seconds on a 4G connection.
* Pages cached via stale-while-revalidate; re-authentication is automatic on token rotation.
## Offline
The web app is not designed for offline use. For offline and air-gapped workflows, use the [Desktop Application](/docs/desktop-app).
## Keyboard Shortcuts
| Shortcut | Action |
| -------- | ------------------------------------------------------------- |
| `/` | Focus global search |
| `g h` | Go to home |
| `g v` | Go to vulnerabilities |
| `g p` | Go to policies |
| `g w` | Go to workflows |
| `c` | Create (context-aware: new policy, new workflow, new project) |
| `?` | Show all shortcuts |
## Accessibility
* WCAG 2.2 AA conformance.
* Full keyboard navigation.
* High-contrast and reduced-motion themes.
* Screen reader support for all data tables.
## Data Residency
* **US tenancy** — data stored in `us-east-1` and `us-west-2`.
* **EU tenancy** — data stored in `eu-west-1` and `eu-central-1`.
* **Government tenancy** — data stored in AWS GovCloud or Azure Government.
Tenancy is chosen at signup and cannot be changed without a data-migration engagement.
## FAQ & Troubleshooting
**I was signed out with no warning in the middle of a session.**
Sessions expire after 8 hours idle or 24 hours absolute by default (see [Authentication](#authentication)) — this is enforced regardless of activity in another tab. If it's happening sooner than expected, check whether your Enterprise tenant has tightened these limits, or whether an admin revoked your session directly (deprovisioning revokes all active sessions immediately — see [Deprovisioning](/docs/rbac-teams#deprovisioning)).
**The app shows a banner saying my browser isn't supported, but it seems to mostly work.**
Anything below the minimum versions in [Supported Browsers](#supported-browsers) may render and function partially, but isn't tested and can break silently on newer features (for example, WebGPU-backed dashboards on Firefox). Upgrade to at least the listed minimum version, or switch to Chrome/Edge for guaranteed parity.
**A finding, scan result, or workflow status I know just changed isn't showing up without a manual reload.**
The web app relies on a live WebSocket/SSE connection for the updates described in [Real-Time Updates](#real-time-updates). If that connection has dropped (flaky network, corporate proxy interference, a laptop resuming from sleep), the page can fall behind until it's re-established. A manual reload always pulls current state directly, regardless of the live connection's status.
**My global search / asset graph query returns nothing, but I expect matches.**
Check the query against the [Search syntax](/docs/esscm/search#search-syntax) reference — stacking multiple filters (e.g. `severity:critical AND project:payments-service`) narrows results to items matching every condition, so an overly-narrow combination can under-match. Also confirm the asset is actually onboarded — an unconnected repository or an image with no SBOM won't appear (see [Shadow Asset Detection](/docs/asset-discovery#shadow-asset-detection)).
**Our tenant is provisioned in the wrong region — can we just move it?**
No, not as a self-service action. Tenancy (US, EU, or Government) is fixed at signup per [Data Residency](#data-residency) because it determines where data is physically stored. Moving requires a data-migration engagement — contact Safeguard support to scope it.
## Related
* [Desktop Application](/docs/desktop-app) — native app for local projects and offline.
* [MCP Server](/docs/mcp) — use the same capabilities from Claude or ChatGPT.
* [API Reference](/docs/api-reference) — programmatic access.
* [CLI](/docs/cli) — command-line access.
* [SSO Authentication Setup](/docs/sso-authentication) — step-by-step SAML/OIDC/OAuth provider configuration.
* [RBAC, Teams & Organizations](/docs/rbac-teams) — roles, MFA, API keys, sessions, and deprovisioning.
* [Asset Discovery](/docs/asset-discovery) — what the global search bar and asset graph query.
* [Unified Findings & Feature Flags](/docs/unified-findings) — how scanner engine findings are consolidated and browsed.
# Webhooks & Events (/docs/webhooks-events)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Webhooks & Events
Safeguard publishes every meaningful state change as an event. Subscribe via webhook, stream via Kafka / Kinesis / Pub-Sub, or poll the events API. Every webhook payload is signed so you can verify the sender.
## Event Catalog
Events follow the shape `..`.
### Findings
| Event | When |
| --------------------------------------------- | ------------------------------------------------ |
| `findings.vulnerability.created` | New vulnerability finding on any asset |
| `findings.vulnerability.severity_changed` | EPSS / KEV / CVSS update changed severity bucket |
| `findings.vulnerability.reachability_changed` | Reachability classification updated |
| `findings.vulnerability.suppressed` | Exception granted or false-positive confirmed |
| `findings.vulnerability.resolved` | Upgrade / patch / removal verified |
| `findings.secret.created` | New secret detected |
| `findings.secret.verified` | Secret confirmed live via issuer API |
| `findings.secret.revoked` | Secret revocation completed |
| `findings.license.created` | New license-policy violation |
| `findings.malware.created` | Eagle flagged a malicious artifact |
### Scans
| Event | When |
| ---------------- | ----------------------------------------------------- |
| `scan.started` | Scan of any asset begins |
| `scan.completed` | Scan completes; payload includes new findings summary |
| `scan.failed` | Scan errored; payload includes failure reason |
### Zero-Days
| Event | When |
| --------------------------- | ---------------------------------------------------- |
| `zero_day.published` | Safeguard publishes a new `SG-YYYY-NNNNN` advisory |
| `zero_day.affecting_tenant` | A published zero-day affects an asset in your tenant |
| `zero_day.embargo_ended` | CVE has been assigned and the advisory is now public |
### Remediation
| Event | When |
| ----------------------------------- | ---------------------------------------- |
| `remediation.plan_created` | Griffin generated a plan |
| `remediation.pr_opened` | Auto-fix PR opened in your repo |
| `remediation.pr_merged` | Auto-fix PR merged upstream |
| `remediation.pr_closed` | Auto-fix PR closed without merge |
| `remediation.self_heal.started` | Self-heal container rebuild started |
| `remediation.self_heal.promoted` | Self-heal image promoted to registry tag |
| `remediation.self_heal.rolled_back` | Self-heal rollback triggered |
### Attestations
| Event | When |
| --------------------------------- | ----------------------------------------------------- |
| `attestation.created` | New attestation published |
| `attestation.verification_failed` | Attestation verification failed (admission, CI, etc.) |
### Workflows
| Event | When |
| ------------------------ | ---------------------------------- |
| `workflow.run.started` | Workflow run began |
| `workflow.run.completed` | Workflow run finished successfully |
| `workflow.run.failed` | Workflow run failed |
### Policy
| Event | When |
| -------------------------- | ------------------------------ |
| `policy.violation` | A BLOCK or WARN fired |
| `policy.exception_granted` | An exception was approved |
| `policy.exception_expired` | A time-boxed exception expired |
### Asset & Vendor
| Event | When |
| --------------------------- | ---------------------------------------------------- |
| `asset.discovered` | New asset found (repo, image, model, workload, SBOM) |
| `asset.ungoverned` | Asset flagged as missing owner / SBOM / governance |
| `vendor.sbom_received` | New vendor SBOM uploaded |
| `vendor.risk_score_changed` | TPRM risk score threshold crossed |
### Audit
| Event | When |
| -------------- | ------------------------------------------ |
| `audit.action` | Any state-mutating action in the audit log |
## Delivery Options
### HTTP Webhook
Create a subscription on the **Webhooks** page: the endpoint URL, the event types, a signing secret, and an optional filter. There is no CLI command for this yet.
Payload:
```json
{
"id": "evt_01J...ABC",
"type": "findings.vulnerability.created",
"created_at": "2026-04-23T12:34:56.789Z",
"data": { "finding": { ... }, "asset": { ... } },
"tenant": "acme",
"api_version": "2026-01-01"
}
```
Every payload ships with headers:
* `X-Safeguard-Signature`: `v1,t=,s=`
* `X-Safeguard-Event-Id`: the event ID (idempotent).
* `X-Safeguard-Delivery-Attempt`: attempt count (1 for first delivery).
* `X-Safeguard-Api-Version`.
### Streams
Push events directly into your stream:
* **AWS Kinesis Data Streams / Firehose** — direct integration.
* **Azure Event Hubs** — direct integration.
* **GCP Pub/Sub** — direct integration.
* **Confluent Cloud / Apache Kafka** — via webhook sink.
* **NATS** — via webhook sink.
* **Redis Streams** — via webhook sink.
### SSE / WebSocket
For interactive dashboards:
The event stream is not yet available. The snippet below shows the intended
shape so you can plan an integration; it will not connect today. Use webhooks
or polling for anything you are building now.
The browser `EventSource` constructor takes `EventSourceInit` as its second
argument, and its only member is `withCredentials` — **custom headers are not
part of the API and are silently ignored**. Authenticate with a short-lived
session cookie instead:
```javascript
// Browser: the cookie is sent because withCredentials is set.
// Do not put the token in the query string — it lands in access logs.
const es = new EventSource("https://api.safeguard.sh/v1/events/stream", {
withCredentials: true
});
es.addEventListener("findings.vulnerability.created", (e) => { ... });
```
Server-side, where you can set headers, use an EventSource implementation that
supports them (for example `eventsource` on Node):
```javascript
import { EventSource } from "eventsource";
const es = new EventSource("https://api.safeguard.sh/v1/events/stream", {
fetch: (url, init) =>
fetch(url, { ...init, headers: { ...init.headers, Authorization: `Bearer ${token}` } })
});
```
### Polling
There is no CLI command for this yet.
## Filters
Every subscription can be filtered server-side using a subset of the policy expression language:
```
severity in ["critical","high"]
AND env == "production"
AND finding.kev == true
```
Server-side filters minimize traffic and reduce webhook noise.
## Reliability
* **At-least-once delivery.** Consumers must handle duplicates by `X-Safeguard-Event-Id`.
* **Exponential backoff retries** — 11 attempts over 24 hours (1s, 5s, 30s, 1m, 5m, 15m, 1h, 3h, 6h, 12h, 24h).
* **Dead-letter queue** — undelivered events land in a DLQ you can replay from the UI or API.
* **SLA** — 99.9% delivery within 10 seconds for Pro, 99.99% for Enterprise.
## Signature Verification
```python
import hmac, hashlib, time
def verify(secret: bytes, header: str, body: bytes) -> bool:
parts = dict(p.split("=", 1) for p in header.split(",", 1)[1].split(","))
ts, sig = parts["t"], parts["s"]
# reject events older than 5 min (replay guard)
if abs(time.time() - int(ts)) > 300: return False
expected = hmac.new(secret, f"{ts}.".encode() + body, hashlib.sha256).hexdigest()
return hmac.compare_digest(expected, sig)
```
```typescript
import { createHmac, timingSafeEqual } from "crypto";
export function verify(secret: string, header: string, body: Buffer): boolean {
const [_, tsPart, sigPart] = header.split(",");
const ts = tsPart.slice(2);
const sig = sigPart.slice(2);
if (Math.abs(Date.now() / 1000 - Number(ts)) > 300) return false;
const expected = createHmac("sha256", secret).update(`${ts}.`).update(body).digest("hex");
return timingSafeEqual(Buffer.from(expected), Buffer.from(sig));
}
```
## Idempotency
* Each event has a stable `id`.
* Consumers must deduplicate by ID; the guarantee is at-least-once, not exactly-once.
* Within a single event type, Safeguard guarantees monotonically increasing `created_at` for a given subject (finding, asset, workflow run, etc.).
## Testing
Trigger synthetic events for testing without triggering actual state changes:
There is no CLI command for this yet.
The test payload has a `"test": true` field so your consumer can ignore it in production pipelines.
## Observability
The **Webhooks** page shows per-endpoint:
* Delivery attempts (success, retry, failed).
* Average latency.
* DLQ size.
* Last 1000 deliveries with request / response bodies (scrubbed of secrets).
## Managing subscriptions
Subscriptions are listed, edited and deleted on the **Webhooks** page. There is no CLI command for this yet.
## Related
* [API Reference](/docs/api-reference) — full REST API.
* [SDKs](/docs/sdks): no language SDKs are published yet, so verify signatures as shown in [Signature Verification](#signature-verification).
* [Workflows](/docs/workflows) — Safeguard's own consumer of these events.
# Workflow Library (/docs/workflow-library)
# Workflow Library
Safeguard ships 50+ production-ready workflow templates. Each one is a complete YAML definition you can install with one click, tweak, and promote to your org. The library is versioned; templates pin to an SDK version so upgrades are safe.
Install from **Workflows → Library**. There is no CLI command for this yet.
## Auto-Fix & Remediation
| Template | What it does |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| `auto-fix-critical-kev-in-prod` | Triggers on any new KEV-listed critical finding on production assets; runs reachability; opens Griffin auto-fix PR |
| `auto-fix-daily-backlog` | Runs nightly against the top-N reachable findings and opens up to N PRs |
| `auto-fix-transitive-only` | Restricted to transitive-dependency upgrades only (safer for stable teams) |
| `griffin-review-assistant` | Griffin comments on open security PRs explaining the change and any remaining risk |
| `remediate-stale-dependency` | Opens PRs for dependencies unchanged > 365 days with any open CVE |
## Admission & Runtime Gates
| Template | What it does |
| ---------------------------- | ------------------------------------------------------------------------------------------------ |
| `prod-admission-gate` | Blocks admission of pods failing the production policy bundle; pages on-call for critical blocks |
| `sbom-required-at-admission` | Denies admission of images without a valid CycloneDX SBOM attestation ≤ 30 days old |
| `kev-block-prod` | Denies admission of images with KEV-listed unpatched CVEs |
| `unsigned-image-block` | Denies images without a valid Cosign / Notation signature |
| `runtime-drift-alert` | Alerts when a running pod's image digest diverges from its admission-time digest |
## Self-Healing
| Template | What it does |
| ----------------------------- | -------------------------------------------------------------------------------- |
| `self-heal-base-images` | Watches container base images and rebuilds when new CVEs land |
| `self-heal-gold-substitution` | When a Gold equivalent exists, swaps the image automatically |
| `self-heal-staged-rollout` | Canary-based self-heal with automatic rollback on metric regression |
| `self-heal-ai-model-deps` | Self-heal for the AI-side dependency chain (`transformers`, `torch`, tokenizers) |
## Scanning & Discovery
| Template | What it does |
| ----------------------------- | -------------------------------------------------------------------- |
| `weekly-sbom-freshness-audit` | Audits SBOM freshness across assets, emails owners of stale ones |
| `shadow-asset-sweep` | Finds repos / images / workloads missing ownership and opens tickets |
| `vendor-sbom-freshness-sla` | Reminds vendors whose SBOMs are approaching SLA |
| `deep-scan-on-push` | Runs a full 100-level scan on every push to main |
| `mono-repo-project-split` | Emits per-service SBOMs from a monorepo push |
## Zero-Day Response
| Template | What it does |
| ---------------------------- | --------------------------------------------------------------------------------------- |
| `zero-day-impact-assessment` | On any `zero_day.affecting_tenant` event, produces an impact report and routes to owner |
| `zero-day-autofix` | For zero-days where a patch exists at publication, auto-opens PRs |
| `zero-day-comms` | Drafts customer / exec comms from a template when a CRITICAL zero-day is published |
## Compliance
| Template | What it does |
| ------------------------------- | -------------------------------------------------------------------------------- |
| `fedramp-continuous-monitoring` | Generates the monthly FedRAMP evidence pack |
| `eo-14028-sbom-validation` | Runs SBOM minimum-elements validation; blocks non-compliant releases |
| `cra-readiness-check` | Evaluates each product against CRA essential requirements; opens gaps as tickets |
| `ssdf-evidence-export` | Exports NIST SSDF evidence as OSCAL for auditors |
| `soc2-change-control` | Produces SOC2 change-control artifacts for every production push |
| `iso-27001-control-rollup` | Rolls ISO 27001 Annex A control coverage into a dashboard |
| `dora-register-of-information` | Keeps DORA Register of Information current from TPRM data |
## TPRM (Vendor Risk)
| Template | What it does |
| ----------------------------- | -------------------------------------------------------------- |
| `vendor-sbom-intake` | Ingests new vendor SBOMs, evaluates policy, assigns risk score |
| `vendor-sbom-expiry-reminder` | Emails vendors whose SBOMs are stale |
| `vendor-kev-watchlist` | Flags vendors with any component on CISA KEV |
| `vendor-license-diff` | Alerts on vendor SBOM license-set changes |
| `vendor-offboarding` | Revokes access, purges data, archives history |
## Secrets
| Template | What it does |
| --------------------------- | ------------------------------------------------------------------------------ |
| `secret-verify-and-revoke` | On verified-live secret, revokes via issuer API and rotates via secret manager |
| `secret-history-purge` | Walks Git history, opens PR with filter-repo plan |
| `secret-exposure-dashboard` | Maintains the secrets dashboard and weekly digest |
## Operations & Observability
| Template | What it does |
| ----------------------- | ----------------------------------------------------------------------------------- |
| `daily-digest-to-leads` | Per-team email digest of open urgent findings and this week's remediations |
| `slack-triage-bot` | `#sec-triage` bot that claims, escalates, or suppresses findings via slash commands |
| `pagerduty-p0-bridge` | Pages on-call for P0 findings in production |
| `jira-ticket-sync` | Keeps Jira and Safeguard in sync: create / update / transition |
| `metric-export-otel` | Exports Safeguard metrics to your OTLP endpoint |
## AI / ML
| Template | What it does |
| ----------------------------- | ---------------------------------------------------- |
| `ai-bom-generate-on-deploy` | Generates AI-BOM on every model push to the registry |
| `model-weight-verify` | Verifies model-weight signatures before deployment |
| `eagle-pickle-scan` | Scans every new model for unsafe pickle opcodes |
| `training-data-license-check` | Validates training data licenses against policy |
## Customizing
Every template is editable after you install it from **Workflows → Library**. There is no CLI command for installing, editing or enabling workflows yet.
## Versioning
Each template has a version; upgrading pulls the new version but keeps any customizations by three-way merge. Conflicts are flagged in the UI for review before apply.
## Contributing
If you want a template added to the library, open an issue at `github.com/safeguard-sh/workflow-library` or email `workflows@safeguard.sh`. Safeguard maintains the library — community templates are reviewed, signed, and published under `community/` namespace once approved.
## Related
* [Workflows](/docs/workflows) — the workflow language reference.
* [Runner](/docs/runner) — local workflow execution.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — policies that workflows evaluate.
* [Auto-Fix](/docs/esscm/auto-fix) — the capability most auto-fix templates invoke.
# Workflows (/docs/workflows)
# Workflows
A workflow is a sequence of Safeguard steps triggered by an event. Workflows let you encode "when this happens, do these things" without glue code — for example, "when a new image appears in `prod-registry`, generate an SBOM, evaluate the production policy, and open a PR if Griffin can auto-fix any findings."
## Concepts
A workflow is composed of:
* **Trigger** — what starts the workflow. Triggers are events, schedules, or manual runs.
* **Steps** — the actions to execute, in order or in parallel.
* **Inputs and outputs** — each step reads from the workflow context and can write to it.
* **Conditions** — step-level `if` expressions that decide whether a step runs.
* **Concurrency** — limits on how many instances of a workflow run simultaneously.
Workflows are defined in YAML, live in a Git repository (or inside the Safeguard UI), and run on Safeguard's managed runner or a self-hosted runner.
## Triggers
| Trigger | Fires on |
| ---------------------------- | ------------------------------------------------ |
| `on.image.pushed` | New image or tag in a connected registry |
| `on.repo.pushed` | New commit or tag on a connected Git repository |
| `on.sbom.received` | SBOM uploaded to Portal or via API |
| `on.vulnerability.published` | New vulnerability affects one of your components |
| `on.zero_day.published` | Safeguard publishes a new zero-day advisory |
| `on.policy.violation` | A guardrail records a BLOCK or WARN |
| `on.vendor.sbom_updated` | TPRM vendor sends a new SBOM |
| `on.schedule` | Cron expression (UTC) |
| `on.manual` | Triggered from the UI, CLI, or API |
Triggers can be combined — a workflow can declare multiple `on.*` handlers.
## Example: Auto-fix critical CVEs on main
```yaml
apiVersion: safeguard.sh/workflows/v1
kind: Workflow
metadata:
name: auto-fix-critical-on-main
spec:
on:
vulnerability.published:
filters:
severity: ["critical", "high"]
kev: true
repositories: ["org/api", "org/webapp"]
branch: main
concurrency:
group: "auto-fix-${{ workflow.repository }}"
cancelInProgress: true
steps:
- id: scan
uses: safeguard/scan-repository@v2
with:
repository: ${{ trigger.repository }}
ref: ${{ trigger.ref }}
- id: reachability
uses: safeguard/reachability-analyze@v1
with:
sbom: ${{ steps.scan.outputs.sbom }}
vulnerability: ${{ trigger.vulnerability_id }}
if: ${{ steps.scan.outputs.found == true }}
- id: remediate
uses: safeguard/griffin-remediate@v3
with:
vulnerability: ${{ trigger.vulnerability_id }}
repository: ${{ trigger.repository }}
strategy: conservative
if: ${{ steps.reachability.outputs.reachable == true }}
- id: open-pr
uses: safeguard/open-pull-request@v1
with:
repository: ${{ trigger.repository }}
branch: safeguard/auto-fix/${{ trigger.vulnerability_id }}
title: "Auto-fix ${{ trigger.vulnerability_id }}"
body-template: remediation-summary
if: ${{ steps.remediate.outputs.fixed == true }}
- id: notify
uses: safeguard/slack-notify@v1
with:
channel: "#security-ops"
template: remediation-posted
if: ${{ steps.open-pr.outputs.pr_url != '' }}
```
## Example: Gate every production admission
```yaml
apiVersion: safeguard.sh/workflows/v1
kind: Workflow
metadata:
name: prod-admission-gate
spec:
on:
policy.violation:
filters:
policy: prod-admission-policy
decision: BLOCK
steps:
- id: open-ticket
uses: safeguard/jira-create@v2
with:
project: SEC
summary: "Blocked production admission: ${{ trigger.image }}"
severity: ${{ trigger.severity }}
- id: page-oncall
uses: safeguard/pagerduty-trigger@v1
with:
service: prod-admission-failures
if: ${{ trigger.severity == 'critical' }}
```
## Example: Weekly SBOM freshness audit
```yaml
apiVersion: safeguard.sh/workflows/v1
kind: Workflow
metadata:
name: weekly-sbom-freshness
spec:
on:
schedule:
cron: "0 9 * * 1" # Mondays 09:00 UTC
steps:
- id: audit
uses: safeguard/sbom-freshness-audit@v1
with:
max-age-days: 30
environments: ["production"]
- id: email-owners
uses: safeguard/email-owners@v1
with:
assets: ${{ steps.audit.outputs.stale_assets }}
template: sbom-stale-reminder
if: ${{ steps.audit.outputs.stale_count > 0 }}
```
## Built-In Step Library
Steps are published as versioned `uses:` references. Major categories:
| Category | Steps |
| ----------------- | ------------------------------------------------------------------- |
| **Scanning** | `scan-repository`, `scan-image`, `scan-sbom`, `scan-model` |
| **Analysis** | `reachability-analyze`, `license-analyze`, `eagle-classify` |
| **Remediation** | `griffin-remediate`, `open-pull-request`, `pin-dependency` |
| **Policy** | `evaluate-policy`, `apply-guardrail` |
| **Notifications** | `slack-notify`, `teams-notify`, `email-owners`, `pagerduty-trigger` |
| **Tickets** | `jira-create`, `jira-comment`, `linear-create` |
| **Export** | `export-sbom`, `export-attestation`, `s3-upload` |
| **Integration** | `github-check`, `gitlab-pipeline-emit`, `bitbucket-comment` |
See the [step reference](/docs/api-reference) for the full list with inputs/outputs.
## Runners
Workflows execute on runners:
* **Safeguard Cloud runner** (default) — fully managed, runs in the Safeguard FedRAMP-HIGH environment.
* **Self-hosted runner** — runs inside your VPC / cluster, useful for accessing private networks, air-gapped sites, or regulated data. See [Runner](/docs/runner) for installation.
A workflow can target either with `runs-on: cloud` (default) or `runs-on: self-hosted`.
## Observability
Every workflow run produces:
* A step-by-step timeline in the **Workflows** tab.
* Structured logs streamed to the UI and archived for 90 days (Enterprise: configurable up to 7 years).
* OpenTelemetry spans emitted to your configured OTLP endpoint.
* Audit records signed by Safeguard for every external side-effect (PR opened, ticket created, notification sent).
## Versioning and Promotion
Workflows are versioned via Git — you can require that all workflow changes go through code review before they land. The Safeguard UI shows a diff between the running version and the proposed version for any change.
Environments (`dev`, `staging`, `prod`) can each pin to different workflow versions for safe rollout.
## Related
* [Griffin AI](/docs/griffin-ai) — the remediation model workflows invoke.
* [Auto-Fix](/docs/esscm/auto-fix) — opinionated auto-fix workflow template.
* [Guardrails & Enforcement](/docs/guardrails-enforcement) — policies that generate `policy.violation` triggers.
* [Runner](/docs/runner) — self-hosted workflow execution.
# Zero-Day Discovery (/docs/zero-day-discovery)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Zero-Day Discovery
Safeguard runs a continuous zero-day research pipeline across open source packages, container base images, and AI models. Discovered vulnerabilities are validated, scored, and disclosed through coordinated channels — and delivered to customers before they appear in public CVE feeds.
## How the Pipeline Works
Zero-day discovery runs through four stages: ingestion, analysis, validation, and publishing.
### 1. Ingestion
Safeguard continuously ingests:
* **Every public commit** on watched repositories across npm, PyPI, Maven, NuGet, Crates.io, Go modules, RubyGems, Composer, Conda, Hugging Face, and OCI registries.
* **New releases** within minutes of publication.
* **Maintainer signals** — GitHub issues, pull requests, security advisories in draft, and abnormal commit activity.
* **Container base image changes** — new layers, new binaries, CVE drift.
This ingestion layer is the foundation of the TAOR (Trace, Analyze, Observe, Report) architecture.
### 2. Analysis
Each new artifact goes through:
* **Static analysis** — taint tracking, dataflow, symbolic execution, fuzz-driven input generation across multiple analyzers.
* **Dynamic analysis** — sandboxed execution with syscall / network monitoring to flag behavior that differs from prior releases.
* **Differential analysis** — diff against the previous version to identify sensitive changes (auth, crypto, deserialization, IPC).
* **Dependency graph analysis** — 100-level transitive scanning to find whether a change propagates into widely-used packages.
* **Griffin AI review** — each candidate is reviewed by Griffin AI, which correlates the change against the package's historical patterns, similar vulnerability classes, and known exploit techniques.
### 3. Validation
A finding becomes a candidate zero-day only if:
1. A reproducer is constructed and runs without manual tweaking.
2. A minimum-qualifying-context (MQC) analysis shows a realistic path to exploitation.
3. At least one human researcher signs off on impact and severity.
Pre-validation filtering rejects roughly 96% of raw candidates. The remaining 4% enter the disclosure queue.
### 4. Publishing
Validated zero-days flow through two channels simultaneously:
* **Customer channel** — Safeguard subscribers receive the finding immediately through the ESSCM feed, Portal, and CLI / IDE clients. SBOMs are re-scored. Griffin AI generates remediation PRs where a fix exists.
* **Upstream channel** — coordinated disclosure to the upstream maintainer with a 90-day default embargo (shorter if active exploitation is observed). Safeguard requests CVE assignment and publishes a detailed advisory after the embargo.
## TAOR Architecture
TAOR is the name of Safeguard's zero-day infrastructure.
* **T**race — ingest every artifact, every commit, every release.
* **A**nalyze — run the multi-tool analysis matrix.
* **O**bserve — watch runtime behavior and dependency telemetry across customer fleets (with opt-in, anonymized signal).
* **R**eport — publish to customers and upstream coordinators.
Observe is the distinctive layer: telemetry from customer SBOMs and runtime collectors feeds anomaly detection back into the pipeline. Unusual package co-installations, sudden version pinning across the ecosystem, and suspicious registry uploads all surface as leads.
## Customer Experience
Zero-days appear in your environment as:
* **A new finding** in ESSCM with category `zero-day` and a Safeguard-assigned identifier (`SG-YYYY-NNNNN`).
* **A CVE reference** once the embargo ends (typically 14–90 days after initial disclosure to you).
* **An automated remediation PR** from Griffin AI when a patched version or safe configuration exists.
* **A policy alert** in the Portal if the affected component violates any policy gate.
## Signal-to-Noise Discipline
Not every finding is published. Safeguard suppresses:
* Low-impact bugs that do not cross a trust boundary.
* Findings in unmaintained packages with zero downloads in the last 365 days.
* Issues that require an attacker to already have write access to the application.
Research output targets severity medium and above with a realistic exploit path.
## API and Feed
There is no CLI command for the zero-day feed yet. Subscribers can pull it from the API:
```bash
curl -H "Authorization: Bearer $SG_TOKEN" \
https://api.safeguard.sh/v1/zero-days?severity=high&since=2026-01-01
```
The feed includes the SG identifier, affected components, reproducer hash, severity, exploitation status (`none`, `poc`, `in-the-wild`), and upstream coordination status.
## Researcher Program
Safeguard's research team also accepts external submissions. Validated findings published under the Safeguard disclosure program earn bounties based on impact and novelty. Contact `research@safeguard.sh` for submission guidelines.
## Related
* [Griffin AI](/docs/griffin-ai) — how automated remediation ties into zero-day publishing.
* [Vulnerabilities](/docs/esscm/vulnerabilities) — how discovered issues surface inside ESSCM.
* [Policies and Gates](/docs/esscm/policies-gates) — block artifacts with unpatched zero-days at build or deploy time.
# Calendar & Study Tasks (/docs/academy/calendar)
# Calendar & study tasks
## What's on the calendar
The **Calendar** page (month and agenda views) aggregates everything time-bound in your Academy life:
* **Live sessions and meetups** you've RSVP'd to
* **Study tasks** you create yourself
* **Exam cooldown** end times, so you know when you can retake
* **Certificate expiry** dates
## Study tasks
Create your own study tasks — "finish module 3 by Friday" — from the calendar or from a course page. Tasks carry a title, optional notes, a due date, and an optional course link; mark them done as you go. They're a lightweight way to plan a certification run week by week.
## Exporting to your own calendar
Every calendar item offers:
* **Add to Google Calendar** — a prefilled Google Calendar link; no account connection required.
* **Download .ics** — works with Outlook, Apple Calendar, and any standards-based calendar app.
## The personal iCal feed
For a continuously synced view, subscribe your calendar app to your **personal iCal feed** — a private, tokenized URL available in settings. Google Calendar, Apple Calendar, and Outlook can all subscribe to it, so RSVPs and study tasks appear in your own calendar automatically as they're added.
The feed URL contains a private token: treat it like a credential. You can revoke and regenerate it from settings at any time.
# Certificates: Verifying & Sharing (/docs/academy/certificates)
# Certificates: verifying & sharing
## The public certificate page
Every issued certificate lives at a public URL:
```
https://academy.safeguard.sh/cert/
```
The page renders the certificate itself — holder name, certification, issue and expiry dates — plus **live verification status**. It requires no account to view, and shared links unfurl as rich cards on LinkedIn and X. `academy.safeguard.sh/verify/` redirects to the same page.
Verification is truthful by design:
* **Active** certificates show as valid.
* **Expired** and **revoked** certificates say so, plainly.
* Unknown IDs return a clean 404. Certificate IDs are non-enumerable, so pages can't be guessed or crawled.
For anyone checking a credential — a hiring manager, a customer, a colleague — opening the link is the entire verification process.
## Sharing
From your certificate page you can:
* **Copy the shareable link** — the public URL above.
* **Add to LinkedIn in one click** — a prefilled "Add to profile" deep link with the certification name, issue date, and credential URL.
* **Post directly to LinkedIn, X, or Reddit** — connect the account once under **Settings → Connected accounts**, then post from the certificate page with prefilled text and the certificate link. Your posting history is kept alongside the certificate.
* **Share to Facebook or Instagram** via each platform's share flow.
* **Download the PDF** — a branded certificate document carrying a **QR code** that resolves to the public verification page, so even a printed copy is verifiable.
Newly earned certificates also appear in the [Academy feed](/docs/academy) (you can opt out per certificate).
## Expiry and renewal
Certificates carry the validity period of their certification (24 months for the Safeguard Certified Practitioner). Upcoming expiries appear on your [calendar](/docs/academy/calendar) and dashboard. An expired certificate's page stays up — showing its expired status — and re-certifying issues a fresh certificate.
## Revocation
Safeguard can revoke a certificate (for example, for exam misconduct). Revocation is audit-logged and reflected immediately on the public page.
# Community & Live Sessions (/docs/academy/community-and-live-sessions)
# Community & live sessions
## Course communities
Every course has its own community with two kinds of threads:
* **Doubts** — a question anchored to the course or a specific lesson. If the course has an AI tutor, it posts a first response (clearly labeled as AI); human tutors and fellow learners answer too. As the asker, you mark the answer that resolved your doubt — the thread moves from *answered* to *resolved*.
* **Discussions** — open threads among the people taking the course together.
Reading published threads is public (no account needed); posting requires sign-in and enrollment in the course.
### Moderation
Course communities are public spaces on a branded surface, and they're moderated:
* Every post has a **Report** button; reports go to a moderation queue.
* Moderators can hide posts and lock threads; tutors can lock threads in their courses. All actions are audit-logged.
* Per-user rate limits apply to thread and post creation.
* AI-authored posts are always labeled.
Thread authors are emailed when new answers arrive (batched to avoid mail storms). Direct messages between learners are deliberately not a feature — conversation stays in course-scoped threads.
## Live sessions (Google Meet)
Tutors schedule course-scoped live sessions — office hours, doubt-clearing calls (a session can be spawned directly from a doubt thread), and exam-prep walkthroughs — joined via **Google Meet**.
* Upcoming sessions are listed on the course page.
* **RSVP** to get reminder emails and the session on your [calendar](/docs/academy/calendar).
* Join from the session page at start time.
## Meetups (YouTube Live)
Academy-wide meetups — AMAs, release walkthroughs, security deep-dives — are broadcast on **YouTube Live** and embedded on an Academy event page with a live Q\&A thread alongside the stream. Anyone signed in can RSVP; event pages are publicly viewable.
When the stream ends, the recording persists on the same page, so the meetups section doubles as the **archive** of past events.
In short: Google Meet sessions are interactive and small-group; YouTube Live meetups are one-to-many broadcasts with a permanent replay.
# Exams & Certifications (/docs/academy/exams-and-certifications)
# Exams & certifications
## Certifications and requirements
A **certification** defines what must be satisfied before a certificate is issued — typically completing its course and passing its exam. When every requirement is met, the certificate is issued automatically and you receive an email with your public certificate link.
Certifications carry a validity period (the Safeguard Certified Practitioner is valid for 24 months from issue). Expiry dates appear on your dashboard, your [calendar](/docs/academy/calendar), and the public certificate page.
## Exam modes
The exam engine supports multiple modes; each certification states which it uses.
### Question set (timed)
The standard mode, used by the Safeguard Certified Practitioner exam:
* Questions are **drawn randomly from a larger pool** per attempt — no two attempts see the same set.
* The timer is server-authoritative. For the Practitioner exam: **30 questions, 45 minutes, 70% to pass** (21 of 30).
* Question types include multiple choice, multi-select, and true/false. **Multi-select is graded exact-match** — no partial credit.
* Navigate freely between questions and flag questions to revisit; answers are saved as you go.
* If you disconnect, resume the attempt — the clock keeps running. If time expires mid-attempt, the answers you recorded are submitted automatically.
### Subjective questions
Exams can include written-answer questions. These are graded by AI against a rubric, with the grading rationale stored, and escalate to **human review** when confidence is low or on appeal. Your attempt shows a `grading` status until every answer has a final score; you're emailed when the result lands.
### AI-conducted interview
For certifications that use it, the exam is an adaptive, oral-style interview conducted in chat by the certification's AI tutor — questions adapt to your answers within a fixed turn and time budget. The full transcript is recorded, the AI produces rubric scores with rationale, and human moderation can review before the result is finalized.
## Results, cooldowns, and retakes
* Results show your score and a **per-domain breakdown** (for example: fundamentals, scanning, compliance, platform) — never per-question answer keys.
* A failed attempt starts a **cooldown** (24 hours for the Practitioner exam) before you can retake. The cooldown end shows on your calendar.
* Passing an exam that completes a certification's requirements issues the certificate immediately.
## Integrity
* Answer keys, rubrics, and model answers never leave the server.
* AI grading is explainable — the rationale is stored — and human-overridable, with overrides audit-logged.
* Exam draws are randomized per attempt, and submission is idempotent (a double-submit can't double-grade).
# FAQ (/docs/academy/faq)
# FAQ
### How much does Safeguard Academy cost?
Nothing. Courses, exams, and certificates are free for individuals — there is no paid tier behind the certification.
### Do I need to be a Safeguard customer?
No. Anyone can sign up for a free Safeguard account and use the Academy. The same account works across the product and the Academy, but a product subscription is not required.
### Can I browse without an account?
Yes. The course catalog, course pages, published community threads, meetup event pages, and certificate pages are all public. You need to sign in to enroll, track progress, post, chat with the AI tutor, or take exams.
### What happens if I fail an exam?
A cooldown starts (24 hours for the Safeguard Certified Practitioner exam), after which you can retake. Each attempt draws a fresh random set of questions from the pool. The cooldown end shows on your calendar.
### How are written answers and interviews graded?
Subjective answers are graded by AI against a rubric, with the rationale stored; low-confidence or appealed grades escalate to human review. AI-interview exams record the full transcript and rubric scores, with human moderation available before finalization. You see your score and a per-domain breakdown — never per-question answer keys.
### How long is a certification valid?
Each certification defines its validity — the Safeguard Certified Practitioner is valid for 24 months from issue. Expiry shows on your dashboard, calendar, and the public certificate page.
### How does someone verify my certificate?
They open your certificate link — `academy.safeguard.sh/cert/` — which shows the certificate and its live status (active, expired, or revoked). No account, no forms. The PDF carries a QR code that resolves to the same page.
### Can I add my certificate to LinkedIn?
Yes — one click. The certificate page has an "Add to profile" deep link, and if you connect your LinkedIn account you can also post the certificate directly. Direct posting is likewise available for X and Reddit.
### What languages does the Academy support?
English and Hindi. The AI tutor and AI grading respond in your language.
### Does it work on a phone?
Yes — the Academy is mobile-friendly across the catalog, lessons, community, and dashboard. Audio lessons are built for listening on the go.
### What happens if I disconnect during an exam?
Resume the attempt — your answers are saved as you go and the timer is server-side. If time runs out mid-attempt, whatever you recorded is submitted automatically.
### Who answers questions in the course community?
Three kinds of participants: the course's AI tutor (posts a first response, always labeled as AI), human tutors, and fellow learners. The asker marks the accepted answer.
### Are live sessions recorded?
Academy-wide meetups stream on YouTube Live and persist as recordings on their event pages — that's the archive. Course-scoped Google Meet sessions are small-group and not published as recordings.
### Can my employer verify a candidate's certificate in bulk?
Every certificate is a public URL, so verification is scriptable against the links candidates provide. For anything beyond that, contact [hi@safeguard.sh](mailto:hi@safeguard.sh).
# For Teams (/docs/academy/for-teams)
# For teams
Safeguard Academy is built for individuals, but it works as a team enablement tool out of the box:
* **Onboarding** — the Safeguard Certified Practitioner course takes an engineer from supply-chain security fundamentals to working fluency with scanning, triage, VEX (Vulnerability Exploitability eXchange), SBOMs (Software Bills of Materials), and compliance — the exact workflow your team runs in the product.
* **Same accounts** — learners use their existing Safeguard accounts, so there's nothing to provision. Anyone on your team can enroll today.
* **A verifiable completion signal** — every certificate is a public URL with live status. "Has everyone on the team certified?" is answered by collecting links, not screenshots.
* **Free** — enablement at zero cost per seat, including the certification.
Certificates identify the holder, not a tenant — the Academy holds no customer data, and nothing about your organization's Safeguard usage appears on any public page.
Team-level features — cohort dashboards, bulk enrollment, private courses for customer teams — aren't part of the Academy today. If your organization wants them, tell us: [hi@safeguard.sh](mailto:hi@safeguard.sh).
# Getting Started (/docs/academy/getting-started)
# Getting started
## 1. Browse the catalog
The course catalog at [academy.safeguard.sh](https://academy.safeguard.sh) is public — no account needed to browse courses, read course descriptions and curricula, or view published community threads.
## 2. Sign in or create an account
The Academy uses the same accounts as the rest of Safeguard. If you already use the product, sign in with that account; if not, sign up for free from the Academy. One account works across [app.safeguard.sh](https://app.safeguard.sh) and the Academy.
You need to be signed in to enroll, track progress, post in course communities, chat with the AI tutor, take exams, and earn certificates.
## 3. Enroll in a course
Open a course page and select **Enroll**. Enrollment is free and immediate. The course page shows:
* the curriculum — modules, lessons, and estimated durations
* the course tutors (human profiles and AI tutors)
* the certification the course leads to, if any
* the course community and upcoming live sessions
## 4. Learn
Work through lessons in order or jump around — progress is tracked per content block (see [Taking courses](/docs/academy/taking-courses)). Your dashboard shows every enrollment with its progress and picks up exactly where you left off.
## 5. Get certified
Completing all lessons in a certification's course unlocks its exam. Pass the exam and the certificate is issued automatically, with an email containing your public certificate link. See [Exams & certifications](/docs/academy/exams-and-certifications).
## Keyboard shortcuts
The Academy is keyboard-first:
| Shortcut | Action |
| ------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------- |
| Cmd/Ctrl+K | Command bar — search courses, lessons, threads, your certificates, and navigation |
| ? | Shortcut help overlay |
| Space, ←/→, ↑/↓, f | Player: play/pause, seek, volume, fullscreen |
| ←/→, number keys | Exam: previous/next question, select an option |
# Safeguard Academy (/docs/academy)
# Safeguard Academy
**Safeguard Academy** is Safeguard's free, public learning and certification platform at [academy.safeguard.sh](https://academy.safeguard.sh). Anyone can sign up with a Safeguard account, take curated courses on software supply chain security, pass a certification exam, and receive a publicly verifiable certificate.
Everything is free for individuals — courses, exams, and certificates.
## What's on the Academy
| Capability | What it is |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Courses** | Curated courses built from video, text, and audio lessons, with per-block progress tracking. |
| **Certification exams** | Timed exams in multiple modes: auto-graded question sets, subjective answers with AI-plus-human grading, and AI-conducted interview exams. |
| **Verifiable certificates** | Every certificate is a public page at `academy.safeguard.sh/cert/` with live verification status, LinkedIn sharing, PDF download, and a QR code. |
| **AI tutor** | A per-course chat tutor scoped to the course material. |
| **Course community** | Doubts answered by AI tutors, human tutors, and peers; open discussions; moderated. |
| **Live sessions & meetups** | Course-scoped sessions over Google Meet; Academy-wide meetups on YouTube Live with a recording archive. |
| **Learner calendar** | Sessions, meetups, study tasks, exam cooldowns, and certificate expiries — exportable to Google Calendar and iCal. |
| **Academy feed** | A built-in activity feed: certificates earned, new threads, upcoming meetups. |
## First certification
The Academy's first credential is the **Safeguard Certified Practitioner** — three modules covering supply-chain security fundamentals, the scan/triage/VEX workflow, and SBOM, compliance, and the wider Safeguard ecosystem, followed by a timed 30-question exam (45 minutes, 70% to pass). The credential is valid for 24 months. See [Exams & certifications](/docs/academy/exams-and-certifications) for the full mechanics.
## Platform notes
* **Accounts** — one Safeguard account works across the product and the Academy. The course catalog and certificate pages are public; enrolling, learning, and taking exams require sign-in.
* **Languages** — the Academy is available in English and Hindi.
* **Themes and devices** — light and dark mode; mobile-friendly.
* **Keyboard-first** — press Cmd/Ctrl+K for the command bar (search courses, lessons, threads, your certificates); press ? for the shortcut overlay.
## In this section
* [Getting started](/docs/academy/getting-started) — sign up and enroll in your first course
* [Taking courses](/docs/academy/taking-courses) — lessons, content blocks, progress, and the AI tutor
* [Exams & certifications](/docs/academy/exams-and-certifications) — exam modes, grading, and certification requirements
* [Certificates: verifying & sharing](/docs/academy/certificates) — public verification, LinkedIn, PDF, and QR
* [Community & live sessions](/docs/academy/community-and-live-sessions) — doubts, discussions, Google Meet sessions, YouTube Live meetups
* [Calendar & study tasks](/docs/academy/calendar) — the learner calendar and calendar export
* [FAQ](/docs/academy/faq)
* [For teams](/docs/academy/for-teams)
# Taking Courses (/docs/academy/taking-courses)
# Taking courses
## Course structure
Every course is organized as **modules → lessons → content blocks**. A lesson typically combines a video with a written deep-dive; some lessons add audio. Block types at launch:
* **Video** — embedded player with full keyboard controls.
* **Text** — written lessons in rich markdown.
* **Audio** — hosted audio lessons for listening on the go.
## Progress
Progress is tracked per content block, and the rules are per type:
| Block type | Completion rule |
| ---------- | ------------------------ |
| Video | Watch at least 90% |
| Audio | Listen to at least 90% |
| Text | Explicit "mark complete" |
A lesson is complete when all its required blocks are complete; a course is complete when all lessons are — which unlocks the certification exam, if the course has one. Your enrollment shows a rolled-up progress percentage on the dashboard and course page.
If a video provider is temporarily unavailable, the block renders a fallback link and your recorded progress is unaffected.
## The AI tutor
Courses can have human tutors, an AI tutor, or both — listed on the course page. The AI tutor is a chat, scoped to the course you're in:
* Ask questions about the material at any point in a lesson.
* Answers are generated against the course's content scope — it's a course tutor, not a general chatbot.
* Tutor chat requires enrollment in the course.
AI tutors are always labeled as AI, in chat and in the community alike.
## Picking up where you left off
Everything resumes: lessons remember your position, the dashboard lists your enrollments by recent activity, and Cmd/Ctrl+K jumps straight to any lesson by name.
# Agents & LLMs (/docs/agents)
Safeguard is built to be operated by AI agents as a first-class client. Everything a human does in the web app — connecting repositories, scanning, triaging vulnerabilities, generating remediation plans, checking compliance, exporting reports, and even **buying a plan** — is available to agents through the platform's remote MCP (Model Context Protocol) server. This section explains how an agent or LLM assistant should use the platform end to end.
## Connect
The MCP server is hosted at `mcp.safeguard.sh` and works with every major assistant — Claude, ChatGPT, Copilot, Gemini, Le Chat, Perplexity, Cursor, and more. Follow the step-by-step guide for your client under [MCP Integrations](/docs/mcp).
Two ways in:
* **Existing account (OAuth):** authentication runs against your Safeguard workspace; the agent acts **as the signed-in user, inside their tenant**.
* **No account yet (agent-native):** connect to the unauthenticated endpoint `https://mcp.safeguard.sh/mcp/signup` and call `safeguard_signup`, then `safeguard_verify_email` with the token from the verification email (`safeguard_resend_verification` sends a new one). That endpoint offers only these three tools. Once the address is verified, connect the main endpoint `https://mcp.safeguard.sh/mcp` and sign in with OAuth. See [Procurement for agents](/docs/agents/procurement) for the full flow.
Tenant, organization, and product scope are carried per session — an agent never sees or touches another tenant's data, and scope can be switched mid-session with `safeguard_switch_organization` and `safeguard_switch_product` when the user belongs to several.
## What an agent can do
The server registers hundreds of tools spanning the whole platform, and a new workspace starts with a small read-only set. The everyday loops:
| Loop | Typical tools |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Onboard** | `safeguard_add_integration` → `safeguard_scan_repository` → `safeguard_list_projects` |
| **Triage** | `safeguard_list_vulnerabilities`, `safeguard_list_findings`, `safeguard_get_vulnerability`, `safeguard_query` (natural language over any entity) |
| **Fix** | `safeguard_get_remediation_plan`, `safeguard_fix_vulnerability`, `safeguard_list_repository_pull_requests`, `safeguard_merge_pull_request` |
| **Comply** | compliance framework checks, policy gate evaluation, evidence exports |
| **Analyze** | SBOM comparison and analysis, dependency graphs, supply-chain risk, package/CVE intelligence |
| **Procure** | account creation, pricing plans, checkout, invoices, entitlements — see [Procurement for agents](/docs/agents/procurement) |
| **Administer** | full CRUD over users, organizations, members, API keys, webhooks, and Guard secret keys (`safeguard_create_secret_key` — plaintext shown once) |
| **Stay informed** | `safeguard_list_notifications`, `safeguard_get_notification`, `safeguard_get_notification_count`, `safeguard_mark_notifications_read` — the user's own notification inbox (scan results, new findings, remediation PRs, billing events) |
For open-ended questions ("what's risky in my newest project?"), prefer `safeguard_query` — it routes through the production query engine and handles ambiguity best. For precise lookups, use the structured tools with filters.
## Governance: what your agent is allowed to do
Tool availability is governed per tenant with [per-tool feature flags](/docs/mcp/tool-gating). A fresh workspace starts with a small curated set covering the onboarding loop; administrators enable more per workspace. Discovery (`tools/list`) and execution (`tools/call`) resolve from the same flag set, so an agent can never call a tool it cannot see. Write-capable tools (merging PRs, purchasing plans) are deliberately opt-in.
Every tool call runs under the session's tenant/org/product scope with the platform's standard audit logging; billing calls additionally emit structured billing audit records.
## Good agent behaviour on Safeguard
* **Start with context.** Call `safeguard_get_current_context` early to learn the tenant, organization, and product in scope.
* **Discover before acting.** List projects/plans/integrations before mutating anything; ids from listings are the inputs to everything else.
* **Prefer natural-language query for exploration**, structured tools for automation.
* **Respect gating errors.** A `Tool "…" is not enabled for this tenant` result means an administrator decision, not a bug — surface it to the user rather than retrying.
* **Keep humans on payment.** Procurement tools return a Stripe-hosted checkout link; hand it to the user rather than trying to complete payment yourself — card data never belongs in a model's context.
## Procure the platform itself
Agents can take a workspace from "we hit our scan limit" to "paid, activated, and resumed" in one conversation: browse the plans offered to the tenant with correct regional pricing, compare tiers (and the features each enables), start checkout, and verify activation. The full walkthrough is on the next page: [Procurement for agents](/docs/agents/procurement).
# Procurement for agents (/docs/agents/procurement)
This page is the operational guide for an agent procuring Safeguard on behalf of its user. It complements the [MCP payments & procurement reference](/docs/mcp/agent-payments) with the recommended conversation flow.
## Prerequisites
* The billing tools are **opt-in** — an administrator must enable them for the workspace (`mcp:tool:safeguard_list_pricing_plans`, `mcp:tool:safeguard_purchase_plan`, `mcp:tool:safeguard_list_billing_invoices`, `mcp:tool:safeguard_get_subscription_entitlements`) in the admin console; only six read-only tools are on by default (see [tool gating](/docs/mcp/tool-gating)).
* The session is authenticated into the tenant that will be buying. Purchases are pinned to the session tenant — there is no way (by design) to buy for another tenant. No account yet? Start at Step 0.
## Step 0 — No account yet? Create one
A new user can sign up from inside the conversation. The regular `/mcp` endpoint requires sign-in, so signup has its own unauthenticated endpoint, **`https://mcp.safeguard.sh/mcp/signup`**, which offers exactly three tools and cannot read or change any data:
```json
// safeguard_signup
{
"email": "founder@newco.io",
"password": "",
"first_name": "Ada",
"last_name": "Lovelace"
}
```
* The account is created unverified and cannot sign in yet. Safeguard emails a verification link to the address.
* Take the `token` value from the link in that email (an agent with access to the user's inbox can do this; otherwise ask the user to open the link) and call `safeguard_verify_email` with just the token.
* If the email doesn't arrive, or the token has expired, call `safeguard_resend_verification` with the email address. It issues a new token and invalidates the old one.
* Once the address is verified, connect the main endpoint `https://mcp.safeguard.sh/mcp` and sign in with OAuth. Every step below runs there, as the new account.
## Step 1 — Resolve the user's pricing region
Send **everything you know** about where the user is. You do not need a clean country code — the server analyses all signals offline and explains its choice:
```json
// safeguard_list_pricing_plans
{
"location": {
"country_name": "India",
"locale": "en-IN",
"timezone": "Asia/Kolkata",
"city": "Bengaluru",
"district_or_state": "Karnataka",
"currency": "INR"
},
"audience": "TEAM"
}
```
Signal precedence: explicit ISO `country` → `country_name` → `locale` region → `timezone` → unambiguous `currency`. A continent, city, or IP address alone cannot safely select one country and falls back to GLOBAL pricing — the response's *Pricing region* section tells you exactly what happened, so you can ask the user for a stronger signal if it matters.
## Step 2 — Compare tiers and audiences
The response groups plans by product. For each plan you get:
* **Tier** (`PRO`, `MAX`, `5X`, `20X`, `ENTERPRISE` …) — depth: quotas and the feature set enabled on activation
* **Audience** (`INDIVIDUAL` single user · `TEAM` · `ENTERPRISE` · `SHARED` for everyone) — fit; filter with `audience`, SHARED plans always included
* Monthly and yearly prices (yearly defaults to 20% off when no explicit yearly price exists)
* The feature list that tier unlocks
* Whether it is purchasable online, or needs a sales contact
Recommend by matching the user's stated need (a quota to lift, a feature to unlock, a team size) against tier features and price — and say why.
## Step 3 — Purchase (fully automatic when a card is on file)
Check `safeguard_get_payment_method_status` first:
* **Card on file** → `safeguard_purchase_plan_autopay` charges it immediately and activates the plan on the spot — no checkout page, no human. Done; skip to Step 4.
* **No card yet** → the first purchase goes through Stripe Checkout (below), which saves the card so every future purchase can use autopay. Manage what's active with `safeguard_list_subscriptions` / `safeguard_cancel_subscription`.
### First purchase — Stripe Checkout
```json
// safeguard_purchase_plan
{
"plan_id": 42,
"interval": "year",
"email": "buyer@example.com"
}
```
The tool returns a **Stripe-hosted checkout URL**. Hand that link to the user — payment is completed on Stripe's page, never in the conversation. Do not ask for, accept, or relay card details; if the user pastes them, tell them to use the link instead. Workspaces with a saved payment method check out in one click.
## Step 4 — Verify the purchase
After the user reports paying (or on their next message), confirm rather than assume:
1. `safeguard_list_billing_invoices` — the new invoice should show status **paid**. That is the procurement receipt; it includes a PDF link for records.
2. `safeguard_get_subscription_entitlements` — lists the feature flags now enabled, so you can tell the user exactly what their new tier switched on.
Activation is automatic on payment (usage limits raised, product license granted). If the user's scans were paused on a usage limit, they can now be resumed. Billing and activation events also land in the user's notification inbox — check them with `safeguard_list_notifications` / `safeguard_get_notification`.
## Failure modes
| You see | It means | Do |
| ---------------------------------------- | ------------------------------------------------------- | ---------------------------------------------------------------------------- |
| Tool not enabled for this tenant | Admin hasn't opted the workspace into that billing tool | Tell the user which flag to ask their admin for |
| "This plan isn't purchasable online yet" | No online price on the plan | Use the plan's contact-sales route |
| Checkout returns no URL | Stripe not configured in this environment | Escalate to [sales@safeguard.sh](mailto:sales@safeguard.sh) |
| Invoice still `open` after payment | Payment not completed or still settling | Re-check after a moment; the hosted invoice link lets the user finish paying |
## Audit expectations
Every call you make on this journey — including read-only pricing and invoice pulls — is recorded with your tenant, user, action, and outcome, and the money events (activation, license grant) land in the platform audit log. Behave as if the compliance team is watching, because they can.
# Safeguard CLI (/docs/cli)
# Safeguard CLI
The Safeguard CLI scans code, container images and SBOMs on your own machine, sends only the results to the platform, and includes an assistant that can fix what it finds.
## Overview
The CLI allows you to:
* Scan a directory, a Git repository, a container image or an existing SBOM for vulnerabilities
* Find hardcoded secrets and misconfigurations
* Validate SPDX, CycloneDX and VEX documents
* Run platform-assigned scan jobs locally, uploading SBOMs and findings but never source
* Fix and review code with the built-in assistant, interactively or in CI with `safeguard exec`
## Quick Start
Install it — macOS and Linux:
```bash
curl -fsSL https://cli.safeguard.sh/install | bash
```
Windows:
```powershell
irm https://cli.safeguard.sh/install.ps1 | iex
```
Then open the terminal and sign in:
```bash
safeguard
```
Type `/login` to authenticate, then `/scan .` to scan the folder you are in.
Or just ask it something — "how many critical vulns do we have" works.
## Key Features
| Feature | Description |
| --------------------------------- | ------------------------------------------------------------------------------- |
| **Vulnerability scanning** | `safeguard scan` builds an SBOM and matches it against vulnerability databases |
| **Secrets and misconfigurations** | `safeguard detect`, with table, JSON or SARIF output |
| **SBOM validation** | `safeguard validate` for CycloneDX, SPDX and VEX |
| **Local runner** | Executes the platform's scan jobs on your machine; only results leave it |
| **Assistant** | `safeguard agent` interactively, `safeguard exec` non-interactively |
| **Offline databases** | `safeguard update --import` loads a vulnerability database downloaded elsewhere |
Policies and gates are evaluated in the platform, not by the CLI. See
[Policies & gates](/docs/esscm/policies-gates).
## Documentation
## System Requirements
The CLI is a single static binary. There is no runtime to install alongside
it — no Node, no Python, no JVM.
| Requirement | Minimum |
| -------------------- | ---------------------------------------------------------------------------- |
| **Operating System** | macOS, Linux, or Windows — see [Platforms](/docs/cli/installation#platforms) |
| **Architecture** | x86\_64 or arm64 (Windows ships x86\_64 only) |
| **Disk Space** | \~40MB for the binary, plus the scanners it downloads on first use |
## Getting Help
```bash
# View all commands
safeguard --help
# Get help for a specific command
safeguard scan --help
safeguard detect --help
```
## Next Steps
1. [Install the CLI](/docs/cli/installation)
2. [Learn basic usage](/docs/cli/usage)
3. [Integrate with CI/CD](/docs/cicd-integration)
# CLI Installation (/docs/cli/installation)
# CLI Installation
The Safeguard CLI is a single static binary. There is no runtime to install
alongside it — no Node, no Python, no JVM — and nothing it depends on at run
time beyond the scanners it downloads on first use.
## Install
**macOS and Linux**
```bash
curl -fsSL https://cli.safeguard.sh/install | bash
```
**Windows**
```powershell
irm https://cli.safeguard.sh/install.ps1 | iex
```
The installer detects your OS and architecture, resolves the current release,
verifies the download against the published checksums, and puts one
`safeguard` binary on your PATH.
Confirm it landed:
```bash
safeguard --version
```
If `safeguard --version` reports a version you do not recognise, you probably
have an older copy earlier on your PATH — a `go install` build under
`~/go/bin`, for example. Run `which -a safeguard` (`Get-Command safeguard -All`
on Windows) to see every copy, and remove the ones you do not want.
## Read it before you run it
Piping a script from the internet into a shell is worth being careful about.
The installer is about a hundred lines of plain bash, and you are welcome to
read it first:
```bash
curl -fsSL https://cli.safeguard.sh/install -o install.sh && less install.sh
bash install.sh
```
Never pipe a URL you have not read into a shell — ours included.
## Checksum verification
Every release publishes a `checksums.txt` next to its archives. The installer
downloads it, checks the archive it just fetched, and refuses to install on a
mismatch.
The two installers differ in one security-relevant way, and it is worth
knowing which one you are running:
| Installer | Missing `checksums.txt` |
| ---------------------------- | ------------------------------------- |
| `install.sh` (macOS / Linux) | **Fails closed** — the install aborts |
| `install.ps1` (Windows) | **Warns and continues** |
On Windows, a release with no published checksums file will still install,
with a warning printed to the console. If you are installing in an environment
where that matters, verify the archive yourself against
`https://cli.safeguard.sh/releases//checksums.txt` before running the
binary.
To skip verification deliberately — an air-gapped mirror that does not carry
the checksums file, for instance — set `SAFEGUARD_SKIP_CHECKSUM=1`. It is an
explicit opt-out and it is never the default.
## Environment variables
Both installers read two variables:
| Variable | Effect |
| ----------------------- | ----------------------------------------------------- |
| `SAFEGUARD_VERSION` | Install this exact release instead of the current one |
| `SAFEGUARD_INSTALL_DIR` | Put the binary here instead of the default location |
Pin a release. Substitute the release you want for `` — the current
one is , and every published
release is listed at [cli.safeguard.sh/releases](https://cli.safeguard.sh/releases/latest.txt):
```bash
curl -fsSL https://cli.safeguard.sh/install | SAFEGUARD_VERSION= bash
```
```powershell
$env:SAFEGUARD_VERSION = ""; irm https://cli.safeguard.sh/install.ps1 | iex
```
Choose where it lands:
```bash
curl -fsSL https://cli.safeguard.sh/install | SAFEGUARD_INSTALL_DIR="$HOME/bin" bash
```
Without `SAFEGUARD_INSTALL_DIR`, the shell installer tries `/usr/local/bin` and
falls back to `~/.local/bin` if that is not writable; the PowerShell installer
uses `%LOCALAPPDATA%\Safeguard\bin` and adds it to your user PATH.
## Which release you get
The installers resolve the current version from
`https://cli.safeguard.sh/releases/latest.txt` on every run, so a plain install
always gets the newest release. Pin `SAFEGUARD_VERSION` when you need a build
to stay put — CI is the usual reason.
```bash
curl -fsSL https://cli.safeguard.sh/releases/latest.txt
```
## Platforms
| Target | Archive |
| --------------------- | ----------------------------------------- |
| macOS · Apple Silicon | `safeguard__darwin_arm64.tar.gz` |
| macOS · Intel | `safeguard__darwin_amd64.tar.gz` |
| Linux · x86\_64 | `safeguard__linux_amd64.tar.gz` |
| Linux · arm64 | `safeguard__linux_arm64.tar.gz` |
| Windows · x86\_64 | `safeguard__windows_amd64.zip` |
Windows on ARM is not published as its own build. The PowerShell installer
detects an ARM64 host, warns, and installs the x86\_64 binary, which runs under
emulation.
## First run
The CLI downloads its scanner toolchain the first time it needs it, so a
freshly installed binary has no scanners yet. Open the interactive terminal
once and let it complete setup:
```bash
safeguard
```
`safeguard update` refreshes the vulnerability databases of scanners you
already have. It does not install missing ones — that is what the first
interactive run is for.
## Sign in
Authentication happens inside the interactive terminal:
```bash
safeguard
```
Then type `/login`. Your browser opens, you approve the session, and the
terminal picks it up. `/whoami` shows who you are signed in as, and `/logout`
ends the session.
See [Interactive terminal](/docs/cli/interactive) for what else that terminal
does, and [Slash commands](/docs/cli/slash-commands) for the full list.
## Updating
Re-run the installer. It resolves the current release and replaces the binary
in place:
```bash
curl -fsSL https://cli.safeguard.sh/install | bash
```
```powershell
irm https://cli.safeguard.sh/install.ps1 | iex
```
## Uninstalling
Delete the binary and its state directory.
```bash
safeguard logout --yes
rm "$(command -v safeguard)"
rm -rf ~/.sg ~/.scanner ~/.cli
```
```powershell
Remove-Item "$env:LOCALAPPDATA\Safeguard" -Recurse -Force
```
`~/.sg` holds logs and local history, `~/.scanner` holds the sign-in token,
and `~/.cli` holds the deployment config if you ran `safeguard init`. Removing
them does not touch anything on the platform.
## Next Steps
# Interactive terminal (/docs/cli/interactive)
# Interactive terminal
Run `safeguard` with no arguments and you get a terminal rather than a help
screen:
```bash
safeguard
```
This is where you sign in, ask questions about your security posture, run
scans, and let the runner pick up jobs from the platform. Your code never
leaves the machine — only SBOMs and findings are uploaded.
## Signing in
Type `/login`. Your browser opens, you approve the session, and the terminal
picks it up. Once you are signed in the runner starts polling for scan jobs
scheduled from the platform.
`/whoami` shows the current session; `/logout` ends it and takes the runner
offline.
## Asking for things
Type in plain language. The assistant has tools for your local files and for
your Safeguard data, and picks whichever the question needs:
```text
how many critical vulns do we have
what's the latest file in ~/Downloads
fix the lodash CVE in this repo
```
Anything starting with `/` is a command instead — see
[Slash commands](/docs/cli/slash-commands).
## Writing more than one line
Enter sends your message. To put a newline in it without sending:
| Key | Notes |
| ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| `ctrl+j` | Works everywhere. The one to remember. |
| `alt+enter` | Where the terminal passes it through. Windows consoles intercept this as their own fullscreen toggle, so it does not reach the CLI there. |
| `\` then `enter` | A trailing backslash continues on the next line. |
The input grows as you type and hands the rows back to the transcript when you
send. Past eight rows it scrolls internally rather than swallowing the
conversation.
While a message spans several lines, the up and down arrows move the cursor
inside it. On a single-line input they recall your previous messages instead.
In Windows Terminal you can bind `shift+enter` to send a newline, which is the
key most people reach for. Add this to your `settings.json` actions:
```json
{ "command": { "action": "sendInput", "input": "\n" }, "keys": "shift+enter" }
```
## Selecting and copying
Text selection belongs to your terminal — drag to select, then copy the way
you normally would. The CLI does not capture the mouse, so selection, copy and
paste all behave exactly as they do everywhere else in that terminal.
The trade is that the mouse wheel does not scroll the transcript. Use
`PgUp` / `PgDn` and the arrow keys.
To take a whole answer without dragging across it, use `/copy`, which puts the
last response on your clipboard.
## Commands and files
Typing `/` opens the command palette, filtered as you type. Typing `@` opens a
file picker for the folder you started in, and the file you choose is attached
to your message so the assistant can read it.
Both show five entries at a time and scroll to follow your selection. `↑` and
`↓` move, `enter` chooses, `esc` closes. Neither one hides the conversation
while it is open.
## Approving actions
Some tools change things — writing a file, editing code, running a command.
Those ask before they act. `/permissions` chooses how often:
| Mode | Behaviour |
| ---- | --------------------------------------------------------- |
| Ask | Prompt before every action |
| Auto | Approve known actions, ask for anything new. The default. |
| Yolo | Approve everything, never ask |
The current mode is always shown in the bar under the input.
## Reading the screen
The bar above the input carries the runner's state — idle and polling, or the
scan in progress — with your model and connection status on the right.
Each answer closes with the time it took:
```text
✓ Completed in 2m 59s
```
Your own messages are banded so you can find where each exchange began when
scrolling back.
## Leaving
`/quit` exits. `esc` interrupts whatever is running without exiting, and
`/resume` picks the session back up next time you open the terminal in the
same folder.
## Colour and motion
The terminal uses full colour where it can. It falls back to plain,
escape-code-free output when it should: `NO_COLOR` set, output piped
somewhere, `TERM=dumb`, or CI. In that mode nothing animates, which keeps CI
logs diffable.
If the terminal renders entirely in black and white when you expect colour,
check whether `NO_COLOR` is set in that shell. It is honoured deliberately,
and it is the usual explanation.
## Next Steps
# Slash commands (/docs/cli/slash-commands)
# Slash commands
Inside the [interactive terminal](/docs/cli/interactive), anything beginning
with `/` is a command rather than a message. Type `/` on its own to open the
palette and filter as you type; `↑` and `↓` move, `enter` runs, `esc` closes.
`/help` lists these in the terminal itself.
## Account
| Command | What it does |
| --------- | --------------------------------------------------------------------------------------------------------------- |
| `/login` | Sign in and start scanning. Opens your browser to approve the session, then the runner begins polling for jobs. |
| `/logout` | Sign out and go offline. Stops the runner. |
| `/whoami` | Show who you're signed in as. |
## AI
| Command | What it does |
| ---------- | ----------------------------------------------------------------------------------------------- |
| `/model` | Show or switch the AI model. With no argument it opens a picker; with one it switches directly. |
| `/compact` | Summarize the conversation to free context. |
| `/resume` | Resume your last session in this folder. |
`/model` accepts an id or a label, matched case-insensitively, so `/model
griffin-2p` and `/model Premium` do the same thing. An unknown name is
rejected and lists what is available rather than switching to a model that
does not exist.
## Runner
| Command | What it does |
| -------------- | ----------------------------------------------------------------------------------- |
| `/scan` | Scan a folder, image, or repo. Called with no argument, it asks what to scan. |
| `/status` | Show current scan status — user, tenant, runner, uptime, job counts, approval mode. |
| `/jobs` | Show recent scan history. |
| `/permissions` | Choose approval mode: ask, auto, or yolo. |
## Tools
| Command | What it does |
| --------- | --------------------------------- |
| `/doctor` | Diagnose health and connectivity. |
## General
| Command | What it does |
| ---------- | ---------------------------------------------------------------------------- |
| `/copy` | Copy the last response to the clipboard. |
| `/clear` | Clear the conversation. Also forgets the context the assistant was carrying. |
| `/version` | Show version info. |
| `/help` | Show all commands. |
| `/quit` | Exit Safeguard. |
`/copy` is new in 1.2.0. Your terminal's own selection works too — the CLI does
not capture the mouse — but `/copy` is easier than dragging across a long
answer. See [Selecting and copying](/docs/cli/interactive).
## Attaching a file
`@` is not a command, but it behaves like one: typing it opens a picker for the
folder you started in, and the file you choose is attached to your message so
the assistant can read it.
## Next Steps
# Support Matrix (/docs/cli/support-matrix)
# Support Matrix
This page lists all languages, package managers, container registries, and platforms supported by the Safeguard CLI.
## Programming Languages & Package Managers
### JavaScript / TypeScript
| Package Manager | Manifest Files | Lock Files | Status |
| ---------------- | -------------- | ------------------- | -------------- |
| **npm** | `package.json` | `package-lock.json` | ✅ Full Support |
| **Yarn Classic** | `package.json` | `yarn.lock` | ✅ Full Support |
| **Yarn Berry** | `package.json` | `yarn.lock` | ✅ Full Support |
| **pnpm** | `package.json` | `pnpm-lock.yaml` | ✅ Full Support |
| **Bun** | `package.json` | `bun.lockb` | ✅ Full Support |
### Python
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | ------------------ | ---------------- | -------------- |
| **pip** | `requirements.txt` | - | ✅ Full Support |
| **Pipenv** | `Pipfile` | `Pipfile.lock` | ✅ Full Support |
| **Poetry** | `pyproject.toml` | `poetry.lock` | ✅ Full Support |
| **Conda** | `environment.yml` | `conda-lock.yml` | ✅ Full Support |
| **PDM** | `pyproject.toml` | `pdm.lock` | ✅ Full Support |
### Java / JVM
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | ---------------------------------- | ----------------- | -------------- |
| **Maven** | `pom.xml` | - | ✅ Full Support |
| **Gradle** | `build.gradle`, `build.gradle.kts` | `gradle.lockfile` | ✅ Full Support |
| **Scala SBT** | `build.sbt` | - | ✅ Full Support |
| **Kotlin** | `build.gradle.kts` | - | ✅ Full Support |
### Go
| Package Manager | Manifest Files | Lock Files | Status |
| ---------------- | -------------- | ------------ | ------------------ |
| **Go Modules** | `go.mod` | `go.sum` | ✅ Full Support |
| **Dep** (legacy) | `Gopkg.toml` | `Gopkg.lock` | ⚠️ Limited Support |
### Rust
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | -------------- | ------------ | -------------- |
| **Cargo** | `Cargo.toml` | `Cargo.lock` | ✅ Full Support |
### .NET / C\#
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | ---------------------------------- | -------------------- | -------------- |
| **NuGet** | `*.csproj`, `*.vbproj`, `*.fsproj` | `packages.lock.json` | ✅ Full Support |
| **Paket** | `paket.dependencies` | `paket.lock` | ✅ Full Support |
| **.NET Core** | `*.deps.json` | - | ✅ Full Support |
### Ruby
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | -------------- | -------------- | -------------- |
| **Bundler** | `Gemfile` | `Gemfile.lock` | ✅ Full Support |
### PHP
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | --------------- | --------------- | -------------- |
| **Composer** | `composer.json` | `composer.lock` | ✅ Full Support |
### Swift / iOS
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | --------------- | ------------------ | -------------- |
| **Swift PM** | `Package.swift` | `Package.resolved` | ✅ Full Support |
| **CocoaPods** | `Podfile` | `Podfile.lock` | ✅ Full Support |
### C / C++
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | ------------------------------- | ------------ | -------------- |
| **Conan** | `conanfile.txt`, `conanfile.py` | `conan.lock` | ✅ Full Support |
| **vcpkg** | `vcpkg.json` | - | ✅ Full Support |
### Elixir
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | -------------- | ---------- | -------------- |
| **Mix** | `mix.exs` | `mix.lock` | ✅ Full Support |
### Haskell
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | -------------- | ---------------------- | -------------- |
| **Cabal** | `*.cabal` | `cabal.project.freeze` | ✅ Full Support |
| **Stack** | `stack.yaml` | `stack.yaml.lock` | ✅ Full Support |
### Erlang
| Package Manager | Manifest Files | Lock Files | Status |
| --------------- | -------------- | ------------ | -------------- |
| **Rebar3** | `rebar.config` | `rebar.lock` | ✅ Full Support |
## Container Registries
| Registry | Authentication | Status |
| ----------------------------- | ----------------------------------- | -------------- |
| **Docker Hub** | Username/Password, Token | ✅ Full Support |
| **Amazon ECR** | AWS IAM, Access Keys | ✅ Full Support |
| **Google GCR** | Service Account, gcloud | ✅ Full Support |
| **Azure ACR** | Service Principal, Managed Identity | ✅ Full Support |
| **GitHub Container Registry** | Personal Access Token | ✅ Full Support |
| **GitLab Container Registry** | Personal Access Token | ✅ Full Support |
| **JFrog Artifactory** | API Key, Token | ✅ Full Support |
| **Harbor** | Username/Password | ✅ Full Support |
| **Quay.io** | Robot Account, OAuth | ✅ Full Support |
| **Generic OCI Registry** | Username/Password | ✅ Full Support |
## Binary File Types
| File Type | Extensions | Status |
| ---------------------- | ---------------------- | -------------- |
| **Windows Executable** | `.exe` | ✅ Full Support |
| **Windows Installer** | `.msi` | ✅ Full Support |
| **Windows Library** | `.dll` | ✅ Full Support |
| **Android Package** | `.apk` | ✅ Full Support |
| **Android Bundle** | `.aab` | ✅ Full Support |
| **iOS Application** | `.ipa` | ✅ Full Support |
| **Java Archive** | `.jar`, `.war`, `.ear` | ✅ Full Support |
| **Linux Executable** | ELF binaries | ✅ Full Support |
| **macOS Application** | `.app`, `.dmg` | ✅ Full Support |
## SBOM Formats
### Input Formats
| Format | Versions | Status |
| ------------------ | ------------- | -------------- |
| **CycloneDX JSON** | 1.4, 1.5, 1.6 | ✅ Full Support |
| **CycloneDX XML** | 1.4, 1.5, 1.6 | ✅ Full Support |
| **SPDX JSON** | 2.2, 2.3 | ✅ Full Support |
| **SPDX Tag-Value** | 2.2, 2.3 | ✅ Full Support |
| **SPDX RDF** | 2.2, 2.3 | ✅ Full Support |
### Output Formats
| Format | Status |
| ------------------ | -------------- |
| **CycloneDX JSON** | ✅ Full Support |
| **CycloneDX XML** | ✅ Full Support |
| **SPDX JSON** | ✅ Full Support |
| **SPDX Tag-Value** | ✅ Full Support |
| **SPDX RDF** | ✅ Full Support |
| **CSV** | ✅ Full Support |
| **JSON (Custom)** | ✅ Full Support |
| **SARIF** | ✅ Full Support |
| **JUnit XML** | ✅ Full Support |
## Operating Systems
The CLI is a static binary, so what matters is the OS and architecture, not
the distribution. Five targets are published:
| OS | Architecture | Archive |
| ----------- | ------------- | ----------------------------------------- |
| **macOS** | Apple Silicon | `safeguard__darwin_arm64.tar.gz` |
| **macOS** | Intel | `safeguard__darwin_amd64.tar.gz` |
| **Linux** | x86\_64 | `safeguard__linux_amd64.tar.gz` |
| **Linux** | arm64 | `safeguard__linux_arm64.tar.gz` |
| **Windows** | x86\_64 | `safeguard__windows_amd64.zip` |
Windows on ARM has no build of its own; the installer detects it, warns, and
installs the x86\_64 binary to run under emulation.
## CI/CD Platforms
| Platform | Integration Method | Status |
| ----------------------- | ------------------ | -------------- |
| **GitHub Actions** | Official Action | ✅ Full Support |
| **GitLab CI** | Docker Image | ✅ Full Support |
| **Jenkins** | Plugin, CLI | ✅ Full Support |
| **Azure DevOps** | Extension, CLI | ✅ Full Support |
| **CircleCI** | Orb, CLI | ✅ Full Support |
| **Bitbucket Pipelines** | Docker Image | ✅ Full Support |
| **AWS CodeBuild** | CLI | ✅ Full Support |
| **Google Cloud Build** | CLI | ✅ Full Support |
| **Travis CI** | CLI | ✅ Full Support |
| **TeamCity** | CLI | ✅ Full Support |
## IDE Integrations
| IDE | Extension | Status |
| ----------------- | ------------------- | -------------- |
| **VS Code** | Safeguard Extension | ✅ Available |
| **IntelliJ IDEA** | Safeguard Plugin | ✅ Available |
| **Visual Studio** | Safeguard Extension | ✅ Available |
| **Eclipse** | Safeguard Plugin | 🔄 Coming Soon |
## Runtime Requirements
There is no runtime to install alongside the CLI — no Node, no Python, no JVM.
| Requirement | Minimum |
| -------------- | ------------------------------------------------------------------ |
| **Disk Space** | \~40MB for the binary, plus the scanners it downloads on first use |
## Feature Support by License
| Feature | Free | Pro | Enterprise |
| ---------------------- | -------- | --------- | ---------- |
| SBOM Generation | ✅ | ✅ | ✅ |
| Vulnerability Scanning | 10/month | Unlimited | Unlimited |
| Policy Gates | Basic | Advanced | Custom |
| API Access | Limited | Full | Full |
| CI/CD Integration | ✅ | ✅ | ✅ |
| Offline Mode | ❌ | ❌ | ✅ |
| Priority Support | ❌ | ✅ | ✅ |
## Legend
| Symbol | Meaning |
| ------ | ----------------------- |
| ✅ | Full Support |
| ⚠️ | Limited/Partial Support |
| 🔄 | Coming Soon |
| ❌ | Not Supported |
# System Configuration (/docs/cli/system-configuration)
# System Configuration
The CLI keeps three separate kinds of local state. Most machines only ever
need the first one, and `/login` creates it for you.
| What | Where | Changed with |
| ------------------------------------------- | -------------------------------- | ----------------------------------------------- |
| Sign-in token | `~/.scanner/token.json` | `safeguard login`, `safeguard logout`, `/login` |
| Deployment config (tenant, client, servers) | `~/.cli/config.json` | `safeguard init`, `safeguard config` |
| Assistant and terminal settings | `settings.json` files, see below | editing the file |
Logs go to `~/.sg/logs/safeguard.log`. Set `LOG_DIR` to write them somewhere
else.
## Deployment config
A cloud user signed in with `/login` does not need this. It exists for
on-premise and managed deployments where the machine has to be pointed at a
specific tenant and auth server.
### Initialize
Use the configuration file downloaded from your organization's settings page:
```bash
safeguard init --config-file ./safeguard-config.json
```
Or pass the values directly. `--tenant`, `--client-id` and `--auth-server` are
required:
```bash
safeguard init \
--tenant \
--client-id \
--auth-server https://api.safeguard.sh/auth \
--api-server https://api.safeguard.sh
```
Other flags: `--org-id`, `--org-name`, `--client-secret` and `--env`
(`dev`, `staging` or `prod`, default `prod`).
### View, change, reset
```bash
# Print the current deployment config
safeguard config show
# Change one value
safeguard config set api_server https://safeguard.example.internal
# Delete this machine's deployment and auth configuration
safeguard config reset
```
`config set` accepts these keys and rejects anything else: `tenant_id`,
`client_id`, `auth_server`, `api_server`, `org_name`, `environment`.
`config show` exits non-zero when no configuration exists yet, so a script can
tell "not configured" apart from "configured".
### Cloud or on-premise
```bash
safeguard mode # show the current mode and where it came from
safeguard mode cloud # switch to cloud
safeguard mode onprem # switch to on-premise
```
## Assistant and terminal settings
The interactive terminal and the assistant (`safeguard agent`,
`safeguard exec`) read `settings.json` from up to three places. Higher in the
list wins:
1. Command-line flags
2. `/.safeguard/settings.local.json`, your own overrides, kept out of git
3. `/.safeguard/settings.json`, shared with the repository
4. `~/.safeguard/settings.json`, your user settings
5. Built-in defaults
A repository's own settings apply only after you run `safeguard trust` in it,
and they can never set sign-in, provider or server URLs. Those stay in the
deployment config.
To turn off the background update check from settings:
```json
{ "update": { "check": false } }
```
## Credential storage
The sign-in token is a file readable only by you (mode `0600`) by default.
`SAFEGUARD_CREDENTIAL_STORE` selects where it is kept:
| Value | Store |
| ---------------- | --------------------------------------------------------------------------------------------------- |
| `file` (default) | `~/.scanner/token.json` |
| `native` | The operating system's credential store: macOS Keychain, the Linux Secret Service, or Windows DPAPI |
| `auto` | The native store when one is available, otherwise the file |
## Scanner tools
Scans run syft, grype and trivy. The interactive terminal downloads them the
first time it runs, into `tools/` next to the binary. `safeguard scan`
looks for them in `TOOLS_DIR` first, then next to the binary, then on your
`PATH`. `safeguard update` refreshes their vulnerability databases, and
`safeguard update --scanner grype --import ` loads a database you
downloaded by hand, for a machine with no internet access.
## Environment variables
| Variable | Effect |
| --------------------------------- | ------------------------------------------------------------- |
| `LOG_DIR` | Where `safeguard.log` is written |
| `TOOLS_DIR` | Where to look for the scanner binaries |
| `SAFEGUARD_CREDENTIAL_STORE` | `file`, `native` or `auto`, see above |
| `SAFEGUARD_NO_UPDATE_CHECK=1` | Skip the background check for a new release |
| `SAFEGUARD_DISABLE_SELF_UPDATE=1` | Turn off binary updates entirely |
| `SAFEGUARD_NO_BROWSER` | The interactive terminal does not open a browser for `/login` |
There is no API-key variable and no variable that points the CLI at a config
file. Sign in with `/login` or `safeguard login` instead.
## Next Steps
* [Learn CLI usage](/docs/cli/usage)
* [Troubleshoot issues](/docs/cli/troubleshooting)
* [View support matrix](/docs/cli/support-matrix)
# Troubleshooting CLI Issues (/docs/cli/troubleshooting)
# Troubleshooting CLI Issues
This guide helps you diagnose and resolve common issues with the Safeguard CLI.
## Start with doctor
`safeguard doctor` checks the environment, sign-in, tools and policy and
prints what is wrong, most important first. It changes nothing:
```bash
safeguard doctor
```
For more detail while a scan runs, add `--verbose`:
```bash
safeguard scan --dir . --verbose
```
Every run also writes a structured log to `~/.sg/logs/safeguard.log`.
## Authentication Issues
### "Not authenticated" or HTTP 401
1. See who you are signed in as, and whether the token has expired:
```bash
safeguard whoami
```
2. Sign in again. `--force` re-authorizes even when a session exists, which is
also how you switch accounts:
```bash
safeguard logout
safeguard login --force
```
The CLI does not read an API key from the environment. A machine is
authorized by signing in with `/login` or `safeguard login`.
### Browser sign-in does not open or does not finish
Use the device code by hand:
```bash
safeguard login --no-browser
```
The CLI prints a verification URL and a short code. Open the URL on any device,
enter the code, approve, and the CLI picks up the session.
## Network Issues
### "Connection refused" or "Network error"
**Solutions:**
1. Check internet connectivity:
```bash
curl -I https://api.safeguard.sh/auth
```
2. Configure proxy if behind corporate firewall:
```bash
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
```
3. Check firewall rules allow outbound HTTPS (port 443)
### "Certificate error" or "SSL handshake failed"
**Solutions:**
1. Point the CLI at a custom CA bundle:
```bash
export SSL_CERT_FILE=/path/to/corporate-ca.crt
```
2. Update system CA certificates — the CLI uses the system trust store, so
installing the certificate there fixes it for every tool at once:
```bash
# Ubuntu/Debian
sudo update-ca-certificates
# macOS
security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain /path/to/cert.crt
```
3. If neither works, [contact support](mailto:hi@safeguard.sh) with the
output of `safeguard --version` and the full error.
Do not reach for a flag that turns certificate verification off. Trusting your
corporate CA — either in the system trust store or via `SSL_CERT_FILE` above —
solves the same problem without accepting any certificate from anyone.
### Timeout Errors
**Solutions:**
1. Scan a subdirectory instead of the whole repository:
```bash
safeguard scan --dir ./services/api
```
2. Skip transitive resolution, which makes network calls for every
dependency, unless you need it (it is off unless you pass
`--resolve-transitive`).
## Scanning Issues
### "No dependencies found"
**Possible causes:**
* No manifest files in the directory
* Manifest files not recognized
* Wrong directory specified
**Solutions:**
1. Verify manifest files exist:
```bash
ls -la package.json requirements.txt pom.xml go.mod Cargo.toml
```
2. Check you're in the correct directory:
```bash
pwd
safeguard scan --dir "$(pwd)"
```
### "Unsupported package manager"
**Solution:** Check the [support matrix](/docs/cli/support-matrix) for supported package managers.
### Incomplete SBOM (Missing Dependencies)
**Solutions:**
1. Install dependencies first:
```bash
# Node.js
npm install
# Python
pip install -r requirements.txt
# Go
go mod download
```
2. Include lock files:
```bash
# Ensure lock files exist
ls -la package-lock.json yarn.lock Pipfile.lock
```
### "Out of memory" Error
**Solutions:**
1. Scan subdirectories separately for monorepos:
```bash
safeguard scan --dir ./packages/app1
safeguard scan --dir ./packages/app2
```
## Container Scanning Issues
### "Image not found"
**Solutions:**
1. Verify image exists:
```bash
docker images | grep myimage
```
2. Pull the image first:
```bash
docker pull myimage:latest
safeguard scan --image myimage:latest
```
3. Use full image reference:
```bash
safeguard scan --image docker.io/library/nginx:latest
```
### "Registry authentication failed"
**Solutions:**
1. Login to registry first:
```bash
docker login myregistry.azurecr.io
```
2. Provide credentials:
```bash
safeguard scan --image myregistry.azurecr.io/app:v1 \
--registry-username "$USERNAME" \
--registry-password "$PASSWORD"
```
## Policy and gate issues
The CLI has no policy or gate command. Policies and gates are defined and
evaluated in the platform, on the scans it runs and the results the runner
uploads. See [Policies & gates](/docs/esscm/policies-gates) for how to see why
a gate failed and how exceptions are approved.
## Output Issues
### "Permission denied" When Writing Output
Write somewhere you own:
```bash
safeguard scan --dir . --output ~/safeguard-results
```
### JSON on stdout is mixed with messages
Commands write machine-readable JSON to stdout and every notice and log line to
stderr, so redirect stdout alone:
```bash
safeguard detect --format json > detect.json
```
## Installation Issues
### "Command not found: safeguard"
**Solutions:**
1. Find every copy on your PATH:
```bash
which -a safeguard
```
```powershell
Get-Command safeguard -All
```
2. If more than one appears, the first wins. An old build under `~/go/bin`
shadowing the installed one is the usual cause — check what each reports:
```bash
safeguard --version
```
3. If none appears, the install directory is not on your PATH. Open a new
shell first (the Windows installer adds its directory to the user PATH,
which existing shells do not pick up), then reinstall if it is still
missing:
```bash
curl -fsSL https://cli.safeguard.sh/install | bash
```
### "syft binary not found" on a fresh install
**Symptoms:**
* A scan fails immediately on a machine where the CLI was just installed
**Cause:**
The CLI downloads its scanner toolchain the first time it needs it. A freshly
installed binary has no scanners yet.
**Solution:**
Open the interactive terminal once and let first-run setup finish:
```bash
safeguard
```
`safeguard update` refreshes the vulnerability databases of scanners you
already have — it does not install missing ones. If a directory scan warns and
returns nothing on a new machine, the scanner database has not been populated
yet; run `safeguard update` after the first interactive run.
## Getting More Help
### Collect diagnostic information
```bash
safeguard --version
safeguard doctor > doctor.txt
```
### Contact support
Raise it from the CLI, which files it on the same queue as the product's
Help & Feedback sheet:
```bash
safeguard support bug "what you ran, what you expected, what happened"
```
Or email [hi@safeguard.sh](mailto:hi@safeguard.sh) with the `doctor` output,
the error and the steps to reproduce. The log file is
`~/.sg/logs/safeguard.log`.
## Reset Everything
As a last resort, reset the CLI completely:
```bash
# Sign out and remove the deployment config
safeguard logout --yes
safeguard config reset --yes
# Remove local state: logs, history, sign-in token
rm -rf ~/.sg ~/.scanner
# Reinstall over the top
curl -fsSL https://cli.safeguard.sh/install | bash
```
```powershell
Remove-Item "$env:USERPROFILE\.sg", "$env:USERPROFILE\.scanner" -Recurse -Force
irm https://cli.safeguard.sh/install.ps1 | iex
```
Then open the terminal and sign in again:
```bash
safeguard
```
Type `/login`, then `/doctor` to confirm health and connectivity.
# CLI Usage (/docs/cli/usage)
# CLI Usage
This page covers the commands you run directly, outside the interactive
terminal. Most people start with the terminal instead: run `safeguard`, type
`/login`, then `/scan .`. See [Interactive terminal](/docs/cli/interactive) and
[Slash commands](/docs/cli/slash-commands).
`safeguard --help` lists every command in the build you have, and
`safeguard --help` lists its flags. If this page and `--help`
disagree, `--help` is right.
## Command structure
```bash
safeguard [subcommand] [flags]
```
## Sign in
Authentication is an OAuth 2.0 device-code flow. It works the same from the
terminal (`/login`) and from the command line:
```bash
# Opens your browser; approve the session there
safeguard login
# On a machine with no browser: prints a URL and a code to enter elsewhere
safeguard login --no-browser
# Who am I signed in as, and when does the token expire
safeguard whoami
# Revoke the session and remove the local token
safeguard logout
```
The token is stored on the machine that signed in. There is no API-key
environment variable for the CLI: a machine is authorized by signing in once.
## Scan
`safeguard scan` builds an SBOM for a target, matches it against
vulnerability databases, and writes the results as JSON files under
`--output` (default `./output`). It takes exactly one target:
```bash
# A local directory (your own or proprietary code)
safeguard scan --dir .
# A container image
safeguard scan --image nginx:latest
# A private registry
safeguard scan --image myregistry.azurecr.io/myapp:v1 \
--registry-username "$REGISTRY_USER" \
--registry-password "$REGISTRY_PASSWORD"
# A Git repository
safeguard scan --repo https://github.com/org/repo
# A private repository
safeguard scan --repo https://github.com/org/private-repo --git-token "$GIT_TOKEN"
# An SBOM you already have (SPDX or CycloneDX, detected automatically)
safeguard scan --sbom sbom.json
```
Useful flags:
| Flag | Effect |
| -------------------------------- | ------------------------------------------------------------------------ |
| `--output ` | Where results are written (default `output`) |
| `--scanners ]` | Run only these scanners |
| `--resolve-transitive` | Resolve transitive dependencies through deps.dev |
| `--org-namespace ` | Namespaces that identify your own private packages, such as `@mycompany` |
| `--format auto\|spdx\|cyclonedx` | Format of the SBOM passed with `--sbom` |
| `--verbose` | More detail while the scan runs |
Results include `vuln.json`, `license.json` and `collection.json`, among
others, in a folder per scan. To see them in the platform alongside your other
projects, scan from the interactive terminal (`/scan .`) while signed in: the
runner uploads the SBOM and findings, never your source.
`safeguard scan` runs syft and grype. The interactive terminal downloads them
the first time it runs. On a machine that has never opened the terminal, such
as a fresh CI container, put `syft` and `grype` on the `PATH` or point
`TOOLS_DIR` at a directory that holds them.
### Exit codes
`safeguard scan` does not fail on findings. It exits `0` when the scan ran,
whatever it found, `1` when the command itself failed (a bad flag, an
unreadable target), and `2` when results were written but the vulnerability
scan did not actually run, so a script never mistakes that for a clean pass.
There is no severity threshold flag; gating on findings is done by
[policy gates](/docs/esscm/policies-gates) in the platform.
## Find secrets and misconfigurations
```bash
# Secrets and misconfigurations in the current directory
safeguard detect
# Only secrets, as SARIF, written to a file
safeguard detect --detect secrets --format sarif --output detect.sarif
# Only report high and critical
safeguard detect --severity high
```
`--format` takes `table` (default), `json` or `sarif`. Values are redacted in
the output unless you pass `--redact=false`.
## Validate an SBOM
```bash
safeguard validate sbom.json
safeguard validate ./sboms --recursive
safeguard validate sbom.json --strict -o report.json
```
It checks CycloneDX (JSON and XML), SPDX (JSON, YAML, tag-value and RDF) and
VEX (CSAF and OpenVEX) documents against their specifications. `--strict`
treats warnings as errors, and `--fail-fast` stops at the first error.
## Fix and review
```bash
# Update vulnerable dependencies
safeguard fix --help
# Review the working-tree changes for correctness and security
safeguard review --help
# Run the assistant non-interactively, for example in CI
safeguard exec "summarise the critical findings in this repository"
```
`safeguard exec` runs one agent turn and exits. Its default permission mode is
`strict`: nothing is asked and anything the policy file has not pre-approved is
denied. It refuses to run outside a git repository unless you pass
`--skip-git-repo-check`. `--output-format json` gives a machine-readable
result.
## Keep it current
```bash
# Refresh the vulnerability databases (grype and trivy)
safeguard update
# Update the safeguard binary itself
safeguard self-update
# Check whether a new release exists without installing it
safeguard self-update --check
```
## Check the installation
```bash
safeguard doctor
```
`doctor` checks the environment, sign-in, tools and policy, and prints what
is wrong in the order that matters. It changes nothing and exits `0` whenever
the checks ran, so read its lines rather than its exit code.
## Ask for help
```bash
safeguard support ask "how do I scope a DAST scan to one host?"
safeguard support bug "the scan reported zero findings on a repo with known CVEs"
safeguard support feedback "the findings table should remember my filters"
safeguard support list
safeguard support show SUP-7KQ4-M2XD
safeguard support reply SUP-7KQ4-M2XD "it happens on every scan of that repo"
```
These raise the same tickets as the product's Help & Feedback sheet, and you
follow them in the app's Messages › Support too. You need to be signed in.
`--priority low|normal|high|urgent` sets the urgency (default `normal`), and
`--yes` answers the confirmation in advance. In the interactive terminal,
`/bug`, `/feedback` and `/support` do the same. See
[Help and support](/docs/help-and-support/cli-and-assistants).
## Environment variables
The CLI has no API-key variable and no config-file path variable. The ones
you are most likely to want:
| Variable | Effect |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ |
| `SAFEGUARD_NO_BROWSER` | The interactive terminal does not open a browser for `/login` (also the case when `CI` is set). For `safeguard login`, pass `--no-browser` |
| `SAFEGUARD_NO_UPDATE_CHECK=1` | Skip the background check for a new release |
| `SAFEGUARD_DISABLE_SELF_UPDATE=1` | Turn off binary updates entirely |
| `TOOLS_DIR` | Directory to look in for syft, grype and the other scanners |
| `LOG_DIR` | Where to write `safeguard.log` (default `~/.sg/logs`) |
The installer reads its own variables, listed on
[Installation](/docs/cli/installation#environment-variables).
## Getting help
```bash
safeguard --help
safeguard scan --help
safeguard detect --help
safeguard validate --help
```
## Next Steps
* [Configure the CLI](/docs/cli/system-configuration)
* [Troubleshoot issues](/docs/cli/troubleshooting)
* [View support matrix](/docs/cli/support-matrix)
# Approvals (/docs/compliance-requests/approvals)
# Approvals
Some changes only count once a person decides them: a policy is in force once approved, evidence counts once accepted, an access review proves something once completed. Each decision is recorded with who made it, when, and why.
## Who can approve
A **compliance reviewer** makes these decisions. A reviewer is:
* an administrator (Super Admin, Tenant Admin or Org Admin);
* a holder of the **GRC** role, or of a compliance admin, manager or reviewer role; or
* anyone granted the `compliance:review`, `compliance:approve`, `compliance:admin` or `compliance:manage` permission.
Three rules sit above the role check:
* **An auditor does not decide your programme.** The Auditor role alone is not a reviewer: an external auditor tests management's decisions and does not make them. In an audit engagement, though, the auditor accepts or rejects what you submit against their requests (see [audit requests](#audit-requests)).
* **The assistant never decides.** A change made through Safeguard's AI assistant or an MCP client can draft and submit, but never accept, approve, launch or acknowledge, whoever is signed in behind it.
* **Unknown roles are refused.** If Safeguard cannot tell who is deciding, it refuses the decision and says why, rather than assume.
## Policies
On **Compliance › Policies**, a policy goes to review with **Submit for review**, and a reviewer approves it. An approval covers one version of the content.
* Editing an approved policy sends the new version to review, while the approved version stays in force. Staff keep following the text they were asked to follow until the new one is approved.
* On approval, the effective date defaults to the approval day and the next review to one year later. Marking the annual review done moves the review date on by a year without a new version.
* A reviewer launches an acknowledgement campaign (**Launch**) so staff acknowledge a specific approved version.
## Evidence
On **Compliance › Evidence**, evidence starts as **submitted**, and a reviewer chooses **Accept** or **Reject**. The decision is stamped with who made it, when and why.
* A result recorded by an automated test from its own run starts accepted on that basis.
* Changing accepted evidence (its file, link, note, dates or control) makes a new version, which goes back to submitted: an acceptance covers the version the reviewer saw.
* Accepted evidence with an end date becomes **expiring** inside its reminder window and **expired** from that date.
## Access reviews
On **Compliance › Access Reviews**, **Launch campaign** pulls every account from the connected systems in scope and assigns each one to a reviewer: per system, each person's manager, or one group of reviewers. Each reviewer gets a task.
* For each account the reviewer decides **Keep**, **Revoke** or **Modify**. **Revoke** and **Modify** need a reason. The item's reviewer, the campaign owner or a tenant administrator can decide.
* A decision never removes access by itself. Revoking is a separate, explicit confirmation for each item, carried out through the connected system or as a ticket.
* **Complete campaign** needs every item decided. It freezes the decisions and produces the evidence: a CSV, a signed summary and evidence records for the access controls.
## Test exclusions
On a test's detail page under **Compliance › Tests**, **Exclude** asks to exclude one resource from that test, such as a break-glass account. Give a **Reason**, choose an **Approver** and set **Expires on**.
Nothing is excluded until the approver approves it. From then until the expiry date, the resource counts as not applicable, with your reason shown as the evidence. An exclusion is **Pending approval**, **Approved**, **Rejected**, **Revoked** or **Expired**; the **Exclusions** tab lists them.
## Risk acceptance
On **Compliance › Risks**, accepting a residual risk depends on its level:
* **Low or medium**: the risk owner can accept it, recorded with their name and reason.
* **High or critical**: acceptance needs an approver with an admin role, and a date to review it within a year.
If the residual risk later rises above the level it was accepted at, the acceptance shows **Needs re-approval**: re-approve it or revoke it.
## Crosswalk mappings
On **Compliance › Crosswalk**, a reviewer decides whether a mapping between two frameworks' controls holds for your programme: **Approve**, **Reject** (with why it does not hold) or **Withdraw decision**.
* Approving an **equivalent** mapping makes accepted evidence for the source control count toward the target control in your programme. Approving a **partial** mapping confirms the suggestion but makes nothing count.
* Decisions are never edited or deleted: each is a new record, and the latest one counts, so the full history stays readable. Each is tied to the mapping's text, so an approval no longer applies if a later crosswalk version changes the mapping.
## Trust Center
* **Access requests** to your restricted documents are approved or denied by a reviewer, unless an auto-approval rule decides them ([Trust Center access requests](/docs/trust-center/access-requests)).
* **Audit outcome**: only a compliance reviewer or administrator can publish or take down the auditor's opinion on your Trust Center ([Trust Center setup](/docs/trust-center#audit-outcome)).
## Audit requests
In an audit engagement, the auditor lists what they need. Your team answers each request and chooses **Submit to auditor**; the auditor then chooses **Accept** or **Reject**, giving a reason for a rejection. Only auditors accept requests, draw samples, open findings and issue opinions.
## Assistants and MCP clients
Safeguard's AI assistant and MCP clients such as Claude or ChatGPT can read your programme and prepare changes, within the access your workspace and role allow. Two safeguards apply:
* **Writes wait for you.** An MCP client runs a write only after you confirm it in that client. In Griffin AI Search, every write shows a **Confirm** / **Cancel** card and runs only after you choose **Confirm**.
* **Decisions stay with people.** Even a confirmed write cannot approve, accept, launch or acknowledge anything: those decisions are made by a person in the app.
## Related
* [Requests and approvals](/docs/compliance-requests)
* [Trust Center access requests](/docs/trust-center/access-requests)
# Requests and approvals (/docs/compliance-requests)
# Requests and approvals
Your compliance programme receives requests from outside and makes decisions inside. Each has its own place in Safeguard, a record of who did what, and a rule about who may decide.
| Workflow | Who starts it | Where it is handled |
| ---------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------- |
| [Trust Center access requests](/docs/trust-center/access-requests) | A customer, prospect, partner or auditor asks to see a restricted document | **Compliance › Trust Center › Access requests** |
| [Privacy requests](/docs/compliance-requests/privacy-requests) | A person asks about their personal data, and your team records it | **Compliance › Privacy requests** |
| [Integration requests](/docs/compliance-requests/integration-requests) | Someone on your team asks Safeguard for a connector it does not list | **Compliance › Connectors › Request integration** |
| [Approvals](/docs/compliance-requests/approvals) | A change that only counts once a person decides it: a policy, evidence, an access review, a test exclusion, a risk acceptance, a crosswalk mapping | Where the item lives, by a compliance reviewer |
Assistants are bound by the same rules. Safeguard's AI assistant and MCP clients can prepare work, but they never approve, accept or sign off: those decisions are made by a person in the app. See [Approvals](/docs/compliance-requests/approvals#assistants-and-mcp-clients).
# Integration requests (/docs/compliance-requests/integration-requests)
# Integration requests
If a system you use is not on **Compliance › Connectors**, ask Safeguard to add it. Search the list first: [Connectors](/docs/connectors) shows every connector Safeguard has today.
## Send a request
1. Open **Compliance › Connectors** and choose **Request integration**, or the **Request an integration** link under the page title.
2. Fill in **Request an integration**:
| Field | What to enter |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Integration name** | The system's name. Required. |
| **Website (optional)** | Its address, so the team finds the right product. |
| **Category** | The closest category, such as Identity & SSO or Cloud Infrastructure. |
| **What would you use it for? (optional)** | What evidence or data Safeguard should collect from it, for example "MFA status of every user" or "who has admin access". |
3. Choose **Submit request**.
The request is saved to your workspace with the status **requested**, under your name and the time you sent it, and the Safeguard team reviews it and follows up with you.
## Until it exists
You can still cover the system's controls:
* Connect it as an MCP server with **Add custom MCP**, if the vendor publishes one, so Griffin AI can search it.
* Upload evidence for its controls by hand on **Compliance › Evidence**.
## Related
* [Compliance connectors](/docs/compliance-connectors)
* [Requests and approvals](/docs/compliance-requests)
# Privacy requests (/docs/compliance-requests/privacy-requests)
# Privacy requests
People can ask you about their personal data: to see it, delete it, correct it, move it, object to its use or restrict it. **Compliance › Privacy requests** is the register where your team records each request and what you did about it, with its deadline.
## Intake and verification
Safeguard does not take requests from data subjects directly. They reach you through your own channels, for example the **Privacy contact email** on your [Trust Center](/docs/trust-center), which the page shows for data subject requests and GDPR inquiries. Confirm the person's identity in your own process before you act. Then record the request in Safeguard.
Record a reference for the person, such as a ticket or case id, never their email address. The register is evidence an auditor reads, so it holds the request and its outcome, not the person's data.
## Record a request
On **Compliance › Privacy requests**, choose **Record a request** and fill in:
| Field | What to enter |
| --------------------- | ----------------------------------------------------------------------------------------------- |
| **Request type** | **Access**, **Deletion**, **Rectification**, **Portability**, **Objection** or **Restriction**. |
| **Status** | **Received**, **In progress**, **Completed**, **Refused** or **Withdrawn**. |
| **Received on** | The date the request arrived. Required. |
| **Subject reference** | A ticket or case id, never the person's email address. |
| **Received through** | The channel it came in by. |
| **Notes** | Anything your team needs. |
## Deadlines
A request is due 30 days after it was received. You can extend the deadline to at most 92 days after receipt with an **Extended due date (optional)**, which counts only with **Why the deadline was extended** filled in.
The **Deadline** column shows where each request stands:
| Deadline | Meaning |
| ------------------------- | -------------------------------------------- |
| **Open** | Not finished, and still inside its deadline. |
| **Overdue** | Not finished, and past its deadline. |
| **On time** | Completed by its deadline. |
| **Late** | Completed after its deadline. |
| **Refused with a reason** | Refused, with the reason recorded. |
| **Withdrawn** | The person withdrew it. |
The page counts **Open requests**, **Overdue** and **Deletion requests** at the top.
## Complete, refuse or withdraw
Open the request and set its status, with the date in **Completed, refused or withdrawn on**:
* **Completed**: you did what was asked.
* **Refused**: also fill in **Why it was refused**. The reason is what an auditor reads.
* **Withdrawn**: the person withdrew it.
Safeguard checks the record as you save: a completion date needs a finished status and the reverse, nothing can be completed before it was received, no date can be in the future, and the subject reference must not be an email address.
Each request keeps its history. A compliance reviewer records and edits requests; an auditor can read them.
## The evidence it produces
Where it is switched on for your workspace, the automated test **Deletion requests are completed within 30 days** reads this register every day. For each deletion request received in the last year, or still open, it passes when the request was completed, or refused with a recorded reason, within 30 days of receipt or by a recorded, reasoned extension of at most 92 days. An open request past its deadline fails; one still inside it, or withdrawn, is not applicable. Results show the request's id, dates and outcome, never the subject reference.
The test is evidence toward SOC2 C1.2 and CC6.5, ISO/IEC 27001:2022 Annex A 8.10 and 5.34, and NIST CSF 2.0 GV.OC-03. To fix a failure, complete the deletion or refuse it with the legal reason, and record the outcome and its date on the request.
## Related
* [Requests and approvals](/docs/compliance-requests)
* [Trust Center setup](/docs/trust-center)
# Cloudflare (/docs/compliance-connectors/cloudflare)
# Connect Cloudflare
Safeguard reads your Cloudflare zones and account with read-only access: SSL/TLS mode and minimum TLS version, Always Use HTTPS, HSTS, DNSSEC, the managed WAF rules, whether API tokens expire, and whether the account's logs are exported.
Use the **API token** method for the compliance checks. Cloudflare's OAuth sign-in connects Cloudflare's MCP server, and the token it issues works only with that server, not with the Cloudflare API the checks read. An OAuth connection still works for Search. If your card was connected with OAuth, the checks report an error asking you to reconnect with an API token.
## 1. Create the API token in Cloudflare
1. In the Cloudflare dashboard, open **My Profile › API Tokens** (or create an account-owned token) and choose **Create Token › Create Custom Token**.
2. Add these permissions, all **Read**:
| Type | Permission |
| ------- | ------------------ |
| Account | Account Settings |
| Account | Account API Tokens |
| Zone | Zone |
| Zone | Zone Settings |
| Zone | DNS |
| Zone | Zone WAF |
3. Under **Zone Resources**, include the zones you want checked, for example **All zones** or specific zones.
4. Create the token and copy it. Cloudflare shows it once.
Optional: the audit-log export check lists your Logpush jobs, which Cloudflare documents only under the **Logs** permission with write (**Edit**) access. That is broader than read-only. Without it, that one check reports an error naming the permission, and every other check still runs.
## 2. Connect it in Safeguard
1. Open **Compliance › Connectors**, search for **Cloudflare** and click **Connect**.
2. Choose **API token**:
| Field | What to enter |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| API token | The token |
| Account ID (optional) | Your Cloudflare account ID, to limit the checks to that account's zones. It is on the right of any zone's overview page. |
3. Click **Connect with token**. The card shows **Verified** once Cloudflare accepts the token.
## Several accounts
Cloudflare can be connected more than once, one connection per account. When multiple accounts are switched on for your workspace, open the connected card and choose **Add another account**.
## What Safeguard checks
* SSL/TLS encryption mode is Full (strict)
* Minimum TLS version
* Always Use HTTPS and HSTS
* DNSSEC
* The managed WAF ruleset is deployed and blocking
* API tokens have an expiry
* Account audit logs are exported
If you use Cloudflare Access, connect the **Cloudflare Access** card too; it checks that your Access applications require MFA.
## Troubleshooting
* **Not working, mentioning the MCP server**: the card was connected with OAuth. Use **Reconnect** and enter an API token.
* **Not working, naming a permission**: add that Read permission to the token in Cloudflare, then use **Re-check**.
# GitLab (/docs/compliance-connectors/gitlab)
# Connect GitLab
Safeguard reads your GitLab groups and projects with read-only access: two-factor and SSO enforcement, members and administrators, branch protection, merge request approvals, pipelines, and security scanning settings.
There are three cards:
* **GitLab**: gitlab.com, or a self-managed instance if you fill in its Base URL.
* **GitLab Self-Managed**: your own GitLab instance.
* **GitLab Issues**: GitLab used as a ticket tracker.
## What the credential can see
Safeguard reads every top-level group the credential's user is a member of. A user in no group is judged on the projects they own. Some reads need more than membership:
| Setting | Needs |
| --------------------------------------------------------------------------- | ------------------------------------------------------------------- |
| Groups, projects, members, two-factor requirement, "pipelines must succeed" | The `read_api` scope and any membership |
| Protected branches | Developer role on the project (Maintainer on older GitLab versions) |
| Pipelines and their jobs on private projects | Reporter role on the project |
| Merge request approval rules | GitLab Premium |
| Secret push protection | GitLab Ultimate |
On a plan without a feature, the setting does not exist, and the check says so instead of failing.
## Option A: personal access token (recommended)
1. In GitLab, open your avatar menu › **Edit profile › Access tokens** and add a new token.
2. Select only the **`read_api`** scope, and set an expiry that fits your policy.
3. Create it as a user who is a member of the groups you want checked, with the roles above.
4. In Safeguard, open **Compliance › Connectors**, search for **GitLab** and click **Connect**. Choose **API token**:
| Field | What to enter |
| ---------------------- | -------------------------------------------------------------------------------- |
| Base URL (self-hosted) | Leave empty for gitlab.com. For a self-managed instance, its `https://` address. |
| API token / PAT | The token |
A self-managed instance must be reachable at a public `https://` address. Safeguard refuses private and reserved addresses.
## Option B: OAuth (gitlab.com only)
Choose **OAuth** on the GitLab card and approve the sign-in. GitLab's OAuth sign-in asks for the `api` and `read_user` scopes; `api` also permits writes, though Safeguard only reads. For a strictly read-only connection, use a token with `read_api`.
OAuth signs in to gitlab.com only. Connect a self-managed instance with a token.
## Several self-managed instances
**GitLab Self-Managed** can be connected more than once, one connection per instance. When multiple accounts are switched on for your workspace, open the connected card and choose **Add another account**. A second group on gitlab.com is not a separate account: one gitlab.com connection already covers every group its user belongs to.
## What Safeguard checks
* Two-factor authentication required for the group, and SSO enforced
* Administrators and how many there are, outside collaborators, and whether admins are exempt from rules
* Default branch protection: no direct pushes and no force pushes
* Merge request approvals required, no self-approval, stale approvals dismissed, code owner review
* Required pipeline checks, and merged changes that were reviewed
* Secret detection and push protection, dependency scanning alerts and their age, code scanning, and fork restrictions
## Troubleshooting
* **Not working, naming a scope or role**: give the token `read_api`, or give its user the role the message names on that project.
* **A group is missing**: the token's user is not a member of that group.
# Google Cloud (/docs/compliance-connectors/google-cloud)
# Connect Google Cloud
Safeguard reads your Google Cloud projects with read-only access: IAM, Cloud Storage buckets, logging, keys, networking and the other services the checks cover. One connection reads every project the credential can see; a project that cannot be read shows one error naming that project, and the others still run.
The **Google Cloud Platform** and **Google Cloud Storage** cards read the same Google Cloud API, so one connection covers both.
## Choose a sign-in
* **OAuth**: you sign in with Google and approve `cloud-platform.read-only`. Safeguard reads what your Google account can see.
* **Service account key**: you create a service account, grant it read-only roles, and paste its JSON key. Best for a stable connection that does not depend on one person's account.
## Option A: OAuth
1. Open **Compliance › Connectors**, search for **Google Cloud Platform** and click **Connect**.
2. Choose **OAuth**, sign in with Google and approve the read-only scope.
If the card later shows **Not working** because the token expired, use **Re-authorize**.
## Option B: Service account
1. In the Google Cloud console, create a service account and a **JSON key** for it.
2. Grant it these roles on each project, or once on the folder or organization above them:
`roles/viewer`, `roles/iam.securityReviewer`, `roles/logging.viewer`, `roles/cloudkms.viewer`, `roles/serviceusage.serviceUsageViewer`, `roles/orgpolicy.policyViewer`, `roles/serviceusage.apiKeysViewer`, `roles/essentialcontacts.viewer`, `roles/monitoring.viewer`, `roles/dns.reader`, `roles/bigquery.metadataViewer`, `roles/container.clusterViewer`, `roles/accessapproval.viewer`, `roles/policyanalyzer.activityAnalysisViewer`
`roles/viewer` alone lets the connection verify and list resources. The IAM policy reads, such as whether a bucket is public, need `roles/iam.securityReviewer`; the rest each add the reads of one service.
3. For the organization-level checks, also grant on the organization: `roles/resourcemanager.organizationViewer`, `roles/iam.securityReviewer` and `roles/browser`.
4. In Safeguard, open **Compliance › Connectors › Google Cloud Platform › Connect**, choose **API token** and paste the whole key into **Service account key (JSON)**.
## Several organizations
Google Cloud can be connected more than once, one connection per account. When multiple accounts are switched on for your workspace, open the connected card and choose **Add another account**. See [Several accounts of one provider](/docs/compliance-connectors#several-accounts-of-one-provider).
## What Safeguard checks
Cloud Storage, including public buckets and locked log buckets, plus IAM, logging, keys, networking and the other services the roles above read. Every check only reads. A read that Google refuses is reported as an error naming the missing permission or role, not as a failed control.
## Troubleshooting
* **Not working, naming a permission or role**: grant the role it names on the project, folder or organization, then use **Re-check**.
* **A project is missing**: the credential cannot see it. Grant the roles on that project, or on a folder or organization above it.
# Google Workspace (/docs/compliance-connectors/google-workspace)
# Connect Google Workspace
Safeguard reads your Google Workspace directory and policies with read-only access: users and admins, 2-Step Verification and password policies, session length, third-party app access, external Drive sharing, and the SPF, DKIM and DMARC records of your domains.
There are two cards:
* **Google Workspace**: users, admins, policies and email authentication. The Drive sharing policy is checked here too.
* **Google Drive**: a separate connection that collects Drive evidence, with the `drive.readonly` grant. It can also connect Google's Drive MCP server for Search.
## Choose a sign-in
| | OAuth | Service account with domain-wide delegation |
| ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------- |
| Who sets it up | A Google Workspace administrator signs in and approves | A Google Cloud project owner and a Workspace super admin |
| Scopes | `admin.directory.user.readonly`, `admin.directory.domain.readonly`, `admin.directory.device.mobile.readonly` | The scopes you delegate (below) |
| Policy checks (password, 2-Step Verification, session length, third-party apps, Drive sharing) | Not covered: OAuth does not request the Cloud Identity policy scope | Covered with `cloud-identity.policies.readonly` |
Use the service account if you want every check. OAuth is quicker and covers users, admins, inactive and departed accounts, and email authentication.
## Option A: OAuth
1. In Safeguard, open **Compliance › Connectors**, search for **Google Workspace** and click **Connect**.
2. Choose **OAuth** and sign in with a Google Workspace administrator account. The directory is visible only to administrators.
3. Approve the read-only scopes. The card shows **Verified** once Google confirms the grant.
## Option B: Service account with domain-wide delegation
1. In the Google Cloud console, create a service account in a project you control and create a **JSON key** for it.
2. In the Google Admin console, open **Security › API controls › Domain-wide delegation** and add the service account's client ID with these read-only scopes:
* `https://www.googleapis.com/auth/admin.directory.user.readonly`
* `https://www.googleapis.com/auth/admin.directory.domain.readonly`
* `https://www.googleapis.com/auth/admin.directory.user.security` (for the check on departed users who still hold OAuth tokens)
* `https://www.googleapis.com/auth/cloud-identity.policies.readonly` (for the policy checks)
* `https://www.googleapis.com/auth/admin.directory.device.mobile.readonly` (for mobile device checks)
Google's guide: [Control API access with domain-wide delegation](https://support.google.com/a/answer/162106).
3. In Safeguard, open **Compliance › Connectors › Google Workspace › Connect** and choose **API token**:
| Field | What to enter |
| ----------------------------- | --------------------------------------------------------------------------------------------------------- |
| Service account key (JSON) | The full JSON key file |
| Admin email to impersonate | An administrator's address, for example `admin@your-domain.com`. The service account reads as this admin. |
| OAuth access token (optional) | Leave empty. It is an alternative for a short-lived token with Admin SDK Directory scopes. |
A scope you did not delegate affects only the checks that need it: those show an error naming the scope to add under **Domain-wide delegation**, and the rest still run.
## Google Drive
Connect the **Google Drive** card with OAuth (scope `drive.readonly`) or the same service account form. The external sharing check itself comes from the Google Workspace connection's policy read, so connect Google Workspace with the service account if you need it.
## What Safeguard checks
* 2-Step Verification enforced, and weak second factors disabled
* Administrators: how many, and whether they use phishing-resistant MFA
* Password policy and session length
* Inactive users, and departed users who are still active or still hold OAuth tokens
* Third-party app access restrictions
* External Drive sharing
* SPF, DKIM and DMARC on your domains, read from public DNS
Policies are judged for every organizational unit and group they target, so a weaker setting on a sub-unit is not hidden by a strong top-level one.
## Troubleshooting
* **Not working, naming a scope**: delegate that scope under **Domain-wide delegation**, or switch from OAuth to the service account for policy checks.
* **Not working with a service account**: check that the admin email is an administrator in the same Workspace, and that the JSON key belongs to the service account you delegated.
# Compliance connectors (/docs/compliance-connectors)
# Compliance connectors
A compliance connector links Safeguard to a system you run, such as your identity provider, cloud account, code host or ticket tracker. Safeguard reads from it with read-only access and turns what it reads into evidence for your controls.
## Where to connect
Open **Compliance › Connectors**. Search for the system, or filter by category, by **Automated evidence** or **Connection record only**, and by **Connected** or **Not connected**. Click **Connect** on a card to open its connect form.
Admins decide which connectors members of the organization can use, under **Settings › Connector access** or with **Manage connectors** on the Connectors page. A connector that is switched off there does not appear for members, and the server refuses to connect it.
Can't find a system? Use **Request integration** on the Connectors page.
## Three ways to connect
The connect form offers up to three methods. Which ones appear depends on the connector.
| Method | How it works | Use it for |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------- |
| **OAuth** | You approve read access on the vendor's own consent screen. There is no secret to copy, and you can revoke access at the vendor at any time. Offered where Safeguard has an OAuth app for that vendor. | Evidence collection and automated compliance tests, unless the connect form says the tests need the API token method |
| **API token** | You paste an API token or key, plus any account details the form asks for. The form lists the read-only grant to create at the vendor and links to the vendor's documentation. Always available. | Evidence collection and automated compliance tests |
| **MCP server** | You connect the vendor's Model Context Protocol server by URL. This is the method Search (Griffin AI) uses, because Search works by calling a connector's tools. | Asking Griffin AI about the system |
Some vendors' OAuth sign-in connects their MCP server rather than their API. Those connections serve Search but cannot feed the compliance tests; the guide for such a connector tells you to use the API token method instead.
## What happens to your credential
* Credentials are encrypted at rest with authenticated encryption. Safeguard never shows a saved secret again: the card only says that a credential is stored.
* Every guide asks for the narrowest read-only grant the vendor offers. A few vendors have no read-only option; their guide and connect form say so. Safeguard only makes read calls with the credential either way.
* A self-hosted server (for example your own GitLab, SigNoz, StackRox or Logto) must be reachable at a public `https://` address. Safeguard refuses private, loopback and cloud-metadata addresses before it sends anything.
* If a vendor restricts API access by IP address, allow Safeguard's outbound address. Ask Safeguard support for it.
## Card statuses
After you connect, Safeguard checks the credential with the vendor and shows the result on the card.
| Status | Meaning | What to do |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |
| **Verified** | The provider confirmed this credential. | Nothing. |
| **Not working** | The provider rejected this credential, or a setting is wrong. The card shows the reason, for example a missing grant or a wrong region. | Reconnect, or fix the setting the reason names. |
| **Unverified** | The credential is stored but not confirmed yet: the provider did not answer the last check. | Use **Re-check** to try again. |
Admins can **Re-check** one connection, or **Re-check all**. **Collect evidence now** on the Connectors page starts a collection immediately instead of waiting for the next scheduled run.
## Managing a connection
Open a connected card to manage it:
* **Test connection** asks the provider whether the stored credential still works.
* **Reconnect** lets you enter the credential again, for example after you rotate a key or change a setting such as the region.
* **Re-authorize** runs the sign-in again, for an expired token or a rotated key.
* **Rename** changes the label that tells one account apart from another account of the same provider.
* **Disconnect** clears the credential. The connection's tests stop and its earlier results stay as history.
* **Remove** deletes the connector entirely.
### Several accounts of one provider
Some providers can be connected more than once, one connection per account: **OVHcloud**, **AWS** (including GovCloud), **Google Cloud** (including Cloud Storage), **Microsoft Azure** (including Azure Government), **Cloudflare**, **GitLab Self-Managed** and **Jira**. When multiple accounts are switched on for your workspace, a connected card offers **Add another account**: give the account a label (for example "OVHcloud US" and "OVHcloud EU") and enter that account's credentials. Each account gets its own card, every test runs against each account, and each result names the account it came from.
## Automated tests
Most connectors feed **automated compliance tests**, which check a setting in the connected system against a control and record the evidence. Tests for a provider are switched on per workspace by the Safeguard team, so a new connection may show **Verified** before its tests run.
A newly added test starts in a **preview** period, typically 14 days. During preview its results show on the **Tests** page, but they do not change any control's status or your readiness score, and they open no tasks. After the preview the test counts like any other.
Tests run on a schedule, about every six hours, and each test runs as often as it is due (daily by default). To run them sooner, use **Run now** or **Run all tests** on **Compliance › Tests**.
## Setup guides
Every other connector has setup steps on its category's page under **Setup by category**, for example [Identity & SSO](/docs/compliance-connectors/setup/identity-and-sso) or [Version Control](/docs/compliance-connectors/setup/version-control): the methods that work for it, the OAuth scopes Safeguard asks for, the credential and permissions to create at the vendor, and what to enter in the connect form. The [setup reference](/docs/compliance-connectors/reference) lists every connector in one table, and the [Connectors](/docs/connectors) page lists every connector by category with the evidence it produces.
# Infisical (/docs/compliance-connectors/infisical)
# Connect Infisical
Safeguard reads your Infisical organization with a machine identity: who holds an organization seat, the Universal Auth token settings of your machine identities, whether secret rotation is set up, and the organization audit log. Safeguard never reads a secret value.
## 1. Create a machine identity in Infisical
1. In your organization, open **Access Control › Identities** and create an identity, for example "Safeguard compliance".
2. Give it an organization role that can read members, identities and audit logs and has no access to any project's secrets. A custom organization role is best. The built-in **Member** role with no project membership also works, but then there are no rotations to read.
3. Open the identity, choose **Universal Auth** and create a **client secret**. Copy the **Client ID** and **Client Secret**.
4. Copy your **Organization ID** from the organization settings.
### Optional: secret rotation
To judge secret rotation, add the identity to each project with a custom project role that allows only **Secret Rotation: Read**. That role gives no access to secret values.
### Plan requirement
The audit log is available on Infisical's **Pro** plan. On other plans, the audit-log check reports that the plan does not include audit logs; the other checks still run.
## 2. Connect it in Safeguard
1. Open **Compliance › Connectors**, search for **Infisical** and click **Connect**.
2. Choose **API token**:
| Field | What to enter |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Client ID | The identity's Universal Auth client ID |
| Client secret | The client secret |
| Organization ID | Your organization's ID |
| Instance URL (optional) | Leave blank for `https://app.infisical.com`. Infisical EU: `https://eu.infisical.com`. Self-hosted: your own address. |
3. Click **Connect with token**.
## What Safeguard checks
* Organization members are linked to people in your personnel register, people who left no longer have a seat, and how many admins there are
* Members sign in with MFA or SSO. Infisical's API does not report MFA enrollment for most members, so the check names the members it could not confirm and asks you to attest for them.
* Machine identities' access tokens are short-lived
* Secret rotation is enabled
* Audit logs are available
## Troubleshooting
* **The audit-log check names the Pro plan**: expected on plans without audit logs. Upgrade, or attest audit logging another way.
* **Rotation checks have nothing to evaluate**: add the identity to your projects with the Secret Rotation: Read role.
# Jira (/docs/compliance-connectors/jira)
# Connect Jira
Safeguard reads Jira Cloud as a ticket tracker, with read access: security, incident, offboarding and post-mortem tickets, their priority, assignee, status and resolution dates, the issues linked to incidents, and the site's user accounts for access reviews.
Jira Cloud only. Jira Data Center and Jira Server are not supported.
## Option A: OAuth
1. Open **Compliance › Connectors**, search for **Jira** and click **Connect**.
2. Choose **OAuth** and approve Atlassian's consent screen. Safeguard asks for `read:jira-work` and `offline_access`.
An OAuth connection reads up to three Jira sites that your Atlassian account can reach. Everything is read as your account, so it sees what you can see.
## Option B: API token
1. Sign in to [id.atlassian.com](https://id.atlassian.com) with the account Safeguard should read as, and open **Security › API tokens** to create a token. The token has that account's Jira permissions, so use an account that can browse the projects holding security and incident tickets.
2. In Safeguard, open **Compliance › Connectors › Jira › Connect** and choose **API token**:
| Field | What to enter |
| ----------------------- | -------------------------------------------------------- |
| Atlassian account email | The account the token was created on |
| API token | The token |
| Site URL | Your site, for example `https://your-team.atlassian.net` |
## Several sites
Jira can be connected more than once, one connection per site. When multiple accounts are switched on for your workspace, open the connected card and choose **Add another account**.
## What Safeguard checks
Safeguard finds tickets by label or issue type (security, incident, offboarding, post-mortem) that are open or were resolved recently, then checks:
* Security issues are assigned, and the highest-priority ones are resolved within their time limit
* Incidents have their follow-up work closed, and a post-mortem
* Every departure has an offboarding ticket
* Jira accounts belong to people in your personnel register, and people who left no longer have access (bots and service-desk customers are left out)
A ticket counts as resolved at its resolution date, or, in a workflow that sets no resolution, when it moved to a Done status.
## Troubleshooting
* **Not working with an API token**: check the email matches the account that created the token, and that the site URL is your `atlassian.net` address.
* **Tickets are missing**: the connecting account cannot browse that project. Grant it browse access, or connect with an account that has it.
# Logto (/docs/compliance-connectors/logto)
# Connect Logto
Logto signs in your own product's users. Safeguard reads its sign-in experience through the Logto Management API: whether MFA is required, which sign-in factors are allowed, the password policy, and who holds access to the Management API.
This is customer-access evidence. Logto is not treated as your workforce identity provider, so the employee access-review checks (accounts linked to people, leavers) do not run for it.
Logto has no read-only scope for its Management API: the only permission it offers is `all`. Safeguard only makes read calls with the credential, and you can revoke it in Logto at any time.
## 1. Create a machine-to-machine app in Logto
1. In the Logto Console, open **Applications › Create application** and choose **Machine-to-machine**. Name it, for example "Safeguard compliance".
2. Assign it a role that holds the **Logto Management API** resource's `all` permission.
3. Copy the app's **App ID** and **App secret**, and your Logto endpoint.
## 2. Connect it in Safeguard
1. Open **Compliance › Connectors**, search for **Logto** and click **Connect**.
2. Choose **API token**:
| Field | What to enter |
| -------------------- | ---------------------------------------------------------------------------------- |
| Instance URL | Logto Cloud: `https://.logto.app`. Self-hosted: your own Logto address. |
| Client ID | The App ID |
| Client secret | The App secret |
| Tenant ID (optional) | Your tenant ID, needed only when Logto Cloud is behind a custom domain |
3. Click **Connect with token**.
A self-hosted Logto must be reachable at a public `https://` address on the standard port.
## What Safeguard checks
* MFA is required at sign-in
* Weak sign-in factors are disabled
* The password policy meets your minimums, including lockout after repeated failures
* How many accounts can use the Management API
## Troubleshooting
* **Not working on Logto Cloud with a custom domain**: fill in **Tenant ID**.
* **Not working, naming the Management API**: check the app's role holds the Logto Management API `all` permission.
# OVHcloud (/docs/compliance-connectors/ovhcloud)
# Connect OVHcloud
Safeguard reads your OVHcloud account with GET calls only: the account's sign-in IP restriction and audit-log forwarding, the account's users and their MFA, Public Cloud instance backups and Object Storage, and the Edge Network Firewall on your IP blocks.
## Pick the right region first
An OVHcloud application key exists on one OVHcloud API only. Create the keys on the API that holds your account, and choose the matching **Region** in Safeguard:
| Region | Create the keys at |
| ------ | ------------------------------------------ |
| `eu` | `https://eu.api.ovh.com/createToken/` |
| `ca` | `https://ca.api.ovh.com/createToken/` |
| `us` | `https://api.us.ovhcloud.com/createToken/` |
Keys made at ovh.com outside Europe and Canada usually belong to `ca`. If you choose the wrong region, the connection reports which region the keys belong to, for example: "These OVHcloud keys were created on the ca API, but this connection's Region is us. Reconnect and choose Region ca."
## 1. Create the keys in OVHcloud
1. Open the createToken page for your region and sign in to your OVHcloud account.
2. Fill in an application name and description, for example "Safeguard compliance" and "Read-only access for compliance evidence".
3. Set **Validity**. Unlimited keeps the connection working; a shorter validity means you reconnect when it expires.
4. Add these **Rights**, all with method **GET**:
* `/me`
* `/me/*`
* `/cloud/project`
* `/cloud/project/*`
* `/ip`
* `/ip/*`
5. Create the keys and copy the **Application key**, **Application secret** and **Consumer key**.
### Optional: S3 keys for bucket access checks
OVHcloud's API does not report S3 bucket ACLs or bucket policies. To check them, create a Public Cloud S3 user with a read-only policy that allows `s3:GetBucketAcl` and `s3:GetBucketPolicy`, and add its access key and secret key below. Without them, each S3 bucket's public-access result is an error naming this optional grant, never a pass.
## 2. Connect it in Safeguard
1. Open **Compliance › Connectors**, search for **OVHcloud** and click **Connect**.
2. Choose **API token**:
| Field | What to enter |
| --------------------- | ---------------------------------------------------------- |
| Application key | From step 1 |
| Application secret | From step 1 |
| Consumer key | From step 1 |
| Region | `eu`, `ca` or `us`, matching the createToken page you used |
| Access key (optional) | The S3 user's access key |
| Secret key (optional) | The S3 user's secret key |
3. Click **Connect with token**. The card shows **Verified** and the account's identifier once OVHcloud accepts the keys.
## Accounts in more than one region
If you run OVHcloud accounts in more than one region, for example the US and Europe, connect each one. When multiple accounts are switched on for your workspace, open the first account's card and choose **Add another account**. Give it a label such as "OVHcloud EU", choose its region and paste that account's keys. Each account gets its own card, and every check runs against both.
## What Safeguard checks
* The account's sign-in is restricted by IP address
* The account audit log is forwarded to a Logs Data Platform stream
* The account's users, and whether they use MFA
* Public Cloud instances have backups
* Object Storage containers are not public, are encrypted and have versioning
* The Edge Network Firewall does not leave admin or database ports open to the internet
Public Cloud security groups are not in OVHcloud's API, so they are covered by attestation instead.
## Troubleshooting
* **"These OVHcloud keys were created on the … API"**: the region does not match where the keys were created. Use **Reconnect** and choose the region the message names.
* **"OVHcloud does not recognise this application key"**: no region knows the keys. Create them again on the createToken page for your account's region.
* **"This call has not been granted"**: a GET right is missing. Create new keys with all six rights.
* **Not working after the keys expire**: create new keys and use **Reconnect**.
# Connector setup reference (/docs/compliance-connectors/reference)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Every one of the 672 connectors, as the connect form on **Compliance › Connectors** shows it. **Connect with** lists the methods the card is built for: OAuth appears only where Safeguard has an OAuth app for that vendor, and the API token method is always there. **The form asks for** is what the API token method asks for. **Grant at the vendor** is the vendor's own name for the read-only scope, role or permission to create, shown as the vendor writes it; where a vendor has no read-only option, the note says so. Each connector's name links to its own page, with the steps to connect it.
See [Compliance connectors](/docs/compliance-connectors) for how connecting works, card statuses and multiple accounts.
## Identity & SSO
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ----------------------------------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| [**1Password**](/docs/compliance-connectors/setup/identity-and-sso/1password) | API token | SCIM bridge URL, SCIM bridge bearer token | — | — |
| [**Auth0**](/docs/compliance-connectors/setup/identity-and-sso/auth0) | API token | Auth0 domain, M2M client ID, M2M client secret, Management API token (optional) | — | — |
| [**Auth0 SSO**](/docs/compliance-connectors/setup/identity-and-sso/auth0-sso) | API token | Auth0 domain, M2M client ID, M2M client secret, Management API token (optional) | — | — |
| [**Authentik**](/docs/compliance-connectors/setup/identity-and-sso/authentik) | API token | Instance URL, API token | `view: users, authenticator devices, validation stages` | [Docs](https://docs.goauthentik.io/docs/users-sources/user/) |
| [**Beyond Identity**](/docs/compliance-connectors/setup/identity-and-sso/beyond-identity) | API token | Tenant ID, Realm ID, Access token, Region | `identities:read` | [Docs](https://developer.beyondidentity.com/api/v1) |
| [**Clerk**](/docs/compliance-connectors/setup/identity-and-sso/clerk) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Cloudflare Access**](/docs/compliance-connectors/setup/identity-and-sso/cloudflare-access) | API token | API token, Account ID | `Access: Audit Logs Read`, `Access: Apps and Policies Read` | [Docs](https://developers.cloudflare.com/cloudflare-one/identity/users/seat-management/) |
| [**CyberArk**](/docs/compliance-connectors/setup/identity-and-sso/cyberark) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**CyberArk SSO**](/docs/compliance-connectors/setup/identity-and-sso/cyberark-sso) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Descope**](/docs/compliance-connectors/setup/identity-and-sso/descope) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Duo Security**](/docs/compliance-connectors/setup/identity-and-sso/duo-security) | API token | Integration key, Secret key, Host | `Grant resource - Read`, `Grant administrators - Read` | [Docs](https://duo.com/docs/administration-users) |
| [**Duo SSO**](/docs/compliance-connectors/setup/identity-and-sso/duo-sso) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Entrust**](/docs/compliance-connectors/setup/identity-and-sso/entrust) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**ForgeRock**](/docs/compliance-connectors/setup/identity-and-sso/forgerock) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Frontegg**](/docs/compliance-connectors/setup/identity-and-sso/frontegg) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**FusionAuth**](/docs/compliance-connectors/setup/identity-and-sso/fusionauth) | API token | Instance URL, API key, Tenant ID (optional), Application ID (optional) | `GET /api/user/search`, `GET /api/tenant` | [Docs](https://fusionauth.io/docs/) |
| [**Google Cloud Identity**](/docs/compliance-connectors/setup/identity-and-sso/google-cloud-identity) | OAuth, API token | Service account key (JSON), Admin email to impersonate, OAuth access token (optional) | — | — |
| [**Google SSO**](/docs/compliance-connectors/setup/identity-and-sso/google-sso) | OAuth, API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Google Workspace**](/docs/compliance-connectors/setup/identity-and-sso/google-workspace) | OAuth, API token | Service account key (JSON), Admin email to impersonate, OAuth access token (optional) | — | — |
| [**HYPR**](/docs/compliance-connectors/setup/identity-and-sso/hypr) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**IBM Verify**](/docs/compliance-connectors/setup/identity-and-sso/ibm-verify) | API token | Instance URL, Client ID, Client secret; or, instead: Access token (optional) | `readUsers`, `readUserGroups` | [Docs](https://docs.verify.ibm.com/verify/reference/getusers) |
| [**Idaptive**](/docs/compliance-connectors/setup/identity-and-sso/idaptive) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**JumpCloud**](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**JumpCloud MDM**](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud-mdm) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**JumpCloud SSO**](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud-sso) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Keycloak**](/docs/compliance-connectors/setup/identity-and-sso/keycloak) | API token | Keycloak base URL, Realm, Service account client ID, Client secret, Admin bearer token (optional) | — | — |
| [**LastPass SSO**](/docs/compliance-connectors/setup/identity-and-sso/lastpass-sso) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**LoginRadius**](/docs/compliance-connectors/setup/identity-and-sso/loginradius) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Logto**](/docs/compliance-connectors/setup/identity-and-sso/logto) | API token | Instance URL, Client ID, Client secret, Tenant ID (optional) | `Logto Management API: all (M2M role)`
Logto issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://docs.logto.io/integrate-logto/interact-with-management-api) |
| [**Microsoft Entra ID**](/docs/compliance-connectors/setup/identity-and-sso/microsoft-entra-id) | OAuth, API token | Directory (tenant) ID, Application (client) ID, Client secret, Graph access token (optional) | — | — |
| [**Microsoft Entra SSO**](/docs/compliance-connectors/setup/identity-and-sso/microsoft-entra-sso) | OAuth, API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**miniOrange**](/docs/compliance-connectors/setup/identity-and-sso/miniorange) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Okta**](/docs/compliance-connectors/setup/identity-and-sso/okta) | API token | Okta org URL, API token | — | — |
| [**Okta SSO**](/docs/compliance-connectors/setup/identity-and-sso/okta-sso) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**OneLogin**](/docs/compliance-connectors/setup/identity-and-sso/onelogin) | API token | Client ID, Client secret, Subdomain | `Read All`
Optional, broader than read-only: Manage users. Without it, the checks that need it show an error naming it. Safeguard only reads with it. | [Docs](https://developers.onelogin.com/api-docs/2/multi-factor-authentication/enrolled-factors) |
| [**OneLogin SSO**](/docs/compliance-connectors/setup/identity-and-sso/onelogin-sso) | API token | Client ID, Client secret, Subdomain | `Read All`
Optional, broader than read-only: Manage users. Without it, the checks that need it show an error naming it. Safeguard only reads with it. | [Docs](https://developers.onelogin.com/api-docs/2/multi-factor-authentication/enrolled-factors) |
| [**Oracle Identity**](/docs/compliance-connectors/setup/identity-and-sso/oracle-identity) | API token | Instance URL, Client ID, Client secret | `read users (confidential application)` | [Docs](https://docs.oracle.com/en/cloud/paas/iam-domains-rest-api/op-admin-v1-users-get.html) |
| [**Ping Identity**](/docs/compliance-connectors/setup/identity-and-sso/ping-identity) | API token | Environment ID, Region, Worker app client ID, Worker app client secret | — | — |
| [**Ping SSO**](/docs/compliance-connectors/setup/identity-and-sso/ping-sso) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**PingOne**](/docs/compliance-connectors/setup/identity-and-sso/pingone) | API token | Environment ID, Region, Worker app client ID, Worker app client secret | — | — |
| [**RingCentral**](/docs/compliance-connectors/setup/identity-and-sso/ringcentral) | API token | Access token, Environment (optional) | `ReadAccounts` | [Docs](https://developers.ringcentral.com/api-reference/Extensions/listExtensions) |
| [**Rippling Identity**](/docs/compliance-connectors/setup/identity-and-sso/rippling-identity) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**RSA SecurID**](/docs/compliance-connectors/setup/identity-and-sso/rsa-securid) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SailPoint**](/docs/compliance-connectors/setup/identity-and-sso/sailpoint) | API token | Instance URL, Client ID, Client secret | `idn:campaign:read`, `sp:search:read` | [Docs](https://developer.sailpoint.com/docs/api/v3/) |
| [**Saviynt**](/docs/compliance-connectors/setup/identity-and-sso/saviynt) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SecureAuth**](/docs/compliance-connectors/setup/identity-and-sso/secureauth) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Stytch**](/docs/compliance-connectors/setup/identity-and-sso/stytch) | API token, MCP server | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SuperTokens**](/docs/compliance-connectors/setup/identity-and-sso/supertokens) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Teleport**](/docs/compliance-connectors/setup/identity-and-sso/teleport) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Transmit Security**](/docs/compliance-connectors/setup/identity-and-sso/transmit-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**WorkOS**](/docs/compliance-connectors/setup/identity-and-sso/workos) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**WorkOS SSO**](/docs/compliance-connectors/setup/identity-and-sso/workos-sso) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Zitadel**](/docs/compliance-connectors/setup/identity-and-sso/zitadel) | API token | Instance URL, Personal access token, Organization ID (optional) | `ORG_OWNER_VIEWER`, `IAM_OWNER_VIEWER` | [Docs](https://zitadel.com/docs/apis/resources/user_service_v2/user-service-list-users) |
## Cloud Infrastructure
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ------------------------------------------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [**Akamai**](/docs/compliance-connectors/setup/cloud-infrastructure/akamai) | API token | Host, Client token, Client secret, Access token | `IAM User Admin: READ-ONLY`, `Application Security: READ-ONLY`, `CPS: READ-ONLY`, `Contract API: READ-ONLY` | [Docs](https://techdocs.akamai.com/iam/docs/two-factor-authentication) |
| [**Alibaba Cloud**](/docs/compliance-connectors/setup/cloud-infrastructure/alibaba-cloud) | API token | Access key ID, Access key secret, Region (optional), Regions (optional) | `ReadOnlyAccess` | [Docs](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair) |
| [**Amazon Web Services**](/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services) | API token | AWS Access Key ID, AWS Secret Access Key, Region, Session token (optional) | — | — |
| [**Aptible**](/docs/compliance-connectors/setup/cloud-infrastructure/aptible) | API token | SCIM token | `SCIM token`
A SCIM token can also create and change users, and Aptible has no read-only one. Safeguard only reads with it. | [Docs](https://www.aptible.com/docs/core-concepts/security-compliance/access-permissions) |
| [**AWS GovCloud**](/docs/compliance-connectors/setup/cloud-infrastructure/aws-govcloud) | API token | AWS Access Key ID, AWS Secret Access Key, Region, Session token (optional) | — | — |
| [**Azure Government**](/docs/compliance-connectors/setup/cloud-infrastructure/azure-government) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Civo**](/docs/compliance-connectors/setup/cloud-infrastructure/civo) | API token | API key, Regions (optional) | Civo issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://www.civo.com/docs/networking/firewalls) |
| [**Cloudflare**](/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare) | API token | API token, Account ID (optional) | `Account Settings Read`, `Zone Read`, `Zone Settings Read`, `DNS Read`, `Zone WAF Read`, `Account API Tokens Read`
Optional, read-only: Bot Management Read. The connection does not ask for it by default; without it, the checks that need it show an error naming it. | [Docs](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/) |
| [**Cloudflare R2**](/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare-r2) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Crossplane**](/docs/compliance-connectors/setup/cloud-infrastructure/crossplane) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**DigitalOcean**](/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean) | API token | Access token | `*:read` | [Docs](https://docs.digitalocean.com/products/networking/firewalls/) |
| [**DigitalOcean Spaces**](/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean-spaces) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Fastly**](/docs/compliance-connectors/setup/cloud-infrastructure/fastly) | API token | API token | `global:read` | [Docs](https://www.fastly.com/documentation/guides/account-info/user-access-and-control/) |
| [**Fly.io**](/docs/compliance-connectors/setup/cloud-infrastructure/fly-io) | API token | Access token, Organization | `fly tokens create readonly` | [Docs](https://fly.io/docs/security/two-factor-authentication/) |
| [**GoDaddy**](/docs/compliance-connectors/setup/cloud-infrastructure/godaddy) | API token | API key, API secret, Environment (optional), Customer number (optional); or, instead: Personal access token | `domains.domain:read`
Recommended: a personal access token with only domains.domain:read, created at developer.godaddy.com › Personal Access Tokens; it is read-only. Or a classic API key and secret for the same environment (production or OTE): GoDaddy is retiring those for its Domains API and they carry full account access, though Safeguard only reads with them. Add the customer number to read DNSSEC from GoDaddy; without it, Safeguard checks the public DS record.
GoDaddy limits its Domains API to eligible accounts: its documentation asks for at least one domain or a plan that grants management access, and GoDaddy has restricted production access to accounts with 10 or more domains or a Discount Domain Club (Domain Pro) plan. If GoDaddy refuses the account, the tests show an error naming this restriction, never a failure. | [Docs](https://developer.godaddy.com/docs/api-users/auth) |
| [**Google Cloud Platform**](/docs/compliance-connectors/setup/cloud-infrastructure/google-cloud-platform) | OAuth, API token | Service account key (JSON) | — | — |
| [**HashiCorp Consul**](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-consul) | API token | Base URL, API token | `agent:read` | [Docs](https://developer.hashicorp.com/consul/docs/security/acl) |
| [**HashiCorp Nomad**](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-nomad) | API token | Base URL, API token | `agent:read` | [Docs](https://developer.hashicorp.com/nomad/docs/secure/acl) |
| [**Heroku**](/docs/compliance-connectors/setup/cloud-infrastructure/heroku) | API token | API key, Team (optional) | `read` | [Docs](https://devcenter.heroku.com/articles/multi-factor-authentication) |
| [**Hetzner**](/docs/compliance-connectors/setup/cloud-infrastructure/hetzner) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**IBM Cloud**](/docs/compliance-connectors/setup/cloud-infrastructure/ibm-cloud) | API token | API key, Account ID (optional), Regions (optional) | `Viewer (platform)`, `Reader (service)` | [Docs](https://cloud.ibm.com/docs/account?topic=account-manapikey) |
| [**Kubernetes**](/docs/compliance-connectors/setup/cloud-infrastructure/kubernetes) | API token | API server URL, Service account token, Cluster CA certificate (PEM) (optional), Cluster name (optional); or, instead: Kubeconfig (optional) | `get, list: clusterrolebindings, clusterroles, roles, rolebindings, namespaces, nodes, pods, serviceaccounts, networkpolicies`, `get, list: constraints.gatekeeper.sh, kyverno.io policies` | [Docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) |
| [**Linode**](/docs/compliance-connectors/setup/cloud-infrastructure/linode) | API token | Access token | `account:read_only`, `firewall:read_only`, `linodes:read_only` | [Docs](https://techdocs.akamai.com/cloud-computing/docs/security-controls-for-user-accounts) |
| [**Microsoft Azure**](/docs/compliance-connectors/setup/cloud-infrastructure/microsoft-azure) | OAuth, API token | Directory (tenant) ID, Application (client) ID, Client secret, Graph access token (optional) | — | — |
| [**Netlify**](/docs/compliance-connectors/setup/cloud-infrastructure/netlify) | API token, MCP server | Access token, Account (optional) | Netlify issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://docs.netlify.com/manage/accounts-and-billing/team-management/manage-team-members/) |
| [**Northflank**](/docs/compliance-connectors/setup/cloud-infrastructure/northflank) | API token | API token, Team ID | `Team > Members > Read` | [Docs](https://northflank.com/docs/v1/application/collaborate/manage-your-team) |
| [**Nutanix**](/docs/compliance-connectors/setup/cloud-infrastructure/nutanix) | API token | Base URL, Username, Password | `Prism Central Viewer` | [Docs](https://portal.nutanix.com/) |
| [**OpenStack**](/docs/compliance-connectors/setup/cloud-infrastructure/openstack) | API token | API URL, Application credential ID, Application credential secret, Region (optional) | `reader` | [Docs](https://docs.openstack.org/api-ref/identity/v3/) |
| [**Oracle Cloud**](/docs/compliance-connectors/setup/cloud-infrastructure/oracle-cloud) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Oracle Cloud Government**](/docs/compliance-connectors/setup/cloud-infrastructure/oracle-cloud-government) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**OVHcloud**](/docs/compliance-connectors/setup/cloud-infrastructure/ovhcloud) | API token | Application key, Application secret, Consumer key, Region, Access key (optional), Secret key (optional) | `GET /me`, `GET /me/*`, `GET /cloud/project`, `GET /cloud/project/*`, `GET /ip`, `GET /ip/*`
Optional, broader than read-only: an S3 user with a read-only policy (s3:GetBucketAcl, s3:GetBucketPolicy). Without it, the checks that need it show an error naming it. Safeguard only reads with it. | [Docs](https://help.ovhcloud.com/csm/en-api-getting-started-ovhcloud-api) |
| [**Platform.sh**](/docs/compliance-connectors/setup/cloud-infrastructure/platform-sh) | API token | API token, Organization ID, Environment (optional) | Platform.sh issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://docs.platform.sh/administration/security/mfa.html) |
| [**Portainer**](/docs/compliance-connectors/setup/cloud-infrastructure/portainer) | API token | Base URL, Access token | `administrator`
Portainer shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://docs.portainer.io/admin/user/users) |
| [**Proxmox**](/docs/compliance-connectors/setup/cloud-infrastructure/proxmox) | API token | Base URL, Token ID, Token secret | `PVEAuditor on /` | [Docs](https://pve.proxmox.com/wiki/User_Management) |
| [**Qovery**](/docs/compliance-connectors/setup/cloud-infrastructure/qovery) | API token | API token, Organization ID (optional) | `the lowest role that reads members` | [Docs](https://www.qovery.com/docs/configuration/organization/members-rbac) |
| [**Rackspace**](/docs/compliance-connectors/setup/cloud-infrastructure/rackspace) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Railway**](/docs/compliance-connectors/setup/cloud-infrastructure/railway) | API token | API token, Workspace ID | `workspace token`
Railway issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://docs.railway.com/reference/teams) |
| [**Rancher**](/docs/compliance-connectors/setup/cloud-infrastructure/rancher) | API token | Base URL, API token | `Read-only global role` | [Docs](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions) |
| [**Red Hat OpenShift**](/docs/compliance-connectors/setup/cloud-infrastructure/red-hat-openshift) | API token | API server URL, Service account token, Cluster CA certificate (PEM) (optional); or, instead: Kubeconfig (optional) | `get: oauths, apiservers (config.openshift.io)`, `get: configs (imageregistry.operator.openshift.io)`, `get, list: securitycontextconstraints, clusterrolebindings` | [Docs](https://docs.redhat.com/en/documentation/openshift_container_platform/4.17/html/authentication_and_authorization/using-rbac) |
| [**Render**](/docs/compliance-connectors/setup/cloud-infrastructure/render) | API token | API key, Owner ID (optional) | Render issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://render.com/docs/team-members) |
| [**Scaleway**](/docs/compliance-connectors/setup/cloud-infrastructure/scaleway) | API token | Secret key, Organization ID, Zones (optional) | `IAMReadOnly`, `InstancesReadOnly` | [Docs](https://www.scaleway.com/en/docs/iam/how-to/activate-mfa/) |
| [**Spaceship**](/docs/compliance-connectors/setup/cloud-infrastructure/spaceship) | API token | API key, API secret | `domains:read`, `dnsrecords:read`
Create the key in Spaceship's API Manager (spaceship.com › API Manager › New API key) with only the domains:read and dnsrecords:read scopes, both read-only, then paste the key and its secret. Spaceship's API does not show DNSSEC, the account's two-factor authentication or who can sign in: Safeguard checks DNSSEC through the public DS record, and the other two are attested. | [Docs](https://docs.spaceship.dev/#section/Spaceship-API/Authentication) |
| [**UpCloud**](/docs/compliance-connectors/setup/cloud-infrastructure/upcloud) | API token | Username, Password; or, instead: API token (optional) | `API sub-account, read access` | [Docs](https://developers.upcloud.com/1.3/3-accounts/) |
| [**Vercel**](/docs/compliance-connectors/setup/cloud-infrastructure/vercel) | API token, MCP server | Access token, Team ID (optional) | `team-scoped token`
Vercel issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://vercel.com/docs/rbac/managing-team-members) |
| [**VMware**](/docs/compliance-connectors/setup/cloud-infrastructure/vmware) | API token | Base URL, Username, Password | `Read-only (SSO user)` | [Docs](https://developer.broadcom.com/xapis/vsphere-automation-api/latest/) |
| [**VMware Carbon Black**](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-carbon-black) | API token | Environment, Org key, API ID, API secret | `device: READ`, `org.alerts: READ` | [Docs](https://developer.carbonblack.com/reference/carbon-black-cloud/platform/latest/devices-api) |
| [**VMware Workspace ONE**](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-workspace-one) | API token | Host, Tenant code, Access token; or, instead: Username (optional), Password (optional) | `Devices: read (read-only administrator)` | [Docs](https://developer.omnissa.com/workspace-one-uem-apis/) |
| [**Vultr**](/docs/compliance-connectors/setup/cloud-infrastructure/vultr) | API token | API key | `instance and firewall read ACLs`
Optional, broader than read-only: manage\_users. Without it, the checks that need it show an error naming it. Safeguard only reads with it. | [Docs](https://docs.vultr.com/products/network/firewall) |
| [**Yotta**](/docs/compliance-connectors/setup/cloud-infrastructure/yotta) | Record only | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Version Control
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ------------------------------------------------------------------------------------------------ | ---------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- |
| [**Assembla**](/docs/compliance-connectors/setup/version-control/assembla) | API token | API key, API secret, Space (optional) | Assembla issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time.
The credential carries its user's rights: create it as a user who can see every account. | [Docs](https://api-docs.assembla.cc/content/ref/user_roles_index.html) |
| [**AWS CodeCommit**](/docs/compliance-connectors/setup/version-control/aws-codecommit) | API token | AWS Access Key ID, AWS Secret Access Key, Region, Session token (optional) | — | — |
| [**Azure DevOps**](/docs/compliance-connectors/setup/version-control/azure-devops) | OAuth, API token | Directory (tenant) ID, Application (client) ID, Client secret, Graph access token (optional) | — | — |
| [**Beanstalk**](/docs/compliance-connectors/setup/version-control/beanstalk) | API token | Account, Username, Access token | Beanstalk shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
Beanstalk issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://api.beanstalkapp.com/user.html) |
| [**Bitbucket**](/docs/compliance-connectors/setup/version-control/bitbucket) | OAuth, API token | Bitbucket username, App password, Workspace | — | — |
| [**Codeberg**](/docs/compliance-connectors/setup/version-control/codeberg) | API token | Organization, Access token | `read:organization`, `read:repository`, `read:user`
Codeberg shows some settings only to owners, so create the token as an owner. Safeguard only reads with it. | [Docs](https://forgejo.org/docs/latest/user/protection/) |
| [**Gerrit**](/docs/compliance-connectors/setup/version-control/gerrit) | API token | Instance URL, Username, HTTP password | `Read on projects and refs/meta/config`, `View All Accounts` | [Docs](https://gerrit-review.googlesource.com/Documentation/access-control.html) |
| [**Gitea**](/docs/compliance-connectors/setup/version-control/gitea) | API token | Instance URL, Access token, Organization | `read:organization`, `read:repository`, `read:user`
Gitea shows some settings only to owners, so create the token as an owner. Safeguard only reads with it. | [Docs](https://docs.gitea.com/api/1.22/) |
| [**GitHub**](/docs/compliance-connectors/setup/version-control/github) | OAuth, API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**GitHub Dependabot**](/docs/compliance-connectors/setup/version-control/github-dependabot) | OAuth, API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**GitHub Enterprise**](/docs/compliance-connectors/setup/version-control/github-enterprise) | OAuth, API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**GitHub Issues**](/docs/compliance-connectors/setup/version-control/github-issues) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**GitKraken**](/docs/compliance-connectors/setup/version-control/gitkraken) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**GitLab**](/docs/compliance-connectors/setup/version-control/gitlab) | API token | Base URL (self-hosted), API token / PAT | — | — |
| [**GitLab Issues**](/docs/compliance-connectors/setup/version-control/gitlab-issues) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**GitLab Self-Managed**](/docs/compliance-connectors/setup/version-control/gitlab-self-managed) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Launchpad**](/docs/compliance-connectors/setup/version-control/launchpad) | API token | Team, Consumer key (optional), OAuth token (optional), OAuth token secret (optional) | `READ_PRIVATE (private teams only)` | [Docs](https://launchpad.net/+apidoc/devel.html) |
| [**Perforce**](/docs/compliance-connectors/setup/version-control/perforce) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SourceForge**](/docs/compliance-connectors/setup/version-control/sourceforge) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Vulnerability Scanning
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ----------------------------------------------------------------------------------------------------------------------------------- | --------------------- | -------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| [**Acunetix**](/docs/compliance-connectors/setup/vulnerability-scanning/acunetix) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Aikido Security**](/docs/compliance-connectors/setup/vulnerability-scanning/aikido-security) | API token | Client ID, Client secret, Region; or, instead: Access token (optional) | `issues:read`, `repositories:read` | [Docs](https://help.aikido.dev/) |
| [**Anchore**](/docs/compliance-connectors/setup/vulnerability-scanning/anchore) | API token | API URL, API key, Account (optional); or, instead: Username (optional), Password (optional) | `read-only role` | [Docs](https://docs.anchore.com/current/docs/vulnerability_management/) |
| [**Apiiro**](/docs/compliance-connectors/setup/vulnerability-scanning/apiiro) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Arnica**](/docs/compliance-connectors/setup/vulnerability-scanning/arnica) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**AWS Inspector**](/docs/compliance-connectors/setup/vulnerability-scanning/aws-inspector) | API token | AWS Access Key ID, AWS Secret Access Key, Region, Session token (optional) | — | — |
| [**Bright Security**](/docs/compliance-connectors/setup/vulnerability-scanning/bright-security) | API token | API key | `projects:read`, `scans:read` | [Docs](https://docs.brightsec.com/) |
| [**Bugcrowd**](/docs/compliance-connectors/setup/vulnerability-scanning/bugcrowd) | API token | API token | `view the programs' submissions`
If Bugcrowd restricts API access by IP address, allow Safeguard's outbound address. | [Docs](https://docs.bugcrowd.com/) |
| [**Burp Suite**](/docs/compliance-connectors/setup/vulnerability-scanning/burp-suite) | API token | Server URL, API key | `view sites, scans and issues` | [Docs](https://portswigger.net/burp/documentation/dast) |
| [**Chainguard**](/docs/compliance-connectors/setup/vulnerability-scanning/chainguard) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Checkmarx**](/docs/compliance-connectors/setup/vulnerability-scanning/checkmarx) | API token | Refresh token, Tenant, Region | `view-projects`, `view-scans`, `view-results` | [Docs](https://docs.checkmarx.com/) |
| [**Cobalt**](/docs/compliance-connectors/setup/vulnerability-scanning/cobalt) | API token | API token, Organization token (optional), Region (optional) | `organization member` | [Docs](https://docs.cobalt.io/) |
| [**Contrast Security**](/docs/compliance-connectors/setup/vulnerability-scanning/contrast-security) | API token | API key, Username, Service key, Organization ID, Base URL (optional) | `View` | [Docs](https://docs.contrastsecurity.com/) |
| [**Dependency-Track**](/docs/compliance-connectors/setup/vulnerability-scanning/dependency-track) | API token | API URL, API key | `VIEW_PORTFOLIO`, `VIEW_VULNERABILITY` | [Docs](https://docs.dependencytrack.org/) |
| [**Detectify**](/docs/compliance-connectors/setup/vulnerability-scanning/detectify) | API token | API key | `vulnerabilities: read` | [Docs](https://support.detectify.com/) |
| [**Edgescan**](/docs/compliance-connectors/setup/vulnerability-scanning/edgescan) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Endor Labs**](/docs/compliance-connectors/setup/vulnerability-scanning/endor-labs) | API token | API key, API secret, Namespace, Region | `Read-Only` | [Docs](https://docs.endorlabs.com/) |
| [**Escape**](/docs/compliance-connectors/setup/vulnerability-scanning/escape) | API token | API key | `read` | [Docs](https://docs.escape.tech/) |
| [**GitGuardian**](/docs/compliance-connectors/setup/vulnerability-scanning/gitguardian) | API token | API token, Region (optional), Base URL (optional) | `incidents:read`, `sources:read` | [Docs](https://docs.gitguardian.com/) |
| [**Grype**](/docs/compliance-connectors/setup/vulnerability-scanning/grype) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**HackerOne**](/docs/compliance-connectors/setup/vulnerability-scanning/hackerone) | API token | API identifier, API token, Program handle (optional) | `Report viewer` | [Docs](https://docs.hackerone.com/) |
| [**Intruder**](/docs/compliance-connectors/setup/vulnerability-scanning/intruder) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Invicti**](/docs/compliance-connectors/setup/vulnerability-scanning/invicti) | API token | User ID, API token, Base URL (optional) | `read-only role` | [Docs](https://www.invicti.com/support/) |
| [**JFrog Xray**](/docs/compliance-connectors/setup/vulnerability-scanning/jfrog-xray) | API token | Instance URL, Access token | `Read on the watched resources` | [Docs](https://docs.jfrog.com/) |
| [**Legit Security**](/docs/compliance-connectors/setup/vulnerability-scanning/legit-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Mend**](/docs/compliance-connectors/setup/vulnerability-scanning/mend) | API token | Email, User key, Organization ID, Base URL (optional) | `Auditor (service user)` | [Docs](https://docs.mend.io/) |
| [**Nessus**](/docs/compliance-connectors/setup/vulnerability-scanning/nessus) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Nuclei**](/docs/compliance-connectors/setup/vulnerability-scanning/nuclei) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Nucleus Security**](/docs/compliance-connectors/setup/vulnerability-scanning/nucleus-security) | API token | Instance URL, API key, Project ID (optional) | `read-only access to the projects` | [Docs](https://api-docs.nucleussec.com/nucleus/docs/) |
| [**OpenVAS**](/docs/compliance-connectors/setup/vulnerability-scanning/openvas) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**OWASP ZAP**](/docs/compliance-connectors/setup/vulnerability-scanning/owasp-zap) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Ox Security**](/docs/compliance-connectors/setup/vulnerability-scanning/ox-security) | API token | API key, Base URL (optional) | `read-only API key role` | [Docs](https://docs.ox.security/) |
| [**Phylum**](/docs/compliance-connectors/setup/vulnerability-scanning/phylum) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Probely**](/docs/compliance-connectors/setup/vulnerability-scanning/probely) | API token | API key | `read-only role` | [Docs](https://help.probely.com/) |
| [**Qualys**](/docs/compliance-connectors/setup/vulnerability-scanning/qualys) | API token | Username, Password, Platform | `API access`, `Reader` | [Docs](https://docs.qualys.com/) |
| [**Qualys EDR**](/docs/compliance-connectors/setup/vulnerability-scanning/qualys-edr) | API token | API URL, Username, Password | `Reader (EDR)` | [Docs](https://docs.qualys.com/en/edr/api/) |
| [**Rapid7 InsightVM**](/docs/compliance-connectors/setup/vulnerability-scanning/rapid7-insightvm) | API token | API key, Region | `InsightVM read-only` | [Docs](https://docs.rapid7.com/insightvm/) |
| [**Red Hat Advanced Cluster Security**](/docs/compliance-connectors/setup/vulnerability-scanning/red-hat-advanced-cluster-security) | API token | Instance URL, API token | `Analyst (system role)` | [Docs](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.11/html/api_reference/index) |
| [**Safeguard**](/docs/compliance-connectors/setup/vulnerability-scanning/safeguard) | API token, MCP server | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Semgrep**](/docs/compliance-connectors/setup/vulnerability-scanning/semgrep) | API token | API token | `Web API`
Safeguard's compliance tests for Semgrep need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://semgrep.dev/docs/) |
| [**Snyk**](/docs/compliance-connectors/setup/vulnerability-scanning/snyk) | API token | API token, Organization ID (optional), Region | — | — |
| [**Socket**](/docs/compliance-connectors/setup/vulnerability-scanning/socket) | API token | API token, Organization (optional) | `alerts:list` | [Docs](https://docs.socket.dev/) |
| [**SonarQube**](/docs/compliance-connectors/setup/vulnerability-scanning/sonarqube) | API token | Base URL (optional), API token, Organization (optional) | `Browse` | [Docs](https://docs.sonarsource.com/) |
| [**StackHawk**](/docs/compliance-connectors/setup/vulnerability-scanning/stackhawk) | API token | API key, Organization ID (optional) | `Member` | [Docs](https://docs.stackhawk.com/) |
| [**StackRox**](/docs/compliance-connectors/setup/vulnerability-scanning/stackrox) | API token | Instance URL, API token | `Analyst (system role)` | [Docs](https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_security_for_kubernetes/4.11/html/api_reference/index) |
| [**Tenable**](/docs/compliance-connectors/setup/vulnerability-scanning/tenable) | API token | Access key, Secret key, Environment (optional) | `Basic (vulnerability export)`, `Administrator or a custom Export role (asset export)` | [Docs](https://docs.tenable.com/vulnerability-management/Content/Explore/Findings/Vulnerabilities.htm) |
| [**Tenable Cloud Security**](/docs/compliance-connectors/setup/vulnerability-scanning/tenable-cloud-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Trivy**](/docs/compliance-connectors/setup/vulnerability-scanning/trivy) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**TruffleHog**](/docs/compliance-connectors/setup/vulnerability-scanning/trufflehog) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Veracode**](/docs/compliance-connectors/setup/vulnerability-scanning/veracode) | API token | API ID, API key, Region | `Results API` | [Docs](https://docs.veracode.com/) |
| [**Wallarm**](/docs/compliance-connectors/setup/vulnerability-scanning/wallarm) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## HRIS
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ----------------------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
| [**15Five**](/docs/compliance-connectors/setup/hris/15five) | API token | API key | 15Five shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://my.15five.com/api/public/) |
| [**ADP Workforce Now**](/docs/compliance-connectors/setup/hris/adp-workforce-now) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Ashby**](/docs/compliance-connectors/setup/hris/ashby) | API token | API key | `organizationRead` | [Docs](https://developers.ashbyhq.com/reference/userlist) |
| [**BambooHR**](/docs/compliance-connectors/setup/hris/bamboohr) | API token | Company subdomain, API key | `workEmail`, `hireDate`, `supervisorEId`, `employmentHistoryStatus`
The credential carries its user's rights: create it as a user who can see every account. | [Docs](https://documentation.bamboohr.com/docs/list-of-field-names) |
| [**Bob**](/docs/compliance-connectors/setup/hris/bob) | API token | Service user ID, Service user token | `View: Root, Work, Internal, Payroll (Employment)` | [Docs](https://apidocs.hibob.com/reference/post_people-search) |
| [**Ceridian Dayforce**](/docs/compliance-connectors/setup/hris/ceridian-dayforce) | API token | Host, Client namespace, Username, Password; or, instead: Access token (optional) | `read employee status, contacts and managers` | [Docs](https://developers.dayforce.com/Build/API-Explorer.aspx) |
| [**Charlie HR**](/docs/compliance-connectors/setup/hris/charlie-hr) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Culture Amp**](/docs/compliance-connectors/setup/hris/culture-amp) | API token | SCIM base URL, SCIM token | `SCIM token` | [Docs](https://support.cultureamp.com/en/) |
| [**Deel**](/docs/compliance-connectors/setup/hris/deel) | API token | Organization API token | `people:read` | [Docs](https://developer.deel.com/api/reference/endpoints/people/get-people) |
| [**Employment Hero**](/docs/compliance-connectors/setup/hris/employment-hero) | API token | Access token, Organization ID | `employees read` | [Docs](https://developer.employmenthero.com/api-references) |
| [**Factorial**](/docs/compliance-connectors/setup/hris/factorial) | API token | API key; or, instead: Access token (optional) | `employees: read` | [Docs](https://apidoc.factorialhr.com/) |
| [**Greenhouse**](/docs/compliance-connectors/setup/hris/greenhouse) | API token | Access token | `harvest:users:list` | [Docs](https://harvestdocs.greenhouse.io/reference/get_v3-users) |
| [**Gusto**](/docs/compliance-connectors/setup/hris/gusto) | API token | Access token, Company ID, Environment (optional) | `employees:read`, `contractors:read`, `company_admin:read`
Safeguard's compliance tests for Gusto need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://docs.gusto.com/app-integrations/reference/get-v1-companies-company_id-employees) |
| [**HiBob**](/docs/compliance-connectors/setup/hris/hibob) | API token | Service user ID, Service user token | `View: Root, Work, Internal, Payroll (Employment)` | [Docs](https://apidocs.hibob.com/reference/post_people-search) |
| [**Hourly**](/docs/compliance-connectors/setup/hris/hourly) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Humaans**](/docs/compliance-connectors/setup/hris/humaans) | API token | Access token | `people: read`, `job roles: read` | [Docs](https://docs.humaans.io/api/) |
| [**Insperity**](/docs/compliance-connectors/setup/hris/insperity) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Justworks**](/docs/compliance-connectors/setup/hris/justworks) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Lattice**](/docs/compliance-connectors/setup/hris/lattice) | API token | API key | `users: read` | [Docs](https://developers.lattice.com/reference/api_users) |
| [**Lever**](/docs/compliance-connectors/setup/hris/lever) | API token | API key; or, instead: Access token (optional) | `users:read:admin` | [Docs](https://hire.lever.co/developer/documentation#users) |
| [**Multiplier**](/docs/compliance-connectors/setup/hris/multiplier) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Namely**](/docs/compliance-connectors/setup/hris/namely) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Oyster HR**](/docs/compliance-connectors/setup/hris/oyster-hr) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Papaya Global**](/docs/compliance-connectors/setup/hris/papaya-global) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Paychex**](/docs/compliance-connectors/setup/hris/paychex) | API token | Company ID, Client ID, Client secret; or, instead: Access token (optional) | `workers: read`, `communications: read` | [Docs](https://developer.paychex.com/documentation) |
| [**Paycom**](/docs/compliance-connectors/setup/hris/paycom) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Paylocity**](/docs/compliance-connectors/setup/hris/paylocity) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Personio**](/docs/compliance-connectors/setup/hris/personio) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Remote**](/docs/compliance-connectors/setup/hris/remote) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Rippling**](/docs/compliance-connectors/setup/hris/rippling) | API token | API token | `workers:read`, `users:read`, `employment_types:read` | [Docs](https://developer.rippling.com/documentation/rest-api) |
| [**Rippling MDM**](/docs/compliance-connectors/setup/hris/rippling-mdm) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Sage HR**](/docs/compliance-connectors/setup/hris/sage-hr) | API token | Subdomain, API key | Sage HR shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://developers.sage.hr/) |
| [**SAP SuccessFactors**](/docs/compliance-connectors/setup/hris/sap-successfactors) | API token | Host, Username, Password, Company ID; or, instead: Access token (optional) | `User`, `EmpEmployment`, `EmpJob` | [Docs](https://help.sap.com/docs/SAP_SUCCESSFACTORS_PLATFORM) |
| [**Sapling**](/docs/compliance-connectors/setup/hris/sapling) | API token | Subdomain, API key | `profiles: read` | [Docs](https://developer.saplingapp.io/) |
| [**TriNet**](/docs/compliance-connectors/setup/hris/trinet) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**UKG**](/docs/compliance-connectors/setup/hris/ukg) | API token | Host, Username, Password, Customer API key | `Employee Employment Information: View`, `Person Details: View` | [Docs](https://developer.ukg.com/hcm/reference) |
| [**Workable**](/docs/compliance-connectors/setup/hris/workable) | API token | Subdomain, Access token | `r_jobs` | [Docs](https://workable.readme.io/reference/members) |
| [**Workday**](/docs/compliance-connectors/setup/hris/workday) | API token | Report URL, Username, Password; or, instead: Client ID, Client secret, Refresh token | `Integration System User`, `Get_Workers (custom report, web service enabled)` | [Docs](https://developer.workday.com/) |
| [**Workleap**](/docs/compliance-connectors/setup/hris/workleap) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Zenefits**](/docs/compliance-connectors/setup/hris/zenefits) | API token | Access token | `people:read`, `employments:read` | [Docs](https://developers.zenefits.com/docs/people) |
## Endpoint Detection & Response
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ---------------------------------------------------------------------------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| [**Arctic Wolf**](/docs/compliance-connectors/setup/endpoint-detection-and-response/arctic-wolf) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Arctic Wolf Managed Awareness**](/docs/compliance-connectors/setup/endpoint-detection-and-response/arctic-wolf-managed-awareness) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Bitdefender GravityZone**](/docs/compliance-connectors/setup/endpoint-detection-and-response/bitdefender-gravityzone) | API token | API URL, API key | `Network API`, `Incidents API` | [Docs](https://www.bitdefender.com/business/support/en/77209-128483-getendpointslist.html) |
| [**Blackpoint Cyber**](/docs/compliance-connectors/setup/endpoint-detection-and-response/blackpoint-cyber) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Check Point Harmony**](/docs/compliance-connectors/setup/endpoint-detection-and-response/check-point-harmony) | API token | Region, Client ID, Access key | `Endpoint: Read-only` | [Docs](https://app.swaggerhub.com/apis/Check-Point/web-mgmt-external-api-production) |
| [**Cisco Secure Endpoint**](/docs/compliance-connectors/setup/endpoint-detection-and-response/cisco-secure-endpoint) | API token | Region, Client ID, API key | `Read-only` | [Docs](https://developer.cisco.com/docs/secure-endpoint/) |
| [**Cortex XDR**](/docs/compliance-connectors/setup/endpoint-detection-and-response/cortex-xdr) | API token | API URL, API key, API key ID, Key type (optional) | `Viewer` | [Docs](https://cortex-docs.paloaltonetworks.com/xdr-5-api/cortex-platform/endpoint-management.md) |
| [**CrowdStrike Falcon**](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon) | API token | Client ID, Client secret, Cloud, Member CID (optional) | `Hosts: Read`, `Prevention policies: Read`, `Alerts: Read`, `Vulnerabilities: Read`, `User management: Read` | [Docs](https://developer.crowdstrike.com/api-reference/collections/hosts/) |
| [**CrowdStrike Falcon Cloud**](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon-cloud) | API token | Client ID, Client secret, Cloud | `CSPM registration: Read` | [Docs](https://developer.crowdstrike.com/docs/openapi/) |
| [**Cybereason**](/docs/compliance-connectors/setup/endpoint-detection-and-response/cybereason) | API token | Host, Username, Password | `read-only analyst` | [Docs](https://nest.cybereason.com/) |
| [**Cynet**](/docs/compliance-connectors/setup/endpoint-detection-and-response/cynet) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Deep Instinct**](/docs/compliance-connectors/setup/endpoint-detection-and-response/deep-instinct) | API token | Base URL, API key | `read-only API connector` | [Docs](https://www.deepinstinct.com/support) |
| [**Elastic Security**](/docs/compliance-connectors/setup/endpoint-detection-and-response/elastic-security) | API token | Instance URL, API key, Space ID (optional) | `Fleet: Read`, `Integrations: Read`, `Security: Read` | [Docs](https://www.elastic.co/docs/api/doc/kibana/) |
| [**ESET Protect**](/docs/compliance-connectors/setup/endpoint-detection-and-response/eset-protect) | API token | Region, Username, Password | `read-only permission set` | [Docs](https://help.eset.com/eset_connect/en-US/) |
| [**Fleet osquery**](/docs/compliance-connectors/setup/endpoint-detection-and-response/fleet-osquery) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Fortinet FortiEDR**](/docs/compliance-connectors/setup/endpoint-detection-and-response/fortinet-fortiedr) | API token | Host, Username, Password, Organization (optional) | `REST API, read-only` | [Docs](https://docs.fortinet.com/product/fortiedr) |
| [**Huntress**](/docs/compliance-connectors/setup/endpoint-detection-and-response/huntress) | API token | API key, API secret | — | [Docs](https://api.huntress.io/docs) |
| [**Jamf Protect**](/docs/compliance-connectors/setup/endpoint-detection-and-response/jamf-protect) | API token | Tenant, Client ID, Password | `read-only role` | [Docs](https://learn.jamf.com/r/en-US/jamf-protect-documentation/Jamf_Protect_API) |
| [**Kaspersky Endpoint**](/docs/compliance-connectors/setup/endpoint-detection-and-response/kaspersky-endpoint) | API token | Server URL, Username, Password | `Auditor` | [Docs](https://support.kaspersky.com/help/KSC/15.1/KSCAPI/index.html) |
| [**Lookout**](/docs/compliance-connectors/setup/endpoint-detection-and-response/lookout) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Malwarebytes**](/docs/compliance-connectors/setup/endpoint-detection-and-response/malwarebytes) | API token | Client ID, Client secret, Account ID, Region | `read` | [Docs](https://cloud.threatdown.com/api/v2/docs) |
| [**Microsoft Defender for Endpoint**](/docs/compliance-connectors/setup/endpoint-detection-and-response/microsoft-defender-for-endpoint) | API token | Tenant ID, Client ID, Client secret | `Machine.Read.All`, `Alert.Read.All`, `Vulnerability.Read.All` | [Docs](https://learn.microsoft.com/en-us/defender-endpoint/investigate-alerts) |
| [**Rapid7 InsightIDR**](/docs/compliance-connectors/setup/endpoint-detection-and-response/rapid7-insightidr) | API token | Region, User key | `Read Only user` | [Docs](https://help.rapid7.com/insightidr/en-us/api/v2/docs.html) |
| [**Red Canary**](/docs/compliance-connectors/setup/endpoint-detection-and-response/red-canary) | API token | Subdomain, API key | `read access` | [Docs](https://help.redcanary.com/hc/en-us) |
| [**SentinelOne**](/docs/compliance-connectors/setup/endpoint-detection-and-response/sentinelone) | API token | Subdomain, API token | `Viewer` | [Docs](https://community.sentinelone.com/s/) |
| [**Sophos Intercept X**](/docs/compliance-connectors/setup/endpoint-detection-and-response/sophos-intercept-x) | API token | Client ID, Client secret | `Service Principal Read-only` | [Docs](https://developer.sophos.com/reference/common-v1/tenant-access/list-tenant-admins/) |
| [**Symantec Endpoint**](/docs/compliance-connectors/setup/endpoint-detection-and-response/symantec-endpoint) | API token | Client ID, Client secret, Region; or, instead: OAuth token (optional) | `View` | [Docs](https://apidocs.securitycloud.symantec.com/) |
| [**Tanium**](/docs/compliance-connectors/setup/endpoint-detection-and-response/tanium) | API token | Host, API token | `Read Only User`, `Threat Response Read Only` | [Docs](https://help.tanium.com/) |
| [**Trellix**](/docs/compliance-connectors/setup/endpoint-detection-and-response/trellix) | API token | Server URL, Username, Password | `System Tree: View`, `Threat Event Log: View` | [Docs](https://docs.trellix.com/) |
| [**Trend Micro Apex One**](/docs/compliance-connectors/setup/endpoint-detection-and-response/trend-micro-apex-one) | API token | Region, API key | `Endpoint Inventory: View`, `Workbench: View` | [Docs](https://automation.trendmicro.com/xdr/Guides/Regional-domains/) |
| [**Webroot**](/docs/compliance-connectors/setup/endpoint-detection-and-response/webroot) | API token | GSM key, Site ID, Client ID, Client secret, Username, Password | `View-only site access`, `Console.GSM`
Webroot has no narrower grant for these reads. Safeguard only reads with it. | [Docs](https://unityapi.webrootcloudav.com/Docs/en/APIDoc/APIReference) |
| [**WithSecure**](/docs/compliance-connectors/setup/endpoint-detection-and-response/withsecure) | API token | Client ID, Client secret, Organization ID (optional) | `connect.api.read` | [Docs](https://connect.withsecure.com/api-reference/elements) |
## MDM
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| -------------------------------------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- |
| [**42Gears**](/docs/compliance-connectors/setup/mdm/42gears) | API token | Instance URL, API key, Username, Password | `role template with no actions` | [Docs](https://docs.42gears.com/) |
| [**Action1**](/docs/compliance-connectors/setup/mdm/action1) | API token | Client ID, Client secret, Region, Organization ID (optional) | `view_endpoints` | [Docs](https://app.action1.com/apidocs/) |
| [**Addigy**](/docs/compliance-connectors/setup/mdm/addigy) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Automox**](/docs/compliance-connectors/setup/mdm/automox) | API token | API key, Organization ID | `read-only administrator` | [Docs](https://docs.automox.com/product/Developer/Developer_LP.htm) |
| [**Baramundi**](/docs/compliance-connectors/setup/mdm/baramundi) | API token | Server URL, Username, Password | `read-only role on endpoints and AD users` | [Docs](https://docs.baramundi.com/) |
| [**Cisco Meraki SM**](/docs/compliance-connectors/setup/mdm/cisco-meraki-sm) | API token | API key, Network ID | `sm:config:read` | [Docs](https://developer.cisco.com/meraki/api-v1/get-network-sm-devices/) |
| [**Citrix Endpoint Management**](/docs/compliance-connectors/setup/mdm/citrix-endpoint-management) | API token | Server URL, Auth token; or, instead: Citrix Cloud token (optional) | `PUBLIC_API_ACCESS (view devices)` | [Docs](https://docs.citrix.com/en-us/citrix-endpoint-management/rest-apis.html) |
| [**Esper**](/docs/compliance-connectors/setup/mdm/esper) | API token | Tenant, API key | `Viewer` | [Docs](https://api.esper.io/) |
| [**Fleet**](/docs/compliance-connectors/setup/mdm/fleet) | API token | Server URL, API token | `API-only user`, `Observer` | [Docs](https://fleetdm.com/docs/rest-api/rest-api) |
| [**Hexnode**](/docs/compliance-connectors/setup/mdm/hexnode) | API token | Subdomain, API key | `API access enabled` | [Docs](https://www.hexnode.com/mobile-device-management/developers/devices/list-all-devices/) |
| [**IBM MaaS360**](/docs/compliance-connectors/setup/mdm/ibm-maas360) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Ivanti Neurons**](/docs/compliance-connectors/setup/mdm/ivanti-neurons) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Jamf**](/docs/compliance-connectors/setup/mdm/jamf) | API token | Subdomain, Client ID, Client secret; or, instead: API token (optional) | `Read Computers`, `Read Mobile Devices`, `Read macOS Configuration Profiles` | [Docs](https://developer.jamf.com/jamf-pro/reference/get_v1-computers-inventory) |
| [**Kandji**](/docs/compliance-connectors/setup/mdm/kandji) | API token | Subdomain, API token, Region (optional) | `Device list`, `Device details`, `Device status` | [Docs](https://support.kandji.io/kb/library-overview) |
| [**Kolide**](/docs/compliance-connectors/setup/mdm/kolide) | API token | API key | `read-only (no write permissions ticked)` | [Docs](https://support.1password.com/device-trust-api/) |
| [**ManageEngine**](/docs/compliance-connectors/setup/mdm/manageengine) | API token | Access token, Data center | `DesktopCentralCloud.Common.READ`, `DesktopCentralCloud.DataEncryption.READ` | [Docs](https://www.manageengine.com/products/desktop-central/help/api/cloud/api-index.html) |
| [**Microsoft Intune**](/docs/compliance-connectors/setup/mdm/microsoft-intune) | API token | Tenant ID, Client ID, Client secret | `DeviceManagementManagedDevices.Read.All`, `DeviceManagementConfiguration.Read.All` | [Docs](https://learn.microsoft.com/en-us/intune/device-security/compliance/overview) |
| [**Miradore**](/docs/compliance-connectors/setup/mdm/miradore) | API token | Site, API key | Miradore has no narrower grant for these reads. Safeguard only reads with it. | [Docs](https://www.miradore.com/knowledge/integrations/miradore-api/) |
| [**Mosyle**](/docs/compliance-connectors/setup/mdm/mosyle) | API token | Access token, Email, Password | `Devices: View`, `Users: View`, `API Integration: View, Create`
Mosyle's API signs in with an admin's email and password as well as the access token. Create a dedicated admin for Safeguard whose role can only view devices and users, with its own Mosyle password (an admin who signs in only through SSO cannot use the API). Signed in as that admin, create the token under Organization › Integrations › Mosyle API Integration, with Public access or Safeguard's address allowed. Enter all three here yourself: Safeguard stores them encrypted and sends the password only to Mosyle's sign-in.
Mosyle's API reference is not public, so Safeguard reads only the fields public integrations confirm. FileVault, the firewall and a Mac's screen lock show a "couldn't read" error, never a pass or a fail, until the first live connection confirms where Mosyle reports them; attest them meanwhile. Until Mosyle's tests are switched on for your workspace, device posture stays an attestation.
Safeguard's compliance tests for Mosyle need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://business.mosyle.com/) |
| [**NinjaOne**](/docs/compliance-connectors/setup/mdm/ninjaone) | API token | Client ID, Client secret, Region; or, instead: Access token (optional) | `monitoring` | [Docs](https://app.ninjarmm.com/apidocs-beta/core-resources) |
| [**Prey**](/docs/compliance-connectors/setup/mdm/prey) | API token | API key | Prey has no narrower grant for these reads. Safeguard only reads with it. | [Docs](https://api.preyproject.com/) |
| [**Scalefusion**](/docs/compliance-connectors/setup/mdm/scalefusion) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SimpleMDM**](/docs/compliance-connectors/setup/mdm/simplemdm) | API token | API key | `Devices: Read` | [Docs](https://api.simplemdm.com/v1) |
| [**SOTI MobiControl**](/docs/compliance-connectors/setup/mdm/soti-mobicontrol) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Ticketing
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| -------------------------------------------------------------------------------------------------- | --------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| [**Aha!**](/docs/compliance-connectors/setup/ticketing/aha) | API token | Subdomain, API key | Aha! shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://www.aha.io/api/resources/users/list_users) |
| [**Airtable**](/docs/compliance-connectors/setup/ticketing/airtable) | API token, MCP server | Account ID, Access token | `enterprise.account:read`, `enterprise.user:read`
Needs Airtable's Enterprise Scale plan.
Safeguard's compliance tests for Airtable need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://airtable.com/developers/web/api/get-users-by-id-or-email) |
| [**Asana**](/docs/compliance-connectors/setup/ticketing/asana) | API token, MCP server | Access token, Workspace ID (optional) | `workspace_memberships:read`, `users:read`, `tasks:read`, `tags:read` | [Docs](https://developers.asana.com/reference/getworkspacemembershipsforworkspace) |
| [**Azure Boards**](/docs/compliance-connectors/setup/ticketing/azure-boards) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Basecamp**](/docs/compliance-connectors/setup/ticketing/basecamp) | API token | Account ID, Access token | Basecamp shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://github.com/basecamp/bc3-api/blob/master/sections/people.md) |
| [**ClickUp**](/docs/compliance-connectors/setup/ticketing/clickup) | API token | API token, Team ID (optional) | `owner or admin token (to see roles)` | [Docs](https://help.clickup.com/) |
| [**Freshdesk**](/docs/compliance-connectors/setup/ticketing/freshdesk) | API token | Domain, API key | `Account Administrator`
Freshdesk shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://developers.freshdesk.com/api/#list_all_agents) |
| [**Freshservice**](/docs/compliance-connectors/setup/ticketing/freshservice) | API token | Domain, API key; or, instead: Access token (optional) | `freshservice.tickets.view` | [Docs](https://api.freshservice.com/) |
| [**Hive**](/docs/compliance-connectors/setup/ticketing/hive) | API token | Workspace ID, API key | — | [Docs](https://developers.hive.com/reference/listusers) |
| [**Intercom Tickets**](/docs/compliance-connectors/setup/ticketing/intercom-tickets) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Jira**](/docs/compliance-connectors/setup/ticketing/jira) | OAuth, API token | Atlassian account email, API token, Site URL | — | — |
| [**Jira Service Management**](/docs/compliance-connectors/setup/ticketing/jira-service-management) | API token | Atlassian account email, API token, Site URL | `read:servicedesk-request`, `read:jira-work` | [Docs](https://developer.atlassian.com/cloud/jira/service-desk/rest/api-group-request/) |
| [**Linear**](/docs/compliance-connectors/setup/ticketing/linear) | API token, MCP server | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Monday.com**](/docs/compliance-connectors/setup/ticketing/monday-com) | API token, MCP server | API token, Board IDs | `boards:read`, `users:read`
Safeguard's compliance tests for Monday.com need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://support.monday.com/) |
| [**Opsgenie Alerts**](/docs/compliance-connectors/setup/ticketing/opsgenie-alerts) | API token | API key, Region | `Read`, `Configuration access` | [Docs](https://support.atlassian.com/opsgenie/) |
| [**PagerDuty**](/docs/compliance-connectors/setup/ticketing/pagerduty) | API token, MCP server | API key, Region (optional) | `services.read`, `escalation_policies.read`, `schedules.read`, `users.read`, `incidents.read` | [Docs](https://support.pagerduty.com/main/docs/escalation-policies) |
| [**PagerDuty Incidents**](/docs/compliance-connectors/setup/ticketing/pagerduty-incidents) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Productboard**](/docs/compliance-connectors/setup/ticketing/productboard) | API token | Access token | `members:read`, `members:pii:read` | [Docs](https://developer.productboard.com/reference/listmembers) |
| [**Redmine**](/docs/compliance-connectors/setup/ticketing/redmine) | API token | Instance URL, API key | `View issues` | [Docs](https://www.redmine.org/projects/redmine/wiki/Rest_Issues) |
| [**ServiceNow**](/docs/compliance-connectors/setup/ticketing/servicenow) | API token | Instance URL, Username, Password; or, instead: Access token (optional) | `read: incident, problem, sc_req_item, change_request, sys_user, sys_user_has_role` | [Docs](https://www.servicenow.com/docs/) |
| [**Shortcut**](/docs/compliance-connectors/setup/ticketing/shortcut) | API token | API token | — | [Docs](https://help.shortcut.com/) |
| [**Smartsheet**](/docs/compliance-connectors/setup/ticketing/smartsheet) | API token | Access token, Region (optional) | `READ_USERS`, `System Admin`
Smartsheet shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://developers.smartsheet.com/api/smartsheet/openapi/users/list-users) |
| [**SolarWinds Service Desk**](/docs/compliance-connectors/setup/ticketing/solarwinds-service-desk) | API token | Region, API token | `view incidents, audits and users` | [Docs](https://apidoc.samanage.com/) |
| [**Teamwork**](/docs/compliance-connectors/setup/ticketing/teamwork) | API token | Site, API key; or, instead: Access token (optional) | `site administrator`
Teamwork shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
Safeguard's compliance tests for Teamwork need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://apidocs.teamwork.com/docs/teamwork/v3/people/get-projects-api-v3-people-json) |
| [**Trello**](/docs/compliance-connectors/setup/ticketing/trello) | API token | Enterprise ID, API key, API token | `read:enterprise:trello`
Needs Trello's Enterprise plan.
Trello shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
Safeguard's compliance tests for Trello need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://developer.atlassian.com/cloud/trello/rest/api-group-enterprises/) |
| [**Wrike**](/docs/compliance-connectors/setup/ticketing/wrike) | API token | Access token, Host (optional), Account ID (optional) | `wsReadOnly`, `amReadOnlyUser` | [Docs](https://developers.wrike.com/api/v4/contacts/) |
| [**YouTrack**](/docs/compliance-connectors/setup/ticketing/youtrack) | API token | Instance URL, Permanent token | `Read Issue`, `Read User (Hub)` | [Docs](https://www.jetbrains.com/help/youtrack/devportal/resource-api-issues.html) |
| [**Zendesk**](/docs/compliance-connectors/setup/ticketing/zendesk) | API token | Subdomain, Email, API token; or, instead: Access token (optional) | `users:read`
Zendesk shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
Safeguard's compliance tests for Zendesk need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://developer.zendesk.com/api-reference/ticketing/users/users/) |
| [**Zendesk Sell**](/docs/compliance-connectors/setup/ticketing/zendesk-sell) | API token | Access token | `read`
The credential carries its user's rights: create it as a user who can see every account. | [Docs](https://developer.zendesk.com/api-reference/sales-crm/resources/users/) |
| [**Zoho Desk**](/docs/compliance-connectors/setup/ticketing/zoho-desk) | API token | Organization ID, Access token, Data center (optional) | `Desk.basic.READ`
Safeguard's compliance tests for Zoho Desk need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://desk.zoho.com/DeskAPIDocument#Agents) |
## Observability
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ------------------------------------------------------------------------------------------------------ | --------------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| [**Amazon CloudWatch**](/docs/compliance-connectors/setup/observability/amazon-cloudwatch) | API token | AWS Access Key ID, AWS Secret Access Key, Region, Session token (optional) | — | — |
| [**AppDynamics**](/docs/compliance-connectors/setup/observability/appdynamics) | API token | Instance URL, Client ID, Client secret | `read-only role` | [Docs](https://docs.appdynamics.com/appd/24.x/latest/en/extend-cisco-appdynamics/cisco-appdynamics-apis/alert-and-respond-api) |
| [**Better Stack**](/docs/compliance-connectors/setup/observability/better-stack) | API token | API token, Telemetry token (optional) | Better Stack issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://betterstack.com/docs/uptime/api/list-all-existing-monitors/) |
| [**Bugsnag**](/docs/compliance-connectors/setup/observability/bugsnag) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Checkmk**](/docs/compliance-connectors/setup/observability/checkmk) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Chronosphere**](/docs/compliance-connectors/setup/observability/chronosphere) | API token | Instance URL, API token | `read-only service account` | [Docs](https://docs.chronosphere.io/tooling/api-info/definition) |
| [**Coralogix**](/docs/compliance-connectors/setup/observability/coralogix) | API token | Domain, API key | `alerts:ReadConfig`, `team-members:ReadConfig` | [Docs](https://coralogix.com/docs/user-guides/account-management/user-management/scim/) |
| [**Cronitor**](/docs/compliance-connectors/setup/observability/cronitor) | API token | API key | `monitors and notification lists: read` | [Docs](https://cronitor.io/docs/monitor-api) |
| [**Datadog**](/docs/compliance-connectors/setup/observability/datadog) | API token | API Key, Application Key, Site | `monitors_read`, `synthetics_read`, `logs_read_config`, `logs_read_archives`, `user_access_read`, `security_monitoring_signals_read`, `security_monitoring_findings_read` | [Docs](https://docs.datadoghq.com/monitors/notify/) |
| [**Datadog CSM**](/docs/compliance-connectors/setup/observability/datadog-csm) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Dynatrace**](/docs/compliance-connectors/setup/observability/dynatrace) | API token | Instance URL, API token, Account ID (optional), Client ID (optional), Client secret (optional) | `settings.read`, `account-idm-read` | [Docs](https://docs.dynatrace.com/docs/dynatrace-api/account-management-api/user-management-api) |
| [**Elastic Observability**](/docs/compliance-connectors/setup/observability/elastic-observability) | API token | API key (optional), Instance URL (optional); or, instead: API key (optional), Instance URL (optional) | `Cloud Viewer`, `monitor`, `read_ilm`, `view_index_metadata (logs-*)`, `Stack rules: Read` | [Docs](https://www.elastic.co/docs/deploy-manage/users-roles/cloud-organization) |
| [**Google Cloud Operations**](/docs/compliance-connectors/setup/observability/google-cloud-operations) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Grafana**](/docs/compliance-connectors/setup/observability/grafana) | API token | API token, Instance URL | `org.users:read`, `alert.provisioning:read`, `serviceaccounts:read` | [Docs](https://grafana.com/docs/grafana/latest/administration/service-accounts/) |
| [**Honeycomb**](/docs/compliance-connectors/setup/observability/honeycomb) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Instana**](/docs/compliance-connectors/setup/observability/instana) | API token | Instance URL, API token | `alert configurations and users: read` | [Docs](https://www.ibm.com/docs/en/instana-observability/current?topic=apis-instana-rest-api) |
| [**LogicMonitor**](/docs/compliance-connectors/setup/observability/logicmonitor) | API token | Account, Bearer token | `view-only API user` | [Docs](https://www.logicmonitor.com/support/rest-api-developers-guide/overview/using-logicmonitors-rest-api) |
| [**Logz.io**](/docs/compliance-connectors/setup/observability/logz-io) | API token | Region, API token | Logz.io issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://docs.logz.io/docs/logz/manage-users) |
| [**Nagios**](/docs/compliance-connectors/setup/observability/nagios) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Netdata**](/docs/compliance-connectors/setup/observability/netdata) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**New Relic**](/docs/compliance-connectors/setup/observability/new-relic) | API token | User key, Account ID, Region | `read-only: user management, alerts, data management` | [Docs](https://docs.newrelic.com/docs/accounts/accounts-billing/new-relic-one-user-management/user-management-ui-and-tasks/) |
| [**OpenTelemetry**](/docs/compliance-connectors/setup/observability/opentelemetry) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Pingdom**](/docs/compliance-connectors/setup/observability/pingdom) | API token | API token | `read-only` | [Docs](https://docs.pingdom.com/api/) |
| [**Prometheus**](/docs/compliance-connectors/setup/observability/prometheus) | API token | Server URL, Alertmanager URL (optional), Bearer token (optional), Username (optional), Password (optional) | `read access through your proxy` | [Docs](https://prometheus.io/docs/prometheus/latest/querying/api/) |
| [**Raygun**](/docs/compliance-connectors/setup/observability/raygun) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Rollbar**](/docs/compliance-connectors/setup/observability/rollbar) | API token | Access token | `read` | [Docs](https://docs.rollbar.com/reference/getting-started-1) |
| [**Sentry**](/docs/compliance-connectors/setup/observability/sentry) | API token, MCP server | Auth token, Organization, Region (optional) | `org:read`, `project:read`, `alerts:read`, `member:read`
Safeguard's compliance tests for Sentry need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://docs.sentry.io/organization/authentication/two-factor-authentication/) |
| [**SigNoz**](/docs/compliance-connectors/setup/observability/signoz) | API token | Base URL, API key | `SigNoz-Viewer`, `SigNoz-Admin (optional elevated grant, for the account tests)`
A service account key with SigNoz-Viewer verifies the connection and runs the alert and log-retention tests. The account tests (accounts linked to people, leavers, admin count) list users and roles, which only the SigNoz-Admin role can do: custom roles cannot grant user management. SigNoz-Admin also grants write, so give it as an elevated grant, or keep the key as Viewer and attest those tests. | [Docs](https://signoz.io/docs/manage/administrator-guide/iam/service-accounts/) |
| [**Site24x7**](/docs/compliance-connectors/setup/observability/site24x7) | API token | Data center, Access token | `Site24x7.Admin.Read`, `Site24x7.Account.Read` | [Docs](https://www.site24x7.com/help/api/) |
| [**Splunk**](/docs/compliance-connectors/setup/observability/splunk) | API token | API token, Instance ID, Environment (optional) | `sc_admin`, `list_users`, `search-head API access (port 8089)`
If Splunk restricts API access by IP address, allow Safeguard's outbound address. | [Docs](https://docs.splunk.com/Documentation/SplunkCloud/latest/Config/ManageIndexes) |
| [**Splunk SOAR**](/docs/compliance-connectors/setup/observability/splunk-soar) | API token | Base URL, Auth token | `automation user, read on containers` | [Docs](https://help.splunk.com/en/splunk-soar) |
| [**Sumo Logic**](/docs/compliance-connectors/setup/observability/sumo-logic) | API token | Access ID, Access key, Region | `View Users and Roles`, `View Partitions`, `View Monitors` | [Docs](https://help.sumologic.com/docs/manage/users-roles/) |
| [**Uptime Robot**](/docs/compliance-connectors/setup/observability/uptime-robot) | API token | API key | `read-only API key` | [Docs](https://uptimerobot.com/api/v3/) |
| [**VictoriaMetrics**](/docs/compliance-connectors/setup/observability/victoriametrics) | API token | Server URL, Alertmanager URL (optional), Bearer token (optional), Username (optional), Password (optional) | `read access through your proxy` | [Docs](https://docs.victoriametrics.com/victoriametrics/vmalert/) |
| [**Zabbix**](/docs/compliance-connectors/setup/observability/zabbix) | API token | Server URL, API token | `action.get`, `user.get`
Zabbix has no narrower grant for these reads. Safeguard only reads with it. | [Docs](https://www.zabbix.com/documentation/current/en/manual/api/reference/user/get) |
## Cloud Storage Provider
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| --------------------------------------------------------------------------------------------------------- | ---------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| [**Amazon S3**](/docs/compliance-connectors/setup/cloud-storage-provider/amazon-s3) | API token | AWS Access Key ID, AWS Secret Access Key, Region, Session token (optional) | — | — |
| [**Azure Blob Storage**](/docs/compliance-connectors/setup/cloud-storage-provider/azure-blob-storage) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Backblaze**](/docs/compliance-connectors/setup/cloud-storage-provider/backblaze) | API token | Key ID, Application key | `listBuckets`, `readBucketEncryption`, `readBucketRetentions` | [Docs](https://www.backblaze.com/docs/cloud-storage-buckets) |
| [**Box**](/docs/compliance-connectors/setup/cloud-storage-provider/box) | API token, MCP server | Access token | `manage_managed_users`, `App + Enterprise access`
Box has no narrower grant for these reads. Safeguard only reads with it. | [Docs](https://developer.box.com/reference/get-users/) |
| [**Citrix ShareFile**](/docs/compliance-connectors/setup/cloud-storage-provider/citrix-sharefile) | API token | Subdomain, Access token, Region (optional) | `AdminManageEmployees`
Citrix ShareFile shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://api.sharefile.com/docs/resource?name=Users) |
| [**Dropbox**](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox) | API token | Access token | `members.read` | [Docs](https://developers.dropbox.com/business) |
| [**Dropbox Sign**](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox-sign) | API token | API key; or, instead: Access token (optional) | `team_access`
Dropbox Sign shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://developers.hellosign.com/api/reference/operation/teamGet/) |
| [**Egnyte**](/docs/compliance-connectors/setup/cloud-storage-provider/egnyte) | API token, MCP server | Domain, Access token | `Egnyte.user`
Egnyte shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
Safeguard's compliance tests for Egnyte need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://developers.egnyte.com/docs/read/User_Management_API_Documentation) |
| [**Google Cloud Storage**](/docs/compliance-connectors/setup/cloud-storage-provider/google-cloud-storage) | OAuth, API token | Service account key (JSON) | — | — |
| [**Google Drive**](/docs/compliance-connectors/setup/cloud-storage-provider/google-drive) | OAuth, API token, MCP server | Service account key (JSON), Admin email to impersonate, OAuth access token (optional) | `drive.readonly` | [Docs](https://support.google.com/a/answer/60781) |
| [**Hack The Box**](/docs/compliance-connectors/setup/cloud-storage-provider/hack-the-box) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**iCloud**](/docs/compliance-connectors/setup/cloud-storage-provider/icloud) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**IDrive**](/docs/compliance-connectors/setup/cloud-storage-provider/idrive) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**MinIO**](/docs/compliance-connectors/setup/cloud-storage-provider/minio) | API token | Server URL, Access key, Secret key | `s3:ListAllMyBuckets`, `s3:GetBucket*` | [Docs](https://min.io/docs/minio/linux/administration/identity-access-management/policy-based-access-control.html) |
| [**Nextcloud**](/docs/compliance-connectors/setup/cloud-storage-provider/nextcloud) | API token | Base URL, Username, App password | Nextcloud shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/instruction_set_for_users.html) |
| [**OneDrive**](/docs/compliance-connectors/setup/cloud-storage-provider/onedrive) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**ownCloud**](/docs/compliance-connectors/setup/cloud-storage-provider/owncloud) | API token | Base URL, Username, App password | ownCloud shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://doc.owncloud.com/server/11.0/developer_manual/core/apis/provisioning-api.html) |
| [**pCloud**](/docs/compliance-connectors/setup/cloud-storage-provider/pcloud) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SharePoint**](/docs/compliance-connectors/setup/cloud-storage-provider/sharepoint) | API token | Tenant ID, Client ID, Client secret, Cloud (optional) | `SharePointTenantSettings.Read.All`, `Global Reader or SharePoint Administrator (signed-in user)` | [Docs](https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off) |
| [**Storj**](/docs/compliance-connectors/setup/cloud-storage-provider/storj) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Wasabi**](/docs/compliance-connectors/setup/cloud-storage-provider/wasabi) | API token | Access key, Secret key | `s3:ListAllMyBuckets`, `s3:GetBucket*` | [Docs](https://docs.wasabi.com/docs/bucket-settings) |
## Compliance As Code
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| --------------------------------------------------------------------------------------------- | --------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------- |
| [**Anecdotes**](/docs/compliance-connectors/setup/compliance-as-code/anecdotes) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Apptega**](/docs/compliance-connectors/setup/compliance-as-code/apptega) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Archer**](/docs/compliance-connectors/setup/compliance-as-code/archer) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**AuditBoard**](/docs/compliance-connectors/setup/compliance-as-code/auditboard) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Confluence**](/docs/compliance-connectors/setup/compliance-as-code/confluence) | API token | Email, API token, Site URL, Organization ID (optional), Organization admin API key (optional) | `Organization admin API key`, `read:jira-work`
Safeguard's compliance tests for Confluence need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://developer.atlassian.com/cloud/admin/organization/rest/api-group-users/) |
| [**Drata**](/docs/compliance-connectors/setup/compliance-as-code/drata) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**First Advantage**](/docs/compliance-connectors/setup/compliance-as-code/first-advantage) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Google Docs**](/docs/compliance-connectors/setup/compliance-as-code/google-docs) | OAuth, API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Hyperproof**](/docs/compliance-connectors/setup/compliance-as-code/hyperproof) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**LogicGate**](/docs/compliance-connectors/setup/compliance-as-code/logicgate) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**MetricStream**](/docs/compliance-connectors/setup/compliance-as-code/metricstream) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**NAVEX PolicyTech**](/docs/compliance-connectors/setup/compliance-as-code/navex-policytech) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Notion**](/docs/compliance-connectors/setup/compliance-as-code/notion) | API token, MCP server | Access token | `Read user information including email addresses` | [Docs](https://developers.notion.com/reference/get-users) |
| [**PowerDMS**](/docs/compliance-connectors/setup/compliance-as-code/powerdms) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Scrut Automation**](/docs/compliance-connectors/setup/compliance-as-code/scrut-automation) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Secureframe**](/docs/compliance-connectors/setup/compliance-as-code/secureframe) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Sprinto**](/docs/compliance-connectors/setup/compliance-as-code/sprinto) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Strike Graph**](/docs/compliance-connectors/setup/compliance-as-code/strike-graph) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Thoropass**](/docs/compliance-connectors/setup/compliance-as-code/thoropass) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**TrustCloud**](/docs/compliance-connectors/setup/compliance-as-code/trustcloud) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Tugboat Logic**](/docs/compliance-connectors/setup/compliance-as-code/tugboat-logic) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Vanta**](/docs/compliance-connectors/setup/compliance-as-code/vanta) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Vendor Procurement
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ----------------------------------------------------------------------------------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [**Airbase**](/docs/compliance-connectors/setup/vendor-procurement/airbase) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**BitSight**](/docs/compliance-connectors/setup/vendor-procurement/bitsight) | API token | API token, Company ID (optional) | `view the company's own rating` | [Docs](https://help.bitsighttech.com/hc/en-us) |
| [**Brex**](/docs/compliance-connectors/setup/vendor-procurement/brex) | API token | Access token | `users.readonly` | [Docs](https://developer.brex.com/openapi/team_api/) |
| [**Conveyor**](/docs/compliance-connectors/setup/vendor-procurement/conveyor) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Coupa**](/docs/compliance-connectors/setup/vendor-procurement/coupa) | API token | Instance URL, Access token; or, instead: Client ID (optional), Client secret (optional) | `core.user.read` | [Docs](https://compass.coupa.com/en-us/products/product-documentation/integration-technical-documentation/the-coupa-core-api/resources/reference-data-resources/users-api-\(users\)) |
| [**CyberGRX**](/docs/compliance-connectors/setup/vendor-procurement/cybergrx) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Gatekeeper**](/docs/compliance-connectors/setup/vendor-procurement/gatekeeper) | API token | API server URL, Service account token, Cluster CA certificate (PEM) (optional), Cluster name (optional); or, instead: Kubeconfig (optional) | `get, list: clusterrolebindings, clusterroles, roles, rolebindings, namespaces, nodes, pods, serviceaccounts, networkpolicies`, `get, list: constraints.gatekeeper.sh, kyverno.io policies` | [Docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) |
| [**Gatekeeper OPA**](/docs/compliance-connectors/setup/vendor-procurement/gatekeeper-opa) | API token | API server URL, Service account token, Cluster CA certificate (PEM) (optional), Cluster name (optional); or, instead: Kubeconfig (optional) | `get, list: clusterrolebindings, clusterroles, roles, rolebindings, namespaces, nodes, pods, serviceaccounts, networkpolicies`, `get, list: constraints.gatekeeper.sh, kyverno.io policies` | [Docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) |
| [**HyperComply**](/docs/compliance-connectors/setup/vendor-procurement/hypercomply) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Loopio**](/docs/compliance-connectors/setup/vendor-procurement/loopio) | API token | Access token, Region (optional); or, instead: Client ID (optional), Client secret (optional) | `user:read`, `role:read` | [Docs](https://developer.loopio.com/) |
| [**OneTrust Questionnaire**](/docs/compliance-connectors/setup/vendor-procurement/onetrust-questionnaire) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**OneTrust Vendorpedia**](/docs/compliance-connectors/setup/vendor-procurement/onetrust-vendorpedia) | API token | Host, Access token; or, instead: Client ID (optional), Client secret (optional) | `SCIM`
A SCIM token can also create and change users, and OneTrust Vendorpedia has no read-only one. Safeguard only reads with it. | [Docs](https://developer.onetrust.com/onetrust/reference/getallusersusingget) |
| [**Order.co**](/docs/compliance-connectors/setup/vendor-procurement/order-co) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Panorays**](/docs/compliance-connectors/setup/vendor-procurement/panorays) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Precoro**](/docs/compliance-connectors/setup/vendor-procurement/precoro) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Prevalent**](/docs/compliance-connectors/setup/vendor-procurement/prevalent) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**ProcessUnity**](/docs/compliance-connectors/setup/vendor-procurement/processunity) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Ramp**](/docs/compliance-connectors/setup/vendor-procurement/ramp) | API token, MCP server | Access token; or, instead: Client ID (optional), Client secret (optional) | `users:read` | [Docs](https://docs.ramp.com/developer-api/v1/api/users) |
| [**Responsive**](/docs/compliance-connectors/setup/vendor-procurement/responsive) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**RiskRecon**](/docs/compliance-connectors/setup/vendor-procurement/riskrecon) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SafeBase**](/docs/compliance-connectors/setup/vendor-procurement/safebase) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SAP Ariba**](/docs/compliance-connectors/setup/vendor-procurement/sap-ariba) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Sastrify**](/docs/compliance-connectors/setup/vendor-procurement/sastrify) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SecurityScorecard Atlas**](/docs/compliance-connectors/setup/vendor-procurement/securityscorecard-atlas) | API token | API token, Domain | `read the company's own scorecard` | [Docs](https://support.securityscorecard.com/hc/en-us) |
| [**Setyl**](/docs/compliance-connectors/setup/vendor-procurement/setyl) | API token | API key, Consumer ID | `company-wide API key (an Owner creates it)` | [Docs](https://developers.setyl.com/) |
| [**Spendflo**](/docs/compliance-connectors/setup/vendor-procurement/spendflo) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Tropic**](/docs/compliance-connectors/setup/vendor-procurement/tropic) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**UpGuard Vendor Risk**](/docs/compliance-connectors/setup/vendor-procurement/upguard-vendor-risk) | API token | API key | `BreachRisk` | [Docs](https://help.upguard.com/en/) |
| [**Vendict**](/docs/compliance-connectors/setup/vendor-procurement/vendict) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Vendr**](/docs/compliance-connectors/setup/vendor-procurement/vendr) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Venminder**](/docs/compliance-connectors/setup/vendor-procurement/venminder) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Whistic**](/docs/compliance-connectors/setup/vendor-procurement/whistic) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Zip**](/docs/compliance-connectors/setup/vendor-procurement/zip) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## User Access Review
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ----------------------------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------- | --------------------- | ----------------------------------------------------------------------------------------------- |
| [**BetterCloud**](/docs/compliance-connectors/setup/user-access-review/bettercloud) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**ConductorOne**](/docs/compliance-connectors/setup/user-access-review/conductorone) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Josys**](/docs/compliance-connectors/setup/user-access-review/josys) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Lumos**](/docs/compliance-connectors/setup/user-access-review/lumos) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Omada Identity**](/docs/compliance-connectors/setup/user-access-review/omada-identity) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Opal**](/docs/compliance-connectors/setup/user-access-review/opal) | API token | API token | `read-only token` | [Docs](https://docs.opal.dev/api-reference/campaigns/get-campaigns) |
| [**Rezonate**](/docs/compliance-connectors/setup/user-access-review/rezonate) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Sonrai Access**](/docs/compliance-connectors/setup/user-access-review/sonrai-access) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Torii**](/docs/compliance-connectors/setup/user-access-review/torii) | API token | API key | — | [Docs](https://developers.toriihq.com/reference/getusers) |
| [**Trelica**](/docs/compliance-connectors/setup/user-access-review/trelica) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Veza**](/docs/compliance-connectors/setup/user-access-review/veza) | API token | Instance URL, API key | `view access reviews` | [Docs](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/workflows/listaccessworkflows) |
| [**Zilla Security**](/docs/compliance-connectors/setup/user-access-review/zilla-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Zluri**](/docs/compliance-connectors/setup/user-access-review/zluri) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Security Training
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ---------------------------------------------------------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------- | ------------------------------------------------ | ------------------------------------------------------------------------------------------------------ |
| [**360Learning**](/docs/compliance-connectors/setup/security-training/360learning) | API token | Client ID, Client secret, Region | `users:read`, `paths:read`, `pathStats:read` | [Docs](https://360learning.readme.io/reference/v2pathsgetpathstatscontroller_getpathstats) |
| [**Cornerstone**](/docs/compliance-connectors/setup/security-training/cornerstone) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Coursera**](/docs/compliance-connectors/setup/security-training/coursera) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Curricula**](/docs/compliance-connectors/setup/security-training/curricula) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**CybSafe**](/docs/compliance-connectors/setup/security-training/cybsafe) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Docebo**](/docs/compliance-connectors/setup/security-training/docebo) | API token | Subdomain, Access token | `api`, `users and enrollments: read` | [Docs](https://help.docebo.com/hc/en-us/articles/360020124479-Docebo-API-Browser) |
| [**Hoxhunt**](/docs/compliance-connectors/setup/security-training/hoxhunt) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Immersive Labs**](/docs/compliance-connectors/setup/security-training/immersive-labs) | API token | Access key, Secret key | `organisation activity: read` | [Docs](https://docs.immersivelabs.com/) |
| [**Infosec IQ**](/docs/compliance-connectors/setup/security-training/infosec-iq) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**KnowBe4**](/docs/compliance-connectors/setup/security-training/knowbe4) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Lessonly**](/docs/compliance-connectors/setup/security-training/lessonly) | API token | Subdomain, API key | — | [Docs](https://docs.lessonly.com/) |
| [**Living Security**](/docs/compliance-connectors/setup/security-training/living-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Mimecast Awareness**](/docs/compliance-connectors/setup/security-training/mimecast-awareness) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**NINJIO**](/docs/compliance-connectors/setup/security-training/ninjio) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Pluralsight**](/docs/compliance-connectors/setup/security-training/pluralsight) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Proofpoint Security Awareness**](/docs/compliance-connectors/setup/security-training/proofpoint-security-awareness) | API token | API key, Region | `Results API: Training`, `Results API: Phishing` | [Docs](https://help.proofpoint.com/Proofpoint_Security_Awareness/Administration/Results_API) |
| [**Riot**](/docs/compliance-connectors/setup/security-training/riot) | API token | API key, Workspace ID (optional) | `courses, campaigns and attacks: read` | [Docs](https://docs.tryriot.com/) |
| [**SANS Security Awareness**](/docs/compliance-connectors/setup/security-training/sans-security-awareness) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Secure Code Warrior**](/docs/compliance-connectors/setup/security-training/secure-code-warrior) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**TalentLMS**](/docs/compliance-connectors/setup/security-training/talentlms) | API token | Domain, API key | — | [Docs](https://www.talentlms.com/pages/docs/TalentLMS-API-Documentation.pdf) |
| [**Terranova Security**](/docs/compliance-connectors/setup/security-training/terranova-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**TryHackMe**](/docs/compliance-connectors/setup/security-training/tryhackme) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Udemy Business**](/docs/compliance-connectors/setup/security-training/udemy-business) | API token | Organization, Organization ID, Client ID, Client secret | `Reporting API` | [Docs](https://business-support.udemy.com/hc/en-us/articles/115005521688-Udemy-Business-Reporting-API) |
| [**Wizer**](/docs/compliance-connectors/setup/security-training/wizer) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Background Check Providers
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| --------------------------------------------------------------------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------- | ------------------------------ | --------------------------------------- |
| [**Accurate**](/docs/compliance-connectors/setup/background-check-providers/accurate) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Certn**](/docs/compliance-connectors/setup/background-check-providers/certn) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Checkr**](/docs/compliance-connectors/setup/background-check-providers/checkr) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Cisive**](/docs/compliance-connectors/setup/background-check-providers/cisive) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**ClearChecks**](/docs/compliance-connectors/setup/background-check-providers/clearchecks) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**GoodHire**](/docs/compliance-connectors/setup/background-check-providers/goodhire) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**HireRight**](/docs/compliance-connectors/setup/background-check-providers/hireright) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**IDenfy**](/docs/compliance-connectors/setup/background-check-providers/idenfy) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Jumio**](/docs/compliance-connectors/setup/background-check-providers/jumio) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Onfido**](/docs/compliance-connectors/setup/background-check-providers/onfido) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Persona**](/docs/compliance-connectors/setup/background-check-providers/persona) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Socure**](/docs/compliance-connectors/setup/background-check-providers/socure) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Sterling**](/docs/compliance-connectors/setup/background-check-providers/sterling) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Truework**](/docs/compliance-connectors/setup/background-check-providers/truework) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Universal Background Screening**](/docs/compliance-connectors/setup/background-check-providers/universal-background-screening) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Veremark**](/docs/compliance-connectors/setup/background-check-providers/veremark) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Vetty**](/docs/compliance-connectors/setup/background-check-providers/vetty) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Yardstik**](/docs/compliance-connectors/setup/background-check-providers/yardstik) | API token | API key | `reports and candidates: read` | [Docs](https://developer.yardstik.com/) |
| [**Zinc**](/docs/compliance-connectors/setup/background-check-providers/zinc) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## CSPM
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ----------------------------------------------------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------- |
| [**Aqua Security**](/docs/compliance-connectors/setup/cspm/aqua-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**AWS Security Hub**](/docs/compliance-connectors/setup/cspm/aws-security-hub) | API token | AWS Access Key ID, AWS Secret Access Key, Region, Session token (optional) | — | — |
| [**Check Point CloudGuard**](/docs/compliance-connectors/setup/cspm/check-point-cloudguard) | API token | API key ID, API key secret, Region | `read-only role` | [Docs](https://sc1.checkpoint.com/documents/CloudGuard_Dome9/Documentation/Compliance-Policy/Findings.htm) |
| [**Cloudanix**](/docs/compliance-connectors/setup/cspm/cloudanix) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**CoreStack**](/docs/compliance-connectors/setup/cspm/corestack) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Cyscale**](/docs/compliance-connectors/setup/cspm/cyscale) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Ermetic**](/docs/compliance-connectors/setup/cspm/ermetic) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Google Security Command Center**](/docs/compliance-connectors/setup/cspm/google-security-command-center) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Kion**](/docs/compliance-connectors/setup/cspm/kion) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Lacework**](/docs/compliance-connectors/setup/cspm/lacework) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Microsoft Defender for Cloud**](/docs/compliance-connectors/setup/cspm/microsoft-defender-for-cloud) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Orca Security**](/docs/compliance-connectors/setup/cspm/orca-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Prisma Cloud**](/docs/compliance-connectors/setup/cspm/prisma-cloud) | API token | Access key, Secret key, API URL | `Account Group Read Only` | [Docs](https://docs.prismacloud.io/en/) |
| [**Rapid7 InsightCloudSec**](/docs/compliance-connectors/setup/cspm/rapid7-insightcloudsec) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Sonrai Security**](/docs/compliance-connectors/setup/cspm/sonrai-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Stream Security**](/docs/compliance-connectors/setup/cspm/stream-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Sweet Security**](/docs/compliance-connectors/setup/cspm/sweet-security) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Sysdig**](/docs/compliance-connectors/setup/cspm/sysdig) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Trend Micro Cloud One**](/docs/compliance-connectors/setup/cspm/trend-micro-cloud-one) | API token | API key, Region | `Read Only` | [Docs](https://docs.trendmicro.com/en-us/documentation/article/trend-micro-cloud-one-conformity-checks) |
| [**Turbot**](/docs/compliance-connectors/setup/cspm/turbot) | API token | Instance URL, Access key, Secret key | `Turbot/ReadOnly` | [Docs](https://turbot.com/guardrails/docs/reference/graphql/query/controls) |
| [**Uptycs**](/docs/compliance-connectors/setup/cspm/uptycs) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Wiz**](/docs/compliance-connectors/setup/cspm/wiz) | API token | Client ID, Client secret, Data center, Environment (optional) | `read:vulnerabilities` | [Docs](https://docs.wiz.io/wiz-docs/docs/vulnerability-findings) |
| [**Zscaler Posture Control**](/docs/compliance-connectors/setup/cspm/zscaler-posture-control) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Security Automation
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| -------------------------------------------------------------------------------------------------------- | --------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| [**Blink Ops**](/docs/compliance-connectors/setup/security-automation/blink-ops) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Cortex XSOAR**](/docs/compliance-connectors/setup/security-automation/cortex-xsoar) | API token | Base URL, API key, API key ID (optional) | `read-only role` | [Docs](https://docs-cortex.paloaltonetworks.com/r/Cortex-XSOAR/6.x/Cortex-XSOAR-Administrator-Guide/Incident-Lifecycle) |
| [**Cyware**](/docs/compliance-connectors/setup/security-automation/cyware) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**D3 Security**](/docs/compliance-connectors/setup/security-automation/d3-security) | API token | API URL, Header name, Header value, Username, Site | `the command's webhook key` | [Docs](https://docs.d3security.com/api-docs/working-version/get-incidents) |
| [**Google Chronicle SOAR**](/docs/compliance-connectors/setup/security-automation/google-chronicle-soar) | API token | Project ID, Location, Instance ID, Service account key (JSON); or, instead: Access token (optional) | `roles/chronicle.viewer` | [Docs](https://cloud.google.com/chronicle/docs/reference/rest/v1alpha/projects.locations.instances.cases/list) |
| [**IBM QRadar SOAR**](/docs/compliance-connectors/setup/security-automation/ibm-qradar-soar) | API token | Base URL, Organization ID, API key ID, API key secret | `read on incidents` | [Docs](https://www.ibm.com/docs/en/sqsp) |
| [**Make**](/docs/compliance-connectors/setup/security-automation/make) | API token | Organization ID, API token, Zone | `user:read`, `organizations:read` | [Docs](https://developers.make.com/api-documentation/api-reference/users) |
| [**Mindflow**](/docs/compliance-connectors/setup/security-automation/mindflow) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**n8n**](/docs/compliance-connectors/setup/security-automation/n8n) | API token | Instance URL, API key | `user:list`
n8n shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://docs.n8n.io/user-management/) |
| [**Palo Alto XSOAR**](/docs/compliance-connectors/setup/security-automation/palo-alto-xsoar) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Pipedream**](/docs/compliance-connectors/setup/security-automation/pipedream) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Rapid7 InsightConnect**](/docs/compliance-connectors/setup/security-automation/rapid7-insightconnect) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Shuffle**](/docs/compliance-connectors/setup/security-automation/shuffle) | API token | API key, Base URL (optional) | `organization admin`
Shuffle shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://shuffler.io/docs/organizations) |
| [**Swimlane**](/docs/compliance-connectors/setup/security-automation/swimlane) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**ThreatConnect**](/docs/compliance-connectors/setup/security-automation/threatconnect) | API token | Base URL, Access ID, Secret key; or, instead: API token (optional) | — | [Docs](https://docs.threatconnect.com/en/latest/rest_api/v3/users/users.html) |
| [**Tines**](/docs/compliance-connectors/setup/security-automation/tines) | API token | Instance URL, API key | `tenant admin`
Tines shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://www.tines.com/api/admin/users/list/) |
| [**Torq**](/docs/compliance-connectors/setup/security-automation/torq) | API token | Client ID, Client secret, Region | `read on cases` | [Docs](https://developers.torq.io/apidocs/query-cases) |
| [**Tray.io**](/docs/compliance-connectors/setup/security-automation/tray-io) | API token | Access token, Region (optional) | `organization admin`
Tray.io shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://tray.ai/documentation/developer/platform-apis/users) |
| [**Workato**](/docs/compliance-connectors/setup/security-automation/workato) | API token | API token, Data center | `Get collaborators` | [Docs](https://docs.workato.com/en/workato-api/team) |
| [**Zapier**](/docs/compliance-connectors/setup/security-automation/zapier) | API token, MCP server | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Infrastructure
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ----------------------------------------------------------------------------------------------- | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| [**Ansible**](/docs/compliance-connectors/setup/infrastructure/ansible) | API token | Server URL, Access token, API path (optional) | `System Auditor`, `read scope` | [Docs](https://docs.ansible.com/automation-controller/latest/html/userguide/users.html) |
| [**Bridgecrew**](/docs/compliance-connectors/setup/infrastructure/bridgecrew) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Checkov**](/docs/compliance-connectors/setup/infrastructure/checkov) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Cloud Custodian**](/docs/compliance-connectors/setup/infrastructure/cloud-custodian) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**CloudQuery**](/docs/compliance-connectors/setup/infrastructure/cloudquery) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Conftest**](/docs/compliance-connectors/setup/infrastructure/conftest) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Docker**](/docs/compliance-connectors/setup/infrastructure/docker) | API token | Organization, Docker ID, Personal access token | — | — |
| [**env0**](/docs/compliance-connectors/setup/infrastructure/env0) | API token | Organization ID, API key ID, API key secret | `Organization Admin`
env0 shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://docs.envzero.com/api-reference/organization/list-users) |
| [**Fairwinds Polaris**](/docs/compliance-connectors/setup/infrastructure/fairwinds-polaris) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Firebase**](/docs/compliance-connectors/setup/infrastructure/firebase) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | `firebase.readonly` | [Docs](https://firebase.google.com/docs/rules/insecure-rules) |
| [**HashiCorp Terraform**](/docs/compliance-connectors/setup/infrastructure/hashicorp-terraform) | API token | Organization or team API token, Organization name, HCP Terraform host | — | — |
| [**HashiCorp Vault**](/docs/compliance-connectors/setup/infrastructure/hashicorp-vault) | API token | Server URL, API token, Namespace (optional) | `read + sudo: sys/audit`, `read: sys/auth`, `read + list: identity/mfa/login-enforcement`
HashiCorp Vault has no narrower grant for these reads. Safeguard only reads with it. | [Docs](https://developer.hashicorp.com/vault/docs/auth/login-mfa) |
| [**Infisical**](/docs/compliance-connectors/setup/infrastructure/infisical) | API token | Client ID, Client secret, Organization ID, Instance URL (optional) | `Machine identity (Universal Auth)`, `Organization: Member read`, `Organization: Identity read`, `Organization: Audit Logs read`, `Project: Secret Rotation read (no secret access)`
Needs Infisical's Pro (audit logs) plan. | [Docs](https://infisical.com/docs/documentation/platform/identities/universal-auth) |
| [**Kyverno**](/docs/compliance-connectors/setup/infrastructure/kyverno) | API token | API server URL, Service account token, Cluster CA certificate (PEM) (optional), Cluster name (optional); or, instead: Kubeconfig (optional) | `get, list: clusterrolebindings, clusterroles, roles, rolebindings, namespaces, nodes, pods, serviceaccounts, networkpolicies`, `get, list: constraints.gatekeeper.sh, kyverno.io policies` | [Docs](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) |
| [**MongoDB Atlas**](/docs/compliance-connectors/setup/infrastructure/mongodb-atlas) | API token | Public key, Private key (PEM), Organization ID (optional), Environment (optional); or, instead: Client ID (optional), Client secret (optional) | `Organization Read Only`, `Project Read Only` | [Docs](https://www.mongodb.com/docs/atlas/security/ip-access-list/) |
| [**Open Policy Agent**](/docs/compliance-connectors/setup/infrastructure/open-policy-agent) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**PlanetScale**](/docs/compliance-connectors/setup/infrastructure/planetscale) | API token | Organization, Service token ID, Service token; or, instead: Access token (optional) | `read_organization`, `read_database`, `read_branch`, `read_backups`
Safeguard's compliance tests for PlanetScale need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://planetscale.com/docs/concepts/access-control) |
| [**Prowler**](/docs/compliance-connectors/setup/infrastructure/prowler) | API token | API key, Base URL (optional) | `read findings` | [Docs](https://docs.prowler.com/) |
| [**Pulumi**](/docs/compliance-connectors/setup/infrastructure/pulumi) | API token | Organization, Access token | `organization admin`
Pulumi shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
Needs Pulumi's Business Critical (policy groups) plan. | [Docs](https://www.pulumi.com/docs/reference/cloud-rest-api/organizations/) |
| [**Pulumi Cloud**](/docs/compliance-connectors/setup/infrastructure/pulumi-cloud) | API token | Organization, Access token | `organization admin`
Pulumi Cloud shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
Needs Pulumi Cloud's Business Critical (policy groups) plan. | [Docs](https://www.pulumi.com/docs/reference/cloud-rest-api/organizations/) |
| [**Redis Cloud**](/docs/compliance-connectors/setup/infrastructure/redis-cloud) | API token | Account key, User key | `Viewer` | [Docs](https://redis.io/docs/latest/operate/rc/security/access-control/access-management/) |
| [**Regula**](/docs/compliance-connectors/setup/infrastructure/regula) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Sentinel**](/docs/compliance-connectors/setup/infrastructure/sentinel) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Spacelift**](/docs/compliance-connectors/setup/infrastructure/spacelift) | API token | Instance URL, API key ID, API key secret; or, instead: Access token (optional) | `Read on the root space` | [Docs](https://docs.spacelift.io/concepts/identity-access-management/user) |
| [**Steampipe**](/docs/compliance-connectors/setup/infrastructure/steampipe) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Supabase**](/docs/compliance-connectors/setup/infrastructure/supabase) | API token, MCP server | Access token | `organizations:read`, `projects:read`, `database:read` | [Docs](https://supabase.com/docs/guides/platform/access-control) |
| [**Terraform Cloud**](/docs/compliance-connectors/setup/infrastructure/terraform-cloud) | API token | Organization or team API token, Organization name, HCP Terraform host | — | — |
| [**Terrascan**](/docs/compliance-connectors/setup/infrastructure/terrascan) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**tfsec**](/docs/compliance-connectors/setup/infrastructure/tfsec) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Digital Signature
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ------------------------------------------------------------------------------------------------ | ------------ | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- |
| [**Adobe Acrobat Sign**](/docs/compliance-connectors/setup/digital-signature/adobe-acrobat-sign) | API token | Access token, API URL | `user_read:account`
Safeguard's compliance tests for Adobe Acrobat Sign need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://secure.na1.adobesign.com/public/docs/restapi/v6) |
| [**BoldSign**](/docs/compliance-connectors/setup/digital-signature/boldsign) | API token | API key, Region (optional); or, instead: Access token (optional) | BoldSign shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
BoldSign issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://developers.boldsign.com/users/list-users/) |
| [**Concord**](/docs/compliance-connectors/setup/digital-signature/concord) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Contractbook**](/docs/compliance-connectors/setup/digital-signature/contractbook) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**ContractSafe**](/docs/compliance-connectors/setup/digital-signature/contractsafe) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Documenso**](/docs/compliance-connectors/setup/digital-signature/documenso) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**DocuSign**](/docs/compliance-connectors/setup/digital-signature/docusign) | API token | Access token, Organization ID, Account ID, Environment (optional) | `user_read`, `organization_read`
Safeguard's compliance tests for DocuSign need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://developers.docusign.com/docs/admin-api/reference/users/) |
| [**DocuSign CLM**](/docs/compliance-connectors/setup/digital-signature/docusign-clm) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Eversign**](/docs/compliance-connectors/setup/digital-signature/eversign) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Evisort**](/docs/compliance-connectors/setup/digital-signature/evisort) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Foxit eSign**](/docs/compliance-connectors/setup/digital-signature/foxit-esign) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**GetAccept**](/docs/compliance-connectors/setup/digital-signature/getaccept) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Ironclad**](/docs/compliance-connectors/setup/digital-signature/ironclad) | API token | Access token, Environment (optional) | `scim.users.readUsers` | [Docs](https://developer.ironcladapp.com/reference/retrieve-all-users) |
| [**Juro**](/docs/compliance-connectors/setup/digital-signature/juro) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Lexion**](/docs/compliance-connectors/setup/digital-signature/lexion) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**LinkSquares**](/docs/compliance-connectors/setup/digital-signature/linksquares) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Oneflow**](/docs/compliance-connectors/setup/digital-signature/oneflow) | API token | SCIM token | `SCIM API token`
A SCIM token can also create and change users, and Oneflow has no read-only one. Safeguard only reads with it. | [Docs](https://developer.oneflow.com/reference/list-users) |
| [**OneSpan Sign**](/docs/compliance-connectors/setup/digital-signature/onespan-sign) | API token | API key, Instance URL | `account manager` | [Docs](https://docs.onespan.com/docs/managing-senders) |
| [**PandaDoc**](/docs/compliance-connectors/setup/digital-signature/pandadoc) | API token | API key; or, instead: Access token (optional) | `read` | [Docs](https://developers.pandadoc.com/reference/list-members) |
| [**PandaDoc NDA**](/docs/compliance-connectors/setup/digital-signature/pandadoc-nda) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**RightSignature**](/docs/compliance-connectors/setup/digital-signature/rightsignature) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Signable**](/docs/compliance-connectors/setup/digital-signature/signable) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Signeasy**](/docs/compliance-connectors/setup/digital-signature/signeasy) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SignNow**](/docs/compliance-connectors/setup/digital-signature/signnow) | API token | Access token, Organization ID | `organization admin`
SignNow shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://docs.signnow.com/docs/organization/operations/get-v2-organizations-org-id-members) |
| [**SignRequest**](/docs/compliance-connectors/setup/digital-signature/signrequest) | API token | API token, Subdomain | `team API token`
SignRequest issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://signrequest.com/api/v1/docs/) |
| [**SignWell**](/docs/compliance-connectors/setup/digital-signature/signwell) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Skribble**](/docs/compliance-connectors/setup/digital-signature/skribble) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**SpotDraft**](/docs/compliance-connectors/setup/digital-signature/spotdraft) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Yousign**](/docs/compliance-connectors/setup/digital-signature/yousign) | API token | API key, Environment (optional) | Yousign issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://developers.youtrust.com/reference/get-users-1) |
| [**Zoho Sign**](/docs/compliance-connectors/setup/digital-signature/zoho-sign) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Communications Platforms
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ------------------------------------------------------------------------------------------------- | ---------------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| [**8x8**](/docs/compliance-connectors/setup/communications-platforms/8x8) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Aircall**](/docs/compliance-connectors/setup/communications-platforms/aircall) | API token | API ID, API token; or, instead: Access token (optional) | Aircall issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://developers.aircall.io/api-references) |
| [**Dialpad**](/docs/compliance-connectors/setup/communications-platforms/dialpad) | API token | API key, Environment (optional) | `company admin`
Dialpad shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://developers.dialpad.com/reference/userslist) |
| [**Discord**](/docs/compliance-connectors/setup/communications-platforms/discord) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Front**](/docs/compliance-connectors/setup/communications-platforms/front) | API token | API token; or, instead: Access token (optional) | `teammates:read` | [Docs](https://dev.frontapp.com/reference/list-teammates) |
| [**Google Meet**](/docs/compliance-connectors/setup/communications-platforms/google-meet) | OAuth, API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**GoTo Connect**](/docs/compliance-connectors/setup/communications-platforms/goto-connect) | API token | Access token, Account ID | `identity:`, `admin user` | [Docs](https://developer.goto.com/admin) |
| [**Intercom**](/docs/compliance-connectors/setup/communications-platforms/intercom) | API token, MCP server | Access token, Region (optional) | `Read admins` | [Docs](https://developers.intercom.com/docs/references/rest-api/api.intercom.io/admins/listadmins) |
| [**Mailgun**](/docs/compliance-connectors/setup/communications-platforms/mailgun) | API token | API key, Region (optional) | `list users` | [Docs](https://documentation.mailgun.com/docs/mailgun/api-reference/send/mailgun/users) |
| [**Mattermost**](/docs/compliance-connectors/setup/communications-platforms/mattermost) | API token | Server URL, Access token | `system admin or system read-only admin` | [Docs](https://docs.mattermost.com/configure/authentication-configuration-settings.html) |
| [**MessageBird**](/docs/compliance-connectors/setup/communications-platforms/messagebird) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Microsoft Teams**](/docs/compliance-connectors/setup/communications-platforms/microsoft-teams) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Miro**](/docs/compliance-connectors/setup/communications-platforms/miro) | API token | Organization ID, Access token | — | — |
| [**Nextiva**](/docs/compliance-connectors/setup/communications-platforms/nextiva) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**OpenPhone**](/docs/compliance-connectors/setup/communications-platforms/openphone) | API token | API key | OpenPhone issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://www.quo.com/docs/mdx/api-reference/users/list-users) |
| [**Plivo**](/docs/compliance-connectors/setup/communications-platforms/plivo) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Postmark**](/docs/compliance-connectors/setup/communications-platforms/postmark) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Rocket.Chat**](/docs/compliance-connectors/setup/communications-platforms/rocket-chat) | API token | Server URL, User ID, Auth token | `view-full-other-user-info` | [Docs](https://developer.rocket.chat/apidocs/get-users-list) |
| [**SendGrid**](/docs/compliance-connectors/setup/communications-platforms/sendgrid) | API token | API key | `teammates.read` | [Docs](https://www.twilio.com/docs/sendgrid/api-reference/teammates/retrieve-all-teammates) |
| [**Slack**](/docs/compliance-connectors/setup/communications-platforms/slack) | OAuth, API token, MCP server | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | `users:read`, `users:read.email` | [Docs](https://slack.com/help/articles/212221668-Mandatory-workspace-two-factor-authentication) |
| [**Telnyx**](/docs/compliance-connectors/setup/communications-platforms/telnyx) | API token | API key | `owner or admin`
Telnyx shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
Telnyx issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time. | [Docs](https://developers.telnyx.com/api-reference/organization-users/list-organization-users) |
| [**Twilio**](/docs/compliance-connectors/setup/communications-platforms/twilio) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Vonage**](/docs/compliance-connectors/setup/communications-platforms/vonage) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Webex**](/docs/compliance-connectors/setup/communications-platforms/webex) | API token | Access token | `spark-admin:people_read`, `spark-admin:roles_read` | [Docs](https://developer.webex.com/docs/api/v1/people) |
| [**Zoom**](/docs/compliance-connectors/setup/communications-platforms/zoom) | API token | Account ID, Client ID, Client secret; or, instead: Access token (optional) | `user:read:list_users:admin`, `role:read:list_roles:admin`, `role:read:role:admin`, `account:read:settings:admin`
Safeguard's compliance tests for Zoom need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://developers.zoom.us/docs/api/users/) |
## Data Export
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ------------------------------------------------------------------------------------ | ---------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------- |
| [**Airbyte**](/docs/compliance-connectors/setup/data-export/airbyte) | API token | Organization ID, Client ID, Client secret; or, instead: Access token (optional) | `Organization Admin`
Airbyte shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://reference.airbyte.com/reference/listuserswithinanorganization) |
| [**Amazon Redshift**](/docs/compliance-connectors/setup/data-export/amazon-redshift) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Amplitude**](/docs/compliance-connectors/setup/data-export/amplitude) | API token | SCIM token, Region (optional) | `SCIM key`
A SCIM token can also create and change users, and Amplitude has no read-only one. Safeguard only reads with it.
Needs Amplitude's Enterprise plan. | [Docs](https://amplitude.com/docs/apis/analytics/scim) |
| [**Census**](/docs/compliance-connectors/setup/data-export/census) | API token | Workspace ID, Access token | `organization API token` | [Docs](https://fivetran.com/docs/activations/rest-api/api-reference/v1/organization-apis/workspaces/workspace-users/list-workspace-users) |
| [**ClickHouse**](/docs/compliance-connectors/setup/data-export/clickhouse) | API token | Key ID, Key secret | `control-plane:organization:view` | [Docs](https://clickhouse.com/docs/cloud/security/cloud-access-management) |
| [**Databricks**](/docs/compliance-connectors/setup/data-export/databricks) | API token | Instance URL, Access token | `service principal (not a workspace admin)` | [Docs](https://docs.databricks.com/aws/en/admin/users-groups/users) |
| [**dbt Cloud**](/docs/compliance-connectors/setup/data-export/dbt-cloud) | API token | Account ID, Service token, API URL (optional) | `Account Viewer` | [Docs](https://docs.getdbt.com/dbt-cloud/api-v2) |
| [**Fivetran**](/docs/compliance-connectors/setup/data-export/fivetran) | API token | API key, API secret | `Account Administrator`
Fivetran shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://fivetran.com/docs/rest-api/api-reference/users/list-all-users) |
| [**Google BigQuery**](/docs/compliance-connectors/setup/data-export/google-bigquery) | OAuth, API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Hevo Data**](/docs/compliance-connectors/setup/data-export/hevo-data) | API token | Access key, Secret key, Region | — | [Docs](https://api-docs.hevodata.com/reference/getallusersfromteam) |
| [**Hightouch**](/docs/compliance-connectors/setup/data-export/hightouch) | API token | SCIM token | `SCIM token`
A SCIM token can also create and change users, and Hightouch has no read-only one. Safeguard only reads with it.
Needs Hightouch's Business plan. | [Docs](https://hightouch.com/docs/workspace-management/sso) |
| [**Looker**](/docs/compliance-connectors/setup/data-export/looker) | API token | Instance URL, Client ID, Client secret | `see_users`
Safeguard's compliance tests for Looker need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://cloud.google.com/looker/docs/admin-panel-authentication-two-factor) |
| [**Matillion**](/docs/compliance-connectors/setup/data-export/matillion) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Mixpanel**](/docs/compliance-connectors/setup/data-export/mixpanel) | API token | SCIM token, Region (optional) | `SCIM token`
A SCIM token can also create and change users, and Mixpanel has no read-only one. Safeguard only reads with it.
Needs Mixpanel's Enterprise plan. | [Docs](https://docs.mixpanel.com/docs/access-security/single-sign-on) |
| [**RudderStack**](/docs/compliance-connectors/setup/data-export/rudderstack) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Segment**](/docs/compliance-connectors/setup/data-export/segment) | API token | Access token, Region (optional) | `Workspace Owner`
Segment shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://docs.segmentapis.com/tag/IAM-Users) |
| [**Snowflake**](/docs/compliance-connectors/setup/data-export/snowflake) | API token | Account, User, Private key (PEM), Private key passphrase (optional), Role, Warehouse; or, instead: OAuth token (optional) | `IMPORTED PRIVILEGES ON DATABASE SNOWFLAKE`, `USAGE on the warehouse` | [Docs](https://docs.snowflake.com/en/user-guide/security-mfa) |
| [**Stitch**](/docs/compliance-connectors/setup/data-export/stitch) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## CRM
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ------------------------------------------------------------------------------------------ | --------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| [**ActiveCampaign**](/docs/compliance-connectors/setup/crm/activecampaign) | API token | API URL, API key | ActiveCampaign shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
The credential carries its user's rights: create it as a user who can see every account. | [Docs](https://developers.activecampaign.com/reference/list-all-users) |
| [**Affinity**](/docs/compliance-connectors/setup/crm/affinity) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Attio**](/docs/compliance-connectors/setup/crm/attio) | API token, MCP server | Access token | `user_management:read` | [Docs](https://docs.attio.com/rest-api/endpoint-reference/workspace-members/list-workspace-members) |
| [**Capsule**](/docs/compliance-connectors/setup/crm/capsule) | API token | Access token | — | [Docs](https://developer.capsulecrm.com/v2/operations/User) |
| [**Close**](/docs/compliance-connectors/setup/crm/close) | API token, MCP server | API key, Organization ID (optional); or, instead: Access token (optional) | `Admin` | [Docs](https://developer.close.com/api/resources/memberships) |
| [**Copper**](/docs/compliance-connectors/setup/crm/copper) | API token | API key, Email; or, instead: Access token (optional) | — | [Docs](https://developer.copper.com/account-and-users/list-users.html) |
| [**folk**](/docs/compliance-connectors/setup/crm/folk) | API token | API key | — | [Docs](https://developer.folk.app/api-reference/users/list-users) |
| [**Freshsales**](/docs/compliance-connectors/setup/crm/freshsales) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**GoHighLevel**](/docs/compliance-connectors/setup/crm/gohighlevel) | API token | Private integration token, Company ID (optional); or, instead: Location ID (optional) | `users.readonly` | [Docs](https://marketplace.gohighlevel.com/docs/) |
| [**HubSpot**](/docs/compliance-connectors/setup/crm/hubspot) | API token, MCP server | Access token | `settings.users.read` | [Docs](https://developers.hubspot.com/docs/api/settings/user-provisioning) |
| [**Insightly**](/docs/compliance-connectors/setup/crm/insightly) | API token | API key, Pod (optional) | Insightly shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://api.insightly.com/v3.1/Help) |
| [**Keap**](/docs/compliance-connectors/setup/crm/keap) | API token | API key; or, instead: Access token (optional) | Keap has no narrower grant for these reads. Safeguard only reads with it. | [Docs](https://developer.keap.com/docs/restv2/) |
| [**Microsoft Dynamics 365**](/docs/compliance-connectors/setup/crm/microsoft-dynamics-365) | API token | Instance URL, Access token | `prvReadUser`, `prvReadRole`
Safeguard's compliance tests for Microsoft Dynamics 365 need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://learn.microsoft.com/en-us/power-platform/admin/create-users) |
| [**Nutshell**](/docs/compliance-connectors/setup/crm/nutshell) | API token | Email, API key | — | [Docs](https://developers.nutshell.com/) |
| [**Pipedrive**](/docs/compliance-connectors/setup/crm/pipedrive) | API token | API token; or, instead: Access token (optional), API URL (optional) | `users:read` | [Docs](https://developers.pipedrive.com/docs/api/v1/Users) |
| [**Salesflare**](/docs/compliance-connectors/setup/crm/salesflare) | API token | API key | — | [Docs](https://api.salesflare.com/docs) |
| [**Salesforce**](/docs/compliance-connectors/setup/crm/salesforce) | API token | Instance URL, Access token | `api`, `View Setup and Configuration`
Needs Salesforce's Enterprise (or API enabled) plan.
Optional, broader than read-only: Manage Multi-Factor Authentication in API. Without it, the checks that need it show an error naming it. Safeguard only reads with it. | [Docs](https://help.salesforce.com/s/articleView?id=sf.deactivating_users.htm) |
| [**Streak**](/docs/compliance-connectors/setup/crm/streak) | API token | API key | The credential carries its user's rights: create it as a user who can see every account. | [Docs](https://streak.readme.io/reference/get-teams) |
| [**SugarCRM**](/docs/compliance-connectors/setup/crm/sugarcrm) | API token | Instance URL, Access token, Client ID (optional), Client secret (optional); or, instead: Username (optional), Password (optional) | `Users: Read` | [Docs](https://support.sugarcrm.com/documentation/) |
| [**Vtiger**](/docs/compliance-connectors/setup/crm/vtiger) | API token | Instance URL, Username, Access key | Vtiger shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. | [Docs](https://help.vtiger.com/article/147111249-Rest-API-Manual) |
| [**Zoho CRM**](/docs/compliance-connectors/setup/crm/zoho-crm) | API token | Access token, API URL | `ZohoCRM.users.READ` | [Docs](https://www.zoho.com/crm/developer/docs/api/v8/get-users.html) |
## Cyber Insurance
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ------------------------------------------------------------------------------------------ | ------------ | -------------------------------------------------------------------------------------------- | ------------------- | ----------- |
| [**AIG**](/docs/compliance-connectors/setup/cyber-insurance/aig) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Aon**](/docs/compliance-connectors/setup/cyber-insurance/aon) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**At-Bay**](/docs/compliance-connectors/setup/cyber-insurance/at-bay) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**AXA XL**](/docs/compliance-connectors/setup/cyber-insurance/axa-xl) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Beazley**](/docs/compliance-connectors/setup/cyber-insurance/beazley) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Chubb**](/docs/compliance-connectors/setup/cyber-insurance/chubb) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Coalition**](/docs/compliance-connectors/setup/cyber-insurance/coalition) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Corvus Insurance**](/docs/compliance-connectors/setup/cyber-insurance/corvus-insurance) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Cowbell Cyber**](/docs/compliance-connectors/setup/cyber-insurance/cowbell-cyber) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Embroker**](/docs/compliance-connectors/setup/cyber-insurance/embroker) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Hiscox**](/docs/compliance-connectors/setup/cyber-insurance/hiscox) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Marsh**](/docs/compliance-connectors/setup/cyber-insurance/marsh) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Munich Re**](/docs/compliance-connectors/setup/cyber-insurance/munich-re) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Resilience**](/docs/compliance-connectors/setup/cyber-insurance/resilience) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Travelers**](/docs/compliance-connectors/setup/cyber-insurance/travelers) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Vouch**](/docs/compliance-connectors/setup/cyber-insurance/vouch) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Woodruff Sawyer**](/docs/compliance-connectors/setup/cyber-insurance/woodruff-sawyer) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Zurich**](/docs/compliance-connectors/setup/cyber-insurance/zurich) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
## Business Applications
| Connector | Connect with | The form asks for | Grant at the vendor | Vendor docs |
| ---------------------------------------------------------------------------------------------------------- | --------------------- | -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- |
| [**Apollo IO**](/docs/compliance-connectors/setup/business-applications/apollo-io) | API token, MCP server | API key | `master API key`
Safeguard's compliance tests for Apollo IO need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://docs.apollo.io/reference/get-a-list-of-users) |
| [**Canva**](/docs/compliance-connectors/setup/business-applications/canva) | API token, MCP server | SCIM token | `SCIM token`
A SCIM token can also create and change users, and Canva has no read-only one. Safeguard only reads with it.
Safeguard's compliance tests for Canva need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://www.canva.dev/docs/scim/list-users/) |
| [**Carta**](/docs/compliance-connectors/setup/business-applications/carta) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**ChatGPT**](/docs/compliance-connectors/setup/business-applications/chatgpt) | API token | Workspace ID, Compliance API key | `Compliance API`
Needs ChatGPT's Enterprise or Edu plan.
Needs a ChatGPT Enterprise or Edu Compliance API key and the workspace ID. An API key from platform.openai.com does not work here: connect it with the OpenAI API Platform card. | [Docs](https://help.openai.com/en/articles/9261474-compliance-api-for-enterprise-customers) |
| [**Claude (Anthropic)**](/docs/compliance-connectors/setup/business-applications/claude-anthropic) | API token | Organization admin API key, Organization ID (optional) | `Claude Console: Admin API key (admin role)`, `Claude Enterprise: read:members`, `read:compliance_org_data`, `read:compliance_activities`
Claude Console: an Admin API key (sk-ant-admin01-…) from Console › Settings › Admin keys; Anthropic issues no read-only one, and Safeguard only reads with it. Claude Enterprise: a key from claude.ai › Organization settings › API with only the read scopes listed. A Claude API key (sk-ant-api03-…) does not work here. | [Docs](https://platform.claude.com/docs/en/manage-claude/admin-api-keys) |
| [**Cohere**](/docs/compliance-connectors/setup/business-applications/cohere) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**DeepSeek**](/docs/compliance-connectors/setup/business-applications/deepseek) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**ElevenLabs**](/docs/compliance-connectors/setup/business-applications/elevenlabs) | API token | API key | `workspace_members_read`, `workspace_read`, `audit_log_read`
Create the key on a service account with only workspace\_members\_read, workspace\_read and audit\_log\_read. ElevenLabs keeps the audit log on Enterprise plans. | [Docs](https://elevenlabs.io/docs/overview/administration/workspaces/service-accounts) |
| [**Figma**](/docs/compliance-connectors/setup/business-applications/figma) | API token, MCP server | Tenant ID, SCIM token, Environment (optional) | `SCIM API token`
Needs Figma's Organization or Enterprise plan.
Safeguard's compliance tests for Figma need the credential on the API token tab: an OAuth connection cannot read everything they check. | [Docs](https://help.figma.com/hc/en-us/articles/360048514653-Set-up-automatic-provisioning-via-SCIM) |
| [**Fireworks AI**](/docs/compliance-connectors/setup/business-applications/fireworks-ai) | API token | API key, Account ID | `admin role (an admin service account)`
Fireworks AI issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time.
Needs the API key of an admin, best an admin service account (firectl user create --service-account --role admin), and your account ID. Listing every user's keys needs the admin role. | [Docs](https://docs.fireworks.ai/accounts/service-accounts) |
| [**Groq**](/docs/compliance-connectors/setup/business-applications/groq) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Hugging Face**](/docs/compliance-connectors/setup/business-applications/hugging-face) | API token | Access token, Organization | `organization admin (fine-grained token)`, `Team or Enterprise plan`
Hugging Face issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time.
Needs an access token of an organization admin (or an Enterprise service account) and the organization's name. Hugging Face shows members' emails and tokens only on Team and Enterprise plans. | [Docs](https://huggingface.co/docs/hub/enterprise-hub-tokens-management) |
| [**LinkedIn**](/docs/compliance-connectors/setup/business-applications/linkedin) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Microsoft 365 Copilot**](/docs/compliance-connectors/setup/business-applications/microsoft-365-copilot) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Mistral AI**](/docs/compliance-connectors/setup/business-applications/mistral-ai) | API token | Organization admin API key | `Admin API key (organization admin)`
Needs Mistral AI's Enterprise plan.
Mistral AI issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time.
Needs a Mistral Admin API key, created in the Mistral console › API keys. The Admin API is in preview and needs an Enterprise plan. A standard API key does not work here. | [Docs](https://docs.mistral.ai/admin/admin-api/overview) |
| [**OpenAI API Platform**](/docs/compliance-connectors/setup/business-applications/openai-api-platform) | API token | Organization admin API key | `Admin API key (organization Owner)`
OpenAI API Platform issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time.
Needs an OpenAI Admin API key (sk-admin-…), created by an organization Owner at platform.openai.com › Settings › Organization › Admin keys. A project API key or a ChatGPT Compliance API key does not work here. | [Docs](https://developers.openai.com/api/reference/administration/overview) |
| [**OpenRouter**](/docs/compliance-connectors/setup/business-applications/openrouter) | API token | Management key | `Management API key (Org Admin)`
OpenRouter issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time.
Needs an OpenRouter management API key, created by an Org Admin on the Management API Keys page. A model API key does not work here. | [Docs](https://openrouter.ai/docs/guides/overview/auth/management-api-keys) |
| [**Perplexity**](/docs/compliance-connectors/setup/business-applications/perplexity) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Replicate**](/docs/compliance-connectors/setup/business-applications/replicate) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Stripe**](/docs/compliance-connectors/setup/business-applications/stripe) | API token, MCP server | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**Together AI**](/docs/compliance-connectors/setup/business-applications/together-ai) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
| [**xAI**](/docs/compliance-connectors/setup/business-applications/xai) | API token | Management key, Team ID (optional) | `Management key (team scope)`
xAI issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time.
Needs an xAI management key from console.x.ai › Settings › Management Keys, scoped to your team. Leave the team ID blank to use the key's own team. An API key for the models does not work here. | [Docs](https://docs.x.ai/docs/management-api) |
| [**Z.ai (Zhipu GLM)**](/docs/compliance-connectors/setup/business-applications/z-ai-zhipu-glm) | API token | API token / Personal access token, Base URL (optional), Account / Org / Workspace (optional) | — | — |
# SigNoz (/docs/compliance-connectors/signoz)
# Connect SigNoz
Safeguard reads your SigNoz with a service account key, GET calls only: alert rules and the notification channels they reach, log retention, and the users and roles in your workspace. It works with SigNoz Cloud and with a self-hosted SigNoz.
## Which role to give the key
| Role | Checks it covers |
| ----------------- | ------------------------------------------------------------------------ |
| **SigNoz-Viewer** | Verifies the connection; alert rules notify a channel; log retention |
| **SigNoz-Admin** | Also the account checks: accounts linked to people, leavers, admin count |
The account checks list users and roles, which only SigNoz-Admin can do: custom roles cannot grant user management. SigNoz-Admin also grants write access, so either give it as an elevated grant (Safeguard only reads with it), or keep the key as Viewer and attest the account checks instead.
## 1. Create a service account key in SigNoz
1. In SigNoz, open **Settings › Service Accounts** and create a service account, for example "Safeguard compliance".
2. Give it the **SigNoz-Viewer** role, or **SigNoz-Admin** for the account checks.
3. Create a key for it and copy it.
## 2. Connect it in Safeguard
1. Open **Compliance › Connectors**, search for **SigNoz** and click **Connect**.
2. Choose **API token**:
| Field | What to enter |
| -------- | ----------------------------------------------------------------------------------------------- |
| Base URL | Your SigNoz address, for example `https://.signoz.cloud`, or your self-hosted SigNoz |
| API key | The service account key |
3. Click **Connect with token**.
A self-hosted SigNoz must be reachable at a public `https://` address. Safeguard refuses private, loopback and cloud-metadata addresses before it sends anything.
## What Safeguard checks
* Alert rules reach a notification channel. A rule routed only by a routing policy is reported as unknown, because Safeguard does not evaluate routing expressions.
* Log retention meets your minimum
* With SigNoz-Admin: SigNoz accounts belong to people in your personnel register, people who left no longer have access, and how many admins there are
## Troubleshooting
* **The account checks show an error naming SigNoz-Admin**: expected with a Viewer key. Give the key SigNoz-Admin, or attest those checks.
* **Not working with a self-hosted SigNoz**: make sure the Base URL is a public `https://` address.
# StackRox (/docs/compliance-connectors/stackrox)
# Connect StackRox (Red Hat Advanced Cluster Security)
Safeguard reads your StackRox Central with an API token, GET calls only: vulnerability findings per workload, cluster health, open policy violations, policy enforcement, notifiers and their health, and compliance scan results. The **StackRox** and **Red Hat Advanced Cluster Security** cards connect the same way, to a self-hosted Central or to an RHACS Cloud Service instance.
## Before you start
* Central must be reachable at a public `https://` address. For RHACS Cloud Service, that is your instance's Central URL, for example `https://acs-.acs.rhcloud.com`. Safeguard refuses private, loopback and cloud-metadata addresses before it sends anything.
* The checks about workloads, vulnerabilities and violations need at least one secured cluster reporting to Central. Without one, Central-level checks (policies, notifiers, compliance) still run, and the cluster checks have nothing to evaluate.
## 1. Create an API token in Central
1. In Central, open **Platform Configuration › Integrations**.
2. Under **Authentication Tokens**, choose **API Token**, then **Generate token**.
3. Name it, for example "Safeguard compliance", and choose the **Analyst** role. Analyst reads every resource and changes none.
4. Click **Generate** and copy the token. Central shows it once.
## 2. Connect it in Safeguard
1. Open **Compliance › Connectors**, search for **StackRox** (or **Red Hat Advanced Cluster Security**) and click **Connect**.
2. Choose **API token**:
| Field | What to enter |
| ------------ | ---------------------------------------------------------------- |
| Instance URL | Your Central URL, for example `https://acs-.acs.rhcloud.com` |
| API token | The token |
3. Click **Connect with token**. The card shows **Verified** once Central accepts the token.
## What Safeguard checks
* Critical, high and medium vulnerabilities are fixed within their time limits
* Scan coverage: every secured cluster's sensor is reporting to Central, so its workloads are assessed
* Open violations of high and critical policies are triaged
* Enforcement is turned on for deploy-time and runtime policies
* A notifier is configured and healthy
* Compliance scan results, per secured cluster
## Troubleshooting
* **Not working, refusing the address**: Central must be a public `https://` address.
* **Not working with a 401 or 403**: generate a new token with the Analyst role.
# Authentication (/docs/console/authentication)
Every request to the inference API carries an API key. Keys are issued by Safeguard's servers from the Console; nothing in your browser creates or stores them.
## Send the key
Put the key in the `Authorization` header of every request:
```bash
curl https://api.safeguard.sh/gpt/v1/models \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY"
```
A key is `sg-api-` followed by 64 lowercase hexadecimal characters. The gateway accepts these keys and nothing else: a Safeguard sign-in token, an MCP key or a key made for another purpose is refused with `401 invalid_api_key`. With the OpenAI SDKs, pass the key as `api_key` (Python) or `apiKey` (Node.js) and the SDK sends the header for you.
The Console's [Workbench](/docs/console/workbench) is the one exception: it runs on your Safeguard sign-in, so you can try models without a key.
## Scope
A key created in the Console carries one scope, `inference`, and no other. It can:
* call `POST /chat/completions`;
* list models with `GET /models` and `GET /models/{id}`;
* describe itself with `GET /key`.
It cannot call any other Safeguard API. Keys made for other purposes, such as MCP keys, cannot call the inference API.
A key belongs to the person who created it and spends the workspace's credit. It cannot be limited to one organization, project, product or agent.
## Create a key
1. In the Console, open **API keys** and choose **Create key**.
2. Fill in the form:
| Field | What it does |
| --------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| **Name** | A label, such as `production backend`. Left empty, the key is called `Untitled key`. |
| **Monthly spend limit (USD, optional)** | The most this key may spend in a calendar month (UTC). Empty means no limit for the key; the workspace limit still applies. |
| **Requests per minute (optional)** | A whole number. Empty means the default of 60 requests per minute. |
The form also explains where your prompts go: when you send a request with the key, the prompt goes to the provider of the model you choose (for example OpenAI, Anthropic or Google) and is processed under that provider's terms. That choice is yours, per request. Safeguard never uses API traffic to train models, and request logs hold metadata only unless an administrator turns on prompt storage. See [Privacy and data](/docs/console/privacy-and-data).
3. Choose **Create key**, then copy the key from the **Copy your key** dialog. This is the only time the full key is shown. Clicking outside the dialog does not close it.
Safeguard stores only a SHA-256 hash of the key, plus its start (`sg-api-` and eight characters) and its last four characters, so the Console can show which key is which. Afterwards the Console shows the key masked, as its start and end: `sg-api-1a2b3c4d…9f8e`. A key created before the end was stored shows its start only.
* **Create key** is disabled until the API Platform is on for your workspace.
* Any member of the workspace can create a key, except an auditor account, whose access is read-only.
* Keys created in the Console do not expire. Revoke a key to end it.
* Times on **API keys**, such as **Created** and **Last used**, are shown in your browser's time zone. The server sends them in UTC.
## Change a key's limits
On **API keys**, choose **Edit** on a key to change its name, its monthly spend limit or its requests per minute. Leave a limit empty for no spend limit, or for the default rate limit.
The gateway reads a key's settings again at most 30 seconds after a change, so a new limit applies within 30 seconds.
| Limit | Range | When it is reached |
| ------------------- | ------------------------------------------------------------------ | ----------------------------------------------- |
| Monthly spend limit | In the Console, an amount above zero with up to two decimal places | `402 key_spend_limit_exceeded` |
| Requests per minute | 1 to 10,000 (default 60) | `429 rate_limited`, with a `Retry-After` header |
[Limits](/docs/console/limits) explains how both are counted.
## Check a key
`GET /key` describes the key that calls it:
```bash
curl https://api.safeguard.sh/gpt/v1/key \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY"
```
```json
{
"data": {
"name": "production backend",
"prefix": "sg-api-1a2b3c4d",
"scopes": ["inference"],
"monthly_spend_limit_usd": "50.0",
"rate_limit_rpm": null,
"available_credit_usd": 42.5,
"month_spent_usd": 3.25,
"month": "2026-10"
}
}
```
| Field | Meaning |
| -------------------------- | --------------------------------------------------------------------------- |
| `name`, `prefix`, `scopes` | The key's name, its visible start and its scopes. |
| `monthly_spend_limit_usd` | The key's monthly spend limit as a decimal string, or `null` for none. |
| `rate_limit_rpm` | The key's requests per minute, or `null` for the default. |
| `available_credit_usd` | The workspace's credit balance minus what requests in flight have reserved. |
| `month_spent_usd` | What this key has spent in the current month. |
| `month` | The current month in UTC, as `YYYY-MM`. |
The last three fields are left out when the billing service cannot answer at that moment; the request still succeeds.
## Revoke a key
On **API keys**, choose **Revoke** on the key and confirm. Requests that use the key are refused within 30 seconds, because the gateway remembers a key it has already checked for up to 30 seconds. A revoke cannot be undone. The key moves to the **Revoked** section of **API keys**, where it stays listed with when it was revoked and what it spent this month, so its use can still be traced.
A key also stops working when:
* its owner is deactivated in the workspace, which revokes their keys at the same time; reactivating the member does not bring the keys back;
* its owner's account is deleted, suspended or locked.
## Keep keys safe
* Keep keys on your servers. Never put one in browser code, a mobile app or a public repository: anyone holding a key can spend your workspace's credit.
* Use one key per application and environment. You can then revoke one without stopping the others, and see usage per key.
* Give every key a monthly spend limit that matches what that application should spend.
* If a key may have been exposed, revoke it and create a new one.
[Key management best practices](/docs/console/key-management-best-practices) covers storage and rotation in more detail.
## Authentication errors
| Status | `code` | Meaning |
| ------ | ------------------ | ---------------------------------------------------------------------------------------------- |
| 401 | `invalid_api_key` | The key is missing, malformed, unknown, revoked or expired, or its owner can no longer use it. |
| 403 | `gateway_disabled` | The key is valid, but the API Platform is not switched on for the workspace. |
| 503 | `auth_unavailable` | Safeguard could not check keys at that moment. Retry after a short wait. |
The 401 message reads: `Invalid, revoked or expired API key. Keys start with sg-api- and are sent as 'Authorization: Bearer '.` It never says which of the reasons applies.
# Bring your own model (/docs/console/bring-your-own-model)
Bringing your own model means calling a model through your own provider account or your own endpoint, with your own key, instead of through Safeguard's account. Your provider bills you directly, and Safeguard charges no fee.
**Version 1 is limited.** The gateway accepts your own models only from the Workbench, never with an API key. In this version the Workbench's model list shows catalog models only, so a model of your own can't be picked there yet.
## What version 1 supports
| | Your own model |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| **Where it works** | The Workbench route, for a person signed in to the Console. The API Platform must be switched on for the workspace. |
| **With an API key** | Not supported. The request is refused with `400 unsupported_parameter`. |
| **Safeguard fee** | None. The gateway records the cost as $0, and your provider bills you under your own agreement. |
| **Credit** | Not needed. Nothing is reserved or charged. |
| **Request log** | Logged like any other request, with a cost of $0. |
| **Prompt and output text** | Stored only if **Store prompts and outputs** is on, as for any request. |
| **Retries and fallbacks** | Never. A failure is returned, not sent to another model. |
| **Zero data retention** | Not applied. Your agreement with your provider decides what it keeps. |
| **Rate limit** | The Workbench's per-person limit. |
In a request, a model of your own is named `custom:` followed by its ID in your workspace.
## Add a model
A tenant admin adds the model in the web app:
1. In ESSCM, open **Integrations › Configure Scanner**, then **Models**.
2. Under **Your own models**, select **Add model**.
3. Enter a **Name** and choose the **Provider** and the **Type**: **Frontier vendor (your account)** or **Self-hosted (your endpoint)**.
4. Under **Which API does it speak?**, choose OpenAI-compatible, Anthropic Messages or Google Gemini.
5. Enter the **Model name at the vendor**, the **Endpoint URL** where needed, and the **API key**.
6. Select **Save**.
The key is kept in Safeguard's credential vault, never with the model's settings, and it is fetched only when a call is made. It is never logged.
Safeguard's servers make the call, so a self-hosted endpoint must be reachable from Safeguard.
The **Input cost** and **Output cost** fields on that form help you compare routing choices. Nothing is billed from them. **Route jobs to this model** sends work from Safeguard's own AI features, such as search and chat, to the model. It has no effect on the API Platform.
## Not supported yet
* Using your own key with a catalog model, such as calling an OpenAI model in the catalog with your OpenAI key. Catalog models always run on Safeguard's account. To use your key, add the model as your own.
* Calling your own models with an API key.
* Choosing your own model from the Workbench's model list.
## Related
* [Workbench](/docs/console/workbench)
* [Pricing and billing](/docs/console/pricing-and-billing)
* [Privacy and data](/docs/console/privacy-and-data)
* [Zero data retention](/docs/console/zero-data-retention)
# Changelog (/docs/console/changelog)
## 14 October 2026
Each item below is in early access and switched on per workspace by Safeguard; where it is off, nothing changes.
* **Routing.** Chat and completions requests can list more models in `models`, prefer, limit or exclude providers with `provider.order`, `only` and `ignore`, and sort candidates by price, latency or uptime with `provider.sort`. The `X-Route` header names the provider route that served the answer. See [Routing](/docs/console/routing).
* **Embeddings.** `POST /embeddings` for embeddings models, billed per input token at the provider's list price with no markup. The text you send is never stored. See [Embeddings](/docs/console/embeddings).
* **Completions.** `POST /completions` accepts the legacy single-prompt format for chat models. See [Completions](/docs/console/completions).
* **Console.** A **Models** page lists every model with its provider, context length, prices per 1M tokens and measured latency and uptime; the Workbench adds Chat, Compare (two or three models side by side) and a code panel. See [Workbench](/docs/console/workbench#chat-compare-and-code).
* **Your own provider keys.** Workspace administrators can add a provider key per provider; requests for that provider then run on it, billed by the provider with no Safeguard fee. The key is sealed and never shown again. See [Your own provider keys](/docs/console/provider-keys).
* **Usage statements.** **Usage** lists every month with activity and downloads each as CSV. See [Credits and invoices](/docs/console/credits-and-invoices#usage-statements).
* **Key creation explains where prompts go.** The prompt goes to the provider of the model you choose, per request, and Safeguard never uses API traffic to train models. See [Privacy and data](/docs/console/privacy-and-data).
## 9 October 2026
* **Safeguard's own lineup is three models and Zero.** Griffin, Eagle and Lion are one model each, with no Lite, S, M, L or XL variants. Griffin has 750 billion parameters and a context window of 1.1 million tokens, Eagle 70 billion and 1 million tokens, and Lion 15 billion and 128K tokens. Zero has no model weights and uses no model tokens.
* **Catalog prices for Griffin, Eagle and Lion.** Griffin is listed at $0.0001 per million input tokens and $0.0001 per million output tokens, Eagle at $0.00001 and $0.00001, and Lion at $0.000001 and $0.000001, no longer **Price on request**. Zero stays at $0. None of Safeguard's own models can be called through the API yet.
* **Where they run.** All four can run on-prem, air-gapped, in a private cloud (VPC) and in public cloud, and are available in 245 countries and territories, with the exclusions listed in [Safeguard models](/docs/console/safeguard-models#where-they-run).
## 8 October 2026, second update
* **One rule for which models can be called.** A model is `available` only when the catalog lists it as available and it passes the launch checks; otherwise it shows `request_access` or `coming_soon`. `GET /models?all=true`, the Workbench and the gateway all use the same rule. Each model now carries `runnable` and, when it cannot be called, an `unavailable_reason`. Models not published in the catalog are never listed or served.
* **`X-Generation-Id` on every chat response.** Streamed or not, the header carries the request id (`gen-…`), as does an error returned after the request was accepted. `X-Request-Id` is now only an internal id for Safeguard's audit trail. The Workbench shows each run's **Request ID**.
* **Keys by name, never by id.** Keys are shown masked, as their start and end (`sg-api-1a2b3c4d…9f8e`). **Usage** and the request log name each key by its name and masked form, Workbench runs as **Console workbench**, and a key that no longer exists as **Deleted key**. Revoked keys stay listed under **Revoked** on **API keys**.
* **Key edits are recorded as `auth.api.key.updated`**, naming only the fields that changed. A save that changes nothing records nothing.
* **Tenant admins and super admins** manage the gateway settings, card top-up and stored prompts. Safeguard's billing service enforces it, and each change is recorded in the workspace's audit trail with the role it was made under.
* **Retention is configurable but not yet enabled.** Until Safeguard sets the periods, request logs and stored prompts are kept until deleted. Managers can delete stored prompts with **Delete stored prompts**; turning storage off does not delete them.
* **The zero data retention setting is now called "Only use models whose provider offers zero data retention".** Its behaviour is unchanged: other models are refused.
* **Times are sent in UTC**, as ISO 8601 with `Z`, and the Console shows them in your browser's time zone.
## 8 October 2026
* **The inference API is deployed and switched off for early access.** It serves `POST /chat/completions` with streaming, `GET /models`, `GET /models/{id}` and `GET /key` at `https://api.safeguard.sh/gpt/v1`, in OpenAI's Chat Completions format. It stays off until Safeguard turns it on for a workspace.
* **API keys are issued by Safeguard's servers.** A key is `sg-api-` and 64 hexadecimal characters, carries only the `inference` scope, is shown once and is stored as a hash. Each key can have a monthly spend limit and a requests-per-minute limit, and a revoke takes effect within 30 seconds.
* **Prepaid credit and spend limits.** Each request reserves its maximum cost before the provider is called and is charged its actual cost afterwards, with no markup on third-party models. Requests stop at zero credit with `402`. Monthly limits apply per workspace and per key. The request log keeps metadata only, and storing prompts is opt-in. Card top-up is built and switched off; until it is on, Safeguard adds credit.
* **Launch checks for every model.** A model can be called only when the catalog lists it as available with prices and a successful end-to-end test call is recorded. For third-party providers, the provider's terms, its place on the Trust Center subprocessor list and Safeguard's legal documents are checked first.
* **One catalog for the website and the API.** [safeguard.sh/models](https://safeguard.sh/models) and the gateway read the same model catalog. Safeguard Zero is listed with no model tokens, at $0 per million tokens.
* **The Console is connected to the gateway.** Where the API Platform is on: keys are created, edited and revoked on the server; the Workbench streams through the gateway and shows each run's cost; **Usage** shows the gateway's metering, the request log, credit and the credit ledger; tenant admins manage the workspace's spend limit, prompt storage, fallbacks and zero data retention. Where it is off, **Create key** is disabled.
* **These docs moved to `/docs/console`**, with pages for every part of the API. Links to `/docs/api-platform` redirect here.
## 5 October 2026
* **The Console was added to the web app** as Safeguard's fifth product, off by default: **Dashboard**, **Search**, **Workbench**, **API keys**, **Usage** and **Settings**, opened from the product switcher or with **G** then **5**. At that stage the inference service behind it did not exist yet, so no request reached a model.
# Chat completions (/docs/console/chat-completions)
```
POST https://api.safeguard.sh/gpt/v1/chat/completions
```
The request and response follow OpenAI's Chat Completions format. Safeguard reads a few fields itself, passes a fixed set of optional fields to the provider, and ignores everything else.
Text only: a message part that is not text is refused. `n` must be `1`. Your own models (`custom:`) are refused with an API key; the gateway accepts them only from the Console Workbench, which cannot pick them yet. The API Platform is switched on per workspace by Safeguard, and while it is in early access it answers `403 gateway_disabled` where it is off.
## Request
Send JSON with `Content-Type: application/json` and your key in `Authorization: Bearer `. The body can be up to 8 MiB; a larger body is refused with `413 request_too_large`.
### Fields Safeguard reads
| Field | Type | Rules |
| ------------------------------ | ---------------- | --------------------------------------------------------------------------------- |
| `model` | string, required | A model id from [`GET /models`](/docs/console/models). |
| `messages` | array, required | 1 to 2,000 messages. See [Messages](#messages). |
| `max_completion_tokens` | integer | 1 to 1,000,000. If both are sent, `max_completion_tokens` wins over `max_tokens`. |
| `max_tokens` | integer | 1 to 1,000,000. |
| `temperature` | number | 0 to 2. |
| `top_p` | number | 0 to 1. |
| `stop` | string or array | A string, or up to four strings. |
| `stream` | boolean | `true` returns server-sent events. See [Streaming](/docs/console/streaming). |
| `stream_options.include_usage` | boolean | With `stream: true`, adds a final chunk carrying `usage`. |
| `n` | integer | Only `1`. Any other value is refused with `400 unsupported_parameter`. |
| `user` | string | Accepted and dropped. It is never sent to the provider. |
| `provider` | object | Safeguard's routing options. See [Routing options](#routing-options). |
The output token cap sent to the provider is the value you set, lowered to the model's `max_output_tokens` when the catalog states one. If you set none, the cap is 4,096 tokens or the model's maximum, whichever is lower.
### Fields passed to the provider
These are forwarded unchanged when present. The gateway does not check their values; the provider does.
| Field | Notes |
| --------------------------------------- | -------------------------------------------------------------------- |
| `tools`, `tool_choice` | Function calling. Whether a model supports tools is up to the model. |
| `parallel_tool_calls` | |
| `response_format` | JSON mode or structured output, where the model supports it. |
| `seed` | |
| `presence_penalty`, `frequency_penalty` | |
For Anthropic models, only `temperature`, `tools` and `tool_choice` from the two tables are sent with the messages and the token cap; `top_p`, `stop`, `response_format`, `seed`, the penalties and `parallel_tool_calls` are not. When you set no `temperature`, the provider's own default applies.
Any field not listed on this page is ignored and not forwarded.
### Messages
Each message is an object with a `role` and, usually, `content`.
* `role` is one of `system`, `developer`, `user`, `assistant` or `tool`. The gateway accepts all five; whether a model accepts `developer` or `tool` messages is up to its provider.
* `content` is a string, `null`, or an array of text parts such as `{"type": "text", "text": "..."}`. A part of any other type, such as an image or audio, is refused with `400 unsupported_parameter`.
* `name`, `tool_calls` and `tool_call_id` are kept. Other keys on a message are dropped.
### Routing options
`provider` is a Safeguard extension:
```json
"provider": { "allow_fallbacks": true, "zdr": true }
```
| Field | Meaning |
| ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `allow_fallbacks` | `true` lets the gateway retry once and then try a listed fallback model of the same family when the provider fails. `false` turns that off. When absent, the workspace setting applies, and it is off unless a tenant admin or super admin turns it on. See [Reliability and fallbacks](/docs/console/reliability-and-fallbacks). |
| `zdr` | `true` routes only to models offered with zero data retention. When the workspace requires zero data retention, every request is routed that way and a request cannot turn it off. See [Zero data retention](/docs/console/zero-data-retention). |
Fallbacks never leave the model family, and never go to the models Safeguard uses for its own platform features.
Where [routing](/docs/console/routing) is switched on for your workspace, `provider` also takes `order`, `only`, `ignore` and `sort`, and the request can list more models in `models`. Where it is not, those fields are refused with `400 unsupported_parameter`.
### When a provider rejects a parameter
Providers do not all accept the same parameters. If a provider rejects the token limit's name, the gateway switches between `max_tokens` and `max_completion_tokens` and sends the request again. If it rejects another optional parameter as unsupported for the model, such as a `temperature` the model does not allow, the gateway drops that parameter and sends the request again. These repeats go to the same provider and are not fallbacks.
## Examples
### A basic request
curl
Python
Node.js
```bash
curl https://api.safeguard.sh/gpt/v1/chat/completions \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "MODEL_ID",
"messages": [
{"role": "system", "content": "Answer in one short paragraph."},
{"role": "user", "content": "What does reachability analysis add to a vulnerability scan?"}
],
"max_completion_tokens": 300,
"temperature": 0.2
}'
```
```python
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
response = client.chat.completions.create(
model="MODEL_ID",
messages=[
{"role": "system", "content": "Answer in one short paragraph."},
{"role": "user", "content": "What does reachability analysis add to a vulnerability scan?"},
],
max_completion_tokens=300,
temperature=0.2,
)
print(response.choices[0].message.content)
```
```js
import OpenAI from 'openai';
const client = new OpenAI({
baseURL: 'https://api.safeguard.sh/gpt/v1',
apiKey: process.env.SAFEGUARD_INFERENCE_KEY,
});
const response = await client.chat.completions.create({
model: 'MODEL_ID',
messages: [
{ role: 'system', content: 'Answer in one short paragraph.' },
{ role: 'user', content: 'What does reachability analysis add to a vulnerability scan?' },
],
max_completion_tokens: 300,
temperature: 0.2,
});
console.log(response.choices[0].message.content);
```
### Calling a tool
The gateway passes `tools` and `tool_choice` to the provider and returns the provider's `tool_calls` in the message.
curl
Python
```bash
curl https://api.safeguard.sh/gpt/v1/chat/completions \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "MODEL_ID",
"messages": [{"role": "user", "content": "Is lodash 4.17.20 affected by a known vulnerability?"}],
"tools": [{
"type": "function",
"function": {
"name": "lookup_package",
"description": "Look up known vulnerabilities for a package version.",
"parameters": {
"type": "object",
"properties": {
"ecosystem": {"type": "string"},
"name": {"type": "string"},
"version": {"type": "string"}
},
"required": ["ecosystem", "name", "version"]
}
}
}],
"tool_choice": "auto"
}'
```
```python
import json
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
tools = [{
"type": "function",
"function": {
"name": "lookup_package",
"description": "Look up known vulnerabilities for a package version.",
"parameters": {
"type": "object",
"properties": {
"ecosystem": {"type": "string"},
"name": {"type": "string"},
"version": {"type": "string"},
},
"required": ["ecosystem", "name", "version"],
},
},
}]
response = client.chat.completions.create(
model="MODEL_ID",
messages=[{"role": "user", "content": "Is lodash 4.17.20 affected by a known vulnerability?"}],
tools=tools,
tool_choice="auto",
)
message = response.choices[0].message
for call in message.tool_calls or []:
print(call.function.name, json.loads(call.function.arguments))
```
To continue the conversation, send the assistant message with its `tool_calls`, then a `tool` message with the matching `tool_call_id` and your function's result as `content`.
### Requiring zero data retention and allowing fallbacks
`provider` is not an OpenAI parameter, so the OpenAI SDKs send it through `extra_body` (Python) or as an extra field (Node.js).
curl
Python
Node.js
```bash
curl https://api.safeguard.sh/gpt/v1/chat/completions \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "MODEL_ID",
"messages": [{"role": "user", "content": "Summarise this incident report in three bullet points: ..."}],
"provider": {"zdr": true, "allow_fallbacks": true}
}'
```
```python
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
response = client.chat.completions.create(
model="MODEL_ID",
messages=[{"role": "user", "content": "Summarise this incident report in three bullet points: ..."}],
extra_body={"provider": {"zdr": True, "allow_fallbacks": True}},
)
print(response.model, response.choices[0].message.content)
```
```js
import OpenAI from 'openai';
const client = new OpenAI({
baseURL: 'https://api.safeguard.sh/gpt/v1',
apiKey: process.env.SAFEGUARD_INFERENCE_KEY,
});
const response = await client.chat.completions.create({
model: 'MODEL_ID',
messages: [{ role: 'user', content: 'Summarise this incident report in three bullet points: ...' }],
provider: { zdr: true, allow_fallbacks: true },
});
console.log(response.model, response.choices[0].message.content);
```
## Response
```json
{
"id": "gen-6f1c2e0a9b4d4c7e8a1f3b5d7c9e0a2b",
"object": "chat.completion",
"created": 1791475000,
"model": "MODEL_ID",
"provider": "openai",
"choices": [
{
"index": 0,
"message": { "role": "assistant", "content": "Reachability analysis checks whether ..." },
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 41,
"completion_tokens": 120,
"total_tokens": 161,
"cost": 0.000521
}
}
```
The values above are illustrative.
| Field | Meaning |
| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `id` | The request id: `gen-` and 32 hexadecimal characters. Safeguard logs the request under it, and the `X-Generation-Id` response header carries the same id. |
| `object` | `chat.completion`. |
| `created` | Unix time in seconds. |
| `model` | The model that answered. When a fallback answered, this is the fallback's id. |
| `provider` | The route that served the request, such as `openai`. See [Models](/docs/console/models#provider-routes). |
| `choices` | One choice. `message` holds `role` (`assistant`), `content`, and any other field the provider returned with a value, such as `tool_calls`. `finish_reason` is the provider's, such as `stop`, `length` or `tool_calls`. |
| `usage.prompt_tokens`, `usage.completion_tokens`, `usage.total_tokens` | Token counts as the provider reported them. |
| `usage.cost` | What the request cost in US dollars, as a JSON number. |
| `usage.prompt_tokens_details.cached_tokens` | Present when the provider reported cached input tokens. |
| `usage.estimated` | `true` when the provider reported no usage, so the gateway counted the tokens itself. Absent otherwise. |
## Cost
For each request the gateway works out:
`cost = (input tokens × input price + output tokens × output price) ÷ 1,000,000`
with prices in US dollars per million tokens from the catalog, and no markup. When the catalog has a cached-input price, cached input tokens are charged at that price instead of the input price. The result is rounded half up to 8 decimal places.
Before calling the provider, the gateway reserves the most the request could cost and refuses it with `402` if that does not fit your credit or a spend limit. After the call, it charges the actual cost and releases the rest. A request that ends in an error before any output costs nothing. See [Limits](/docs/console/limits) and [Pricing and billing](/docs/console/pricing-and-billing).
## Errors
Errors use OpenAI's shape, `{"error": {"message", "type", "code", "param"}}`. [Errors](/docs/console/errors) lists every status and code.
## Related
* [Streaming](/docs/console/streaming)
* [Models](/docs/console/models)
* [Errors](/docs/console/errors)
* [Limits](/docs/console/limits)
# Choosing a model (/docs/console/choosing-a-model)
The catalog at [safeguard.sh/models](https://safeguard.sh/models) lists every model Safeguard knows, with its prices, context window and data policy. Through the API you can call the models that `GET /models` returns; the catalog shows the wider set. Start from what your application needs, then narrow the list.
## Price
* The catalog shows each model's price per million input tokens and per million output tokens. For third-party models it is the provider's list price, and Safeguard adds no markup.
* `GET /models` returns the same prices in `pricing`, as decimal strings.
* Output tokens usually cost more than input tokens, so a task that writes long answers is priced mostly by its output price.
* A model shown as **Price on request** has no per-token price in the catalog and cannot be called through the API.
* Safeguard's own models are listed per million input and per million output tokens: Griffin at $0.0001 and $0.0001, Eagle at $0.00001 and $0.00001, Lion at $0.000001 and $0.000001, and Zero at $0, because it uses no model tokens. None of them can be called through the API yet.
* To compare models side by side, use the compare view at [safeguard.sh/models/compare](https://safeguard.sh/models/compare).
Every response tells you what it cost in `usage.cost`, so you can measure a model on your own prompts. See [Pricing and billing](/docs/console/pricing-and-billing).
## Context and output length
* `context_length` is how many tokens of input and conversation the model can take.
* `max_output_tokens` is the most it can write in one answer. The gateway caps your `max_tokens` at this value.
* A longer context costs more per request, because every input token is billed. Send what the task needs.
## Where it runs and where your data goes
Each model's page in the catalog has a data policy: where prompts go, the provider's retention terms, whether zero data retention is offered, and the provider's region terms. Read it before you send sensitive data.
* **Third-party models** run on their provider's infrastructure. Your prompts go to that provider.
* **Open-weight models** are served by whichever inference host runs the weights; their data policy says what that means for your prompts.
* **Safeguard's own models** are served through the API only by Safeguard-hosted inference, so your prompts go to Safeguard, on its own infrastructure. On the Safeguard platform they can also run on-prem, air-gapped, in a private cloud (VPC) or in public cloud. They are not callable through the API yet; see [Safeguard models](/docs/console/safeguard-models#where-they-run).
## Country and region
The catalog's data policy states each provider's region terms as the provider publishes them, such as a global default or optional regional endpoints. The gateway calls each provider's standard API endpoint, and it does not choose a region for you per request. If where data is processed matters for you, choose a model whose provider terms fit, and read [Regions and data residency](/docs/console/regions-and-data-residency).
## Security and data handling
* **Zero data retention.** `zdr_available: true` means the model can be used with zero data retention. Ask for it per request with `provider.zdr`, or have a tenant admin or super admin require it for the workspace. See [Zero data retention](/docs/console/zero-data-retention).
* **Open weights.** The catalog marks open-weight models, whose weights you could also run yourself.
* **Prompt storage.** Whatever model you choose, Safeguard's request log keeps metadata only unless a tenant admin or super admin turns on prompt storage. See [Privacy and data](/docs/console/privacy-and-data).
## Quality and speed
Rankings and benchmark pages for the catalog are coming soon. Until then, the most reliable test is your own: run the same prompts through two or three candidates in the Console [Workbench](/docs/console/workbench), which shows tokens, cost, latency and time to first token for each run.
## A short method
1. List what the task needs: input size, answer length, data sensitivity, region.
2. Filter the catalog by those, then by price.
3. Try the shortlist in the Workbench with real prompts.
4. Check `GET /models` to confirm the model can be called through the API. With `?all=true`, a model you cannot call yet says why in `unavailable_reason`.
5. Set `max_tokens` and a key spend limit that match the task.
# Completions (/docs/console/completions)
```
POST https://api.safeguard.sh/gpt/v1/completions
```
The completions endpoint is switched on per workspace by Safeguard, in addition to the API Platform itself. Where it is off, it answers `403 gateway_disabled`. New code should use [chat completions](/docs/console/chat-completions).
Some older tools only speak OpenAI's legacy Completions format. The gateway accepts it for chat models: your `prompt` becomes one user message, and the request then runs exactly like a chat completion (the same models, routing, billing, limits and request log).
## Request
| Field | Type | Rules |
| ----------------------------------------------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------- |
| `model` | string, required | A chat model id from [`GET /models`](/docs/console/models). An embeddings model is refused with `400 invalid_request`. |
| `prompt` | string, required | One string. An array of prompts or a token array is refused with `400 unsupported_parameter`. |
| `max_tokens` | integer | As for chat. |
| `temperature`, `top_p`, `stop` | | As for chat. |
| `stream`, `stream_options` | | As for chat. See [Streaming](/docs/console/streaming). |
| `seed`, `presence_penalty`, `frequency_penalty` | | Passed to the provider. |
| `models`, `provider` | | [Routing](/docs/console/routing) and the routing options, as for chat. |
| `user` | string | Accepted and dropped. |
Refused with `400 unsupported_parameter`: `suffix`, `echo`, `logprobs`, `best_of`, and `n` other than `1`.
## Response
```json
{
"id": "gen-…",
"object": "text_completion",
"created": 1760457600,
"model": "openai/gpt-6-sol",
"provider": "openai",
"choices": [{ "text": "An SBOM lists every component in a piece of software.", "index": 0, "finish_reason": "stop", "logprobs": null }],
"usage": { "prompt_tokens": 12, "completion_tokens": 13, "total_tokens": 25, "cost": 0.000154 }
}
```
Streamed chunks have the same `object` and carry the new text in `choices[0].text`, then `data: [DONE]`.
## Example
curl
Python
```bash
curl https://api.safeguard.sh/gpt/v1/completions \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "openai/gpt-6-sol", "prompt": "Define SBOM in one sentence.", "max_tokens": 60}'
```
```python
from openai import OpenAI
import os
client = OpenAI(base_url="https://api.safeguard.sh/gpt/v1", api_key=os.environ["SAFEGUARD_INFERENCE_KEY"])
resp = client.completions.create(model="openai/gpt-6-sol", prompt="Define SBOM in one sentence.", max_tokens=60)
print(resp.choices[0].text)
```
# Console guide (/docs/console/console-guide)
The Console is the API Platform's part of the Safeguard web app. It appears when Safeguard turns the API Platform on for your workspace.
## Open the Console
* Open the product switcher and choose **API Platform (Console)**, or
* press **G**, then **5**.
The sidebar has **Dashboard**, **Search**, **Workbench**, **API keys**, **Usage** and **Settings**.
## The connection notice
When your workspace is set up for the API Platform but the gateway does not serve it yet, the Dashboard, Workbench, API keys and Usage pages show a notice, **The inference gateway is not connected for this workspace yet.**, with the reason underneath:
* **The inference API is not switched on for this deployment.** The gateway is off for the whole Safeguard deployment, as it is during early access.
* **The inference API is not enabled for this account.** It is off for your workspace.
When the gateway serves your workspace, the notice does not appear.
## Dashboard
Your activity over the last 14 days, counted in UTC days.
| Item | Shows |
| ----------------------------------- | --------------------------------------------------------- |
| **Requests** | Requests in the period, with the amount spent underneath. |
| **Input tokens**, **Output tokens** | Tokens in the period. |
| **Active API keys** | Your keys that are not revoked. |
| **Requests per day** | A bar chart, one bar per day. |
**API keys** and **Open workbench** at the top take you to those pages. With no activity yet, the chart says so and suggests creating a key or trying a prompt.
## Search
The same Griffin AI search as in the other Safeguard products, so you can ask about your workspace without leaving the Console.
## Workbench
Try a model without writing code: choose a model, write a system prompt and a prompt, set **Max tokens** and **Temperature**, and select **Run**. The answer streams in with its tokens, cost, latency and time to first token. Runs spend the workspace's credit. See [Workbench](/docs/console/workbench).
## API keys
The keys you own. Under **Active**:
| Column | Shows |
| -------------- | ------------------------------------------------------------------------------------------------------------------------- |
| **Name** | The key's name. |
| **Key** | The key masked as its start and end, such as `sg-api-1a2b3c4d…9f8e`. The full key is shown only once, when you create it. |
| **Created** | When the key was created. |
| **Rate limit** | `Default`, or the key's own limit, such as `120/min`. |
| **Last used** | When the key last made a request, updated at most once a minute. |
| **This month** | What the key spent this month against its monthly limit, with a bar that turns red at 90%. |
| **Status** | `Active`, or `Expired` for a key created elsewhere with an expiry date that has passed. |
Revoked keys are listed below, under **Revoked**, with their name, masked key, when they were created and revoked, and what they spent this month. They cannot be used again; they stay listed so their use can be traced.
* **Create key** opens the form: name, monthly spend limit and requests per minute. The next screen shows the key once.
* **Edit** changes the name and the two limits.
* **Revoke** ends a key after you confirm. Requests with it are refused within 30 seconds, and the key moves to **Revoked**.
Until the API Platform is on for your workspace, **Create key** is disabled.
See [Authentication](/docs/console/authentication).
## Usage
What the gateway metered, by UTC day, for the period you choose: **Last 7 days**, **Last 14 days**, **Last 30 days** (the default) or **Last 90 days**.
* **Requests**, **Input tokens**, **Output tokens** and **Cost** for the period.
* **By model** and **By key**: requests, input and output tokens and cost for each. A key is shown by its name and masked form, Workbench runs as **Console workbench**, and a key that no longer exists as **Deleted key**. The Console never shows a key's numeric id.
* **Request log**: the newest requests first, with **Time**, **Model**, **Key** (named the same way as in **By key**), **Input**, **Output**, **Cost**, **Latency** and **Status**. A failed request shows its error code as its status. Output marked `est.` was billed on an estimate because the provider sent no usage. **Load older requests** pages back through the whole log. The log holds metadata only; prompts and outputs are never shown here.
* **Credits and limits**: **Balance**, **Reserved** (held for requests in flight), **Available**, and **Spent this month** against the workspace's monthly limit.
* **Gateway settings**: the workspace's monthly spend limit, **Store prompts and outputs**, **Allow retries and fallbacks** and **Only use models whose provider offers zero data retention**. Tenant admins and super admins can change them; everyone else sees them read-only, with the note "A tenant administrator can change these."
* **Stored prompts** and **Delete stored prompts**: how many prompts are stored, and, for tenant admins and super admins, a button that deletes them all after you confirm.
* **Retention**: how long request logs and stored prompts are kept. Until Safeguard sets a period, both read "kept until deleted (no retention period is set yet)".
* **Credit ledger**: every credit movement, with time, entry type, amount, balance after and note. **Load older entries** pages back.
* **Add credit** appears for tenant admins and super admins when card top-up is available. Otherwise the page says that card top-up is not available yet and to contact Safeguard to add credit.
See [Usage and analytics](/docs/console/usage-and-analytics) and [Credits and invoices](/docs/console/credits-and-invoices).
Times on these pages are shown in your browser's time zone. The server sends them in UTC.
## Settings
The same workspace settings as in the other Safeguard products, such as members, organizations, notifications and appearance, as your role and your workspace's features allow.
## Before the API Platform is on
If the Console is visible but the API Platform is not on for your workspace yet:
* **Create key** is disabled;
* **Run** in the Workbench answers that the inference endpoint is not connected yet, and no request reaches a model;
* **Dashboard** and **Usage** have no metering from the gateway to show.
# Inference API or MCP server (/docs/console/console-vs-mcp)
Safeguard offers two ways for AI to work with it, and they solve different problems.
* The **inference API** is for your own applications: you send prompts to a model you choose, and you pay per token.
* The **[MCP server](/docs/mcp)** is for AI assistants such as Claude, ChatGPT or Cursor: it gives them Safeguard's tools, so they can read and act on your security and compliance data, while the assistant's own model does the thinking.
## Side by side
| | Inference API | MCP server |
| ---------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------- |
| What it does | Runs a model you name on the prompts you send | Lets an assistant call Safeguard's tools: findings, SBOMs, packages, compliance and more |
| Who runs the model | The provider of the model you choose, through Safeguard | Your assistant's own provider |
| Address | `https://api.safeguard.sh/gpt/v1` | `mcp.safeguard.sh` |
| Credentials | An `sg-api-` key with the `inference` scope | OAuth from your assistant, or an MCP key. See [MCP](/docs/mcp#authentication). |
| What you pay Safeguard | Tokens, from prepaid credit, at the provider's list price with no markup | Nothing per call. MCP tool calls are unlimited on every plan, Free included, and never metered. |
| Data | Your prompts go to the provider of the model you choose | Tool calls read your Safeguard workspace with the signed-in person's permissions |
| Status | Early access, switched on per workspace by Safeguard | Available. Tools are enabled per workspace; see [Tool availability](/docs/mcp/tool-gating). |
## Choose the inference API when
* you are building a feature in your own product that needs a model to write, summarise or classify text;
* you want one key and one bill for models from several providers;
* you need a hard spend limit, per-request cost and a request log for that traffic.
## Choose the MCP server when
* you want an assistant your team already uses to answer questions about your Safeguard data, such as "which reachable critical vulnerabilities are open in payments-service?";
* you want an agent to act in Safeguard, within the permissions of the person or key it runs as;
* you want no metering: the assistant's provider bills its own tokens, and Safeguard does not charge per tool call.
## Using both
They are independent. An inference key cannot sign in to the MCP server, and an MCP key cannot call the inference API, so each key keeps to its own job. An application can use the inference API for its model calls while the people building it use the MCP server in their assistant.
## Related
* [MCP integrations](/docs/mcp)
* [Agents and LLMs](/docs/agents)
* [Quickstart](/docs/console/quickstart)
# Credits and invoices (/docs/console/credits-and-invoices)
The inference API is prepaid. Your workspace holds a balance in US dollars, and each request is charged to it when it finishes, at the model's list price with no markup. When the credit runs out, requests are refused until credit is added.
**Early access.** The inference gateway is deployed but switched off, and Safeguard switches it on per workspace. Card top-up is not switched on yet, so for now Safeguard adds credit for you.
## Where to see your credit
Open **Usage** and scroll to **Credits and limits**. When a Console error offers **Add credit** or **Open limits**, the button leads here.
| Figure | What it means |
| -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Balance** | Your credit after every charge so far. |
| **Reserved** | Credit held for requests in flight. |
| **Available** | Balance minus Reserved. New requests draw on this. |
| **Spent this month** | What requests have cost in the current UTC month, which is shown next to the label. Under it: your workspace's monthly limit and the share used, or **No monthly limit**. |
## How a request is charged
1. **Hold.** Before the provider is called, the gateway holds the most the request could cost. That is a deliberately high estimate of the input, plus every output token the request allows, at the price of the most expensive model it might use. If the hold does not fit, the request is refused with a 402 and nothing is charged. See [Spend controls](/docs/console/spend-controls).
2. **Charge.** When the answer is complete, the hold is released and the actual cost is charged: the provider's token counts times the model's list price. The ledger gets a **Usage** entry.
3. **No answer, no charge.** A request that reaches a provider but fails before the provider produces anything costs $0, and appears in the request log with its error code. A request the gateway refuses before calling a provider costs nothing and is not logged.
Costs are worked out to 8 decimal places, so a request that costs a fraction of a cent is charged exactly that.
A hold that is never settled, for example because a request was cut off inside Safeguard, is released after about 30 minutes.
Rarely, a provider reports more input tokens than the gateway estimated. Those tokens were used, so they are charged, and the balance can dip below zero. New requests are then refused until credit is added.
## The credit ledger
**Credit ledger** lists every change to the balance, newest first. **Load older entries** pages back through all of them. Entries are only ever added, never edited.
| Column | What it shows |
| ----------------- | -------------------------------------------------------------- |
| **Time** | When the entry was recorded. |
| **Entry** | **Grant**, **Topup** or **Usage**. |
| **Amount** | Positive for credit added, negative for a charge. |
| **Balance after** | The balance once the entry applied. |
| **Note** | The reason for a grant, or **Card top-up** for a card payment. |
| Entry | What it is |
| --------- | ----------------------------------------------------------------- |
| **Grant** | Credit Safeguard added to your workspace. |
| **Topup** | Credit a tenant admin or super admin bought by card. |
| **Usage** | One request's charge. A request that cost $0 has no ledger entry. |
## Credit granted by Safeguard
While card top-up is off, Safeguard adds credit for you. Contact [hi@safeguard.sh](mailto:hi@safeguard.sh) to arrange it. Each grant shows in your ledger as a **Grant**, with the reason Safeguard recorded in the **Note** column. Safeguard also records which of its staff made the grant.
## Card top-up
Card top-up through Stripe is built, but switched off. Once Safeguard switches it on, a tenant admin or super admin buys credit like this:
1. Open **Usage**, go to **Credits and limits** and select **Add credit**. Everyone else sees "A tenant administrator can add credit." instead of the button.
2. Enter **Credit to add (USD)** and select **Continue to payment**. If the amount is outside the range Safeguard allows, the Console says what the range is.
3. Pay on Stripe's checkout page. For $25 of credit, the line item reads **Safeguard API credit ($25.00, includes $1.06 card processing)**.
4. The credit appears in the ledger as **Topup** once Stripe confirms the payment. Each payment is credited once.
If you leave Stripe's page without paying, nothing is charged and nothing is credited.
### Card fees
You pay the card processing fee at cost: 2.9% of the charge plus $0.30. It is added on top, so the credit you receive is exactly the amount you entered. Safeguard keeps no margin on the fee and does not absorb it either.
The charge is the credit plus $0.30, divided by 0.971 (which is 1 minus 2.9%), rounded up to the next cent. For example, $25.00 of credit is charged $26.06, of which $1.06 is the card fee.
## Invoices and usage statements
The Console does not issue invoices for inference credit. A card top-up is a one-time payment on Stripe's checkout page, and Stripe emails its own receipt for it. Your record is the credit ledger: every grant, top-up and charge, each with the balance after it. For anything else about billing, contact [hi@safeguard.sh](mailto:hi@safeguard.sh).
### Usage statements
Where Safeguard has switched on statements for your workspace, **Usage** lists every month with activity, newest first: requests, input and output tokens, usage cost, top-ups, grants and adjustments. Any member can download a month as CSV:
* one line per day, model, provider route, key and whether the request ran on your own provider key, with requests, tokens and cost;
* then the month's top-ups, grants and adjustments from the ledger.
A statement is a record of usage, not a tax invoice. Text cells that start with `=`, `+`, `-` or `@` are prefixed with `'` so a spreadsheet does not run them as formulas.
## What managers and other members see
Everyone who can open the Console sees the same figures and the same ledger. Only the workspace's tenant admins and super admins can change the gateway settings, buy credit or delete stored prompts.
| | Tenant admins and super admins | Other members |
| -------------------------------------------------------------------------------------------------------------------- | ------------------------------ | --------------------------------------------------------------------- |
| Balance, reserved, available and month spend | See | See |
| Credit ledger | See | See |
| **Gateway settings**: the workspace monthly spend limit, storing prompts, retries and fallbacks, zero data retention | See and change | See only. The Console says "A tenant administrator can change these." |
| **Add credit** by card, when top-up is on | Yes | No |
Safeguard's billing service makes these checks itself, so they do not depend on the Console's screens, and it records each change in the workspace's audit trail. See [Team and access](/docs/console/team-and-access).
## Related
* [Pricing and billing](/docs/console/pricing-and-billing)
* [Spend controls](/docs/console/spend-controls)
* [Usage and analytics](/docs/console/usage-and-analytics)
* [Team and access](/docs/console/team-and-access)
# Deployment options (/docs/console/deployment-options)
**Early access.** The API Platform is deployed in Safeguard's hosted service but switched off by default. Safeguard switches it on per workspace.
| Option | What it involves | Maturity |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ |
| **Safeguard API (hosted)** | Safeguard runs the gateway. Your code calls `https://api.safeguard.sh/gpt/v1` with an API key from any OpenAI-compatible client, and each request goes to the provider of the model you choose. There is nothing to install or operate. | Early access |
| **Public cloud** | Safeguard deployed on the public cloud you choose. The platform is cloud-agnostic, so it isn't tied to one provider. | GA |
| **Private cloud (VPC)** | A single-tenant deployment in a private network, isolated for one customer. For Enterprise. | GA |
| **On-prem** | The full platform in your own datacenter. | GA |
| **Air-gapped** | The complete platform with no outbound connection, including Safeguard's own models. Updates arrive as signed offline bundles. | GA |
The GA labels describe running the Safeguard platform in that environment. The API Platform itself is in early access in every option, switched off until Safeguard turns it on. For any deployment other than the hosted API, ask Safeguard to scope the API Platform with you.
Buying through your cloud provider's marketplace is not available yet for the API Platform. See [Procurement](/docs/console/procurement).
## Which models can run where
**On the Safeguard platform**, Safeguard's own models (Griffin, Eagle, Lion and Zero) and open-weight models can run inside your own environment: in a public or private cloud, on-prem or air-gapped.
Safeguard's own models are available in 245 countries and territories (the ISO 3166-1 list minus the exclusions). They are not offered in Cuba, Iran, North Korea or Syria, nor in the Crimea region of Ukraine or the so-called Donetsk People's Republic (DNR) and Luhansk People's Republic (LNR) regions of Ukraine. See [Safeguard models](/docs/console/safeguard-models#where-they-run).
**Through the API Platform**, in this version:
* every catalog model is served by its provider, or by the host the catalog names for an open-weight model, over the internet;
* Safeguard's own models cannot be called yet, in any option. See [Safeguard models](/docs/console/safeguard-models).
**Closed models**, such as those from OpenAI, Anthropic, Google and xAI, run only on their providers' infrastructure. They are never installed on-prem or in an air-gapped environment, so using one always means sending the request to its provider's API.
So in an air-gapped deployment the API Platform has no model it can serve yet.
## The hosted API
* An OpenAI-compatible API at `https://api.safeguard.sh/gpt/v1`: `POST /chat/completions`, `GET /models`, `GET /models/{id}` and `GET /key`.
* Requests are authenticated with an `sg-api-` key. See [Security and compliance](/docs/console/security-and-compliance).
* Usage is billed at the provider's list price, with no markup, from prepaid credit. See [Pricing and billing](/docs/console/pricing-and-billing).
* Your prompts go to the provider of the model you choose. See [Privacy and data](/docs/console/privacy-and-data) and [Regions and data residency](/docs/console/regions-and-data-residency).
## Getting a dedicated or self-hosted deployment
For committed volume or a dedicated deployment, email [hi@safeguard.sh](mailto:hi@safeguard.sh), and see [Procurement](/docs/console/procurement).
## Related
* [Regions and data residency](/docs/console/regions-and-data-residency)
* [Procurement](/docs/console/procurement)
* [Security and compliance](/docs/console/security-and-compliance)
# Embeddings (/docs/console/embeddings)
```
POST https://api.safeguard.sh/gpt/v1/embeddings
```
Embeddings are switched on per workspace by Safeguard, in addition to the API Platform itself. Where they are off, the endpoint answers `403 gateway_disabled`.
The request and response follow OpenAI's Embeddings format, so the OpenAI SDKs work with only the base URL changed.
## Request
| Field | Type | Rules |
| ----------------- | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `model` | string, required | An embeddings model id from [`GET /models`](/docs/console/models), such as `openai/text-embedding-3-small`. A chat model is refused with `400 invalid_request`. |
| `input` | string or array of strings, required | 1 to 256 non-empty strings. Token arrays are refused with `400 unsupported_parameter`. |
| `encoding_format` | `float` or `base64` | Passed to the provider. |
| `dimensions` | positive integer | Passed to the provider, for models that can shorten their vectors. |
| `user` | string | Accepted and dropped. It is never sent to the provider. |
`models` and the `provider` routing fields are refused with `400 unsupported_parameter`: an embeddings request uses exactly the model you name, because vectors from different models cannot be compared. There are no fallbacks for embeddings.
Anthropic offers no embeddings models through its API, so no `anthropic/` model appears here.
## Response
```json
{
"object": "list",
"data": [{ "object": "embedding", "index": 0, "embedding": [0.0123, -0.0456] }],
"model": "openai/text-embedding-3-small",
"usage": { "prompt_tokens": 8, "total_tokens": 8, "cost": 0.00000016 }
}
```
* `usage.cost` is in USD: the input tokens times the model's input price per 1M tokens, the provider's list price with no markup. Embeddings have no output tokens.
* If the provider reports no token count, the gateway bills an estimate and adds `usage.estimated: true`.
* The `X-Generation-Id` header is the id to quote to support, as for chat.
## Billing and privacy
An embeddings request reserves its estimated cost from your credit before the call and settles the actual cost after it, like a chat request. Spend limits and per-key rate limits apply in the same way.
The request log holds metadata only (model, tokens, cost, latency, status). The text you send for embeddings is never stored, even when the workspace stores prompts for chat.
## Example
curl
Python
Node.js
```bash
curl https://api.safeguard.sh/gpt/v1/embeddings \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "openai/text-embedding-3-small", "input": ["software bill of materials", "SBOM"]}'
```
```python
from openai import OpenAI
import os
client = OpenAI(base_url="https://api.safeguard.sh/gpt/v1", api_key=os.environ["SAFEGUARD_INFERENCE_KEY"])
resp = client.embeddings.create(model="openai/text-embedding-3-small", input=["software bill of materials", "SBOM"])
print(len(resp.data[0].embedding), resp.usage)
```
```js
import OpenAI from "openai";
const client = new OpenAI({ baseURL: "https://api.safeguard.sh/gpt/v1", apiKey: process.env.SAFEGUARD_INFERENCE_KEY });
const resp = await client.embeddings.create({ model: "openai/text-embedding-3-small", input: ["software bill of materials", "SBOM"] });
console.log(resp.data[0].embedding.length, resp.usage);
```
# Errors (/docs/console/errors)
## The error body
Errors from the inference API use OpenAI's shape:
```json
{
"error": {
"message": "Not enough credit for this request. Add credit in the Console, or lower max_tokens.",
"type": "insufficient_quota",
"code": "insufficient_credit",
"param": null
}
}
```
* `code` is the field to branch on. It is stable; the `message` wording may change.
* `type` follows the status: `invalid_request_error` for 400, 404 and 413, `authentication_error` for 401, `insufficient_quota` for 402, `permission_error` for 403, `rate_limit_error` for 429, and `api_error` for 5xx.
* `param` names the offending field when there is one, such as `model` or `messages[0].content`.
* Messages are written by Safeguard. A provider's own error text is never copied into them; a provider failure is described by its HTTP status only.
* An error returned after the gateway accepted the request and called a provider also carries an `X-Generation-Id` header with the request's id (`gen-…`), because the request is in the request log. A refusal before that, such as a 401, 402 or 429 `rate_limited`, has no request id. `X-Request-Id` is a different, internal id for Safeguard's audit trail.
The OpenAI SDKs turn these into their usual exceptions, with the status code and this body.
## Every status and code
| Status | `code` | When | Retry? |
| ------ | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| 400 | `invalid_request` | The body is not valid JSON or not an object, or a field is missing or out of range, such as an unknown `role`, `temperature` above 2 or more than 2,000 messages. Also a `custom:` model that cannot be used. | No. Fix the request. |
| 400 | `unsupported_parameter` | A message part that is not text, `n` other than `1`, or a `custom:` model sent with an API key. Also a [routing](/docs/console/routing) field (`models`, `provider.order`, `only`, `ignore`, `sort`) where routing is not switched on, or on an embeddings request; and the [completions](/docs/console/completions) fields that are not supported. `param` names the field. | No. |
| 400 | `upstream_rejected` | The provider refused the request: it answered 400, 404, 413 or 422. | No. Change the request. |
| 401 | `invalid_api_key` | The key is missing, malformed, unknown, revoked or expired, or its owner can no longer use it. | No. |
| 402 | `insufficient_credit` | The workspace's available credit does not cover the most this request could cost, or the balance is at or below zero. | After credit is added, or with a lower `max_tokens`. |
| 402 | `key_spend_limit_exceeded` | The request would take the key past its monthly spend limit. | After the key's limit is raised, or next month. |
| 402 | `account_spend_limit_exceeded` | The request would take the workspace past its monthly spend limit. | After a tenant admin or super admin raises it, or next month. |
| 403 | `gateway_disabled` | The API Platform is not switched on for this workspace, or the endpoint you called ([embeddings](/docs/console/embeddings), [completions](/docs/console/completions)) is not. | No. |
| 404 | `model_not_found` | `model` is not in the catalog. | No. |
| 413 | `request_too_large` | The request body is larger than 8 MiB. | No. |
| 429 | `rate_limited` | The key reached its requests-per-minute limit. `Retry-After` says how many seconds to wait. | Yes, after `Retry-After`. |
| 429 | `upstream_rate_limited` | The provider is rate limiting the gateway. `Retry-After` is `5`. | Yes, after `Retry-After`. |
| 500 | `internal_error` | The gateway failed unexpectedly. | Yes, with backoff. |
| 502 | `upstream_error` | The provider returned an error, could not be reached, or its stream broke. | Yes, with backoff. |
| 502 | `upstream_auth` | The provider refused Safeguard's own credentials. | Later. Tell Safeguard if it persists. |
| 503 | `model_unavailable` | The model cannot be called through the API: it has not passed the [launch checks](/docs/console/models#how-a-model-becomes-callable), or zero data retention was required and the model does not offer it, or the model catalog could not be read. | Only the catalog case clears by itself. |
| 503 | `auth_unavailable` | Safeguard could not check API keys at that moment. | Yes, after a short wait. |
| 503 | `billing_unavailable` | Safeguard could not check credit at that moment. The gateway refuses rather than serve a request it cannot meter. | Yes, after a short wait. |
| 504 | `upstream_timeout` | The provider did not answer in time, or a stream ran past 900 seconds. | Yes, with backoff. |
Two answers do not use this body, because they come from the API's router before the gateway's code runs: a path the API does not serve, such as `/embeddings`, returns `404` with `{"detail": "Not Found"}`, and a wrong method, such as `GET /chat/completions`, returns `405` with `{"detail": "Method Not Allowed"}`.
## The messages you will see most
| `code` | `message` |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------- |
| `invalid_api_key` | Invalid, revoked or expired API key. Keys start with sg-api- and are sent as 'Authorization: Bearer \'. |
| `gateway_disabled` | The Safeguard inference API is not enabled for this account. |
| `insufficient_credit` | Not enough credit for this request. Add credit in the Console, or lower max\_tokens. |
| `key_spend_limit_exceeded` | This API key's monthly spend limit would be exceeded. |
| `account_spend_limit_exceeded` | Your account's monthly spend limit would be exceeded. |
| `rate_limited` | Too many requests for this API key (limit 60 per minute). The number is the key's limit. |
| `model_not_found` | Model not found: `` |
| `model_unavailable` | Model `` is not available: it is not available through the API yet. Or: zero data retention is not offered for it. |
| `unsupported_parameter` | Only text content is supported (got 'image\_url'). Or: Only n=1 is supported. |
## Retry-After
Two errors carry a `Retry-After` header, in whole seconds:
* `429 rate_limited`: the time until your oldest counted request leaves the 60-second window. A refused request is not counted, so a retry after that wait goes through.
* `429 upstream_rate_limited`: always `5`.
## The order of the checks
The gateway checks a request in this order and answers with the first problem it finds:
1. The key (`401`), then whether the API Platform is on for the workspace (`403`).
2. The body: size (`413`) and fields (`400`).
3. The key's requests per minute (`429 rate_limited`).
4. The model: known (`404`) and callable (`503`).
5. Credit and spend limits for the most the request could cost (`402`).
6. The provider call (`400 upstream_rejected`, `429 upstream_rate_limited`, `502`, `504`).
A request refused at steps 1 to 5 never reaches a provider and costs nothing.
## Errors during a stream
Once a stream has started, the status is already `200`, so a failure arrives as an event in the stream instead:
```text
data: {"error": {"message": "The provider stream ended with an error.", "type": "api_error", "code": "upstream_error", "param": null}}
```
It is followed by the usage chunk, if you asked for one, and `data: [DONE]`. See [Streaming](/docs/console/streaming#errors).
## How to retry
* Retry `429` after `Retry-After`. Retry `500`, `502`, `503 auth_unavailable`, `503 billing_unavailable` and `504` with exponential backoff and a cap on attempts.
* Do not retry the other `4xx` errors unchanged; they will fail the same way.
* Each retry is a new request with a new request id. A retry that reaches a provider and gets an answer is billed like any other request.
* When your workspace or request allows fallbacks, the gateway already retries a failed provider call once before it answers with an error. See [Reliability and fallbacks](/docs/console/reliability-and-fallbacks).
[Troubleshooting](/docs/console/troubleshooting) walks through the common cases and their fixes.
# FAQ (/docs/console/faq)
## Access
**Is the inference API live?**
It is deployed and switched off while it is in early access. Safeguard turns it on for each workspace that asks.
**How do I get access?**
Open a model at [safeguard.sh/models](https://safeguard.sh/models), choose **Use with Safeguard** and leave your email address. Safeguard turns the API Platform on for your workspace. Then follow the [Quickstart](/docs/console/quickstart).
**Why am I getting `403 gateway_disabled`?**
The API Platform is not switched on for your workspace yet. During early access it is off unless Safeguard has turned it on for you.
**Why is Create key disabled?**
For the same reason: keys can be created once the API Platform is on for your workspace. Auditor accounts cannot create keys at all, because their access is read-only.
## Compatibility
**Is it compatible with OpenAI's API?**
With the Chat Completions API, yes: point an OpenAI SDK at `https://api.safeguard.sh/gpt/v1` with an `sg-api-` key. See [SDKs and clients](/docs/console/sdks-and-clients).
**Can I send images or audio?**
Not in v1. A message part that is not text is refused with `400 unsupported_parameter`.
**Are embeddings, image generation or the Responses API available?**
No. The API serves `POST /chat/completions`, `GET /models`, `GET /models/{id}` and `GET /key`.
**Can I ask for several choices with `n`?**
No. `n` must be `1`.
**Do tools and JSON mode work?**
`tools`, `tool_choice`, `parallel_tool_calls` and `response_format` are passed to the provider unchanged, so they work where the model supports them. See [Chat completions](/docs/console/chat-completions).
## Models
**Which models can I call?**
The ones `GET /models` returns. A catalog model becomes callable only after it passes Safeguard's launch checks. See [Models](/docs/console/models).
**Can I call Griffin, Eagle, Lion or Zero?**
Not through the API yet. See [Safeguard models](/docs/console/safeguard-models).
**What do Safeguard's own models cost?**
The catalog lists Griffin at $0.0001 per million input tokens and $0.0001 per million output tokens, Eagle at $0.00001 and $0.00001, and Lion at $0.000001 and $0.000001. Zero uses no model tokens and is listed at $0. They are billed at those rates once they can be called through the API.
**Does Griffin come in sizes, such as S, M or L?**
No. Griffin, Eagle and Lion are one model each, with no Lite, S, M, L or XL variants. Their parameters and context windows are in [Safeguard models](/docs/console/safeguard-models#the-lineup).
**Can I use my own model or my own provider key?**
Not yet. API keys call models on Safeguard's provider accounts. The gateway accepts your own models (`custom:`) only from the Console Workbench, and the Workbench cannot pick them yet. See [Bring your own model](/docs/console/bring-your-own-model).
## Pricing and credit
**Do you add a markup?**
No markup on model usage: for third-party models you pay the provider's list price per token. Each response reports its own cost in `usage.cost`.
**How do I pay?**
Requests spend prepaid credit. Where card top-up is available, a tenant admin or super admin adds credit in the Console and the card fee is passed on at cost. Otherwise Safeguard adds credit for you. See [Pricing and billing](/docs/console/pricing-and-billing).
**Do you send invoices?**
The Console issues no invoices for inference credit. Your record is the credit ledger on **Usage**. See [Credits and invoices](/docs/console/credits-and-invoices).
**What happens when credit runs out?**
Requests stop: they are refused with `402 insufficient_credit` until credit is added.
**Can I cap what we spend?**
Yes. A tenant admin or super admin sets a monthly limit for the workspace, and each key can have its own monthly limit. See [Spend controls](/docs/console/spend-controls).
**Why was a request refused with 402 when I still had credit?**
Before each request the gateway reserves the most it could cost, based on `max_tokens`. Lower `max_tokens`, or add credit. See [Limits](/docs/console/limits#how-the-most-a-request-could-cost-is-worked-out).
## Data
**Where do my prompts go?**
To the provider of the model you name. If you allow fallbacks, a failed request can also go to a listed fallback model of the same family. Never to the models Safeguard uses for its own platform features.
**Do you store my prompts?**
Not by default. The request log keeps metadata such as model, tokens, cost and latency. A tenant admin or super admin can turn on **Store prompts and outputs** for the workspace, and can delete what is stored. See [Privacy and data](/docs/console/privacy-and-data).
**How long do you keep request logs?**
Retention is configurable but not yet enabled: until Safeguard sets the periods, the request log and stored prompts are kept until deleted. Stored prompts can be deleted at any time from **Usage**. See [Privacy and data](/docs/console/privacy-and-data#retention).
**Do you train on my data?**
No. Safeguard never uses your prompts or outputs to train models. Each provider's own terms apply to the requests it receives, and the catalog summarises them for each model.
**Can I choose the region a request runs in?**
No. The gateway calls each provider's standard API and has no region setting. See [Regions and data residency](/docs/console/regions-and-data-residency).
**Can I require zero data retention?**
Yes, per request with `provider.zdr`, or for the whole workspace in **Gateway settings**. Requests then go only to models offered with zero data retention. See [Zero data retention](/docs/console/zero-data-retention).
## Keys and limits
**How quickly does revoking a key take effect?**
Within 30 seconds.
**What is the rate limit?**
60 requests per minute per key by default. You can set a key's own limit from 1 to 10,000. See [Limits](/docs/console/limits).
**Can I call the API from a browser or a mobile app?**
Don't. Anyone who can read the app can read the key. Call the API from your server.
## Streaming
**If I cancel a stream, do I pay less?**
No. The provider keeps generating, and the gateway reads the answer to the end to bill the provider's token counts. Use `max_tokens` to limit a request's cost.
## MCP
**Is the MCP server metered?**
No. MCP tool calls are unlimited on every plan, Free included, and never metered. See [Inference API or MCP server](/docs/console/console-vs-mcp).
## Deployment and buying
**Can we run the API Platform in our own environment?**
The Safeguard platform runs in public cloud, private cloud (VPC), on-prem and air-gapped deployments. The API Platform is in early access in all of them, and in an air-gapped deployment it has no model it can serve yet. See [Deployment options](/docs/console/deployment-options).
**Can we buy through our cloud marketplace?**
Not yet for the API Platform. See [Procurement](/docs/console/procurement).
## Help
**Where can I see whether Safeguard is up?**
At [status.safeguard.sh](https://status.safeguard.sh).
**How do I get help?**
Use **Help & Feedback** in the web app, or email [hi@safeguard.sh](mailto:hi@safeguard.sh). See [Status and support](/docs/console/status-and-support).
# Glossary (/docs/console/glossary)
**API Platform (Console)**
Safeguard's fifth product: an OpenAI-compatible inference API, plus the Console, its pages in the Safeguard web app.
**API key**
The credential your code sends to the inference API: `sg-api-` followed by 64 lowercase hexadecimal characters, created in the Console and shown once. See [Authentication](/docs/console/authentication).
**Available credit**
Your workspace's credit balance minus what requests in flight have reserved.
**Balance**
The workspace's prepaid credit in US dollars, before reservations.
**Base URL**
The address the OpenAI SDKs are pointed at: `https://api.safeguard.sh/gpt/v1`.
**Catalog**
The list of models Safeguard knows, with prices, context windows, data policies and status. It is published at [safeguard.sh/models](https://safeguard.sh/models), and the gateway reads the same catalog.
**Credit ledger**
The record of every change to your credit: credit granted by Safeguard, card top-ups and usage, each with the balance after it.
**Eagle**
Safeguard's discovery and triage model, `safeguard/eagle`: 70 billion parameters and a context window of 1 million tokens, listed at $0.00001 per million input tokens and $0.00001 per million output tokens. Not callable through the API yet. See [Safeguard models](/docs/console/safeguard-models).
**Estimated usage**
Token counts the gateway worked out from the text because the provider reported none. Marked `"estimated": true` in `usage`, and `est.` in the Console's request log.
**Fallback**
A different model the gateway may try when the requested model's provider fails. Only with your permission, and only within the same model family. See [Reliability and fallbacks](/docs/console/reliability-and-fallbacks).
**Gateway**
The Safeguard service behind the inference API. It checks the key, the model and your credit, calls the provider, and records the cost.
**Gateway settings**
Workspace settings in the Console's **Usage** page: the monthly spend limit, prompt storage, retries and fallbacks, and the zero data retention requirement. Only tenant admins and super admins can change them.
**Griffin**
Safeguard's remediation and reasoning model, `safeguard/griffin`: 750 billion parameters and a context window of 1.1 million tokens, listed at $0.0001 per million input tokens and $0.0001 per million output tokens. It is one model, with no Lite, S, M, L or XL variants. Not callable through the API yet. See [Safeguard models](/docs/console/safeguard-models).
**Inference scope**
The scope every Console-created key carries, `inference`, and the only one it carries. It allows chat completions, listing models and `GET /key`, and nothing else.
**Launch checks**
What a catalog model must pass before it can be called through the API: available in the catalog with prices, a configured provider account, the provider's launch checklist for third parties, and a successful end-to-end test. See [Models](/docs/console/models#how-a-model-becomes-callable).
**Lion**
Safeguard's compliance and narrative model, `safeguard/lion`: 15 billion parameters and a context window of 128K tokens, listed at $0.000001 per million input tokens and $0.000001 per million output tokens. The [AI Models](/docs/ai-models) page calls it Lino. Not callable through the API yet. See [Safeguard models](/docs/console/safeguard-models).
**Masked key**
How the Console shows a key without its secret: its start and end, such as `sg-api-1a2b3c4d…9f8e`.
**Markup**
An amount added on top of a provider's price. The API Platform adds none to third-party model usage.
**Model id**
The `provider/model` string you pass as `model`, such as `openai/gpt-6-sol`.
**Monthly spend limit**
A cap on what a key, or the whole workspace, may spend in a calendar month in UTC. Requests that would pass it are refused with `402`.
**Prompt storage**
An opt-in workspace setting that stores the full text of prompts and outputs. Off by default.
**Provider**
The company whose model answers a request. The response's `provider` field names the route used, such as `openai`.
**Request id**
The id of one request: `gen-` followed by 32 hexadecimal characters. It is the response's `id`, and every chat response, streamed or not, also sends it in the `X-Generation-Id` header.
**Request log**
The Console's list of requests, with model, key, tokens, cost, latency and status. Metadata only.
**Reservation**
The amount held from your credit while a request runs: the most it could cost. It shows as **Reserved** in the Console and is released when the request settles, or after about 30 minutes if it never does.
**Settlement**
The step after a request finishes, when the gateway charges its actual cost, releases the reservation and writes the request log entry.
**Streaming**
Receiving the answer as server-sent events while it is generated, with `"stream": true`. See [Streaming](/docs/console/streaming).
**Top-up**
Buying credit by card in the Console, where Safeguard has switched card top-up on. The card fee is passed on at cost.
**Usage chunk**
The last event of a stream when you set `stream_options.include_usage`: no choices, just `usage` with tokens and cost.
**Workbench**
The Console page for trying models without code. It uses your sign-in instead of a key. See [Workbench](/docs/console/workbench).
**Zero**
Safeguard's no-weights model, `safeguard/zero`. It uses no model tokens and is priced at $0 per million tokens. See [Safeguard models](/docs/console/safeguard-models).
**Zero data retention (ZDR)**
Routing only to models whose provider offers zero data retention, per request or for the whole workspace (the setting **Only use models whose provider offers zero data retention**). A model without it is never used, not even as a fallback. See [Zero data retention](/docs/console/zero-data-retention).
# API Platform (Console) (/docs/console)
The API Platform is Safeguard's fifth product, alongside [ESSCM](/docs/esscm), [Portal](/docs/portal), [TPRM](/docs/tprm) and [OSM](/docs/osm). It gives your applications one OpenAI-compatible API for model inference. You send chat completion requests to Safeguard with an API key, Safeguard routes each one to the model you named, and every request is metered against your workspace's prepaid credit.
The Console is the API Platform's interface in the Safeguard web app. It is where you create API keys, try models in the Workbench, follow usage and cost, and manage credit and spend limits.
The inference API is deployed but switched off while it is in early access. To use it, open a model at [safeguard.sh/models](https://safeguard.sh/models) and choose **Use with Safeguard**. Safeguard then turns the API Platform on for your workspace. Until it is on, **Create key** in the Console is disabled, and a request is refused with `403 gateway_disabled`.
## What you get
* **One API, OpenAI's shape.** `POST /chat/completions` with streaming, plus `GET /models`, at the base URL `https://api.safeguard.sh/gpt/v1`. The OpenAI SDKs work once you change the base URL and the key. See [SDKs and clients](/docs/console/sdks-and-clients).
* **Models from several providers in one catalog.** The catalog at [safeguard.sh/models](https://safeguard.sh/models) lists third-party models and Safeguard's own. Through the API, a model can be called only after it passes Safeguard's launch checks. See [Models](/docs/console/models).
* **No markup on model usage.** For third-party models you pay the provider's list price per token. Each response reports its own cost in `usage.cost`. See [Pricing and billing](/docs/console/pricing-and-billing).
* **Spending you control.** Prepaid credit with a hard stop at zero, a monthly spend limit for the workspace, and an optional monthly limit and requests-per-minute limit for each key. See [Limits](/docs/console/limits).
* **Metadata-only logs by default.** The request log keeps model, tokens, cost, latency and status. Storing prompts and outputs is off unless a tenant admin or super admin turns it on. See [Privacy and data](/docs/console/privacy-and-data).
* **Your routing rules.** Zero data retention routing when you ask for it, and retries or fallbacks only when you allow them, within the same model family. See [Reliability and fallbacks](/docs/console/reliability-and-fallbacks).
## Get access
1. **Choose a model.** Open [safeguard.sh/models](https://safeguard.sh/models), pick a model and choose **Use with Safeguard**. The form asks only for your email address.
2. **Safeguard turns it on.** Safeguard switches the API Platform on for your workspace. Requests spend prepaid credit; while card top-up is not available, Safeguard adds the credit to your workspace.
3. **Create a key and call the API.** In the Console, open **API keys** and create a key. The [Quickstart](/docs/console/quickstart) takes you from there to your first request.
## The Console
When the API Platform is on for your workspace, **API Platform (Console)** appears in the product switcher, and pressing **G** then **5** opens it. Its sidebar has **Dashboard**, **Search**, **Workbench**, **API keys**, **Usage** and **Settings**. The [Console guide](/docs/console/console-guide) describes each page.
## Delivery options
| Option | What it is | Maturity |
| -------------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------- |
| **Safeguard API (hosted)** | Safeguard runs the gateway. You call `https://api.safeguard.sh/gpt/v1` with a key from the Console. | Early access |
| **Public cloud** | Safeguard deployed on the public cloud you choose. The platform is cloud-agnostic, so it is not tied to one provider. | GA |
| **Private cloud (VPC)** | A single-tenant deployment in a private network, isolated for one customer. | GA |
| **On-prem** | The full platform in your own datacenter. | GA |
| **Air-gapped** | The complete platform with no outbound connection. | GA |
| **Your cloud marketplace** | Buying the API Platform through your cloud provider's marketplace. | Not available yet |
The GA labels describe running the Safeguard platform in that environment. The API Platform itself is in early access in every option. In a deployment of your own, it can call a provider only when that deployment can reach the provider's API, so in an air-gapped deployment it has no model it can serve yet. [Deployment options](/docs/console/deployment-options) and [Procurement](/docs/console/procurement) have the details.
## v1 limits
* Text only. A message with an image or audio part is refused with `400 unsupported_parameter`.
* One choice per request: `n` must be `1` or absent.
* Chat completions and models only. There are no embeddings, images, audio or legacy completions endpoints.
* Your own models (`custom:`) are accepted only from the Console Workbench, never with an API key, and the Workbench cannot pick them yet. See [Bring your own model](/docs/console/bring-your-own-model).
* Safeguard switches the API Platform on per workspace.
## Related
* [Quickstart](/docs/console/quickstart)
* [Chat completions](/docs/console/chat-completions)
* [Pricing and billing](/docs/console/pricing-and-billing)
* [FAQ](/docs/console/faq)
* [Product Offering](/docs/product-offering)
# Key management best practices (/docs/console/key-management-best-practices)
An inference key is a bearer credential. Whoever holds it can spend your workspace's credit until the key is revoked. Treat it like the password to a paid account.
**Early access.** The inference gateway is deployed but switched off. Safeguard switches it on per workspace, and keys can be created only after that.
## What a key is
* A key is `sg-api-` followed by 64 hexadecimal characters. It goes in the `Authorization: Bearer` header. See [Authentication](/docs/console/authentication).
* The full key is shown once, when you create it. Safeguard stores only a SHA-256 hash of it, so nobody can show it to you again. If you lose it, revoke it and create a new one.
* From then on, the Console shows the key masked, as its start and end: `sg-api-1a2b3c4d…9f8e`.
* A key carries one scope, `inference`. It works with the inference API and nothing else in Safeguard. MCP keys, Guard SDK keys and other Safeguard credentials are not accepted by the inference API.
* A key belongs to your workspace and acts for the member who created it. It stops working if that member is deactivated or removed.
* Keys created in the Console have no expiry date. They work until they are revoked.
## Store keys as secrets
* Copy the key from the **Copy your key** dialog straight into your secret manager. A click outside the dialog does not dismiss it, but the Escape key does, and the key is gone once the dialog closes.
* Give the key to your application at runtime, from your secret manager or an environment variable such as `SAFEGUARD_INFERENCE_KEY`. Keep it out of source code and configuration files.
* Keep it out of tickets, chat, screenshots and logs. If you log outgoing requests, redact the `Authorization` header.
* When you report a problem, quote the key's name or masked form. Never the key.
## Keep keys out of client-side code
Never put a key in a web page, a mobile app or a desktop app you hand out. Anyone with a copy of the app can read the key and spend your credit. Call the inference API from your own server, and have your apps call your server.
## Use one key per app and environment
Create a separate key for each application and each environment, such as production, staging and CI. Then you can revoke one key without touching the others. Each key gets its own monthly spend limit and its own requests-per-minute limit, and **Usage** splits spend by key.
Name each key for where it is used, for example `prod-checkout-service`. **Edit** renames a key without changing its secret.
## Give each key only what it needs
* **Set a monthly spend limit on every key**, sized to its job. A leaked key with a $50 limit is refused once its requests would take it past $50 in the month. See [Spend controls](/docs/console/spend-controls).
* **Lower the requests-per-minute limit** for low-traffic jobs. The default is 60.
* **Ask a tenant admin or super admin for a workspace limit**, as a ceiling over all keys and the Workbench.
* Every key can call every model available to your workspace.
* A key stops working when its owner leaves the workspace. Before someone leaves, replace the keys they created.
## Rotate keys
The Console does not rotate keys for you, but a rotation takes a few minutes:
1. Create a new key with the same limits.
2. Deploy it everywhere the old key is used.
3. Check that the old key is idle. On **API keys**, its **Last used** time stops changing and its **This month** spend stops growing. **Last used** is updated at most about once a minute.
4. Revoke the old key.
Both keys work while you switch over, so nothing fails in between. Rotate on the schedule your security policy sets, when someone with access to a key leaves, and after any suspected exposure.
## If a key leaks
1. **Revoke it now.** On **API keys**, select **Revoke** on the key's row and confirm. The Console warns: "Requests that use this key are refused within 30 seconds. This cannot be undone."
2. **Allow 30 seconds.** The gateway trusts a key it has checked for up to 30 seconds before checking it again, so requests with a revoked key are refused within 30 seconds. A request that had already started runs to its end.
3. **Replace it.** Create a new key and deploy it.
4. **Check what it spent.** A revoked key stays listed under **Revoked** on **API keys**, with what it spent this month. In **Usage**, **By key** and the request log name it by its name and masked form, with each request's time, model, cost and status.
5. **Close the gap.** Find out where the key was exposed and fix that, so the new key does not leak the same way.
If you see usage your team did not make, contact [hi@safeguard.sh](mailto:hi@safeguard.sh) with the key's name and the time window.
A tenant admin can stop all of one member's keys at once by deactivating the member, which also ends their sessions. See [Team and access](/docs/console/team-and-access).
## Related
* [Authentication](/docs/console/authentication)
* [Spend controls](/docs/console/spend-controls)
* [Team and access](/docs/console/team-and-access)
* [Troubleshooting](/docs/console/troubleshooting)
# Limits (/docs/console/limits)
## Rate limits
Each API key has a requests-per-minute limit.
* The default is **60 requests per minute**. You can set a key's own limit, from 1 to 10,000, when you create or edit it on **API keys**.
* Requests are counted over a rolling 60-second window.
* Past the limit, requests are refused with `429 rate_limited` and a `Retry-After` header giving the seconds to wait. Refused requests are not counted.
* The limit is applied by each gateway server process separately, so treat it as approximate: short bursts can go somewhat over the number you set. It is there to stop runaway loops. The dollar limits below are what cap your spend.
Runs in the Console [Workbench](/docs/console/workbench) are limited to 60 a minute for each person.
When a provider rate limits the gateway itself, the request is refused with `429 upstream_rate_limited` and `Retry-After: 5`.
## Spend limits
Before every request, the gateway checks three things against the most the request could cost, in this order, and refuses with `402` at the first that fails:
| Check | Refused with | Who sets it |
| --------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------- | ---------------------------------------------------------------------- |
| **Prepaid credit.** Your balance, minus what requests in flight have reserved, must cover this request. A balance at or below zero refuses every request. | `402 insufficient_credit` | Credit is added by Safeguard, or by card where card top-up is on. |
| **The key's monthly limit.** What the key spent this month, plus its requests in flight, plus this request, must stay within its limit. | `402 key_spend_limit_exceeded` | The key's owner, on **API keys** |
| **The workspace's monthly limit.** The same sum for the whole workspace must stay within its limit. | `402 account_spend_limit_exceeded` | A tenant admin or super admin, in **Usage** under **Gateway settings** |
* Months are calendar months in UTC. A new month starts every limit at zero spent.
* A key or workspace with no monthly limit is limited only by credit.
* Workbench runs spend the workspace's credit and count toward the workspace limit. They use no key, so no key limit applies.
[Spend controls](/docs/console/spend-controls) explains how to set and raise each limit.
## How the most a request could cost is worked out
The gateway cannot know a request's cost before the provider answers, so it holds the most it could cost and charges the actual cost afterwards.
1. **Input.** It estimates the input tokens from your messages, generously, at about one token for every three characters plus a little for each message.
2. **Output.** It assumes the full output cap: your `max_completion_tokens` or `max_tokens`, or when you set none, 4,096 tokens or the model's maximum, whichever is lower.
3. **Price.** It prices both at the model's catalog prices. When fallbacks are allowed, it uses the most expensive of the models it might try.
That amount is held while the request runs and shows as **Reserved** in the Console. When the request finishes, the actual cost is charged and the rest of the hold is released. A hold that is never settled, for example because a request was cut off, is released after about 30 minutes.
If you are close to your credit or a limit, a request with a smaller `max_tokens` holds less and may fit where a larger one does not.
The actual cost can be higher than the hold only when the provider reports more input tokens than the estimate. The provider bills that, so it is charged, and the balance can go slightly below zero. Requests are then refused until credit is added.
## Request size
| Limit | Value |
| --------------------------------------- | ---------------------------------------------------------- |
| Request body | 8 MiB. Larger bodies get `413 request_too_large`. |
| Messages | 1 to 2,000 |
| `max_completion_tokens` or `max_tokens` | 1 to 1,000,000, then lowered to the model's maximum output |
| Output cap when you set none | 4,096 tokens, or the model's maximum if lower |
| `stop` | Up to 4 sequences |
| `n` | 1 |
| Content | Text only |
## Time
| Limit | Value |
| --------------------------------- | --------------------------------------------------- |
| Waiting for a provider to respond | 120 seconds, then `504 upstream_timeout` |
| A single stream | 900 seconds, then an `upstream_timeout` error event |
## Related
* [Spend controls](/docs/console/spend-controls)
* [Errors](/docs/console/errors)
* [Pricing and billing](/docs/console/pricing-and-billing)
# Migrate from OpenAI (/docs/console/migrate-from-openai)
Code written for OpenAI's Chat Completions API moves to Safeguard with three changes: the base URL, the key and the model id. Everything else on this page is about the differences to check before you switch.
## 1. Change the base URL and the key
Python
Node.js
```python
import os
from openai import OpenAI
# Before: client = OpenAI() (OpenAI's API, OPENAI_API_KEY)
client = OpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
```
```js
import OpenAI from 'openai';
// Before: const client = new OpenAI(); (OpenAI's API, OPENAI_API_KEY)
const client = new OpenAI({
baseURL: 'https://api.safeguard.sh/gpt/v1',
apiKey: process.env.SAFEGUARD_INFERENCE_KEY,
});
```
Create the key in the Console under **API keys**. See [Authentication](/docs/console/authentication).
## 2. Map the model ids
Safeguard's model ids name the provider first: OpenAI's `gpt-6-sol` is `openai/gpt-6-sol`. Look the model up at [safeguard.sh/models](https://safeguard.sh/models) or with [`GET /models`](/docs/console/models) and use its `id`.
```python
response = client.chat.completions.create(
model="openai/gpt-6-sol", # was "gpt-6-sol"
messages=[{"role": "user", "content": "Hello"}],
)
```
A model is callable only after it passes Safeguard's launch checks, so confirm that the models you use appear in `GET /models` before you switch traffic.
## 3. Check the parameters you send
| You use | On Safeguard |
| ---------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| `messages` with text content | Same. Roles `system`, `developer`, `user`, `assistant` and `tool`. |
| Images or audio in `messages` | Refused with `400 unsupported_parameter`. Text only in v1. |
| `max_tokens`, `max_completion_tokens` | Same. Capped at the model's maximum output. |
| `temperature`, `top_p`, `stop` | Same, with the same ranges. |
| `stream`, `stream_options.include_usage` | Same. See [Streaming](/docs/console/streaming). |
| `tools`, `tool_choice`, `parallel_tool_calls` | Passed to the provider unchanged. |
| `response_format`, `seed`, `presence_penalty`, `frequency_penalty` | Passed to the provider unchanged. |
| `n` greater than 1 | Refused with `400 unsupported_parameter`. |
| `user` | Accepted and dropped, never sent to the provider. |
| Any other parameter, such as `logprobs`, `logit_bias`, `store` or `metadata` | Ignored and not forwarded. |
The full list is on [Chat completions](/docs/console/chat-completions).
## 4. Check the endpoints you call
Safeguard serves `POST /chat/completions`, `GET /models`, `GET /models/{id}` and `GET /key`. If your code also calls OpenAI's Responses API, Assistants, embeddings, images, audio, files, batches or moderations, keep those calls on OpenAI; Safeguard answers them with `404`.
## What else changes
* **Billing.** Requests spend your workspace's prepaid credit at the provider's list price, with no markup. When credit runs out, requests are refused with `402 insufficient_credit` instead of being billed later. See [Pricing and billing](/docs/console/pricing-and-billing).
* **Cost in every response.** `usage.cost` gives the request's cost in US dollars, and `provider` names the route that served it.
* **Rate limits.** Each key has its own requests-per-minute limit, 60 by default. See [Limits](/docs/console/limits).
* **Errors.** The body has OpenAI's shape, but the codes are Safeguard's, such as `insufficient_credit` and `model_unavailable`. See [Errors](/docs/console/errors).
* **Organizations and projects.** OpenAI organization and project settings have no meaning here. A Safeguard key belongs to your workspace.
* **Data handling.** Your prompts go to the provider of the model you choose. The request log keeps metadata only, unless a tenant admin or super admin turns on prompt storage. See [Privacy and data](/docs/console/privacy-and-data).
## A checklist for the switch
1. Create a key for the application in the Console, with a monthly spend limit.
2. Confirm your models appear in `GET /models`.
3. Change the base URL, the key and the model ids.
4. Run your tests against Safeguard and compare outputs and `usage.cost`.
5. Watch **Usage** in the Console during the first days of traffic.
# Migrate from another router (/docs/console/migrate-from-other-routers)
If your code already calls models through an OpenAI-compatible router or gateway, moving to Safeguard is the same kind of change as moving from OpenAI: a new base URL, a new key and Safeguard's model ids. The details below are the parts that differ from one router to the next.
## 1. Base URL and key
| Setting | Value |
| -------- | ----------------------------------------------------- |
| Base URL | `https://api.safeguard.sh/gpt/v1` |
| API key | An `sg-api-` key from the Console's **API keys** page |
Python
Node.js
```python
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
```
```js
import OpenAI from 'openai';
const client = new OpenAI({
baseURL: 'https://api.safeguard.sh/gpt/v1',
apiKey: process.env.SAFEGUARD_INFERENCE_KEY,
});
```
## 2. Model ids
Safeguard's ids have the form `provider/model`, such as `anthropic/claude-sonnet-5-5`. Many routers use a similar form, but the names after the slash can differ, so look each model up at [safeguard.sh/models](https://safeguard.sh/models) or with [`GET /models`](/docs/console/models) rather than reusing the old string. Only models that appear in `GET /models` can be called today.
## 3. Routing options
Safeguard reads one routing object, `provider`, with two fields:
```json
"provider": { "allow_fallbacks": true, "zdr": true }
```
* `allow_fallbacks` turns on one retry and then the catalog's listed fallbacks for that model, only within the same model family. It is off unless your request or your workspace turns it on.
* `zdr` routes only to models offered with zero data retention.
Other routing fields your router may have used, such as provider order, allow lists or price caps, are ignored. So are attribution headers. To control cost, use `max_tokens` and the [spend limits](/docs/console/spend-controls).
See [Reliability and fallbacks](/docs/console/reliability-and-fallbacks) and [Zero data retention](/docs/console/zero-data-retention).
## 4. Parameters and endpoints
The request and response follow OpenAI's Chat Completions format. Check these differences:
* Text only. Image and audio parts are refused with `400 unsupported_parameter`.
* `n` must be `1`.
* Optional parameters outside the list on [Chat completions](/docs/console/chat-completions) are ignored, not forwarded.
* Only `/chat/completions`, `/models` and `/key` are served. There are no embeddings, images, audio or legacy completions endpoints.
* Streaming uses the same server-sent events, and `stream_options.include_usage` adds a final usage chunk. See [Streaming](/docs/console/streaming).
## 5. Billing
* **No markup.** For third-party models you pay the provider's list price per token. Each response reports its own cost in `usage.cost`, in US dollars.
* **Prepaid credit.** Requests spend your workspace's credit and stop at zero with `402 insufficient_credit`.
* **Spend limits.** A monthly limit for the workspace and, optionally, for each key.
* **Card fees.** Where card top-up is available, the card processor's fee is added to the charge at cost; the credit you receive is the amount you chose.
See [Pricing and billing](/docs/console/pricing-and-billing).
## 6. Your own provider keys
If you used your router with your own provider accounts, note that Safeguard's API keys call models on Safeguard's provider accounts. In this version your own models and endpoints cannot be called with an API key, and the Console cannot pick them yet. See [Bring your own model](/docs/console/bring-your-own-model).
## A checklist for the switch
1. Create a key per application in the Console, each with a monthly spend limit.
2. Map every model id and confirm it appears in `GET /models`.
3. Decide whether you want fallbacks and zero data retention, and set `provider` or ask a tenant admin or super admin to set the workspace defaults.
4. Change the base URL, key and model ids, and run your tests.
5. Watch **Usage** in the Console while traffic moves.
# Models (/docs/console/models)
The inference API reads the same model catalog that [safeguard.sh/models](https://safeguard.sh/models) shows. A model in the catalog can be called through the API only after it passes Safeguard's launch checks, described [below](#how-a-model-becomes-callable).
## List the models you can call
`GET /models` lists the models your key can call right now.
curl
Python
Node.js
```bash
curl https://api.safeguard.sh/gpt/v1/models \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY"
```
```python
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
for model in client.models.list():
print(model.id)
```
```js
import OpenAI from 'openai';
const client = new OpenAI({
baseURL: 'https://api.safeguard.sh/gpt/v1',
apiKey: process.env.SAFEGUARD_INFERENCE_KEY,
});
for await (const model of client.models.list()) {
console.log(model.id);
}
```
Add `?all=true` to list every model published in the catalog, including the ones you cannot call yet, each with its `status` and the reason it cannot be called:
```bash
curl "https://api.safeguard.sh/gpt/v1/models?all=true" \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY"
```
### The response
```json
{
"object": "list",
"data": [
{
"id": "MODEL_ID",
"object": "model",
"created": 0,
"owned_by": "openai",
"name": "Example model",
"context_length": 128000,
"max_output_tokens": 16384,
"pricing": {
"input_per_mtok_usd": "1.0",
"output_per_mtok_usd": "4.0",
"markup_percent": 0
},
"status": "available",
"runnable": true,
"routable": true,
"unavailable_reason": null,
"zdr_available": true,
"region": null
}
]
}
```
The values above are illustrative.
| Field | Meaning |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `id` | The model id to pass as `model`. |
| `owned_by` | The model's provider family, such as `openai`, `anthropic`, `google` or `safeguard`. |
| `name` | The model's display name in the catalog. |
| `context_length` | The context window in tokens, when the catalog states one. |
| `max_output_tokens` | The most output tokens the model allows, when the catalog states one. Requests are capped at this. |
| `pricing.input_per_mtok_usd`, `pricing.output_per_mtok_usd` | Price per million input and output tokens in US dollars, as decimal strings. For third-party models this is the provider's list price. |
| `pricing.cached_input_per_mtok_usd` | Present only when the catalog has a separate price for cached input tokens. |
| `pricing.markup_percent` | Always `0`. |
| `status` | `available` only when you can call the model now: the catalog lists it as available and it passes the launch checks below. Otherwise `request_access` or `coming_soon`. A model the catalog lists as available that is still held by the launch checks shows `request_access`. |
| `runnable` | `true` when you can call the model now. The same rule decides what the gateway serves. |
| `routable` | The same as `runnable`, kept for older clients. |
| `unavailable_reason` | Why the model cannot be called, in a sentence, such as "Coming soon." or "Available on request. It is not sold through the API yet." `null` when it can be called. |
| `zdr_available` | `true` when the model can be used with [zero data retention](/docs/console/zero-data-retention). |
| `region` | A short region code for the model's route when the catalog records one, otherwise `null`. |
| `created` | Always `0`. |
## Get one model
`GET /models/{id}` returns one published model as a single object in the same shape, whether or not you can call it yet. Model ids contain a `/`, and you send them as they are:
```bash
curl https://api.safeguard.sh/gpt/v1/models/openai/gpt-6-sol \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY"
```
An id that is not in the catalog, or not published in it, returns `404` with the code `model_not_found`.
## Model ids and the catalog
A model id has the form `provider/model`, for example `openai/gpt-6-sol` or `safeguard/griffin`. It is the **model id** shown on the model's page at [safeguard.sh/models](https://safeguard.sh/models), not the page's address: the page for `openai/gpt-6-astra` lives at `/models/openai-gpt-6-astra`, but the API takes `openai/gpt-6-astra`.
The catalog also lists models that the chat completions endpoint does not serve, such as embedding, image, rerank and transcription models. The API routes only models priced per million tokens, so a model shown as **Price on request** cannot be called through it.
## Provider routes
Each response says which route served it, in the `provider` field. These are the routes the gateway has clients for:
| `provider` | Provider |
| ----------- | ------------------------------- |
| `openai` | OpenAI |
| `anthropic` | Anthropic |
| `google` | Google (Gemini API) |
| `mistral` | Mistral AI |
| `deepseek` | DeepSeek |
| `xai` | xAI |
| `cohere` | Cohere |
| `together` | Together AI (open-weight host) |
| `fireworks` | Fireworks AI (open-weight host) |
| `groq` | Groq (open-weight host) |
| `safeguard` | Safeguard's own inference |
A route being listed here does not mean any of its models can be called today. That is decided model by model.
## How a model becomes callable
The gateway checks these on every request. A model is callable only when all of them hold:
1. The catalog lists the model as `available`, with both an input and an output price.
2. Safeguard has an account with the model's provider configured for the API.
3. For every provider other than Safeguard itself, the provider's launch checklist is complete: its terms are confirmed to allow resale at list price, it is on the [Trust Center subprocessor list](https://trust.safeguard.sh/subprocessors), and Safeguard's data processing agreement, privacy notice and AI disclosure cover it.
4. A real end-to-end test call to that model, on that route, has succeeded.
DeepSeek prices its API by time of day, while the gateway bills one rate, so DeepSeek models stay unavailable through the API until that is resolved.
A request for a catalog model that fails any check is refused with `503 model_unavailable`. `GET /models?all=true` shows such a model with `runnable: false` and its `unavailable_reason`. Models that are not published in the catalog are never listed or served.
## Availability per workspace
* The API Platform must be on for your workspace. Safeguard switches it on.
* Where it is on, every workspace can call the same models, and so can every key in it.
* If your workspace requires zero data retention, only models with `zdr_available: true` can be called; any other model is refused with `503 model_unavailable`.
## Safeguard's own models
The catalog lists Safeguard's three models (`safeguard/griffin`, `safeguard/eagle` and `safeguard/lion`) and `safeguard/zero`, which answers data questions with no model. Griffin, Eagle and Lion are one model each, with no size variants. Griffin is listed at $0.0001 per million input tokens and $0.0001 per million output tokens, Eagle at $0.00001 and $0.00001, and Lion at $0.000001 and $0.000001. Zero has no model weights, uses no model tokens and is priced at $0. None of them can be called through the API yet. See [Safeguard models](/docs/console/safeguard-models).
## How fresh the list is
The gateway re-reads the catalog every 60 seconds. If the catalog cannot be read, it keeps using its last copy for up to 10 minutes; after that, requests are refused with `503 model_unavailable` until the catalog is back. It never guesses a price.
## Related
* [Choosing a model](/docs/console/choosing-a-model)
* [Chat completions](/docs/console/chat-completions)
* [Pricing and billing](/docs/console/pricing-and-billing)
# Pricing and billing (/docs/console/pricing-and-billing)
**Early access.** The API Platform is deployed but switched off by default. Safeguard switches it on per workspace, and makes each model available only after it passes Safeguard's launch checks. A model in the catalog is not necessarily one you can call yet.
## No markup on model usage
Third-party models are billed at the provider's list price. Safeguard adds nothing on top: every model in `GET /gpt/v1/models` carries `markup_percent: 0`, and the gateway has no setting that could add a margin.
Each price in the model catalog is the provider's own published price per million tokens. It is read on the provider's pricing page and stored with that page's address and the date it was checked, never taken from an aggregator. Every model and its price is on [safeguard.sh/models](https://safeguard.sh/models).
A model is served through the API only when the catalog lists both its input and its output price. A missing price is never treated as zero. Models whose provider charges by time of day (DeepSeek, today) are not served either, because one flat rate would charge more than the provider's off-peak price.
## Safeguard's own models
None of Safeguard's own models can be called through the API yet. The catalog lists Griffin at $0.0001 per million input tokens and $0.0001 per million output tokens, Eagle at $0.00001 and $0.00001, Lion at $0.000001 and $0.000001, and Zero, which uses no model tokens, at $0. When they can be called, they are billed at those catalog rates, the same way as every other model. See [Safeguard models](/docs/console/safeguard-models), [safeguard.sh/models](https://safeguard.sh/models) and [safeguard.sh/pricing](https://safeguard.sh/pricing).
## How a request is priced
A request costs its input tokens times the input price, plus its output tokens times the output price, with prices per million tokens. Amounts are kept to eight decimal places.
* Token counts are the provider's own figures.
* Cached input tokens are billed at the provider's cached-input price when the catalog lists one, and at the input price otherwise.
* A non-streamed response carries its cost in US dollars in `usage.cost`. For a stream, set `stream_options.include_usage` and the last chunk carries it.
* If a provider reports no token counts, for example when a stream ends early, the gateway bills an estimate based on the length of the text. The response's `usage` says `estimated: true`, and the request log marks the request **est.**
* A request that fails before the provider produces any output costs nothing.
Closing the connection does not stop the charge. When a streaming client goes away, the gateway keeps reading the provider's stream to the end, so it can bill the provider's own counts rather than a guess. Stopping a run in the Workbench works the same way.
## Prepaid credit
Model usage is paid from prepaid credit held by your workspace. **Usage › Credits and limits** in the Console shows it:
| Figure | What it is |
| -------------------- | --------------------------------------------------------------------------- |
| **Balance** | Credit on the workspace. |
| **Reserved** | Held for requests that are still running. |
| **Available** | Balance minus reserved: what new requests can use. |
| **Spent this month** | Usage this calendar month (UTC), against the workspace limit if one is set. |
Before each call, the gateway reserves the most the request could cost: a generous estimate of the input, plus every output token it may produce, at the highest price among the models it may use. If you don't set `max_tokens`, the gateway sets one (a server default, or the model's maximum output if that is lower). After the call it releases the hold and charges the actual cost. A smaller `max_tokens` means a smaller hold.
Credit is a hard stop. A request whose maximum cost doesn't fit the available credit is refused with `402 insufficient_credit` before it reaches the provider. Rarely, a provider reports more input than the gateway estimated. The provider billed it, so it is charged, and the balance can go below zero. Every request is then refused until credit is added.
A hold that is never settled, for example after a crash, is released after about 30 minutes.
The **Credit ledger** on the same page lists every credit movement, such as a grant, a top-up or a request's usage, with the balance after each one.
## Adding credit
Until card top-up is switched on, Safeguard adds credit to your workspace. The Usage page says **Card top-up is not available yet. Contact Safeguard to add credit.**
Once card top-up is on, a tenant admin or super admin selects **Add credit**, enters the credit they want and pays on Stripe's checkout page. The card processing fee is passed through at cost, 2.9% of the charge plus $0.30: it is added to the charge, so the credit you receive is the amount you entered, and Safeguard keeps no margin on the fee. The checkout line shows the credit and the fee it includes. Card fees apply only to card top-ups. See [Credits and invoices](/docs/console/credits-and-invoices).
## Spend limits
| Limit | Who sets it | Where | When it would be passed |
| ----------------------------- | ----------------------------- | ------------------------------------------------- | ---------------------------------- |
| Workspace monthly spend limit | A tenant admin or super admin | **Usage › Credits and limits › Gateway settings** | `402 account_spend_limit_exceeded` |
| Key monthly spend limit | The key's owner | **API keys**, when you create or edit a key | `402 key_spend_limit_exceeded` |
Both count the calendar month in UTC, including what running requests have reserved. Leave a limit empty for no limit. Each key also has a requests-per-minute limit, which guards against runaway use rather than capping spend.
To check a key from code, `GET /gpt/v1/key` returns its monthly limit and spend, and the workspace's available credit.
## Workbench runs
Runs in the Workbench are billed and logged like API requests and use the same credit. The usage breakdown by key counts them separately from your keys.
## Models you bring yourself
A request to a model you configured with your own provider account carries no Safeguard charge, and your provider bills you directly. In this version such a model cannot be called with an API key or picked in the Console yet. See [Bring your own model](/docs/console/bring-your-own-model).
## MCP is never metered
MCP tool calls are unlimited on every plan and never charged. See [MCP](/docs/mcp).
## Related
* [Limits](/docs/console/limits)
* [Safeguard models](/docs/console/safeguard-models)
* [Privacy and data](/docs/console/privacy-and-data)
* [Bring your own model](/docs/console/bring-your-own-model)
* [Procurement](/docs/console/procurement)
* [Pricing](https://safeguard.sh/pricing)
# Privacy and data (/docs/console/privacy-and-data)
## Where your prompts go
**Which provider receives a prompt is your choice, made per request**: the model you name (and, with [routing](/docs/console/routing), the models and providers you list) decides it. The Console says so when you create a key. This is separate from Safeguard's own product features, which send no customer data to third-party AI providers.
When you call a model, the gateway sends your request to the provider that serves that model, and the provider sends back the answer. For a closed model, the provider is the company that makes it, such as OpenAI or Anthropic. For an open-weight model, it is the company that hosts it. Each model's page on [safeguard.sh/models](https://safeguard.sh/models) says where prompts go, under **Data policy**.
The gateway sends the provider your messages and the request parameters it needs. It never forwards:
* the `user` field: an end-user ID is your data, so the gateway drops it;
* your API key: the gateway calls the provider with Safeguard's own credentials.
The gateway is kept apart from the rest of Safeguard. Your requests never pass through the AI provider chain behind Safeguard's own product features, and the gateway calls providers with credentials of its own. It also reads none of your workspace's security data. Automated tests enforce that boundary.
### Routing
Where [routing](/docs/console/routing) is switched on, a request can list several models and providers, or ask the gateway to sort them by price, latency or uptime. Every candidate is one you named, the same model at another host, or (with fallbacks on) a same-family fallback; `provider.only` and `provider.ignore` limit which providers can receive the prompt.
### Retries and fallbacks
Off by default. If a tenant admin or super admin turns on **Allow retries and fallbacks**, or a request sets `"provider": { "allow_fallbacks": true }`, a failed request is retried once and can then go to a fallback listed in the catalog. A fallback is always a model from the same family (the same maker), or the same model at another host. So with fallbacks on, a request for an open-weight model can be served by a different host from the one you chose. It never goes to an unrelated model family.
### Before a provider is used
A third-party model is served only after Safeguard has recorded three things for its provider:
1. the provider's terms allow Safeguard to resell it at list price;
2. the provider is on the subprocessor list on [Safeguard's Trust Center](https://trust.safeguard.sh/subprocessors);
3. Safeguard's DPA, privacy notice and AI disclosure have been updated for it.
The gateway checks these on every request and refuses the model until all three are recorded. The rule covers hosts of open-weight models as well as the makers of closed ones, because both receive your prompts.
## What Safeguard keeps
### The request log: metadata only
Every request, from the API or the Workbench, adds one row to your workspace's request log. The row holds metadata, never the text:
* the time, the source (API or Workbench), and the API key used, with its name and masked form;
* the model, its provider and the model ID at the provider, and the model's region when the catalog sets one;
* input, output and cached tokens, and whether they are the provider's figures or an estimate;
* the cost, the latency and the time to the first token;
* the status, the HTTP status and any error code;
* whether the request streamed, was made under zero data retention, or was served by a fallback.
People in your workspace who can open the Console see the log on the **Usage** page, under **Request log**.
### Prompts and outputs: only if you turn it on
Safeguard does not store the text of prompts or outputs by default. A tenant admin or super admin can turn on **Store prompts and outputs** in **Usage › Credits and limits › Gateway settings**. With it on, the full text of every prompt and every output in the workspace is stored by Safeguard.
* Stored text is not shown in the Console. **Usage** shows how many prompts are stored.
* Turning the setting off stops storing new requests. It does not delete text stored while it was on.
* To delete it, a tenant admin or super admin selects **Delete stored prompts** on **Usage** and confirms. Every stored prompt and output in the workspace is deleted, and this cannot be undone.
* It applies to requests made under zero data retention too. ZDR concerns the provider's copy, not Safeguard's.
### API keys
Safeguard keeps a SHA-256 hash of each key, never the key itself. See [Security and compliance](/docs/console/security-and-compliance).
## No training on your data
Safeguard never uses your prompts, outputs or request logs to train models.
What a third-party provider may do with your data is set by that provider's terms. Each model's page summarizes them under **Data policy › Retention**. Some providers' terms allow training in some cases, for example on preview models, so read the page before you send sensitive data.
## Retention
| Record | Kept by | How long |
| ------------------------------------------------------------- | ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Request log (metadata) | Safeguard | Configurable; not yet enabled. Until Safeguard sets a period, it is kept until deleted. |
| Prompts and outputs, when **Store prompts and outputs** is on | Safeguard | Configurable; not yet enabled. Until Safeguard sets a period, they are kept until you delete them with **Delete stored prompts**. Once periods are set, a stored prompt is never kept longer than its log row. |
| Your prompts and outputs at the provider | The provider | Set by the provider's terms. See **Retention** and **Zero data retention** on the model's page. |
Once Safeguard sets the retention periods, a daily job deletes rows older than them. The credit ledger is a financial record and is not deleted. **Usage** shows the current retention under **Retention**.
To limit what providers keep, see [Zero data retention](/docs/console/zero-data-retention). To keep no copy of the text at Safeguard, leave **Store prompts and outputs** off.
## Legal and contacts
* Subprocessors: [trust.safeguard.sh/subprocessors](https://trust.safeguard.sh/subprocessors)
* Data Processing Agreement: [safeguard.sh/legal/dpa](https://safeguard.sh/legal/dpa)
* Privacy questions: [privacy@safeguard.sh](mailto:privacy@safeguard.sh)
## Related
* [Zero data retention](/docs/console/zero-data-retention)
* [Regions and data residency](/docs/console/regions-and-data-residency)
* [Security and compliance](/docs/console/security-and-compliance)
* [Bring your own model](/docs/console/bring-your-own-model)
# Procurement (/docs/console/procurement)
**Early access.** The API Platform is switched off by default, and Safeguard switches it on per workspace. To start, choose **Use with Safeguard** on a model at [safeguard.sh/models](https://safeguard.sh/models), or email [hi@safeguard.sh](mailto:hi@safeguard.sh).
## What you pay for
Model usage, at the provider's list price with no markup, paid from your workspace's prepaid credit. The inference API draws only on that credit, which is separate from your Safeguard plan. See [Pricing and billing](/docs/console/pricing-and-billing).
## Buying direct
Safeguard switches the API Platform on for your workspace and adds credit to it. Once card top-up is switched on, a tenant admin or super admin can also buy credit in the Console with a card, on Stripe's checkout page.
Safeguard's plans are on [safeguard.sh/pricing](https://safeguard.sh/pricing).
## Enterprise agreements
For committed volume or a dedicated deployment, email [hi@safeguard.sh](mailto:hi@safeguard.sh). For where a dedicated deployment can run, see [Deployment options](/docs/console/deployment-options).
## Buying through your cloud provider
Buying the API Platform through a cloud marketplace is not available yet. If your company buys software that way, for example to use committed cloud spend, tell Safeguard which marketplace you use. The Console has no marketplace option: credit comes from Safeguard or, once it is switched on, a card top-up.
## How Safeguard sources models
The gateway calls each third-party model's provider with Safeguard's own credentials, so you don't need an account with the provider. Before a model is sold, Safeguard confirms that the provider's terms allow it to resell the model at list price, and the gateway refuses the model until that is recorded.
To use a provider account you already have, see [Bring your own model](/docs/console/bring-your-own-model).
## For your vendor review
* Security and compliance status, subprocessors and documents on request: [Safeguard's Trust Center](https://trust.safeguard.sh)
* Data Processing Agreement: [safeguard.sh/legal/dpa](https://safeguard.sh/legal/dpa)
* How the API Platform handles your data: [Privacy and data](/docs/console/privacy-and-data) and [Security and compliance](/docs/console/security-and-compliance)
## Related
* [Pricing and billing](/docs/console/pricing-and-billing)
* [Deployment options](/docs/console/deployment-options)
* [Bring your own model](/docs/console/bring-your-own-model)
# Your own provider keys (/docs/console/provider-keys)
Provider keys are switched on per workspace by Safeguard, in addition to the API Platform itself. Where they are off, the panel is hidden and the API answers `403` with the code `feature_disabled`.
With your own provider key (often called BYOK), requests for that provider's models run on your account with the provider. The provider bills you directly; Safeguard charges nothing for those requests and reserves no credit for them. Your Safeguard key, spend limits on paid requests, rate limits, routing and the request log work as before.
## Add a key
1. In the Console, open **API keys**. **Provider keys** is below your keys. Only a tenant admin or super admin sees it.
2. Choose **Set** for a provider, paste the key and save.
| Provider route | |
| -------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ |
| `openai`, `anthropic`, `google`, `mistral`, `deepseek`, `xai`, `cohere`, `together`, `fireworks`, `groq` | Any of these can take your key. Safeguard's own models (`safeguard/…`) cannot. |
After you save, the key is never shown again, to you or to anyone else: the Console shows only its last four characters. It is kept in Safeguard's vault as a sealed credential that no person, workspace member or Safeguard administrator can list or reveal; only the gateway reads it, when it calls the provider for your workspace. **Replace** overwrites it, and **Delete** removes it.
You can switch a key off without deleting it. While it is off, requests use Safeguard's access to that provider where it is offered.
## How requests use it
When your workspace has an enabled key for a model's provider route, every request for that route, from an API key or the Workbench, runs on your key:
* the cost recorded for the request is $0, and no credit is reserved;
* the request log marks it as running on your key;
* the provider's own terms, limits and data handling under your account apply.
A model can run on your key even where it is not yet sold through Safeguard, as long as it is published in the catalog.
If the provider refuses your key (it is wrong, revoked or lacks access), the request fails with `502 upstream_auth` and the message "Your provider key was refused by the provider." The gateway never falls back to Safeguard's own access in that case, so a request you meant to pay for directly is never charged to your credit. If the key cannot be read, the request fails with `503`.
## Related
* [Privacy and data](/docs/console/privacy-and-data)
* [Pricing and billing](/docs/console/pricing-and-billing)
* [Errors](/docs/console/errors)
# Quickstart (/docs/console/quickstart)
The inference API is deployed but switched off while it is in early access. Open a model at [safeguard.sh/models](https://safeguard.sh/models) and choose **Use with Safeguard**; Safeguard then turns the API Platform on for your workspace. Until it is on, **Create key** in the Console is disabled, and requests are refused with `403 gateway_disabled`.
## 1. Get access
Choose **Use with Safeguard** on any model at [safeguard.sh/models](https://safeguard.sh/models) and leave your email address. Safeguard switches the API Platform on for your workspace. Requests spend your workspace's prepaid credit; while card top-up is not available, Safeguard adds the credit for you.
## 2. Create an API key
1. In the Safeguard web app, open the product switcher and choose **API Platform (Console)**, or press **G** then **5**.
2. Open **API keys** and choose **Create key**.
3. Give the key a name, such as `production backend`. You can also set a **Monthly spend limit (USD)** and a **Requests per minute** limit for this key; leave them empty for no spend limit and the default rate limit.
4. Choose **Create key**. The **Copy your key** dialog shows the full key. This is the only time it is shown, so copy it now.
Keep the key on your server, for example in an environment variable:
```bash
export SAFEGUARD_INFERENCE_KEY="sg-api-..."
```
The examples in these docs read the key from `SAFEGUARD_INFERENCE_KEY`. Any name works. We avoid `SAFEGUARD_API_KEY` because Safeguard's CI/CD scanning setup uses that name for a different kind of key.
## 3. Find a model id
List the models your key can call now:
```bash
curl https://api.safeguard.sh/gpt/v1/models \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY"
```
Each entry's `id` is a value you can pass as `model`. Ids have the form `provider/model`, the same ids the catalog at [safeguard.sh/models](https://safeguard.sh/models) shows, for example `openai/gpt-6-sol`. An empty list means no model is switched on for the API yet. See [Models](/docs/console/models).
## 4. Send your first request
Replace `MODEL_ID` with an id from step 3.
curl
Python
Node.js
```bash
curl https://api.safeguard.sh/gpt/v1/chat/completions \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "MODEL_ID",
"messages": [
{"role": "system", "content": "You are a concise assistant."},
{"role": "user", "content": "Explain what an SBOM is in two sentences."}
],
"max_tokens": 200
}'
```
```python
# pip install openai
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
response = client.chat.completions.create(
model="MODEL_ID",
messages=[
{"role": "system", "content": "You are a concise assistant."},
{"role": "user", "content": "Explain what an SBOM is in two sentences."},
],
max_tokens=200,
)
print(response.choices[0].message.content)
print(response.usage)
```
```js
// npm install openai (save as quickstart.mjs, then: node quickstart.mjs)
import OpenAI from 'openai';
const client = new OpenAI({
baseURL: 'https://api.safeguard.sh/gpt/v1',
apiKey: process.env.SAFEGUARD_INFERENCE_KEY,
});
const response = await client.chat.completions.create({
model: 'MODEL_ID',
messages: [
{ role: 'system', content: 'You are a concise assistant.' },
{ role: 'user', content: 'Explain what an SBOM is in two sentences.' },
],
max_tokens: 200,
});
console.log(response.choices[0].message.content);
console.log(response.usage);
```
## 5. Read the answer
The response has OpenAI's shape, plus two fields Safeguard adds: `provider` and `usage.cost`. The values below are illustrative.
```json
{
"id": "gen-6f1c2e0a9b4d4c7e8a1f3b5d7c9e0a2b",
"object": "chat.completion",
"created": 1791475000,
"model": "MODEL_ID",
"provider": "openai",
"choices": [
{
"index": 0,
"message": {
"role": "assistant",
"content": "An SBOM is a list of every component in a piece of software. It lets you see which versions you ship and which known vulnerabilities affect them."
},
"finish_reason": "stop"
}
],
"usage": {
"prompt_tokens": 27,
"completion_tokens": 33,
"total_tokens": 60,
"cost": 0.000159
}
}
```
* `id` is the request id: `gen-` followed by 32 hexadecimal characters. Safeguard records it with the request's log entry, so include it when you ask Safeguard about a request.
* `model` is the model that answered and `provider` is the provider route that served it.
* `usage.cost` is what this request cost in US dollars, at the provider's list price with no markup.
## 6. Check usage and credit
* In the Console, **Usage** shows requests, tokens and cost, a request log, and your credit balance. See [Usage and analytics](/docs/console/usage-and-analytics).
* From code, `GET /key` returns the calling key's limits, its spend this month and your workspace's available credit. See [Authentication](/docs/console/authentication#check-a-key).
## Next steps
* [Chat completions](/docs/console/chat-completions): every request and response field.
* [Streaming](/docs/console/streaming): tokens as they are generated.
* [Errors](/docs/console/errors): what each status means and which ones to retry.
* [Limits](/docs/console/limits): rate limits, spend limits and request sizes.
# Regions and data residency (/docs/console/regions-and-data-residency)
## Where inference runs
A third-party model runs on its provider's infrastructure, so a request to it leaves Safeguard for that provider. Where the provider processes the request is set by the provider's terms. Each model's page on [safeguard.sh/models](https://safeguard.sh/models) shows it under **Data policy › Region**.
What the catalog records for each provider:
| Provider | Region |
| ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| OpenAI | Global by default. OpenAI offers data residency in the US, the EU and other regions, with its approval and at a higher price for newer models. |
| Anthropic | Global by default. US-only inference is available at 1.1 times the price, for Claude 4.6 and later. |
| Google (Gemini API) | No region guarantee. Data may be stored briefly or cached in any country where Google operates. |
| Mistral AI | Global by default, with optional EU or US regional endpoints at 1.1 times the price. |
| xAI | No region guarantee on the default endpoint. A US regional endpoint is available for Grok 4.7 and Grok 4.6 at 1.1 times the price. |
| Cohere | Not stated. |
| DeepSeek | China (PRC). |
| Qwen (Alibaba Cloud) | Singapore, the international deployment whose prices the catalog lists. Other regions have separate price lists. |
| Meta | Depends on the host for its open-weight models. Not stated for the others. |
| Open-weight models served by a host | Set by the host. |
| Safeguard's models | The region your Safeguard workspace runs in. |
The catalog lists more models than the gateway can serve. `GET /gpt/v1/models` returns the ones you can call.
## The gateway does not choose a region
This version has no region setting. You can't choose or restrict the region for a request, a key or a workspace, and the providers' regional options in the table above can't be selected through the gateway.
The catalog can also give a model a `region` value. `GET /gpt/v1/models` returns it as `region`, and your request log records it with each request. It describes the model. It does not route requests.
## Where Safeguard stores your records
| Record | Stored in |
| -------------------------------------------------------------- | ---------------------------------- |
| Request log, credit ledger and gateway settings | Safeguard's billing service |
| Prompt and output text, if **Store prompts and outputs** is on | Safeguard's billing service |
| API key hashes, owners and limits | Safeguard's authentication service |
Both services run in the Safeguard deployment that hosts your workspace. Safeguard does not send these records to model providers. For where Safeguard's hosted service runs, see the FAQ on [Safeguard's Trust Center](https://trust.safeguard.sh/faq).
## Countries where Safeguard's own models are offered
Griffin, Eagle, Lion and Zero are available in 245 countries and territories (the ISO 3166-1 list minus the exclusions). They are not offered in Cuba, Iran, North Korea or Syria, nor in the Crimea region of Ukraine or the so-called Donetsk People's Republic (DNR) and Luhansk People's Republic (LNR) regions of Ukraine. None of them can be called through the API yet. See [Safeguard models](/docs/console/safeguard-models#where-they-run).
## Keeping inference in one place
The Safeguard platform can run Safeguard's models and open-weight models inside an environment you control. Through the API Platform, that is not available yet: catalog models are served by their providers or hosts, and Safeguard's own models cannot be called yet. See [Deployment options](/docs/console/deployment-options).
## Related
* [Privacy and data](/docs/console/privacy-and-data)
* [Zero data retention](/docs/console/zero-data-retention)
* [Deployment options](/docs/console/deployment-options)
# Reliability and fallbacks (/docs/console/reliability-and-fallbacks)
By default the gateway calls the requested model's provider once for each request and returns what happens: it does not retry a failed call or try another model, and the provider SDK's own retries are turned off. The one exception is a parameter the provider rejects, which the gateway adjusts and sends again to the same provider (see [Chat completions](/docs/console/chat-completions#when-a-provider-rejects-a-parameter)). You can opt in to one retry and to fallbacks within the same model family. Your client should still retry the errors that are worth retrying.
## Retries and fallbacks are opt-in
Retries and fallbacks are off by default. You can turn them on in two places:
* **For the workspace.** A tenant admin or super admin turns on **Allow retries and fallbacks** under **Usage**, **Credits and limits**, **Gateway settings**.
* **For one request.** Send `provider.allow_fallbacks` in the request body. It overrides the workspace setting in either direction, so a request can also turn them off.
```bash
curl https://api.safeguard.sh/gpt/v1/chat/completions \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "MODEL_ID",
"messages": [{"role": "user", "content": "Hello"}],
"provider": {"allow_fallbacks": true}
}'
```
When they are off, a provider failure comes straight back to you.
## What happens when they are on
1. If the provider returns a server error, does not answer in time, cannot be reached or rate limits the call, the gateway tries the same model once more.
2. If that fails too, it moves on to the model's fallbacks, in order. Each fallback gets the same single retry.
3. If the provider refuses Safeguard's credentials, the gateway skips the retry and moves straight to the next fallback.
4. If the provider rejects the request as invalid (`upstream_rejected`), the gateway stops. That request is never retried and never sent to a fallback.
Fallbacks follow strict rules:
* Safeguard lists the fallbacks for each model in its model catalog. You cannot choose them.
* A fallback is only ever a model from the same family, meaning the same model maker, or the same model served by another host.
* A fallback has to be available through the API in its own right. If your workspace or the request requires zero data retention, the fallback has to offer it too.
* A fallback is billed at its own price. The credit hold before the call covers the most expensive model the request might use.
* The response tells you what answered: `model` is the model that served the request, and `provider` names the provider the gateway called. The request log lists the request under that model.
For a streamed request, retries and fallbacks happen only before the first chunk reaches you. After that, see [Streams that fail partway](#streams-that-fail-partway).
## No fallback to Safeguard's platform providers
Your requests go only to the provider of the model you asked for, or of one of its listed fallbacks. They never fall back to the providers behind Safeguard's own AI features. The gateway calls providers with its own credentials, kept apart from the ones those features use, and automated tests check that the two paths stay separate.
## Timeouts
* Safeguard sets how long the gateway waits for each provider. The default is 120 seconds, and no provider gets more than 600 seconds. A provider that does not answer in time gives you a 504 `upstream_timeout`.
* A streamed response is cut off after 15 minutes in total. The stream then ends with an `upstream_timeout` error event.
* With retries and fallbacks on, one request can make several attempts, each with its own timeout. Set your client's timeout with that in mind, or stream the response.
## Retrying in your client
Retry only the errors that can succeed on a second try, and wait between attempts.
| Response | Retry? | How long to wait |
| ------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| 429 `rate_limited` | Yes | The `Retry-After` header: the seconds until your key's one-minute window has room again. A refused request does not count toward the limit. |
| 429 `upstream_rate_limited` | Yes | `Retry-After` is 5 seconds. Back off further if it repeats. |
| 502 `upstream_error`, 504 `upstream_timeout` | Yes, a few times | Exponential backoff with jitter. |
| 503 `auth_unavailable`, 503 `billing_unavailable` | Yes | Exponential backoff with jitter. |
| 503 `model_unavailable` | Only when the message says the catalog is temporarily unavailable | Exponential backoff. For any other message, pick another model. |
| 500 `internal_error` | Once or twice | Exponential backoff. |
| 502 `upstream_auth` | No | The provider refused Safeguard's credentials. Try another model. |
| 400, 401, 402, 403, 404, 413 | No | Fix the request, the key, the credit or the limit first. |
* When `Retry-After` is present, wait at least that many seconds. It is a whole number.
* Otherwise, use exponential backoff with jitter, for example about 1, 2 and then 4 seconds plus a random fraction, and cap the number of attempts.
* Each retry is a new request, with its own credit hold and its own charge.
* OpenAI's SDKs can retry some of these responses on their own (`max_retries` in Python, `maxRetries` in Node). Check that setting, so you do not run two retry loops at once.
A small retry loop in Python:
```python
import os
import random
import time
import httpx
URL = "https://api.safeguard.sh/gpt/v1/chat/completions"
RETRY = {
"rate_limited", "upstream_rate_limited", "upstream_error", "upstream_timeout",
"auth_unavailable", "billing_unavailable", "internal_error",
}
def create(body, attempts=4):
headers = {"Authorization": f"Bearer {os.environ['SAFEGUARD_INFERENCE_KEY']}"}
for attempt in range(attempts):
r = httpx.post(URL, json=body, headers=headers, timeout=300)
if r.status_code < 400:
return r.json()
try:
code = r.json()["error"]["code"]
except (ValueError, KeyError, TypeError):
code = None
if code not in RETRY or attempt == attempts - 1:
r.raise_for_status()
wait = r.headers.get("Retry-After")
time.sleep(int(wait) if wait else 2 ** attempt + random.random())
```
## Streams that fail partway
Once the first chunk is on its way, the HTTP status is already 200. If the provider fails after that, the stream ends with an error event, followed by `[DONE]`:
```text
data: {"error": {"message": "The provider stream ended with an error.", "type": "api_error", "code": "upstream_error", "param": null}}
data: [DONE]
```
Treat the answer as incomplete. The tokens produced before the failure are charged, from the provider's usage figures or, when it sent none, the gateway's estimate. If you asked for usage with `stream_options.include_usage`, the final usage chunk still arrives before `[DONE]`. See [Streaming](/docs/console/streaming).
Closing the connection does not stop the charge. If your client disconnects mid-stream, the gateway keeps reading the provider's answer to the end, up to the 15-minute cap, and charges for all of it. The request log shows `client_disconnected`. To keep answers short, set `max_tokens`.
## Related
* [Streaming](/docs/console/streaming)
* [Errors](/docs/console/errors)
* [Request lifecycle](/docs/console/request-lifecycle)
* [Troubleshooting](/docs/console/troubleshooting)
# Request lifecycle (/docs/console/request-lifecycle)
Every call to `POST /gpt/v1/chat/completions` goes through the same steps in the same order. The order tells you which error you get when more than one thing is wrong, and when you start paying. Until step 7 nothing has been sent to a provider, nothing is charged and nothing is written to the request log.
**Early access.** The inference gateway is deployed but switched off. Safeguard switches it on per workspace. Until it is on for yours, requests stop at step 2.
## 1. Check the key
* The gateway reads the key from the `Authorization: Bearer` header. A value that is not a well-formed `sg-api-` key is refused at once with 401 `invalid_api_key`.
* Otherwise it asks Safeguard's authentication service whose key it is. The same 401 comes back for an unknown, revoked or expired key, a key without the `inference` scope, and a key whose owner is no longer an active member. The response never says which.
* Once a key checks out, the gateway trusts it for up to 30 seconds before asking again. That is why revoking a key takes up to 30 seconds. An unknown key is not remembered, so a key you have just created works at once.
* If the authentication service cannot be reached, the answer is 503 `auth_unavailable`.
Sign-in tokens, admin sessions and other kinds of Safeguard key are not accepted on this API.
## 2. Check that the API is on
The gateway has to be switched on as a whole and for your workspace. If either is off, the answer is 403 `gateway_disabled`. The gateway reads your workspace's switch from Safeguard's authentication service at most once a minute. If it cannot read it, it treats the switch as off.
## 3. Check the request body
The body must be JSON of at most 8 MiB, with a `model` and a non-empty `messages` array of text messages. A body that breaks the rules gets 400 `invalid_request` or `unsupported_parameter`. A body over the size limit gets 413 `request_too_large`. The fields are listed in [Chat completions](/docs/console/chat-completions).
## 4. Apply the rate limit
Each key may send a set number of requests per minute: 60, unless you chose another number for the key. Over the limit, the answer is 429 `rate_limited` with a `Retry-After` header.
## 5. Check the model
* The gateway looks up `model` in Safeguard's model catalog. A model that is not there gets 404 `model_not_found`. Models that are not published in the catalog are never served.
* The model also has to be available through the API right now. All of these must hold:
* the catalog lists it as available, with both an input price and an output price;
* Safeguard has credentials set up for its provider;
* for a third-party provider, Safeguard has confirmed that the provider's terms allow resale, listed the provider on its Trust Center subprocessor list, and updated its DPA, privacy notice and AI disclosure;
* a real end-to-end call to that model, through that provider, has succeeded.
* If your workspace or the request requires zero data retention, the model must offer it.
* A model that fails any of these gets 503 `model_unavailable`. With retries and fallbacks on, each listed fallback goes through the same checks.
If the gateway cannot read the provider checklist and verification records, it treats every model as unavailable. It reads them, and the catalog, at most once a minute. If the catalog itself cannot be read, the gateway keeps using its last copy for up to 10 minutes, and after that answers 503.
`GET /gpt/v1/models` lists the models available through the API now. See [Models](/docs/console/models).
## 6. Hold credit
* The gateway works out the most the request could cost: a deliberately high estimate of the input tokens, plus every output token the request allows, at the price of the most expensive model it might use.
* `max_tokens` sets the output allowance. Without it, the gateway uses 4,096 tokens, or the model's own maximum output when that is lower.
* Safeguard's billing service holds that amount against your credit. It checks your balance, then the key's monthly limit, then the workspace's monthly limit. If the hold does not fit, the answer is a 402 that names the reason. See [Spend controls](/docs/console/spend-controls).
* If the billing service cannot be reached, the answer is 503 `billing_unavailable`. The gateway does not serve a request it cannot meter.
## 7. Call the provider
* The gateway sends your messages and the supported parameters to the provider, using Safeguard's credentials for that provider. The `user` field is not passed on.
* It always sends a token cap: your `max_tokens`, lowered to the model's maximum output if it is above that, or the default from step 6.
* For models served through Anthropic's API, only `temperature`, `tools` and `tool_choice` are passed on from the optional parameters.
* On a zero data retention request to OpenAI, it also sends `store: false`.
* It makes one attempt, unless retries and fallbacks are on. If the provider rejects a parameter, the gateway adjusts it and sends the request again to the same provider; see [Chat completions](/docs/console/chat-completions#when-a-provider-rejects-a-parameter). Each attempt has the provider's timeout, 120 seconds by default. See [Reliability and fallbacks](/docs/console/reliability-and-fallbacks).
* When a provider fails, the gateway writes its own error from the provider's HTTP status. The provider's error text is never passed through.
## 8. Settle the cost
* The cost is the provider's token counts times the model's list price, with no markup, worked out to 8 decimal places. Cached input tokens are priced at the catalog's cached-input price where it lists one, and at the input price otherwise.
* The billing service releases the hold and charges the cost. A request that failed before the provider produced anything is charged $0.
* If the provider reported no usage, the gateway estimates the tokens and adds `"estimated": true` to the response's `usage`.
* The response carries `usage.cost` in USD, and `provider`, which names the provider the gateway called. Its `id` is the request's id, which starts with `gen-`, and the `X-Generation-Id` header carries the same id, streamed or not. An error after this point, from the provider call, carries that header too.
* For a stream, the gateway reads the provider's answer to the end even if your client disconnects, and settles from the provider's own figures.
* If the settlement cannot be recorded, the gateway tries once more. A hold that is never settled is released after about 30 minutes.
## 9. Write the log row
Settlement writes one row to your workspace's request log. The row holds metadata only:
* the time (stored in UTC), the source (`api` or `workbench`), and the key with its name and masked form as they were at the time;
* the model, the provider and the model's region, plus the original model when a fallback answered;
* the status, the HTTP status, any error code and how many attempts were made;
* input, output and cached input tokens, and whether they were estimated;
* the cost, the latency and, for a stream, the time to the first token;
* whether the response was streamed and whether zero data retention applied.
The row holds no prompt and no output. Prompts and outputs are stored, separately, only if a tenant admin or super admin has turned on **Store prompts and outputs**. See [Privacy and data](/docs/console/privacy-and-data). The Console shows these rows on **Usage**. See [Usage and analytics](/docs/console/usage-and-analytics).
## Workbench runs
The Console's Workbench goes through the same steps, with a few differences:
* There is no key. You are signed in, and the run is charged to your workspace's credit.
* With no key, there is no key limit: only the balance and the workspace limit apply.
* The rate limit is 60 runs a minute for each person.
* Runs are logged with the source `workbench`.
## Related
* [Chat completions](/docs/console/chat-completions)
* [Reliability and fallbacks](/docs/console/reliability-and-fallbacks)
* [Spend controls](/docs/console/spend-controls)
* [Privacy and data](/docs/console/privacy-and-data)
# Routing (/docs/console/routing)
Routing is switched on per workspace by Safeguard, in addition to the API Platform itself. Where it is off, a request that uses any routing field is refused with `400 unsupported_parameter` and the field named in `param`. The gateway never ignores a routing field silently.
Routing works on [chat completions](/docs/console/chat-completions) and [completions](/docs/console/completions). It does not apply to [embeddings](/docs/console/embeddings), because vectors from different models cannot be mixed, or to your own models (`custom:`).
## Fields
```json
{
"model": "anthropic/claude-sonnet-5-5",
"models": ["openai/gpt-6-sol", "google/gemini-3.5-flash"],
"provider": {
"order": ["anthropic", "openai"],
"only": ["anthropic", "openai", "google"],
"ignore": ["groq"],
"sort": "price",
"allow_fallbacks": true,
"zdr": false
},
"messages": [{ "role": "user", "content": "Hello" }]
}
```
| Field | Type | Meaning |
| -------------------------- | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `models` | array of model ids | Candidates to try after `model`, in your order. Any provider or family. You may leave `model` out, and the first entry is used. By default up to 5 extra models; the platform limit is shown in the error if you send more. |
| `provider.order` | array of provider routes | Routes to prefer, in this order, among the candidates. |
| `provider.only` | array of provider routes | Keep only candidates on these routes. |
| `provider.ignore` | array of provider routes | Drop candidates on these routes. |
| `provider.sort` | `price`, `latency` or `uptime` | Sort the candidates automatically. See [Sorting](#sorting). |
| `provider.allow_fallbacks` | boolean | As before: whether the gateway may retry and move on when a provider fails. See [Reliability and fallbacks](/docs/console/reliability-and-fallbacks). |
| `provider.zdr` | boolean | As before: only models offered with zero data retention. |
A provider route is the API the gateway calls for a model, such as `openai`, `anthropic`, `google`, `mistral`, `deepseek`, `xai`, `cohere`, `together`, `fireworks` or `groq`. The route is not always the model's publisher: an open-weight model can be hosted on several routes.
## How the candidates are built
1. `model`, then each entry of `models`, in your order.
2. After each of them, the same model on other routes (the same weights, another host), when you set `sort`, `order` or `only`, or when fallbacks are allowed.
3. When fallbacks are allowed, the model's listed fallbacks of the same family, as before.
Then `only` and `ignore` filter by route, and every candidate must be one the API Platform can serve for your workspace (and offer zero data retention when you asked for it). If nothing is left, the answer is `503 model_unavailable`. A model id in `models` that does not exist is `404 model_not_found` with `param: "models"`.
## Sorting
The candidates are ordered by `sort` (or the platform default, which is none unless Safeguard sets one), then by `order`, then in the order above. Ties keep their order.
| `sort` | First | Measured how |
| --------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `price` | the smallest estimated cost for this request | your input tokens, estimated, times the input price, plus your `max_tokens` (or the model's output limit) times the output price, at each provider's list price with no markup |
| `latency` | the fastest | the median end-to-end latency of successful requests through the gateway over the last 24 hours, across all workspaces |
| `uptime` | the most reliable | the share of requests over the last 24 hours that did not fail at the provider (provider errors, timeouts, refused credentials and provider rate limits) |
A model with no price, or with too few recent requests to measure, sorts last. Latency and uptime are measured only from real traffic through the gateway; nothing is estimated or copied from elsewhere, so a new model has no figure until it has been used.
## What happens when a provider fails
The gateway calls the first candidate. If the provider fails before anything is streamed (a timeout, a connection failure, a provider error or a provider rate limit), it moves to the next candidate when:
* fallbacks are allowed (`provider.allow_fallbacks`, or the workspace setting), or
* you listed `models` yourself and did not set `allow_fallbacks: false`.
Retrying the same model once happens only when fallbacks are allowed. Once text has been streamed, the gateway never switches models in the middle of an answer.
## Which model answered
The response's `model` field is the model that actually answered, and the `X-Route` response header is the provider route that served it. Each request is billed at the list price of the model and route that served it, with no markup. The [request log](/docs/console/usage-and-analytics) records the route and the sort that chose it.
## Example
curl
Python
Node.js
```bash
curl https://api.safeguard.sh/gpt/v1/chat/completions \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-d '{
"models": ["openai/gpt-6-sol", "anthropic/claude-sonnet-5-5"],
"provider": { "sort": "uptime" },
"messages": [{ "role": "user", "content": "Summarise SBOMs in one sentence." }]
}' -i
```
```python
from openai import OpenAI
import os
client = OpenAI(base_url="https://api.safeguard.sh/gpt/v1", api_key=os.environ["SAFEGUARD_INFERENCE_KEY"])
resp = client.chat.completions.with_raw_response.create(
model="openai/gpt-6-sol",
messages=[{"role": "user", "content": "Summarise SBOMs in one sentence."}],
extra_body={"models": ["anthropic/claude-sonnet-5-5"], "provider": {"sort": "price"}},
)
print(resp.headers.get("x-route"), resp.parse().model)
```
```js
import OpenAI from "openai";
const client = new OpenAI({ baseURL: "https://api.safeguard.sh/gpt/v1", apiKey: process.env.SAFEGUARD_INFERENCE_KEY });
const { data, response } = await client.chat.completions
.create({
model: "openai/gpt-6-sol",
messages: [{ role: "user", content: "Summarise SBOMs in one sentence." }],
models: ["anthropic/claude-sonnet-5-5"],
provider: { sort: "latency" },
})
.withResponse();
console.log(response.headers.get("x-route"), data.model);
```
The Console Workbench builds these requests for you: pick fallback models and a sort, and copy the code it shows.
# Safeguard models (/docs/console/safeguard-models)
Safeguard builds its own security models. The catalog at [safeguard.sh/models](https://safeguard.sh/models) lists them next to the third-party models: three models (Griffin, Eagle and Lion) and Zero, which answers data questions with no model at all.
None of Safeguard's own models can be called through the inference API yet. `GET /models?all=true` lists them with their current status.
## The lineup
| Model | Model id | What it is for | Parameters | Context window | Catalog price per million tokens |
| ----------- | ------------------- | ------------------------------------------------------------------------------------------------ | ------------------------------- | ------------------------------ | --------------------------------- |
| **Griffin** | `safeguard/griffin` | Remediation and reasoning: reachability, patch authoring and fix pull requests. | 750 billion | 1.1 million tokens (1,100,000) | $0.0001 input, $0.0001 output |
| **Eagle** | `safeguard/eagle` | Discovery and triage: malicious package and typosquat classification, and path ranking. | 70 billion | 1 million tokens (1,000,000) | $0.00001 input, $0.00001 output |
| **Lion** | `safeguard/lion` | Compliance and narrative work: evidence mapping, audit summaries and policy drafting. | 15 billion | 128K tokens (128,000) | $0.000001 input, $0.000001 output |
| **Zero** | `safeguard/zero` | Data questions with no model at all: it reads a question into a deterministic, replayable query. | None: Zero has no model weights | Not applicable | $0. Zero uses no model tokens. |
Griffin, Eagle and Lion are one model each. None of them comes in sizes: there is no Lite, S, M, L or XL.
Each has a page in the catalog: [Griffin](https://safeguard.sh/models/griffin), [Eagle](https://safeguard.sh/models/eagle), [Lion](https://safeguard.sh/models/lion) and [Zero](https://safeguard.sh/models/zero).
## Zero uses no model tokens
Zero has no model weights. It turns a question about your data into a deterministic query that can be replayed, and runs that query in process on the Safeguard platform. No language model is called and no model tokens are consumed, which is why its catalog price is $0 per million tokens.
## Where they run
On the Safeguard platform, all four can run on-prem, air-gapped, in a private cloud (VPC) and in public cloud. See [Deployment options](/docs/console/deployment-options).
They are available in 245 countries and territories (the ISO 3166-1 list minus the exclusions). They are not offered in Cuba, Iran, North Korea or Syria, nor in the Crimea region of Ukraine or the so-called Donetsk People's Republic (DNR) and Luhansk People's Republic (LNR) regions of Ukraine.
Through the API Platform, none of them can be called yet, in any of these options.
## How their data is handled
The catalog's data policy for these models says:
| | Griffin, Eagle and Lion | Zero |
| ---------------- | --------------------------------------------------- | ---------------------------------------------------------------------------------- |
| Where prompts go | Safeguard, on its own infrastructure | Nowhere: Zero runs in process on the Safeguard platform |
| Training | Customer data is never used to train shared models. | No model provider is involved. Customer data is never used to train shared models. |
| Region | The region your Safeguard workspace runs in | The region your Safeguard workspace runs in |
## Through the API
* Their catalog status is not yet `available`, so a request naming one is refused with `503 model_unavailable`.
* Through the API, Safeguard's own models are served only by Safeguard-hosted inference, never by a third-party provider.
* Because no third party receives the prompts, the third-party launch checklist does not apply to them. They still need a successful end-to-end test call before they can be called. See [Models](/docs/console/models#how-a-model-becomes-callable).
* When they become callable, they use the same endpoint, request format and billing as every other model, at the catalog prices above.
## In the rest of Safeguard
These models also appear across the Safeguard platform. The [Griffin AI](/docs/griffin-ai) and [AI Models](/docs/ai-models) pages describe them there; the AI Models page calls the compliance model Lino, which is Lion in the catalog.
## Related
* [Models](/docs/console/models)
* [Choosing a model](/docs/console/choosing-a-model)
* [Pricing and billing](/docs/console/pricing-and-billing)
* [Deployment options](/docs/console/deployment-options)
# SDKs and clients (/docs/console/sdks-and-clients)
The inference API speaks OpenAI's Chat Completions format, so you do not need a Safeguard SDK. Any client that lets you set the base URL and the API key can call it.
| Setting | Value |
| -------- | --------------------------------------------------------------------------------------------------------------- |
| Base URL | `https://api.safeguard.sh/gpt/v1` |
| API key | Your `sg-api-…` key, sent as `Authorization: Bearer `. See [Authentication](/docs/console/authentication). |
| Model | A model id from [`GET /models`](/docs/console/models), such as `openai/gpt-6-sol`. |
Write the base URL as shown, without a trailing slash.
## OpenAI Python SDK
```bash
pip install openai
```
Sync
Async
```python
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
response = client.chat.completions.create(
model="MODEL_ID",
messages=[{"role": "user", "content": "List three ways to reduce dependency risk."}],
max_tokens=300,
)
print(response.choices[0].message.content)
print("served by", response.provider, "for $", response.usage.cost)
```
```python
import asyncio
import os
from openai import AsyncOpenAI
client = AsyncOpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
async def main():
response = await client.chat.completions.create(
model="MODEL_ID",
messages=[{"role": "user", "content": "List three ways to reduce dependency risk."}],
max_tokens=300,
)
print(response.choices[0].message.content)
asyncio.run(main())
```
`provider` and `usage.cost` are Safeguard's additions to OpenAI's response. The Python SDK keeps fields it does not know, so you can read them as attributes, as above.
## OpenAI Node.js SDK
```bash
npm install openai
```
```js
import OpenAI from 'openai';
const client = new OpenAI({
baseURL: 'https://api.safeguard.sh/gpt/v1',
apiKey: process.env.SAFEGUARD_INFERENCE_KEY,
});
const response = await client.chat.completions.create({
model: 'MODEL_ID',
messages: [{ role: 'user', content: 'List three ways to reduce dependency risk.' }],
max_tokens: 300,
});
console.log(response.choices[0].message.content);
console.log('served by', response.provider, 'for $', response.usage.cost);
```
Run it as an ES module, for example saved as `example.mjs`. In TypeScript, `provider` and `usage.cost` are not in the SDK's types, so read them through a cast such as `(response.usage as { cost?: number }).cost`.
## Configure with environment variables
Both OpenAI SDKs read `OPENAI_BASE_URL` and `OPENAI_API_KEY` when you create a client without arguments. That helps with tools built on the SDKs that let you set environment variables but not code:
```bash
export OPENAI_BASE_URL="https://api.safeguard.sh/gpt/v1"
export OPENAI_API_KEY="sg-api-..."
```
Set them only for the process that should use Safeguard, so they do not redirect other tools on the same machine.
## curl and other HTTP clients
Any HTTP client works. Send JSON to `POST /chat/completions` with the two headers:
```bash
curl https://api.safeguard.sh/gpt/v1/chat/completions \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "MODEL_ID", "messages": [{"role": "user", "content": "Hello"}]}'
```
For streaming, read the response as server-sent events: one `data:` line per chunk, ending with `data: [DONE]`. See [Streaming](/docs/console/streaming).
## Any OpenAI-compatible client
A library or tool that talks to OpenAI's Chat Completions API can work with Safeguard when:
* it lets you set the base URL to `https://api.safeguard.sh/gpt/v1` and the API key to your `sg-api-` key;
* it uses `/chat/completions`, not OpenAI's other APIs;
* it sends text, one choice at a time.
What the API serves is `POST /chat/completions`, `GET /models`, `GET /models/{id}` and `GET /key`. Features that need other OpenAI endpoints, such as the Responses API, Assistants, embeddings, images, audio, files, batches or moderations, are not available. We have not tested other frameworks and tools, so check them against [Chat completions](/docs/console/chat-completions) before you rely on them.
## Practical notes
* **Keep the key on a server.** Never call the API from browser code or a mobile app: anyone who can read the app can read the key. See [Key management best practices](/docs/console/key-management-best-practices).
* **Newer parameters.** Older SDK versions may not accept newer parameters such as `stream_options` or `max_completion_tokens`. Upgrade, or pass the field through `extra_body` in Python.
* **Timeouts.** The gateway waits up to 120 seconds for a provider, and a stream can run for up to 900 seconds. Give your client a timeout longer than you expect the model to take.
* **Automatic retries.** If your client retries failed requests on its own, each retry is a separate request, and one that gets an answer is billed. The OpenAI SDKs let you set this with `max_retries` (Python) and `maxRetries` (Node.js). See [Errors](/docs/console/errors#how-to-retry).
* **Request ids.** Every chat response's `id` is its request id (`gen-…`), and the `X-Generation-Id` response header carries the same id, streamed or not. Log it with your own records. The separate `X-Request-Id` header is an internal id for Safeguard's audit trail.
# Security and compliance (/docs/console/security-and-compliance)
## In transit
The API accepts requests only over HTTPS. Plain HTTP connections and TLS versions older than 1.2 are refused. The gateway calls third-party providers over HTTPS.
## API keys
* A key is `sg-api-` followed by 64 hexadecimal characters, made from 32 random bytes.
* The full key is shown once, when you create it. Safeguard stores only its SHA-256 hash, and from then on the Console shows the key masked, as its start and end. A lost key can't be recovered: revoke it and create a new one.
* A key has one scope, `inference`. It works only with the API Platform, and nothing else in Safeguard accepts it.
* A key belongs to the member who created it. On **API keys**, the owner can rename it, change its monthly spend limit and its requests-per-minute limit, or revoke it.
* Requests with a revoked key are refused within 30 seconds.
* Keys can be created only while the API Platform is switched on for the workspace. Auditors, whose access is read-only, can't create them.
* Send the key as `Authorization: Bearer` followed by the key. A missing, malformed, unknown, revoked or expired key gets the same `401 invalid_api_key`, which doesn't say which of these it was.
## Checks that fail closed
If the gateway can't confirm something it needs, it refuses the request instead of guessing:
| If the gateway can't check | The request |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| The API key | Is refused with `503 auth_unavailable`. |
| Your credit | Is refused with `503 billing_unavailable`. It is never served unmetered. |
| Whether the API Platform is on for your workspace | Is treated as off: `403 gateway_disabled`. |
| The providers' launch checks | Is refused with `503 model_unavailable`: no model is served until the checks can be read. |
| The model catalog, for more than ten minutes | Is refused with `503 model_unavailable`. |
## Isolation
The gateway is kept apart from the rest of Safeguard. It never routes requests through the AI provider chain behind Safeguard's own product features, and it reads none of your workspace's security data. Automated tests enforce that boundary.
Provider error messages are never copied into responses. A provider failure is reported by its status code only, so a provider that echoes your request back can't leak it through Safeguard. Safeguard's credentials for each provider are held by the gateway and are never logged or returned.
## Launch checks for each provider
Before a third-party model is served, Safeguard records three checks for its provider: the provider's terms allow resale at list price, the provider is on the [Trust Center subprocessor list](https://trust.safeguard.sh/subprocessors), and Safeguard's DPA, privacy notice and AI disclosure cover it. Each change to a check needs a note and is recorded with who made it and when. The model also needs a successful end-to-end test call on its current route. The gateway applies all of this on every request.
## Audit trail
| Event | Where it is recorded |
| ------------------------------------ | ---------------------------------------------------------------------------------------- |
| A key is created, changed or revoked | Safeguard's audit trail, with the key's ID. The key itself is never recorded. |
| A request | Your request log: metadata only. See [Privacy and data](/docs/console/privacy-and-data). |
| Credit is added or used | The credit ledger, with the balance after each entry. |
| A provider's launch check changes | With who changed it, when, and the note explaining why. |
| A model in the catalog changes | Every create, update, archive and restore, with the values before and after. |
## Compliance
Safeguard publishes the status of its compliance frameworks, including SOC2 Type 1 and SOC2 Type 2, on its [Trust Center](https://trust.safeguard.sh). Restricted documents such as audit reports are released there through **Request access**, after Safeguard reviews the request.
The API Platform is new and in early access. Before you rely on a report for it, check that the report's scope covers it.
## Report a security issue
Email [security@safeguard.sh](mailto:security@safeguard.sh), and see the [responsible disclosure policy](https://safeguard.sh/legal/responsible-disclosure-policy).
## Related
* [Authentication](/docs/console/authentication)
* [Privacy and data](/docs/console/privacy-and-data)
* [Deployment options](/docs/console/deployment-options)
* [Status and support](/docs/console/status-and-support)
# Spend controls (/docs/console/spend-controls)
Three things can stop a request from spending: your prepaid balance, a monthly limit on the key, and a monthly limit on the whole workspace. The gateway checks all of them before it calls a provider. A refused request costs nothing.
**Early access.** The inference gateway is deployed but switched off. Safeguard switches it on per workspace, and these controls apply from then on.
## How the checks work
Before each request, the gateway holds the most the request could cost (see [how a request is charged](/docs/console/credits-and-invoices#how-a-request-is-charged)). The hold must pass these checks, in this order:
1. **Balance.** Your available credit, which is the balance minus what requests in flight hold, must cover the hold. At a balance of zero or less, every request is refused.
2. **The key's monthly limit**, if the key has one. What the key has spent this month, plus what its requests in flight hold, plus this request's hold, must stay within the limit.
3. **The workspace's monthly limit**, if one is set. The same sum for the whole workspace, Workbench runs included.
The first check that fails decides the error you get. Months are UTC calendar months, so monthly spend starts again at 00:00 UTC on the 1st.
The checks use the most a request could cost, so a request can be refused while a little credit or headroom is left. A smaller `max_tokens` makes the hold smaller. If you leave `max_tokens` out, the gateway uses 4,096 output tokens, or the model's own maximum when that is lower, for both the hold and the call. Requests in flight at the same time each hold their own amount.
## The 402 responses
All three refusals are HTTP 402 with the type `insufficient_quota`:
| `code` | Message | What to do |
| ------------------------------ | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------ |
| `insufficient_credit` | Not enough credit for this request. Add credit in the Console, or lower max\_tokens. | Add credit, or lower `max_tokens`. |
| `key_spend_limit_exceeded` | This API key's monthly spend limit would be exceeded. | Raise or clear the key's limit, use another key, or wait for next month. |
| `account_spend_limit_exceeded` | Your account's monthly spend limit would be exceeded. | Ask a tenant admin or super admin to raise or clear the workspace limit. |
```json
{
"error": {
"message": "This API key's monthly spend limit would be exceeded.",
"type": "insufficient_quota",
"code": "key_spend_limit_exceeded",
"param": null
}
}
```
Retrying a 402 unchanged rarely helps. It keeps failing until credit is added, a limit changes, or requests in flight finish and release what they hold.
## Limit a key
Set a limit when you create a key: on **API keys**, select **Create key** and fill in **Monthly spend limit (USD, optional)**. To change it later, select **Edit** on the key's row. Leave the field empty for no limit. The Console takes dollars and cents, above zero.
The **This month** column on **API keys** shows each key's spend against its limit. The bar turns red at 90%.
A change to a key's limit reaches the gateway within 30 seconds.
Your code can read the calling key's limit and spend:
```bash
curl https://api.safeguard.sh/gpt/v1/key \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY"
```
| Field in `data` | What it is |
| ------------------------- | -------------------------------------------------------- |
| `monthly_spend_limit_usd` | The key's monthly limit as a string, or `null` for none. |
| `month_spent_usd` | What this key has spent in the current UTC month. |
| `available_credit_usd` | Your workspace's available credit. |
| `month` | The current month, as `YYYY-MM`. |
The response also carries the key's `name`, `prefix`, `scopes` and `rate_limit_rpm`. If the billing service cannot be reached, the spend and credit fields are left out. The workspace limit is not part of this response.
## Limit the workspace
A tenant admin or super admin sets the workspace limit. Open **Usage**, go to **Credits and limits**, and under **Gateway settings** fill in **Workspace monthly spend limit (USD)**, then select **Save settings**. In the Console's words: "Requests that would pass it are refused." Leave it empty for no limit.
The limit applies from the next request. The **Spent this month** card shows how much of it is used.
## Raise a limit
| Refusal | Who fixes it | How |
| ------------------------------ | ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| `insufficient_credit` | A tenant admin or super admin, or Safeguard | Add credit. See [Credits and invoices](/docs/console/credits-and-invoices). |
| `key_spend_limit_exceeded` | The key's owner | On **API keys**, select **Edit**, raise or clear **Monthly spend limit (USD)**, and select **Save**. It takes effect within 30 seconds. |
| `account_spend_limit_exceeded` | A tenant admin or super admin | Under **Gateway settings**, raise or clear the workspace limit and select **Save settings**. It takes effect at once. |
In the Workbench, these errors come with a shortcut to the right place: **Open limits** for a limit, and **Add credit** for credit once card top-up is on.
## Rate limits are separate
Each key also has a limit on requests per minute: 60 unless you set another number, up to 10,000. It guards against runaway clients and is approximate, so it is not a way to cap spend. A request over it gets a 429 with a `Retry-After` header. See [Limits](/docs/console/limits).
## Related
* [Credits and invoices](/docs/console/credits-and-invoices)
* [Key management best practices](/docs/console/key-management-best-practices)
* [Errors](/docs/console/errors)
* [Troubleshooting](/docs/console/troubleshooting)
# Status and support (/docs/console/status-and-support)
## Service status
[status.safeguard.sh](https://status.safeguard.sh) shows the live state of Safeguard's services:
* **API**: the combined platform API, which includes the service that runs the API Platform's gateway;
* the web apps: **Web App**, **Documentation**, **Academy**, **Gold Registry** and **Trust Center**;
* 90 days of uptime history, and past incidents;
* notices from the Safeguard team.
Select **Subscribe** to get status updates by email.
## When a request fails
| Response | What it means | What to do |
| ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------- |
| `403 gateway_disabled`, or the Console says **The inference gateway is not connected for this workspace yet** | The API Platform is not switched on for your workspace. | Ask Safeguard to switch it on. |
| `401 invalid_api_key` | The key is missing, malformed, unknown, revoked or expired. | Check the `Authorization: Bearer` header, or create a new key. |
| `402 insufficient_credit` | The request could cost more than your available credit. | Add credit, or lower `max_tokens`. |
| `402 key_spend_limit_exceeded` or `402 account_spend_limit_exceeded` | The request would pass a monthly spend limit. | Raise the limit, or wait for the next month (UTC). |
| `429 rate_limited` | Too many requests for this key. | Wait for the time in the `Retry-After` header. |
| `503 model_unavailable` | The model can't be served right now, or it doesn't offer zero data retention and your request requires it. | Pick another model. |
| `502 upstream_error` or `504 upstream_timeout` | The model's provider failed or timed out. | Try again. |
Every error code is listed on [Errors](/docs/console/errors). See [Pricing and billing](/docs/console/pricing-and-billing) for credit and limits, and [Zero data retention](/docs/console/zero-data-retention) for ZDR.
## Get help
* **In the web app**, including the Console: select the question-mark icon at the top right of any page, or **Get Help** in your user menu, and use the **Support** tab. Your request becomes a ticket you can follow in **Messages › Support**. See [Support requests](/docs/help-and-support/support-requests).
* **By email**: [hi@safeguard.sh](mailto:hi@safeguard.sh).
* **Security issues**: [security@safeguard.sh](mailto:security@safeguard.sh). See [Security and compliance](/docs/console/security-and-compliance).
* **Privacy questions**: [privacy@safeguard.sh](mailto:privacy@safeguard.sh).
More on getting help is in [Help and support](/docs/help-and-support).
## What to include
When you ask about a specific request, include:
* its ID: the response's `id` or its `X-Generation-Id` header, which starts with `gen-`;
* the time (UTC), the model and the error `code`.
Never send your API key. Safeguard support doesn't need it.
## Related
* [Security and compliance](/docs/console/security-and-compliance)
* [Pricing and billing](/docs/console/pricing-and-billing)
* [Help and support](/docs/help-and-support)
# Streaming (/docs/console/streaming)
Set `"stream": true` on a [chat completion](/docs/console/chat-completions) to receive the answer as it is generated. Add `"stream_options": {"include_usage": true}` to receive the token counts and cost at the end.
## Examples
curl
Python
Node.js
```bash
curl -N https://api.safeguard.sh/gpt/v1/chat/completions \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "MODEL_ID",
"messages": [{"role": "user", "content": "Write a haiku about dependency updates."}],
"stream": true,
"stream_options": {"include_usage": true}
}'
```
```python
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
stream = client.chat.completions.create(
model="MODEL_ID",
messages=[{"role": "user", "content": "Write a haiku about dependency updates."}],
stream=True,
stream_options={"include_usage": True},
)
for chunk in stream:
if chunk.choices:
print(chunk.choices[0].delta.content or "", end="", flush=True)
if chunk.usage:
print(f"\n{chunk.usage.total_tokens} tokens, ${chunk.usage.cost:.6f}")
```
```js
import OpenAI from 'openai';
const client = new OpenAI({
baseURL: 'https://api.safeguard.sh/gpt/v1',
apiKey: process.env.SAFEGUARD_INFERENCE_KEY,
});
const stream = await client.chat.completions.create({
model: 'MODEL_ID',
messages: [{ role: 'user', content: 'Write a haiku about dependency updates.' }],
stream: true,
stream_options: { include_usage: true },
});
for await (const chunk of stream) {
process.stdout.write(chunk.choices[0]?.delta?.content ?? '');
if (chunk.usage) console.log(`\n${chunk.usage.total_tokens} tokens, $${chunk.usage.cost.toFixed(6)}`);
}
```
## What the stream looks like
The response has `Content-Type: text/event-stream`, `Cache-Control: no-cache` and an `X-Generation-Id` header holding the request id (`gen-…`), the same id every chunk carries. Each event is one `data:` line followed by a blank line. The stream ends with `data: [DONE]`. The values below are illustrative.
```text
data: {"id": "gen-6f1c2e0a9b4d4c7e8a1f3b5d7c9e0a2b", "object": "chat.completion.chunk", "created": 1791475000, "model": "MODEL_ID", "provider": "openai", "choices": [{"index": 0, "delta": {"role": "assistant", "content": "Lockfile"}, "finish_reason": null}]}
data: {"id": "gen-6f1c2e0a9b4d4c7e8a1f3b5d7c9e0a2b", "object": "chat.completion.chunk", "created": 1791475000, "model": "MODEL_ID", "provider": "openai", "choices": [{"index": 0, "delta": {"content": " turns green"}, "finish_reason": null}]}
data: {"id": "gen-6f1c2e0a9b4d4c7e8a1f3b5d7c9e0a2b", "object": "chat.completion.chunk", "created": 1791475000, "model": "MODEL_ID", "provider": "openai", "choices": [{"index": 0, "delta": {}, "finish_reason": "stop"}]}
data: {"id": "gen-6f1c2e0a9b4d4c7e8a1f3b5d7c9e0a2b", "object": "chat.completion.chunk", "created": 1791475000, "model": "MODEL_ID", "provider": "openai", "choices": [], "usage": {"prompt_tokens": 16, "completion_tokens": 18, "total_tokens": 34, "cost": 8.8e-05}}
data: [DONE]
```
Every chunk carries the same `id`, `created`, `model` and `provider`. `choices[0].delta` holds the new piece of the answer, including `tool_calls` pieces when the model calls a tool. The gateway leaves out chunks that carry no change.
### The usage chunk
With `stream_options.include_usage` set, the last chunk before `[DONE]` has an empty `choices` array and a `usage` object with the same fields as a non-streamed response: `prompt_tokens`, `completion_tokens`, `total_tokens`, `cost`, and `prompt_tokens_details` or `estimated` when they apply. Without the option, the stream has no usage chunk, and the request is billed all the same.
Some providers do not report usage in a stream. The gateway then counts the tokens from the text itself, bills that estimate, and marks the usage `"estimated": true`.
## Errors
**Before the first chunk.** Until the provider has produced its first chunk, nothing is sent to you, so a refusal or a provider failure comes back as an ordinary HTTP error with a JSON body, exactly as for a non-streamed request. When you allow fallbacks, the gateway's retry and fallback happen in this window too. See [Errors](/docs/console/errors).
**After the stream has started.** The HTTP status is already `200`. If the provider's stream breaks, the gateway sends an error event, then the usage chunk if you asked for one, then `[DONE]`:
```text
data: {"error": {"message": "The provider stream ended with an error.", "type": "api_error", "code": "upstream_error", "param": null}}
```
A stream that runs past 900 seconds ends the same way with the code `upstream_timeout`. The OpenAI SDKs raise an error when they read an error event, so handle it as you would a failed request. The request is billed for what the provider produced before the failure; when the provider reported no usage, that is an estimate marked `"estimated": true`.
If the provider's stream ends without a finish reason and without an error, the gateway sends a last chunk with `"finish_reason": "stop"`.
## Cancelling a stream
To stop early, close the connection: break out of the loop and call `stream.close()` in the Python SDK, or call `stream.controller.abort()` in the Node.js SDK.
Closing the connection stops the gateway sending to you. It does not stop the provider. The gateway keeps reading the provider's answer to the end, for up to 900 seconds, so that it can bill the provider's own token counts, and the request is billed for everything the provider generated. To limit what a request can cost, set `max_completion_tokens` or `max_tokens`.
The **Stop** button in the Console Workbench behaves the same way.
## Related
* [Chat completions](/docs/console/chat-completions)
* [Errors](/docs/console/errors)
* [Reliability and fallbacks](/docs/console/reliability-and-fallbacks)
# Team and access (/docs/console/team-and-access)
The API Platform runs inside your Safeguard workspace, with the members and roles you already have. This page covers who can do what, how keys relate to people and organizations, and where key actions are recorded.
## Switching the API Platform on
Safeguard switches the API Platform on per workspace. Two switches matter:
| Switch | What it does |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| **API Platform (Console)** | Puts the Console in your product switcher. |
| `console:inference_gateway` | Connects the Console to the inference gateway, lets members create inference keys, and lets the API accept your workspace's keys. |
Both are off by default, and Safeguard turns them on. Ask Safeguard. While the API is in early access, the gateway can also be switched off as a whole. The Console then gives the reason "The inference API is not switched on for this deployment."
The gateway reads `console:inference_gateway` at most once a minute. If it cannot read the flag, it treats it as off.
## Who can do what
| Action | Who |
| -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Use the Console's **Dashboard**, **Workbench**, **API keys** and **Usage** pages | Members of a workspace where the API Platform is on |
| Create an inference key | Any active member except an auditor-only account, signed in as themselves |
| Edit or revoke a key in the Console | The key's owner. **API keys** lists only your own keys. |
| Run prompts in the **Workbench** | Members, except auditor-only accounts. Runs are charged to the workspace's credit. |
| See usage, the request log, the credit figures and the ledger | Any member. All of it covers the whole workspace. |
| Change **Gateway settings** | Tenant admins and super admins |
| Add credit by card, once card top-up is on | Tenant admins and super admins |
| Delete stored prompts | Tenant admins and super admins |
| Add credit as a grant | Safeguard |
| Deactivate a member, which revokes their keys | Members who manage members: tenant admins, and organization admins for members of the organizations they administer |
**Gateway settings** are the workspace's monthly spend limit, **Store prompts and outputs**, **Allow retries and fallbacks** and **Only use models whose provider offers zero data retention**. Safeguard's billing service decides who may change them, buy credit or delete stored prompts: the workspace's tenant admins and super admins. The Console shows those controls only to them; everyone else sees the values read-only, with "A tenant administrator can change these."
## Keys belong to people
* A key is created by, and for, the member who is signed in. Nobody can create a key on someone else's behalf, and that includes Safeguard staff using the admin console.
* A key acts for its owner. Every request made with it is charged to the workspace's credit.
* A key works only while its owner is an active member. Deactivating a member revokes their keys in the workspace at once, and reactivating them does not bring the keys back. A member who is removed, suspended or locked out also stops their keys working.
* Safeguard's authentication service also lets a tenant admin change or revoke another member's key, but the Console's **API keys** page lists only your own. To stop another member's keys from the Console, deactivate the member under **Settings › Members**.
## Organizations
* An inference key belongs to the whole workspace. It cannot be limited to an organization, project, product or agent.
* Credit, monthly limits, usage and the request log are kept per workspace and per key, not per organization.
* Every key can call every model available to the workspace.
* To keep teams' spending apart, give each team its own keys, each with its own monthly limit, and compare them under **Usage**, **By key**.
## Audit log
Safeguard writes an audit record for each of these actions. Key actions come from its authentication service; gateway settings, top-ups and deletions of stored prompts come from its billing service.
| Action | Recorded as | With |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| Create a key | `auth.api.key.created` | The key's id, prefix and name |
| Change a key's name or limits | `auth.api.key.updated`, naming only the fields that changed, each with its old and new value. A save that changes nothing records nothing. | The key's id, prefix and name, and `changed` with `From` and `To` for each change |
| Revoke a key | `auth.api.key.revoked` | The key's id |
| Deactivate a member | `auth.account.disabled` | How many of the member's keys were revoked |
| Change **Gateway settings** | `inference.settings.updated` | Only the settings that changed, with old and new values, and the role it was made under (`Tenant_Admin` or `Super Admin`) |
| Start a card top-up | `inference.credits.checkout_started` | The credit, the charge and the card fee, and the role |
| Delete stored prompts | `inference.prompts.deleted` | How many were deleted, and the role |
Every record also holds who acted, the workspace, the time, the IP address and the browser, and whether the action succeeded. The key itself is never recorded. When an access check refuses a key action, the refusal is recorded as a failure: for example, an auditor-only account trying to create a key, or a member trying to change someone else's key.
To read these records, open **Settings › Security activity** in ESSCM, if your workspace has it:
* **My activity** shows your own events.
* **Organization activity** shows everyone's, and only tenant admins see it. Type `auth.api.key` in the action filter and select **Apply** to list key events, or `inference.` to list gateway settings, top-ups and deletions of stored prompts.
Security activity shows IP addresses masked, with the country and region.
When Safeguard changes a feature for your workspace, such as switching `console:inference_gateway` on, the change appears in **Organization activity** too, naming the feature.
## Related
* [Key management best practices](/docs/console/key-management-best-practices)
* [Credits and invoices](/docs/console/credits-and-invoices)
* [Spend controls](/docs/console/spend-controls)
* [Usage and analytics](/docs/console/usage-and-analytics)
# Troubleshooting (/docs/console/troubleshooting)
Every error from the inference API comes back in OpenAI's error shape. Read `error.code` first, because it says more than the HTTP status does.
```json
{
"error": {
"message": "Invalid, revoked or expired API key. Keys start with sg-api- and are sent as 'Authorization: Bearer '.",
"type": "authentication_error",
"code": "invalid_api_key",
"param": null
}
}
```
A request refused before the gateway calls a provider costs nothing and does not appear in the request log. That covers every 401, 402, 403, 404 and 503 on this page, a 429 `rate_limited`, and most 400s. The full list of codes is in [Errors](/docs/console/errors).
## 401 invalid\_api\_key
The key is missing, malformed, unknown, revoked or expired, or its owner is no longer an active member. The gateway gives the same answer in every case.
* **Check the header.** It must be `Authorization: Bearer` followed by the whole key: `sg-api-` and 64 lowercase hexadecimal characters. The Console's key list shows a masked form, which is not the key.
* **Check the kind of key.** Only inference keys work here. MCP keys, Guard SDK keys and Safeguard sign-in tokens get this 401.
* **Was the key revoked?** A revoked key is listed under **Revoked** on **API keys**. Create a new one.
* **Has its owner left?** A key acts for the member who created it. When that member is deactivated or removed, the key stops working. Create a new key while signed in as an active member.
* **Keys created in the Console never expire,** so an old key that stopped working was revoked, or its owner can no longer use it.
## 402 credit or a spend limit
| `code` | Fix |
| ------------------------------ | --------------------------------------------------------------------------------------------------------------------- |
| `insufficient_credit` | Add credit, or lower `max_tokens` so the request's hold fits. At a balance of zero or less, every request is refused. |
| `key_spend_limit_exceeded` | The key's owner raises or clears the key's monthly limit, or you use another key. |
| `account_spend_limit_exceeded` | A tenant admin or super admin raises or clears the workspace's monthly limit. |
The checks use the most a request could cost, so a request with a large `max_tokens` can be refused while some credit is left. See [Spend controls](/docs/console/spend-controls).
## 403 gateway\_disabled
The message is "The Safeguard inference API is not enabled for this account." The API is in early access: it is deployed but switched off, and Safeguard switches it on per workspace. Ask Safeguard to turn it on for yours.
In the Console it looks like this:
* Before the API is on for your workspace, **Create key** on **API keys** is greyed out, and a Workbench run says "The inference endpoint is not connected yet."
* When your workspace is on but the gateway as a whole is still switched off, Console pages say "The inference gateway is not connected for this workspace yet." with the reason underneath.
## 404 model\_not\_found
The message is "Model not found:" followed by the id you sent. That id is not in Safeguard's model catalog. Ids must match exactly, including case. List the ids you can use, and copy one:
```bash
curl https://api.safeguard.sh/gpt/v1/models \
-H "Authorization: Bearer $SAFEGUARD_INFERENCE_KEY"
```
## Model not available
A 503 `model_unavailable` means the model is in the catalog but cannot be used right now. The end of the message says why:
| Message ends with | Meaning | Fix |
| ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| "it is not available through the API yet" | The model has not been made available through the API, or its provider is not set up yet. | Pick a model from `GET /gpt/v1/models`. Without `?all=true`, that list holds only models that are available through the API now. |
| "zero data retention is not offered for it" | Your workspace requires zero data retention, or the request set `provider.zdr`, and the model does not offer it. | Pick a model with `zdr_available: true`, or ask a tenant admin or super admin to turn off **Only use models whose provider offers zero data retention**. |
If the message is "The model catalogue is temporarily unavailable; try again shortly.", retry with backoff.
In the Workbench picker, models marked **(Request access)** or **(Coming soon)** cannot be run.
## 429 too many requests
| `code` | Meaning | Fix |
| ----------------------- | --------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `rate_limited` | Your key sent more requests in the last minute than its limit allows. | Wait the number of seconds in `Retry-After`. Spread requests out, or raise the key's **Requests per minute** with **Edit** on **API keys**, up to 10,000. Separate workloads can use separate keys. |
| `upstream_rate_limited` | The provider is rate limiting the gateway. | Wait for `Retry-After`, which is 5 seconds, and back off if it repeats. Turn on retries and fallbacks, or try another model. |
## 5xx errors
| Status and `code` | Meaning | Fix |
| ------------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------- |
| 500 `internal_error` | The gateway failed unexpectedly. | Retry once or twice with backoff. If it keeps happening, contact support. |
| 502 `upstream_error` | The provider returned an error or could not be reached. | Retry with backoff, or turn on retries and fallbacks. |
| 502 `upstream_auth` | The provider refused Safeguard's credentials. | Nothing to change on your side. Use another model, and tell Safeguard. |
| 503 `auth_unavailable` | API keys cannot be checked right now. | Retry with backoff. |
| 503 `billing_unavailable` | Credit cannot be checked right now. | Retry with backoff. |
| 503 `model_unavailable` | See [Model not available](#model-not-available). | |
| 504 `upstream_timeout` | The provider did not answer in time. | Retry, lower `max_tokens`, or stream the response. |
How to retry well is covered in [Reliability and fallbacks](/docs/console/reliability-and-fallbacks#retrying-in-your-client).
## A revoked key still works, or a key stopped working
* **It still works right after you revoked it.** Revoking takes effect within 30 seconds. A request that started before then runs to its end.
* **It stopped working and nobody revoked it.** Its owner was probably deactivated or removed from the workspace, which stops their keys. Create a new key.
## A streamed answer stops with an error
If the provider fails after streaming has started, the stream ends with an `error` event and then `data: [DONE]`. The answer is incomplete, and the tokens produced so far are charged. Retry the request. See [Streams that fail partway](/docs/console/reliability-and-fallbacks#streams-that-fail-partway).
## 400 bad request
| `code` | Usual cause |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `invalid_request` | A field is missing or out of range, and `param` names it. For example, `temperature` must be from 0 to 2, `top_p` from 0 to 1, and `stop` can hold at most four strings. |
| `unsupported_parameter` | Something the API does not accept, such as image content, or `n` set to anything but 1. |
| `upstream_rejected` | The provider refused the request with a 400, 404, 413 or 422. Check the request against the model's limits, such as its context length. The gateway never retries it. |
A body over 8 MiB gets 413 `request_too_large`. The field rules are in [Chat completions](/docs/console/chat-completions).
## Contact support
Write to [hi@safeguard.sh](mailto:hi@safeguard.sh) with:
* the response's `id`, which starts with `gen-`, if you got one;
* the `X-Generation-Id` response header, which holds the same id;
* the time of the request, the model and the error code;
* the key's name or masked form. Never send the key itself.
## Related
* [Errors](/docs/console/errors)
* [Reliability and fallbacks](/docs/console/reliability-and-fallbacks)
* [Spend controls](/docs/console/spend-controls)
* [Key management best practices](/docs/console/key-management-best-practices)
# Usage and analytics (/docs/console/usage-and-analytics)
The Console has two places to watch your inference traffic. **Dashboard** sums up the last 14 days. **Usage** lets you pick a period, split it by model and by key, and read the request log. Both read the gateway's own metering, which is the same record your credit is charged from.
**Early access.** The inference gateway is deployed but switched off. Safeguard switches it on per workspace. Until it is on for yours, these pages have no gateway figures to show.
## Dashboard
The Dashboard covers the last 14 days, counted in UTC days up to today.
| Card | What it shows |
| ------------------- | ----------------------------------------------------------------------------------------------- |
| **Requests** | Every logged request in those 14 days. The total cost appears under the count, as **$… spent**. |
| **Input tokens** | Input tokens across those requests. |
| **Output tokens** | Output tokens across those requests. |
| **Active API keys** | Your own active inference keys. Keys other members created are not counted. |
Under the cards, **Requests per day** draws one bar per UTC day. Before your first request, the chart says there are no requests yet and points you to **API keys** and the **Workbench**.
## Usage
Pick the period at the top of the page: **Last 7 days**, **Last 14 days**, **Last 30 days** or **Last 90 days**. The default is 30 days. Periods are UTC days ending today.
### Totals
**Requests**, **Input tokens**, **Output tokens** and **Cost** for the period. **Requests** includes requests that ended with an error.
### By model and By key
Two tables split the period's totals. Each row has **Requests**, **Input**, **Output** and **Cost**.
* **By model** has a row per model id. When a fallback model answered a request, the request counts under the fallback. See [Reliability and fallbacks](/docs/console/reliability-and-fallbacks).
* **By key** has a row per key, shown by its name and masked form, such as **production backend · sg-api-1a2b3c4d…9f8e**. The name and mask are the ones the key had when the requests were made, so a renamed or revoked key stays recognizable. Workbench runs use no key, so they are grouped as **Console workbench**. A key that no longer exists shows as **Deleted key**. The Console never shows a key's numeric id.
The **API keys** page shows each key's spend for the current month in its **This month** column.
### Request log
The request log lists requests newest first, 50 at a time. **Load older requests** pages back through the whole history, whatever period you picked above. The Console notes above the table: "Metadata only. Prompts and outputs are not shown here."
| Column | What it shows |
| ----------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Time** | When the gateway recorded the request, at the end of the answer, in your browser's time zone. The server sends it in UTC. |
| **Model** | The model that answered. For a request that failed, the model you asked for. |
| **Key** | The key the request used, named as in **By key**. **Console workbench** for a run in the Workbench. |
| **Input** | Input tokens, as the provider counted them. |
| **Output** | Output tokens. **est.** next to the number means the provider reported no usage, so the tokens and the charge are the gateway's estimate. |
| **Cost** | What the request was charged, in USD. Amounts under a dollar show more decimal places. |
| **Latency** | Milliseconds from the start of the provider call to the end of the answer, including any retry or fallback. |
| **Status** | **OK**, or the error code. |
The status codes you are most likely to see:
| Status | What happened |
| ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `upstream_error`, `upstream_timeout`, `upstream_auth`, `upstream_rate_limited` | The provider failed, did not answer in time, refused Safeguard's credentials or rate limited the call. If no answer was produced, the cost is $0. If a streamed answer broke partway, the tokens already produced are charged. |
| `upstream_rejected` | The provider refused the request as invalid. The cost is $0. |
| `client_disconnected` | Your client closed a streamed response before it finished. The gateway kept reading the provider's answer to the end and charged for all of it. |
Some requests never reach the log. When the gateway refuses a request before calling a provider, it costs nothing and is not logged: your client gets the error directly. That covers a missing or revoked key, the API being switched off, an unknown or unavailable model, too little credit, a spend limit, a rate limit and an invalid request body. See [Troubleshooting](/docs/console/troubleshooting).
## How the figures are counted
* Tokens are the provider's own counts. Cost is those tokens times the model's list price, with no markup. See [Pricing and billing](/docs/console/pricing-and-billing).
* The Dashboard and Usage count UTC days. Monthly figures in the Console use UTC calendar months.
* Usage, the request log and the credit figures cover the whole workspace. Every member who can open the Console sees all of it, not only their own requests. The exceptions are your keys: the **API keys** page and the Dashboard's **Active API keys** card show only keys you own.
* The Console never shows prompts or outputs. Safeguard stores them only if a tenant admin or super admin turns on **Store prompts and outputs**. See [Privacy and data](/docs/console/privacy-and-data).
## Related
* [Credits and invoices](/docs/console/credits-and-invoices)
* [Spend controls](/docs/console/spend-controls)
* [Request lifecycle](/docs/console/request-lifecycle)
* [Troubleshooting](/docs/console/troubleshooting)
# Workbench (/docs/console/workbench)
The Workbench is the Console's playground. It sends the same request your code would send to `POST /chat/completions` and shows the answer as it streams in, with what the run cost. Open it from the Console sidebar, or with **Open workbench** on the Dashboard.
The Workbench uses your Safeguard sign-in, not an API key. Its runs spend your workspace's credit at the same prices as API calls.
## The screen
**Left side**
* **System prompt**: optional instructions that set the model's behaviour. Sent as a `system` message.
* **Prompt**: what you want to ask. Sent as a `user` message.
* **Run** sends the request. While it runs, **Stop** appears.
* **Response**: the answer, filling in as it streams.
**Right side**
* **Model**: the catalog's models, starting on one you can run. A model you cannot run yet shows its state after its name, such as **(Request access)** or **(Coming soon)**. When it is selected, **Run** stays disabled and the Workbench says why, for example "cannot run: Coming soon." If no model can run, the picker says **No model can run right now**. Under the picker, the model's input and output prices per million tokens, when the catalog has them.
* **Max tokens**: the most the model may write. The field offers 1 to 8,192 and starts at 1,024.
* **Temperature**: from 0 to 1 in steps of 0.1. The default is 1.
## After a run
Below the response, the Workbench shows:
| Figure | Meaning |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------- |
| **Input** and **Output** | Tokens, as the provider counted them. |
| **Cost** | The run's cost in US dollars, from the gateway's `usage.cost`. |
| **Latency** | Milliseconds from sending the request to the last byte. |
| **First token** | Milliseconds until the first text arrived. |
| **Request ID** | The run's id, `gen-` and 32 hexadecimal characters, with a copy button. Quote it when you ask Safeguard about a run. |
Two notes can appear: **Token counts are estimates: the server sent no usage.** and **Stopped at the max tokens limit.**, when the model used every token you allowed.
Each run also appears in **Usage**: in the request log and under **By key**, as **Console workbench**, because no key was used.
## When a run fails
The Workbench shows the error with one next step:
| Problem | What you see |
| ----------------------------- | ----------------------------------------------------------------------- |
| Not enough credit | The message, and **Add credit** when card top-up is available. |
| A monthly spend limit reached | The message and **Open limits**, which goes to the limits on **Usage**. |
| Too many runs | **Slow down**, with a countdown from the `Retry-After` header. |
| Model not available | The message, asking you to pick another model. |
When the request reached a provider before it failed, the error also shows its **Request ID**. The [Errors](/docs/console/errors) page lists every code.
## Stop
**Stop** ends the stream in your browser. The provider is not stopped: the gateway keeps reading its answer to the end so that it can bill the provider's own token counts, and the run is billed for everything the provider generated. Lower **Max tokens** to limit what a run can cost.
## Limits that apply
* Runs spend the workspace's prepaid credit and count toward the workspace's monthly spend limit. No key limit applies, because no key is used.
* Each person can start up to 60 runs a minute.
* A support session that is read-only cannot run requests.
## Before the API Platform is on
Until Safeguard turns the API Platform on for your workspace, the Workbench lists two placeholder models, and **Run** answers that the inference endpoint is not connected yet. No request reaches a model.
## Your own models
The Workbench's model list shows catalog models only. Models your workspace added itself cannot be picked in this version. See [Bring your own model](/docs/console/bring-your-own-model).
## Chat, Compare and Code
Where Safeguard has switched on the new Workbench for your workspace, it has three modes and a code panel:
* **Prompt**: one prompt, one answer, as above.
* **Chat**: a multi-turn conversation; each message sends the whole conversation so far.
* **Compare**: one prompt sent to two or three models at once, each answer streamed in its own column with its tokens, cost, latency, time to first token and generation id.
* **Code**: the request you are about to run as curl, Python and Node with the OpenAI SDKs, and plain `fetch`, reading the key from `SAFEGUARD_INFERENCE_KEY`.
Where routing is switched on, Prompt and Chat also let you add fallback models and pick a sort (price, latency or uptime); the code panel includes them. Open a model straight in the Workbench with `/console/workbench?model=`, or from **Models** in the Console sidebar, which lists every model with its provider, context length, prices per 1M tokens (no markup), and measured latency and uptime where there is traffic.
## From the Workbench to code
A Workbench run is a chat completion with `messages` (the system prompt, if any, and your prompt), `max_tokens`, `temperature`, `stream: true` and `stream_options.include_usage: true`. The same request from code:
```python
import os
from openai import OpenAI
client = OpenAI(
base_url="https://api.safeguard.sh/gpt/v1",
api_key=os.environ["SAFEGUARD_INFERENCE_KEY"],
)
stream = client.chat.completions.create(
model="MODEL_ID",
messages=[
{"role": "system", "content": "You are a security reviewer."},
{"role": "user", "content": "Review this dependency update plan: ..."},
],
max_tokens=1024,
temperature=1,
stream=True,
stream_options={"include_usage": True},
)
for chunk in stream:
if chunk.choices:
print(chunk.choices[0].delta.content or "", end="")
```
See [Streaming](/docs/console/streaming) for the rest.
# Zero data retention (/docs/console/zero-data-retention)
Zero data retention (ZDR) is an arrangement under which a model provider does not keep your prompts or the model's outputs after it answers. In the API Platform, ZDR is a routing rule: when it is on, the gateway sends your request only to models whose provider offers it.
## Turn it on
| For | How |
| ------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| One request | Add `"provider": { "zdr": true }` to the request body. |
| The whole workspace | A tenant admin or super admin turns on **Only use models whose provider offers zero data retention** in **Usage › Credits and limits › Gateway settings**. It covers the API and the Workbench. |
A request can ask for ZDR on its own, but it cannot turn off a workspace's requirement.
## How routing works
With ZDR on:
1. The gateway only considers models whose catalog entry has `zdr_available: true`. Fallbacks must meet the same rule.
2. If the model you asked for doesn't offer ZDR, the request goes to an allowed fallback that does, when you have turned fallbacks on. Otherwise it is refused with `503 model_unavailable`, and the message says zero data retention is not offered for that model. It is never sent to a model that doesn't offer ZDR.
3. For OpenAI models, the gateway also sends `store: false`.
4. Safeguard's request log records that the request was made under ZDR.
ZDR does not change two things:
* **Safeguard's own records.** The metadata row in your request log is always kept. Prompt and output text is stored only if **Store prompts and outputs** is on, and that holds for ZDR requests too. Leave it off if you want no copy of the text at Safeguard. See [Privacy and data](/docs/console/privacy-and-data).
* **Models you bring yourself.** The ZDR rule does not apply to them. Your own agreement with that provider decides what it keeps. See [Bring your own model](/docs/console/bring-your-own-model).
**Check the arrangement before you rely on it.** The catalog flag records that a provider offers zero data retention, taken from the provider's published data policy. Some providers offer it only to approved accounts, and the provider's terms decide what it keeps. Before you send regulated data under ZDR, ask Safeguard to confirm the arrangement for that provider.
## Which models offer it
The catalog's `zdr_available` field is the source of truth, and a model whose field is empty is treated as not offering ZDR. You can read the field for every model, available or not, with `GET /gpt/v1/models?all=true`. On [safeguard.sh/models](https://safeguard.sh/models), each model's page shows **Zero data retention** under **Data policy**, and the list can be filtered to **Zero data retention available**.
What the catalog says on 8 October 2026:
| Provider | Zero data retention |
| -------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| OpenAI | Offered for the models OpenAI serves itself. |
| Anthropic | Offered for Claude Opus 5.5, Claude Sonnet 5.5 and Claude Haiku 5.5. Not offered for Claude Fable 5.1 or Claude Mythos 5.1, for which Anthropic requires 30-day retention. |
| Mistral AI | Marked as offered for every Mistral model, so the gateway routes ZDR requests to them. Mistral's terms, quoted in the catalog, exclude preview models such as Mistral Large 4 from ZDR, so check the model's data policy first. |
| xAI | Offered. |
| Cohere | Offered. Cohere grants it to approved enterprise customers. |
| Google (Gemini API) | Not offered on the Gemini API, which is the API the gateway uses for Google's models. |
| DeepSeek, Qwen (Alibaba Cloud) and Meta | Not stated by the provider, so treated as not offered. |
| Open-weight models served by a host, such as gpt-oss, Gemma or Llama | Depends on the host. Not set, so treated as not offered. |
| Safeguard's models: Griffin, Eagle, Lion and Zero | Not set, so a request that requires ZDR is refused for them. |
## Related
* [Models](/docs/console/models)
* [Chat completions](/docs/console/chat-completions)
* [Privacy and data](/docs/console/privacy-and-data)
* [Regions and data residency](/docs/console/regions-and-data-residency)
# Create an Account (/docs/getting-started/create-account)
# Create an Account
Follow these steps to create your Safeguard account and set up your organization.
## Sign Up
### Step 1: Visit Safeguard
Navigate to [safeguard.sh](https://safeguard.sh) and click **Try for Free** or **Book a Call** for enterprise accounts.
### Step 2: Enter Your Details
Provide the following information:
* **Work Email** - Your business email address
* **Full Name** - Your first and last name
* **Organization** - Your company name
* **Password** - Create a strong password
### Step 3: Verify Your Email
1. Check your inbox for a verification email
2. Click the verification link
3. Your account is now active
### Step 4: Complete Setup
After verification, complete your profile:
* Job title
* Team size
* Primary use case
* Timezone
## Organization Setup
Configure your organization settings:
1. **Organization Name** - Your company name
2. **Industry** - Select your industry
3. **Products** - Choose which Safeguard products to enable:
* Enterprise ESCM
* Portal
* Third Party Risk Manager
* Open Source Manager
## Inviting Team Members
Add your team members to collaborate on software supply chain security:
1. Go to **Settings** → **Members**
2. Click **+ Invite Member**
3. Enter the member's email address
4. Assign a role:
* **Tenant\_Admin** - Full administrative access to the organization
* **Manager** - Manage projects, users, and security configurations
* **User** - Standard access to view and work with projects
5. Select the organization(s) the member should have access to
6. Send the invitation
### Managing Members
The Members page displays all team members with:
* Member name and email
* Status (Active/Pending)
* Assigned role (dropdown to change)
* Organization assignment
* Actions menu for additional options
Use the search bar to find specific members, and the refresh button to update the list.
## Next Steps
* [Configure SSO](/docs/sso-authentication) for your team
* [Complete onboarding](/docs/getting-started/onboarding-workflow) to generate your first SBOM
* [Connect your repositories](/docs/esscm/generate-sbom) to start scanning
## Need Help?
Contact us at [hi@safeguard.sh](mailto:hi@safeguard.sh) or visit [safeguard.sh](https://safeguard.sh) for personalized onboarding.
# Getting Started (/docs/getting-started)
# Getting Started
Welcome to Safeguard! This guide will help you get started securing your software supply chain.
## Quick Start
1. **Create an Account** - Sign up at [safeguard.sh](https://safeguard.sh)
2. **Configure SSO** - Set up Single Sign-On (optional)
3. **Complete Onboarding** - Follow the setup wizard
4. **Generate Your First SBOM** - Analyze your first project
## What You'll Learn
In this section, you'll learn how to:
* Create and configure your Safeguard account
* Set up Single Sign-On (SSO) authentication
* Connect your source code repositories
* Generate your first SBOM
* Review vulnerabilities and enable AI Remediate
## Prerequisites
Before you begin, ensure you have:
* A valid email address for account registration
* Access to your source code repositories or container registries
* Administrator access to your identity provider (if configuring SSO)
* Role permissions configured in your organization (if using Role Permission Based Tenant Control add-on)
## Next Steps
## Developer Resources
Official repositories and packages:
* **MCP Server:** [mcp.safeguard.sh](https://mcp.safeguard.sh) - Model Context Protocol server for AI assistants
* **CLI:** [Installation](/docs/cli/installation) - installs from `https://cli.safeguard.sh/install`; Safeguard publishes no npm packages
* **GitHub Organization:** [Safeguard-sh](https://github.com/Safeguard-sh) - Open source tools and integrations
* **VS Code Marketplace:** [IDE Extension](https://marketplace.visualstudio.com/items?itemName=Safeguard-sh-Inc.SafeguardshIdeExtension) - For VS Code
* **Open VSX:** [Cursor Extension](https://open-vsx.org/extension/Safeguard-sh-Inc/SafeguardshIdeExtension) - For Cursor IDE
* **JetBrains Marketplace:** [Plugin for all JetBrains IDEs](https://plugins.jetbrains.com/plugin/30031-safeguard-sh-ide-extension) - IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, GoLand, RubyMine, CLion, Rider, DataGrip, AppCode, Android Studio
## Need Help?
* Email us at [hi@safeguard.sh](mailto:hi@safeguard.sh)
* [Book a demo](https://safeguard.sh) for personalized onboarding
* Visit [safeguard.sh](https://safeguard.sh) for more information
# Onboarding Workflow (/docs/getting-started/onboarding-workflow)
# Onboarding Workflow
Complete the onboarding wizard to connect your repositories, generate your first SBOM, and start securing your software supply chain.
## Overview
The onboarding process guides you through:
1. **Connect Integrations** - Link your source code and container platforms
2. **Add Projects** - Import projects from connected integrations
3. **Review Results** - Explore vulnerabilities, components, and security posture
4. **Enable AI Remediate** - Let Griffin AI remediate issues automatically
## Step 1: Connect Integrations
### Source Code Repositories
Connect to your version control:
1. Go to **Settings** → **Integrations**
2. Click **Connect** next to your provider:
* GitHub
* GitLab
* Bitbucket
* Azure Repos
* AWS CodeCommit
3. Authorize Safeguard access
4. Select repositories to monitor
### Container Registries
Connect to scan container images:
1. Go to **Settings** → **Integrations**
2. Click **Connect** next to your registry:
* Docker Hub
* AWS ECR
* Google GCR
* Azure ACR
3. Enter credentials
4. Test connection
## Step 2: Generate Your First SBOM
Add a project from your connected integrations:
1. Navigate to **Projects**
2. Click **+ Add Project**
3. Select an integration source (GitHub, AWS, Bitbucket, etc.)
4. Choose the repository or image to scan
5. Configure project settings (branch, version)
6. Click **Add Project**
The project will appear in the Projects table showing:
* Project Name
* Version
* Status (active/inactive)
* Organization
* Findings summary (E, C, H, M, L counts)
* Vulnerability count
Generation typically takes 1-5 minutes depending on project size.
## Step 3: Review Results
Click on any project to view the Project Overview page with multiple tabs:
### Info Tab
* Project name and version
* Created date and creator
* Generation method (SCM, Container, Manual)
* Source code repository URL
* Branch/Tag information
* Organization assignment
* Findings by Severity chart
* Vulnerabilities by Severity chart
* Supply Chain Risk by Components
* Findings by Gate
### Additional Tabs
| Tab | Description |
| ------------------------ | ---------------------------------------------------- |
| **Attestation** | Supply chain attestation and provenance verification |
| **Dependencies** | Complete dependency tree and component list |
| **Provenance** | Build and source provenance information |
| **Vulnerabilities** | Security vulnerabilities with severity ratings |
| **Mitigations** | Applied mitigations and accepted risks |
| **Security Posture** | Overall security scoring and posture assessment |
| **Code Quality** | Code quality metrics and issues |
| **Suppliers & Licenses** | License compliance and supplier information |
| **Findings** | All findings across security gates and policies |
## Step 4: Enable AI Remediate
Let Griffin AI fix vulnerabilities automatically:
1. Navigate to the **Vulnerabilities** tab in any project
2. Click the **AI Remediate** button
3. Review the proposed fix
4. Click **Create Pull Request**
Or enable automatic remediation:
1. Go to **Settings** → **AI Remediate**
2. Enable **Automatic PR Creation**
3. Configure settings
4. Save
## Next Steps
You're all set! Here's what to do next:
* [Set up CI/CD integration](/docs/cicd-integration) for continuous scanning
* [Configure policies](/docs/esscm/policies-gates) to enforce security requirements
* [Invite your team](/docs/getting-started/create-account#inviting-team-members) to collaborate
* [Enable continuous monitoring](/docs/esscm/dashboard) for alerts
## Need Help?
* Email: [hi@safeguard.sh](mailto:hi@safeguard.sh)
* Visit [safeguard.sh](https://safeguard.sh) for more information
* Book a demo for hands-on onboarding
# Compliance frameworks (/docs/frameworks)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Safeguard's framework library has **373** frameworks: national data-protection, cybersecurity and sector laws, industry standards such as SOC2, ISO/IEC 27001 and PCI DSS, and Safeguard's own supply-chain policies. This page explains how Safeguard covers a framework, what its readiness score counts, and how to choose the frameworks your organization works on. Every framework has its own page, grouped by region below.
## How Safeguard covers a framework
1. **Scan requirements.** Every framework has a set of requirements that Safeguard checks on each scan of a product, against what the scan found, including the product's software inventory (SBOM). There are 2,207 in all. A framework's page lists its requirements and what Safeguard checks for each.
2. **Controls.** On a framework's **Controls** tab, its scan requirements appear as controls. For 197 frameworks Safeguard's control catalog adds more of the framework's controls (2,197 in all), which you evidence with automated tests, uploaded evidence, policies and attestations.
3. **Automated tests.** Systems you connect (cloud accounts, identity providers, code hosts and many more) run automated tests that map to the controls of SOC2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS and NIST CSF 2.0, and to the CIS benchmarks. Through the crosswalk, that evidence also reaches equivalent controls of the related frameworks, including NIST SP 800-53. For every other framework you can link tests to its controls yourself. See [Frameworks and connectors](/docs/framework-connectors).
4. **Policy templates.** Every framework has policy templates to start from: the [standard set](#policy-templates), adapted to that framework, and for 197 frameworks more templates written for it specifically.
Automated tests map directly to 6 frameworks in the library. For most frameworks, coverage is the scan requirements, the controls and your own evidence.
## Decided by a scan, or by evidence
A scan decides a requirement when it can see what the requirement asks for. Of the 2,207 scan requirements:
* **2,086** are decided by a scan: met or not met.
* **10** are checked by a scan for a prerequisite. A missing prerequisite fails the requirement; only evidence or an attestation passes it.
* **111** need evidence a scan cannot see, such as a policy, an HR record or an access review. They pass when a person attests them with evidence.
Each framework's page marks every requirement with which of these it is.
## What a readiness score counts
A framework's readiness score is the share of its in-scope requirements that pass:
* A requirement passes on a scan that finds it met, or on an attestation by a person that names its evidence.
* A requirement waiting for evidence counts as not yet passing. It stays in the score until someone attests it.
* A requirement a person scopes out, with a written justification, leaves the score.
* The score reads 100 only when every in-scope requirement passes.
* Beside every score, Safeguard shows how many requirements a scan evaluated and how many need evidence or an attestation.
A readiness score is Safeguard's assessment of what it can see. It is not an audit opinion or a certification.
## Choose your frameworks
1. Open **Compliance › Manage**, then the **Frameworks** tab.
2. Find a framework by region, country, industry or type, or search for it.
3. Switch it on, then select **Save**. It appears on **Compliance › Frameworks**, **Controls** and **Overview**.
Out of the box, every framework is switched on except the 176 national data-protection and cybersecurity laws: switch on the ones that apply to you. Your Safeguard plan decides which frameworks your organization can choose from, and your Safeguard administrator manages that list. Choosing a framework does not certify compliance.
## Policy templates
Every framework in the library has these 22 policy templates, adapted to that framework:
* Information Security Policy
* Access Control Policy
* Acceptable Use Policy
* Data Protection & Privacy Policy
* Incident Response Policy
* Business Continuity & Disaster Recovery Policy
* Third-Party / Vendor Risk Management Policy
* Change Management Policy
* Vulnerability & Patch Management Policy
* Logging & Monitoring Policy
* Encryption & Cryptography Policy
* Risk Assessment & Management Policy
* Secure Software Development Policy
* Asset Management Policy
* Security Awareness & HR Security Policy
* Backup & Data Retention Policy
* Network Security Policy
* Data Classification & Handling Policy
* Password & Authentication Policy
* Physical & Environmental Security Policy
* AI & Responsible Use Policy
* Penetration Testing & Security Assessment Policy
Where a framework has its own template on the same subject, that one replaces the standard one. To use a template, open the framework on **Compliance › Frameworks**, then its **Policies** tab, select **New policy** and choose **Start from template**.
## Frameworks by region
| Region | Frameworks |
| --------------------------------------------------------------- | ---------- |
| [Americas](/docs/frameworks/americas) | 107 |
| [Europe](/docs/frameworks/europe) | 76 |
| [Asia-Pacific](/docs/frameworks/asia-pacific) | 62 |
| [Middle East & Africa](/docs/frameworks/middle-east-and-africa) | 76 |
| [International](/docs/frameworks/international) | 41 |
| [Internal](/docs/frameworks/internal) | 11 |
The full list on one page: [All frameworks](/docs/all-frameworks).
# CIS AWS Foundations Benchmark and connectors (/docs/framework-connectors/cis-aws)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard's automated tests map to **41** recommendations of CIS Amazon Web Services Foundations Benchmark v3.0.0. **41** tests apply: 41 read a connected system, and 0 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
A CIS benchmark is a catalogue mapping: results show on the tests, filters and evidence with their recommendation numbers, and the benchmark is not a framework in your library.
## How to connect for this framework
1. Connect the systems you run from the table below. Each connector links to its setup steps.
2. Open **Compliance › Tests** and filter by the benchmark to see its results.
3. Tests run on their schedule, or straight away with **Run now** on **Compliance › Tests**. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
## Connectors with automated evidence (1)
| Connector | Controls it provides evidence for | Tests |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----- |
| [Amazon Web Services](/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services) (also AWS GovCloud, AWS CodeCommit, AWS Inspector, Amazon CloudWatch, Amazon S3, AWS Security Hub) | `1.1`, `1.11`, `1.13`, `1.15`, `1.16`, `1.17`, `1.18`, `1.19`, `1.2`, `1.20`, `1.21`, `1.22`, `1.6`, `1.7`, `2.1.1`, `2.1.2`, `2.1.3`, `2.3.2`, `2.4.1`, `3.4`, `3.8`, `3.9`, `4.1`, `4.10`, `4.11`, `4.12`, `4.13`, `4.14`, `4.15`, `4.16`, `4.2`, `4.3`, `4.4`, `4.5`, `4.6`, `4.7`, `4.8`, `4.9`, `5.1`, `5.4`, `5.6` | 41 |
## Recommendations (41)
| Recommendation | Title | Automated tests | Connectors |
| -------------- | ---------------------------------------------------------- | --------------- | ---------- |
| `1.1` | Account contact details are current | 1 | 7 |
| `1.2` | A security contact is registered for the account | 1 | 7 |
| `1.6` | Root MFA is hardware-backed | 1 | 7 |
| `1.7` | Root is not used for everyday tasks | 1 | 7 |
| `1.11` | No unused access key from user setup | 1 | 7 |
| `1.13` | An IAM user holds at most one active access key | 1 | 7 |
| `1.15` | IAM users get permissions through groups only | 1 | 7 |
| `1.16` | No custom policy grants full admin | 1 | 7 |
| `1.17` | A role can work with AWS Support | 1 | 7 |
| `1.18` | EC2 instances reach AWS through an instance role | 1 | 7 |
| `1.19` | Expired IAM server certificates are removed | 1 | 7 |
| `1.20` | Access Analyzer is on in every region | 1 | 7 |
| `1.21` | People sign in through federation | 1 | 7 |
| `1.22` | CloudShell full access is restricted | 1 | 7 |
| `2.1.1` | S3 bucket policies deny non-TLS requests | 1 | 7 |
| `2.1.2` | MFA Delete on S3 buckets | 1 | 7 |
| `2.1.3` | Macie discovers sensitive S3 data | 1 | 7 |
| `2.3.2` | RDS instances apply minor engine upgrades automatically | 1 | 7 |
| `2.4.1` | EFS is encrypted at rest | 1 | 7 |
| `3.4` | The CloudTrail bucket has access logging | 1 | 7 |
| `3.8` | S3 object writes are logged | 1 | 7 |
| `3.9` | S3 object reads are logged | 1 | 7 |
| `4.1` | Unauthorized API calls are alerted on | 1 | 7 |
| `4.2` | Console sign-in without MFA is alerted on | 1 | 7 |
| `4.3` | Root user activity is alerted on | 1 | 7 |
| `4.4` | IAM policy changes are alerted on | 1 | 7 |
| `4.5` | CloudTrail configuration changes are alerted on | 1 | 7 |
| `4.6` | Failed console sign-ins are alerted on | 1 | 7 |
| `4.7` | Disabling or deleting a customer-managed key is alerted on | 1 | 7 |
| `4.8` | S3 bucket policy changes are alerted on | 1 | 7 |
| `4.9` | AWS Config changes are alerted on | 1 | 7 |
| `4.10` | Security group changes are alerted on | 1 | 7 |
| `4.11` | Network ACL changes are alerted on | 1 | 7 |
| `4.12` | Network gateway changes are alerted on | 1 | 7 |
| `4.13` | Route table changes are alerted on | 1 | 7 |
| `4.14` | VPC changes are alerted on | 1 | 7 |
| `4.15` | AWS Organizations changes are alerted on | 1 | 7 |
| `4.16` | Security Hub is enabled | 1 | 7 |
| `5.1` | Network ACLs block internet admin ports | 1 | 7 |
| `5.4` | Default security groups allow no traffic | 1 | 7 |
| `5.6` | Instance metadata requires session tokens (IMDSv2) | 1 | 7 |
# CIS Microsoft Azure Foundations Benchmark and connectors (/docs/framework-connectors/cis-azure)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard's automated tests map to **85** recommendations of CIS Microsoft Azure Foundations Benchmark v2.1.0. **72** tests apply: 72 read a connected system, and 0 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
A CIS benchmark is a catalogue mapping: results show on the tests, filters and evidence with their recommendation numbers, and the benchmark is not a framework in your library.
## How to connect for this framework
1. Connect the systems you run from the table below. Each connector links to its setup steps.
2. Open **Compliance › Tests** and filter by the benchmark to see its results.
3. Tests run on their schedule, or straight away with **Run now** on **Compliance › Tests**. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
## Connectors with automated evidence (1)
| Connector | Controls it provides evidence for | Tests |
| ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [Microsoft Azure](/docs/compliance-connectors/setup/cloud-infrastructure/microsoft-azure) (also Microsoft Entra ID, Azure Government) | `2.1.10`, `2.1.12`, `2.1.13`, `2.1.17`, `2.1.18`, `2.1.19`, `2.1.2`, `2.1.20`, `2.1.21`, `2.1.9`, `3.10`, `3.11`, `3.12`, `3.13`, `3.14`, `3.16`, `3.2`, `3.3`, `3.5`, `3.7`, `3.8`, `3.9`, `4.1.1`, `4.1.3`, `4.1.4`, `4.1.6`, `4.2.1`, `4.2.2`, `4.2.3`, `4.2.4`, `4.2.5`, `4.3.1`, `4.3.2`, `4.3.3`, `4.3.4`, `4.3.5`, `4.3.6`, `4.4.1`, `4.4.2`, `4.4.3`, `4.4.4`, `4.5.1`, `4.5.2`, `4.5.3`, `5.1.3`, `5.1.4`, `5.1.5`, `5.1.7`, `5.2.1`, `5.2.10`, `5.2.2`, `5.2.3`, `5.2.4`, `5.2.5`, `5.2.6`, `5.2.7`, `5.2.8`, `5.2.9`, `5.3.1`, `5.5`, `6.3`, `6.5`, `6.6`, `7.1`, `7.2`, `7.3`, `7.4`, `7.9`, `8.1`, `8.2`, `8.3`, `8.4`, `8.5`, `8.6`, `8.7`, `9.1`, `9.10`, `9.2`, `9.3`, `9.4`, `9.5`, `9.6`, `9.7`, `9.8`, `9.9` | 72 |
## Recommendations (85)
| Recommendation | Title | Automated tests | Connectors |
| -------------- | ----------------------------------------------------------- | --------------- | ---------- |
| `2.1.2` | Defender for App Service is on | 1 | 3 |
| `2.1.9` | Defender for Containers is on | 1 | 3 |
| `2.1.10` | Defender for Key Vault is on | 1 | 3 |
| `2.1.12` | Defender for Resource Manager is on | 1 | 3 |
| `2.1.13` | The cloud security benchmark policies stay on | 1 | 3 |
| `2.1.17` | Subscription owners get alert emails | 1 | 3 |
| `2.1.18` | A security contact email is set | 1 | 3 |
| `2.1.19` | High-severity alerts are emailed | 1 | 3 |
| `2.1.20` | Defender for Cloud shares data with Defender for Cloud Apps | 1 | 3 |
| `2.1.21` | Defender for Cloud integrates Defender for Endpoint | 1 | 3 |
| `3.2` | Storage uses infrastructure encryption | 1 | 3 |
| `3.3` | Storage key rotation reminders are set | 1 | 3 |
| `3.5` | Queue service requests are logged | 1 | 3 |
| `3.7` | Storage public network access is off | 1 | 3 |
| `3.8` | Storage networks deny by default | 1 | 3 |
| `3.9` | Trusted Azure services can pass the storage firewall | 1 | 3 |
| `3.10` | Storage is reached through private endpoints | 1 | 3 |
| `3.11` | Blob and container soft delete are on | 2 | 3 |
| `3.12` | Storage holding critical data uses customer-managed keys | 1 | 3 |
| `3.13` | Blob service requests are logged | 1 | 3 |
| `3.14` | Table service requests are logged | 1 | 3 |
| `3.16` | Cross-tenant replication is off | 1 | 3 |
| `4.1.1` | SQL server auditing is on | 1 | 3 |
| `4.1.3` | SQL TDE protector is a customer-managed key | 1 | 3 |
| `4.1.4` | SQL servers have an Entra administrator | 1 | 3 |
| `4.1.6` | SQL audit records are kept over 90 days | 1 | 3 |
| `4.2.1` | Defender for SQL is on for SQL servers | 1 | 3 |
| `4.2.2` | SQL vulnerability assessment is set up | 1 | 3 |
| `4.2.3` | SQL vulnerability assessment scans on a schedule | 1 | 3 |
| `4.2.4` | SQL vulnerability assessment reports go to named recipients | 1 | 3 |
| `4.2.5` | SQL vulnerability assessment reports reach admins | 1 | 3 |
| `4.3.1` | PostgreSQL requires TLS | 1 | 3 |
| `4.3.2` | PostgreSQL logs checkpoints | 1 | 3 |
| `4.3.3` | PostgreSQL logs connections | 1 | 3 |
| `4.3.4` | PostgreSQL logs disconnections | 1 | 3 |
| `4.3.5` | PostgreSQL throttles failed connections | 1 | 3 |
| `4.3.6` | PostgreSQL keeps logs more than three days | 1 | 3 |
| `4.4.1` | MySQL requires TLS | 1 | 3 |
| `4.4.2` | MySQL allows only TLS 1.2 and later | 1 | 3 |
| `4.4.3` | MySQL audit log is on | 1 | 3 |
| `4.4.4` | MySQL audit log records connections | 1 | 3 |
| `4.5.1` | Cosmos DB is limited to selected networks | 1 | 3 |
| `4.5.2` | Cosmos DB is reached through private endpoints | 1 | 3 |
| `4.5.3` | Cosmos DB uses Entra ID authorization | 1 | 3 |
| `5.1.3` | Activity log storage is not public | 1 | 3 |
| `5.1.4` | Activity log storage uses a customer-managed key | 1 | 3 |
| `5.1.5` | Key Vault logging is on | 1 | 3 |
| `5.1.7` | App Service HTTP logs are collected | 1 | 3 |
| `5.2.1` | Policy assignment creation is alerted on | 1 | 3 |
| `5.2.2` | Policy assignment deletion is alerted on | 1 | 3 |
| `5.2.3` | NSG creation or change is alerted on | 1 | 3 |
| `5.2.4` | NSG deletion is alerted on | 1 | 3 |
| `5.2.5` | Security solution creation or change is alerted on | 1 | 3 |
| `5.2.6` | Security solution deletion is alerted on | 1 | 3 |
| `5.2.7` | SQL firewall rule changes are alerted on | 1 | 3 |
| `5.2.8` | SQL firewall rule deletion is alerted on | 1 | 3 |
| `5.2.9` | Public IP creation or change is alerted on | 1 | 3 |
| `5.2.10` | Public IP deletion is alerted on | 1 | 3 |
| `5.3.1` | Application Insights is set up | 1 | 3 |
| `5.5` | Basic SKUs are not used for monitored resources | 1 | 3 |
| `6.3` | Internet UDP access is restricted | 1 | 3 |
| `6.5` | Flow logs are kept at least 90 days | 1 | 3 |
| `6.6` | Network Watcher runs in every region in use | 1 | 3 |
| `7.1` | Azure Bastion is used for VM access | 1 | 3 |
| `7.2` | VMs use managed disks | 1 | 3 |
| `7.3` | VM disks are encrypted with customer-managed keys | 1 | 3 |
| `7.4` | Unattached disks use customer-managed keys | 1 | 3 |
| `7.9` | VMs use Trusted Launch | 1 | 3 |
| `8.1` | Keys in RBAC vaults expire | 1 | 3 |
| `8.2` | Keys in access-policy vaults expire | 1 | 3 |
| `8.3` | Secrets in RBAC vaults expire | 1 | 3 |
| `8.4` | Secrets in access-policy vaults expire | 1 | 3 |
| `8.5` | Key vaults are recoverable | 1 | 3 |
| `8.6` | Key vaults use Azure RBAC | 1 | 3 |
| `8.7` | Key vaults use private endpoints | 1 | 3 |
| `9.1` | App Service authentication is set up | 1 | 3 |
| `9.2` | Web apps redirect HTTP to HTTPS | 1 | 3 |
| `9.3` | Web apps use current TLS | 1 | 3 |
| `9.4` | Web apps require client certificates | 1 | 3 |
| `9.5` | Web apps use a managed identity | 1 | 3 |
| `9.6` | Web app PHP runtime is current | 1 | 3 |
| `9.7` | Web app Python runtime is current | 1 | 3 |
| `9.8` | Web app Java runtime is current | 1 | 3 |
| `9.9` | Web apps use the current HTTP version | 1 | 3 |
| `9.10` | Web app FTP deployments are off | 1 | 3 |
# CIS Google Cloud Platform Foundations Benchmark and connectors (/docs/framework-connectors/cis-gcp)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard's automated tests map to **61** recommendations of CIS Google Cloud Platform Foundations Benchmark v3.0.0. **49** tests apply: 49 read a connected system, and 0 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
A CIS benchmark is a catalogue mapping: results show on the tests, filters and evidence with their recommendation numbers, and the benchmark is not a framework in your library.
## How to connect for this framework
1. Connect the systems you run from the table below. Each connector links to its setup steps.
2. Open **Compliance › Tests** and filter by the benchmark to see its results.
3. Tests run on their schedule, or straight away with **Run now** on **Compliance › Tests**. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
## Connectors with automated evidence (1)
| Connector | Controls it provides evidence for | Tests |
| ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [Google Cloud Platform](/docs/compliance-connectors/setup/cloud-infrastructure/google-cloud-platform) | `1.1`, `1.11`, `1.13`, `1.14`, `1.15`, `1.16`, `1.4`, `1.5`, `1.6`, `1.8`, `1.9`, `2.10`, `2.11`, `2.12`, `2.13`, `2.15`, `2.16`, `2.2`, `2.3`, `2.4`, `2.5`, `2.6`, `2.7`, `2.8`, `2.9`, `3.1`, `3.2`, `3.3`, `3.4`, `3.5`, `3.9`, `4.1`, `4.11`, `4.2`, `4.3`, `4.4`, `4.5`, `4.6`, `4.7`, `4.8`, `4.9`, `6.1.2`, `6.1.3`, `6.2.1`, `6.2.2`, `6.2.3`, `6.2.4`, `6.2.5`, `6.2.6`, `6.2.7`, `6.2.8`, `6.3.1`, `6.3.2`, `6.3.3`, `6.3.4`, `6.3.5`, `6.3.6`, `6.3.7`, `6.4`, `7.1`, `7.3` | 49 |
## Recommendations (61)
| Recommendation | Title | Automated tests | Connectors |
| -------------- | --------------------------------------------------------- | --------------- | ---------- |
| `1.1` | Only corporate accounts are granted access | 1 | 1 |
| `1.4` | Service accounts use only Google-managed keys | 1 | 1 |
| `1.5` | Service accounts hold no admin roles | 1 | 1 |
| `1.6` | Service account impersonation is not granted project-wide | 1 | 1 |
| `1.8` | Service account duties are separated | 1 | 1 |
| `1.9` | KMS keys are not public | 1 | 1 |
| `1.11` | KMS duties are separated | 1 | 1 |
| `1.13` | API keys are limited to named hosts and apps | 1 | 1 |
| `1.14` | API keys are limited to the APIs they need | 1 | 1 |
| `1.15` | API keys are replaced every 90 days | 1 | 1 |
| `1.16` | Essential contacts are configured | 1 | 1 |
| `2.2` | A sink exports every log entry | 1 | 1 |
| `2.3` | Log buckets have locked retention | 1 | 1 |
| `2.4` | Project ownership changes are alerted on | 1 | 1 |
| `2.5` | Audit configuration changes are alerted on | 1 | 1 |
| `2.6` | Custom role changes are alerted on | 1 | 1 |
| `2.7` | Firewall rule changes are alerted on | 1 | 1 |
| `2.8` | Route changes are alerted on | 1 | 1 |
| `2.9` | VPC network changes are alerted on | 1 | 1 |
| `2.10` | Storage IAM changes are alerted on | 1 | 1 |
| `2.11` | Cloud SQL configuration changes are alerted on | 1 | 1 |
| `2.12` | Cloud DNS logging covers every VPC | 1 | 1 |
| `2.13` | Cloud Asset Inventory is on | 1 | 1 |
| `2.15` | Access Approval is enrolled | 1 | 1 |
| `2.16` | HTTP(S) load balancers log requests | 1 | 1 |
| `3.1` | No default network | 1 | 1 |
| `3.2` | No legacy networks | 1 | 1 |
| `3.3` | DNSSEC is on for Cloud DNS | 1 | 1 |
| `3.4` | DNSSEC key-signing keys avoid RSASHA1 | 1 | 1 |
| `3.5` | DNSSEC zone-signing keys avoid RSASHA1 | 1 | 1 |
| `3.9` | TLS policies exclude weak ciphers | 1 | 1 |
| `4.1` | VMs avoid the default service account | 1 | 1 |
| `4.2` | VMs avoid the default account with full API access | 1 | 1 |
| `4.3` | VMs block project-wide SSH keys | 1 | 1 |
| `4.4` | OS Login is on | 1 | 1 |
| `4.5` | Serial port access is off | 1 | 1 |
| `4.6` | IP forwarding is off | 1 | 1 |
| `4.7` | Critical VM disks use customer-controlled keys | 1 | 1 |
| `4.8` | Shielded VM is on | 1 | 1 |
| `4.9` | VMs have no public IP | 1 | 1 |
| `4.11` | VMs use Confidential Computing | 1 | 1 |
| `6.1.2` | MySQL hides other databases | 1 | 1 |
| `6.1.3` | MySQL local\_infile is off | 1 | 1 |
| `6.2.1` | PostgreSQL error verbosity is DEFAULT or stricter | 1 | 1 |
| `6.2.2` | PostgreSQL logs connections | 1 | 1 |
| `6.2.3` | PostgreSQL logs disconnections | 1 | 1 |
| `6.2.4` | PostgreSQL logs statements appropriately | 1 | 1 |
| `6.2.5` | PostgreSQL logs messages at WARNING or above | 1 | 1 |
| `6.2.6` | PostgreSQL logs failing statements | 1 | 1 |
| `6.2.7` | PostgreSQL does not log statements by duration | 1 | 1 |
| `6.2.8` | PostgreSQL audit logging is on | 1 | 1 |
| `6.3.1` | SQL Server external scripts are off | 1 | 1 |
| `6.3.2` | SQL Server ownership chaining is off | 1 | 1 |
| `6.3.3` | SQL Server user connections are not capped | 1 | 1 |
| `6.3.4` | SQL Server user options are not set | 1 | 1 |
| `6.3.5` | SQL Server remote access is off | 1 | 1 |
| `6.3.6` | SQL Server trace flag 3625 is on | 1 | 1 |
| `6.3.7` | SQL Server contained database authentication is off | 1 | 1 |
| `6.4` | Cloud SQL requires TLS | 1 | 1 |
| `7.1` | BigQuery datasets are not public | 1 | 1 |
| `7.3` | BigQuery datasets default to a customer-managed key | 1 | 1 |
# CIS Kubernetes Benchmark and connectors (/docs/framework-connectors/cis-k8s)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard's automated tests map to **60** recommendations of CIS Kubernetes Benchmark v1.9.0. **41** tests apply: 41 read a connected system, and 0 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
A CIS benchmark is a catalogue mapping: results show on the tests, filters and evidence with their recommendation numbers, and the benchmark is not a framework in your library.
## How to connect for this framework
1. Connect the systems you run from the table below. Each connector links to its setup steps.
2. Open **Compliance › Tests** and filter by the benchmark to see its results.
3. Tests run on their schedule, or straight away with **Run now** on **Compliance › Tests**. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
## Connectors with automated evidence (1)
| Connector | Controls it provides evidence for | Tests |
| -------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [Kubernetes](/docs/compliance-connectors/setup/cloud-infrastructure/kubernetes) (also Gatekeeper OPA, Kyverno) | `1.2.1`, `1.2.10`, `1.2.12`, `1.2.13`, `1.2.14`, `1.2.15`, `1.2.16`, `1.2.17`, `1.2.18`, `1.2.19`, `1.2.2`, `1.2.21`, `1.2.22`, `1.2.23`, `1.2.24`, `1.2.25`, `1.2.26`, `1.2.27`, `1.2.29`, `1.2.4`, `1.2.5`, `1.2.6`, `1.2.7`, `1.2.8`, `1.3.2`, `1.3.3`, `1.3.4`, `1.3.5`, `1.3.7`, `1.4.1`, `1.4.2`, `2.1`, `2.2`, `2.3`, `2.4`, `2.5`, `2.6`, `5.1.10`, `5.1.11`, `5.1.12`, `5.1.13`, `5.1.2`, `5.1.3`, `5.1.4`, `5.1.5`, `5.1.6`, `5.1.8`, `5.1.9`, `5.2.1`, `5.2.10`, `5.2.11`, `5.2.12`, `5.2.13`, `5.2.6`, `5.2.7`, `5.2.8`, `5.2.9`, `5.4.1`, `5.7.2`, `5.7.4` | 41 |
## Recommendations (60)
| Recommendation | Title | Automated tests | Connectors |
| -------------- | ----------------------------------------------------------- | --------------- | ---------- |
| `1.2.1` | API server refuses anonymous requests | 1 | 3 |
| `1.2.2` | API server reads no static token file | 1 | 3 |
| `1.2.4` | API server presents a client certificate to kubelets | 1 | 3 |
| `1.2.5` | API server verifies kubelet serving certificates | 1 | 3 |
| `1.2.6` | API server authorization is never AlwaysAllow | 1 | 3 |
| `1.2.7` | API server authorizes kubelets with the Node authorizer | 1 | 3 |
| `1.2.8` | API server authorizes with RBAC | 1 | 3 |
| `1.2.10` | AlwaysAdmit admission plugin is off | 1 | 3 |
| `1.2.12` | ServiceAccount admission plugin is on | 1 | 3 |
| `1.2.13` | NamespaceLifecycle admission plugin is on | 1 | 3 |
| `1.2.14` | NodeRestriction admission plugin is on | 1 | 3 |
| `1.2.15` | API server profiling endpoint is off | 1 | 3 |
| `1.2.16` | API server writes an audit log | 1 | 3 |
| `1.2.17` | API server keeps audit logs for at least 30 days | 1 | 3 |
| `1.2.18` | API server keeps at least 10 rotated audit logs | 1 | 3 |
| `1.2.19` | API server rotates audit logs at 100 MB or more | 1 | 3 |
| `1.2.21` | API server checks service account tokens against etcd | 1 | 3 |
| `1.2.22` | API server has a service account verification key | 1 | 3 |
| `1.2.23` | API server authenticates to etcd with a client certificate | 1 | 3 |
| `1.2.24` | API server serves TLS with its own certificate | 1 | 3 |
| `1.2.25` | API server verifies client certificates against a CA | 1 | 3 |
| `1.2.26` | API server verifies etcd's certificate against a CA | 1 | 3 |
| `1.2.27` | API server encrypts stored resources with a provider config | 1 | 3 |
| `1.2.29` | API server offers only strong TLS cipher suites | 1 | 3 |
| `1.3.2` | Controller manager profiling endpoint is off | 1 | 3 |
| `1.3.3` | Controller manager uses one service account per controller | 1 | 3 |
| `1.3.4` | Controller manager signs service account tokens with a key | 1 | 3 |
| `1.3.5` | Controller manager hands pods the cluster root CA | 1 | 3 |
| `1.3.7` | Controller manager listens on loopback only | 1 | 3 |
| `1.4.1` | Scheduler profiling endpoint is off | 1 | 3 |
| `1.4.2` | Scheduler listens on loopback only | 1 | 3 |
| `2.1` | etcd serves client TLS with a certificate | 1 | 3 |
| `2.2` | etcd requires client certificates | 1 | 3 |
| `2.3` | etcd uses no self-signed automatic client TLS | 1 | 3 |
| `2.4` | etcd peers use TLS certificates | 1 | 3 |
| `2.5` | etcd requires peer certificates | 1 | 3 |
| `2.6` | etcd uses no self-signed automatic peer TLS | 1 | 3 |
| `5.1.2` | Few roles can read Secrets | 1 | 3 |
| `5.1.3` | Roles avoid wildcards | 1 | 3 |
| `5.1.4` | Few roles can create pods | 1 | 3 |
| `5.1.5` | Default service accounts are not used | 1 | 3 |
| `5.1.6` | Service account tokens are mounted only where needed | 1 | 3 |
| `5.1.8` | Bind, impersonate and escalate are rarely granted | 1 | 3 |
| `5.1.9` | Few roles can create persistent volumes | 1 | 3 |
| `5.1.10` | Few roles can reach the nodes proxy | 1 | 3 |
| `5.1.11` | Few roles can approve certificate requests | 1 | 3 |
| `5.1.12` | Few roles can change admission webhooks | 1 | 3 |
| `5.1.13` | Few roles can mint service account tokens | 1 | 3 |
| `5.2.1` | An admission policy mechanism is active | 2 | 3 |
| `5.2.6` | Containers cannot escalate privileges | 1 | 3 |
| `5.2.7` | Containers do not run as root | 1 | 3 |
| `5.2.8` | Containers drop NET\_RAW | 1 | 3 |
| `5.2.9` | Containers add no Linux capabilities | 1 | 3 |
| `5.2.10` | Containers drop all Linux capabilities | 1 | 3 |
| `5.2.11` | No Windows HostProcess containers | 1 | 3 |
| `5.2.12` | No hostPath volumes | 1 | 3 |
| `5.2.13` | No host ports | 1 | 3 |
| `5.4.1` | Secrets are mounted as files, not environment variables | 1 | 3 |
| `5.7.2` | Pods use the RuntimeDefault seccomp profile | 1 | 3 |
| `5.7.4` | Workloads stay out of the default namespace | 1 | 3 |
# CIS Oracle Cloud Infrastructure Foundations Benchmark and connectors (/docs/framework-connectors/cis-oci)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard's automated tests map to **51** recommendations of CIS Oracle Cloud Infrastructure Foundations Benchmark v3.0.0. **40** tests apply: 40 read a connected system, and 0 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
A CIS benchmark is a catalogue mapping: results show on the tests, filters and evidence with their recommendation numbers, and the benchmark is not a framework in your library.
## How to connect for this framework
1. Connect the systems you run from the table below. Each connector links to its setup steps.
2. Open **Compliance › Tests** and filter by the benchmark to see its results.
3. Tests run on their schedule, or straight away with **Run now** on **Compliance › Tests**. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
## Connectors with automated evidence (1)
| Connector | Controls it provides evidence for | Tests |
| ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [Oracle Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/oracle-cloud) (also Oracle Cloud Government) | `1.10`, `1.12`, `1.13`, `1.15`, `1.16`, `1.17`, `1.2`, `1.3`, `1.4`, `1.5`, `1.6`, `1.7`, `1.8`, `1.9`, `2.1`, `2.2`, `2.3`, `2.4`, `2.5`, `2.6`, `2.7`, `2.8`, `3.1`, `3.2`, `3.3`, `4.1`, `4.10`, `4.11`, `4.12`, `4.13`, `4.14`, `4.15`, `4.16`, `4.17`, `4.18`, `4.2`, `4.3`, `4.4`, `4.5`, `4.6`, `4.7`, `4.8`, `4.9`, `5.1.1`, `5.1.2`, `5.1.3`, `5.2.1`, `5.2.2`, `5.3.1`, `6.1`, `6.2` | 40 |
## Recommendations (51)
| Recommendation | Title | Automated tests | Connectors |
| -------------- | ---------------------------------------------------------------------- | --------------- | ---------- |
| `1.2` | Only the Administrators group may manage every resource | 1 | 2 |
| `1.3` | Delegated IAM administrators cannot change the Administrators group | 1 | 2 |
| `1.4` | Passwords must be at least 14 characters long | 1 | 2 |
| `1.5` | Passwords expire within one year | 1 | 2 |
| `1.6` | Earlier passwords cannot be reused | 1 | 2 |
| `1.7` | Every Console user with a password uses MFA | 1 | 2 |
| `1.8` | User API keys are replaced at least every 90 days | 1 | 2 |
| `1.9` | Customer secret keys are replaced at least every 90 days | 1 | 2 |
| `1.10` | Auth tokens are replaced at least every 90 days | 1 | 2 |
| `1.12` | Tenancy administrators hold no API keys | 1 | 2 |
| `1.13` | Local users have a verified email address | 1 | 2 |
| `1.15` | Storage administrators cannot delete the resources they manage | 1 | 2 |
| `1.16` | Credentials idle for 45 days are disabled | 1 | 2 |
| `1.17` | A user has at most one active API key | 1 | 2 |
| `2.1` | Security lists do not admit 0.0.0.0/0 on port 22 | 1 | 2 |
| `2.2` | Security lists do not admit 0.0.0.0/0 on port 3389 | 1 | 2 |
| `2.3` | Network security groups do not admit 0.0.0.0/0 on port 22 | 1 | 2 |
| `2.4` | Network security groups do not admit 0.0.0.0/0 on port 3389 | 1 | 2 |
| `2.5` | The default security list allows only ICMP inside the VCN | 1 | 2 |
| `2.6` | Integration Cloud network access is restricted | 1 | 2 |
| `2.7` | Analytics Cloud network access is restricted | 1 | 2 |
| `2.8` | Shared Autonomous Databases are restricted to allowed sources or a VCN | 1 | 2 |
| `3.1` | Legacy instance metadata endpoints are off | 1 | 2 |
| `3.2` | Instances boot with Secure Boot | 1 | 2 |
| `3.3` | Boot volume traffic is encrypted in transit | 1 | 2 |
| `4.1` | Default tags record the creating principal | 1 | 2 |
| `4.2` | A notification topic has a confirmed subscription | 1 | 2 |
| `4.3` | Identity provider changes raise a notification | 1 | 2 |
| `4.4` | Identity provider group mapping changes raise a notification | 1 | 2 |
| `4.5` | IAM group changes raise a notification | 1 | 2 |
| `4.6` | IAM policy changes raise a notification | 1 | 2 |
| `4.7` | User changes raise a notification | 1 | 2 |
| `4.8` | VCN changes raise a notification | 1 | 2 |
| `4.9` | Route table changes raise a notification | 1 | 2 |
| `4.10` | Security list changes raise a notification | 1 | 2 |
| `4.11` | Network security group changes raise a notification | 1 | 2 |
| `4.12` | Network gateway changes raise a notification | 1 | 2 |
| `4.13` | Every subnet has VCN flow logging | 1 | 2 |
| `4.14` | Cloud Guard is enabled in the root compartment | 1 | 2 |
| `4.15` | Cloud Guard problems raise a notification | 1 | 2 |
| `4.16` | Customer-managed keys are rotated at least yearly | 1 | 2 |
| `4.17` | Bucket writes are logged | 1 | 2 |
| `4.18` | Local user sign-ins raise a notification | 1 | 2 |
| `5.1.1` | No Object Storage bucket is publicly visible | 1 | 2 |
| `5.1.2` | Object Storage buckets use a customer-managed key | 1 | 2 |
| `5.1.3` | Object Storage buckets keep object versions | 1 | 2 |
| `5.2.1` | Block volumes use customer-managed keys | 1 | 2 |
| `5.2.2` | Boot volumes use customer-managed keys | 1 | 2 |
| `5.3.1` | File systems use customer-managed keys | 1 | 2 |
| `6.1` | Resources are organised in compartments | 1 | 2 |
| `6.2` | The root compartment holds no workloads | 1 | 2 |
# HIPAA Security Rule and connectors (/docs/framework-connectors/hipaa)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard's automated tests map to **14** controls of HIPAA Security Rule (45 CFR Part 164, Subpart C). **675** tests apply: 640 read a connected system, and 35 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
In the framework library: [HIPAA Security Rule](/docs/frameworks/americas/hipaa), with what a scan checks, the controls and the policy templates.
## How to connect for this framework
1. Connect the systems you run from the table below. Each connector links to its setup steps.
2. Open the framework on **Compliance › Frameworks**, then its **Connectors** tab: it lists the connectors that answer this framework's tests, which of them you have connected, and whether each connection is healthy.
3. Tests run on their schedule, or straight away with **Run now** on **Compliance › Tests**. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
## Connectors with automated evidence (359)
| Connector | Controls it provides evidence for | Tests |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [Microsoft Azure](/docs/compliance-connectors/setup/cloud-infrastructure/microsoft-azure) (also Microsoft Entra ID, Azure Government) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(c)(1)`, `164.312(d)`, `164.312(e)(1)` | 134 |
| [Google Cloud Platform](/docs/compliance-connectors/setup/cloud-infrastructure/google-cloud-platform) | `164.308(a)(1)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(c)(1)`, `164.312(d)`, `164.312(e)(1)` | 100 |
| [Oracle Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/oracle-cloud) (also Oracle Cloud Government) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 64 |
| [Amazon Web Services](/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services) (also AWS GovCloud, AWS CodeCommit, AWS Inspector, Amazon CloudWatch, Amazon S3, AWS Security Hub) | `164.308(a)(1)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 81 |
| [GitLab](/docs/compliance-connectors/setup/version-control/gitlab) (also GitLab Issues, GitLab Self-Managed) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.312(a)(1)`, `164.312(b)`, `164.312(c)(1)`, `164.312(d)` | 37 |
| [Google Workspace](/docs/compliance-connectors/setup/identity-and-sso/google-workspace) (also Google Cloud Identity, Google SSO) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(b)(1)`, `164.310(d)(1)`, `164.312(a)(1)`, `164.312(d)`, `164.312(e)(1)` | 24 |
| [OVHcloud](/docs/compliance-connectors/setup/cloud-infrastructure/ovhcloud) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 25 |
| [GitHub](/docs/compliance-connectors/setup/version-control/github) (also GitHub Enterprise, GitHub Issues) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)`, `164.312(a)(1)`, `164.312(b)`, `164.312(c)(1)`, `164.312(d)` | 40 |
| [Hetzner](/docs/compliance-connectors/setup/cloud-infrastructure/hetzner) | `164.308(a)(1)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 15 |
| [Alibaba Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/alibaba-cloud) | `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 19 |
| [Auth0](/docs/compliance-connectors/setup/identity-and-sso/auth0) (also Auth0 SSO) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)` | 12 |
| [JumpCloud](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud) (also JumpCloud MDM, JumpCloud SSO) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)`, `164.312(d)`, `164.312(e)(1)` | 15 |
| [MongoDB Atlas](/docs/compliance-connectors/setup/infrastructure/mongodb-atlas) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 8 |
| [Okta](/docs/compliance-connectors/setup/identity-and-sso/okta) (also Okta SSO) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)` | 14 |
| [Azure DevOps](/docs/compliance-connectors/setup/version-control/azure-devops) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)`, `164.312(a)(1)`, `164.312(c)(1)` | 25 |
| [Bitbucket](/docs/compliance-connectors/setup/version-control/bitbucket) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.312(a)(1)`, `164.312(c)(1)`, `164.312(d)` | 18 |
| [Cloudflare](/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 12 |
| [IBM Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/ibm-cloud) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 15 |
| [Keycloak](/docs/compliance-connectors/setup/identity-and-sso/keycloak) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)` | 7 |
| [Redis Cloud](/docs/compliance-connectors/setup/infrastructure/redis-cloud) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(d)`, `164.312(e)(1)` | 8 |
| [StackRox](/docs/compliance-connectors/setup/vulnerability-scanning/stackrox) (also Red Hat Advanced Cluster Security) | `164.308(a)(1)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.308(a)(8)`, `164.312(b)` | 10 |
| [Supabase](/docs/compliance-connectors/setup/infrastructure/supabase) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(d)`, `164.312(e)(1)` | 7 |
| [Claude (Anthropic)](/docs/compliance-connectors/setup/business-applications/claude-anthropic) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)` | 7 |
| [Codeberg](/docs/compliance-connectors/setup/version-control/codeberg) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.312(a)(1)`, `164.312(c)(1)` | 6 |
| [CrowdStrike Falcon](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)` | 15 |
| [ElevenLabs](/docs/compliance-connectors/setup/business-applications/elevenlabs) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)` | 6 |
| [Fireworks AI](/docs/compliance-connectors/setup/business-applications/fireworks-ai) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)` | 8 |
| [Fleet](/docs/compliance-connectors/setup/mdm/fleet) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)`, `164.312(e)(1)` | 8 |
| [Gitea](/docs/compliance-connectors/setup/version-control/gitea) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.312(a)(1)`, `164.312(c)(1)` | 6 |
| [Heroku](/docs/compliance-connectors/setup/cloud-infrastructure/heroku) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(d)`, `164.312(e)(1)` | 7 |
| [Infisical](/docs/compliance-connectors/setup/infrastructure/infisical) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)` | 8 |
| [Jamf](/docs/compliance-connectors/setup/mdm/jamf) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)`, `164.312(e)(1)` | 9 |
| [Kandji](/docs/compliance-connectors/setup/mdm/kandji) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)`, `164.312(e)(1)` | 8 |
| [Kolide](/docs/compliance-connectors/setup/mdm/kolide) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)`, `164.312(e)(1)` | 8 |
| [Kubernetes](/docs/compliance-connectors/setup/cloud-infrastructure/kubernetes) (also Gatekeeper OPA, Kyverno) | `164.308(a)(4)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 40 |
| [Linode](/docs/compliance-connectors/setup/cloud-infrastructure/linode) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(d)`, `164.312(e)(1)` | 6 |
| [Microsoft Intune](/docs/compliance-connectors/setup/mdm/microsoft-intune) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)`, `164.312(e)(1)` | 10 |
| [Mistral AI](/docs/compliance-connectors/setup/business-applications/mistral-ai) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)` | 7 |
| [Mosyle](/docs/compliance-connectors/setup/mdm/mosyle) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)`, `164.312(e)(1)` | 9 |
| [OneLogin](/docs/compliance-connectors/setup/identity-and-sso/onelogin) (also OneLogin SSO) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(a)(1)`, `164.312(d)` | 7 |
| [OpenAI API Platform](/docs/compliance-connectors/setup/business-applications/openai-api-platform) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)` | 8 |
| [Scaleway](/docs/compliance-connectors/setup/cloud-infrastructure/scaleway) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(d)`, `164.312(e)(1)` | 5 |
| [Sentry](/docs/compliance-connectors/setup/observability/sentry) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.312(a)(1)`, `164.312(d)` | 6 |
| [Akamai](/docs/compliance-connectors/setup/cloud-infrastructure/akamai) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)`, `164.312(e)(1)` | 5 |
| [ChatGPT](/docs/compliance-connectors/setup/business-applications/chatgpt) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)`, `164.312(d)` | 5 |
| [Cisco Meraki SM](/docs/compliance-connectors/setup/mdm/cisco-meraki-sm) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)` | 8 |
| [ClickHouse](/docs/compliance-connectors/setup/data-export/clickhouse) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(a)(1)` | 5 |
| [Datadog](/docs/compliance-connectors/setup/observability/datadog) (also Datadog CSM) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 10 |
| [Elastic Observability](/docs/compliance-connectors/setup/observability/elastic-observability) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(b)` | 6 |
| [Fastly](/docs/compliance-connectors/setup/cloud-infrastructure/fastly) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)`, `164.312(e)(1)` | 5 |
| [Gerrit](/docs/compliance-connectors/setup/version-control/gerrit) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.312(c)(1)` | 5 |
| [Hugging Face](/docs/compliance-connectors/setup/business-applications/hugging-face) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(d)` | 7 |
| [Ivanti Neurons](/docs/compliance-connectors/setup/mdm/ivanti-neurons) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)` | 8 |
| [LogicMonitor](/docs/compliance-connectors/setup/observability/logicmonitor) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)`, `164.312(b)` | 5 |
| [ManageEngine](/docs/compliance-connectors/setup/mdm/manageengine) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)` | 6 |
| [Miradore](/docs/compliance-connectors/setup/mdm/miradore) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)` | 8 |
| [Nextcloud](/docs/compliance-connectors/setup/cloud-storage-provider/nextcloud) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(a)(1)`, `164.312(d)` | 5 |
| [NinjaOne](/docs/compliance-connectors/setup/mdm/ninjaone) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)` | 6 |
| [OpenRouter](/docs/compliance-connectors/setup/business-applications/openrouter) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(d)` | 6 |
| [PingOne](/docs/compliance-connectors/setup/identity-and-sso/pingone) (also Ping Identity) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(d)` | 6 |
| [PlanetScale](/docs/compliance-connectors/setup/infrastructure/planetscale) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(d)` | 5 |
| [Red Hat OpenShift](/docs/compliance-connectors/setup/cloud-infrastructure/red-hat-openshift) | `164.308(a)(4)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)` | 4 |
| [Render](/docs/compliance-connectors/setup/cloud-infrastructure/render) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(d)` | 5 |
| [SentinelOne](/docs/compliance-connectors/setup/endpoint-detection-and-response/sentinelone) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)` | 8 |
| [ServiceNow](/docs/compliance-connectors/setup/ticketing/servicenow) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 9 |
| [SigNoz](/docs/compliance-connectors/setup/observability/signoz) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)` | 7 |
| [SimpleMDM](/docs/compliance-connectors/setup/mdm/simplemdm) | `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)`, `164.312(e)(1)` | 5 |
| [Snowflake](/docs/compliance-connectors/setup/data-export/snowflake) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)`, `164.312(e)(1)` | 5 |
| [Sophos Intercept X](/docs/compliance-connectors/setup/endpoint-detection-and-response/sophos-intercept-x) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)` | 9 |
| [Splunk](/docs/compliance-connectors/setup/observability/splunk) | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 5 |
| [Sumo Logic](/docs/compliance-connectors/setup/observability/sumo-logic) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)`, `164.312(d)` | 6 |
| [UpCloud](/docs/compliance-connectors/setup/cloud-infrastructure/upcloud) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(e)(1)` | 4 |
| [VMware](/docs/compliance-connectors/setup/cloud-infrastructure/vmware) | `164.308(a)(5)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)` | 6 |
| [Vultr](/docs/compliance-connectors/setup/cloud-infrastructure/vultr) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(e)(1)` | 5 |
| [xAI](/docs/compliance-connectors/setup/business-applications/xai) | `164.308(a)(3)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)` | 4 |
| [Airtable](/docs/compliance-connectors/setup/ticketing/airtable) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Asana](/docs/compliance-connectors/setup/ticketing/asana) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 8 |
| [Authentik](/docs/compliance-connectors/setup/identity-and-sso/authentik) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 5 |
| [Automox](/docs/compliance-connectors/setup/mdm/automox) | `164.308(a)(1)`, `164.308(a)(5)`, `164.310(d)(1)` | 4 |
| [Backblaze](/docs/compliance-connectors/setup/cloud-storage-provider/backblaze) | `164.308(a)(7)`, `164.312(a)(1)`, `164.312(e)(1)` | 3 |
| [Cisco Secure Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/cisco-secure-endpoint) | `164.308(a)(1)`, `164.308(a)(5)`, `164.308(a)(6)` | 6 |
| [ClickUp](/docs/compliance-connectors/setup/ticketing/clickup) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 8 |
| [Cloudflare Access](/docs/compliance-connectors/setup/identity-and-sso/cloudflare-access) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 3 |
| [Coralogix](/docs/compliance-connectors/setup/observability/coralogix) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 3 |
| [Docker](/docs/compliance-connectors/setup/infrastructure/docker) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(a)(1)` | 4 |
| [Duo Security](/docs/compliance-connectors/setup/identity-and-sso/duo-security) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 6 |
| [Dynatrace](/docs/compliance-connectors/setup/observability/dynatrace) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 3 |
| [Fly.io](/docs/compliance-connectors/setup/cloud-infrastructure/fly-io) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [FusionAuth](/docs/compliance-connectors/setup/identity-and-sso/fusionauth) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [GoDaddy](/docs/compliance-connectors/setup/cloud-infrastructure/godaddy) | `164.308(a)(3)`, `164.312(d)`, `164.312(e)(1)` | 3 |
| [Grafana](/docs/compliance-connectors/setup/observability/grafana) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 4 |
| [Hexnode](/docs/compliance-connectors/setup/mdm/hexnode) | `164.308(a)(3)`, `164.308(a)(5)`, `164.310(d)(1)` | 5 |
| [IBM Verify](/docs/compliance-connectors/setup/identity-and-sso/ibm-verify) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Instana](/docs/compliance-connectors/setup/observability/instana) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 3 |
| [Jira](/docs/compliance-connectors/setup/ticketing/jira) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 9 |
| [Linear](/docs/compliance-connectors/setup/ticketing/linear) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 9 |
| [Logto](/docs/compliance-connectors/setup/identity-and-sso/logto) | `164.308(a)(4)`, `164.308(a)(5)`, `164.312(d)` | 4 |
| [Logz.io](/docs/compliance-connectors/setup/observability/logz-io) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 5 |
| [Looker](/docs/compliance-connectors/setup/data-export/looker) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Mailgun](/docs/compliance-connectors/setup/communications-platforms/mailgun) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Make](/docs/compliance-connectors/setup/security-automation/make) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Mattermost](/docs/compliance-connectors/setup/communications-platforms/mattermost) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Microsoft Defender for Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/microsoft-defender-for-endpoint) | `164.308(a)(1)`, `164.308(a)(5)`, `164.308(a)(6)` | 12 |
| [MinIO](/docs/compliance-connectors/setup/cloud-storage-provider/minio) | `164.308(a)(7)`, `164.312(a)(1)`, `164.312(e)(1)` | 3 |
| [Monday.com](/docs/compliance-connectors/setup/ticketing/monday-com) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 8 |
| [New Relic](/docs/compliance-connectors/setup/observability/new-relic) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 4 |
| [OpenStack](/docs/compliance-connectors/setup/cloud-infrastructure/openstack) | `164.308(a)(4)`, `164.308(a)(7)`, `164.312(a)(1)` | 4 |
| [Opsgenie Alerts](/docs/compliance-connectors/setup/ticketing/opsgenie-alerts) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 5 |
| [Oracle Identity](/docs/compliance-connectors/setup/identity-and-sso/oracle-identity) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 5 |
| [ownCloud](/docs/compliance-connectors/setup/cloud-storage-provider/owncloud) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [PagerDuty](/docs/compliance-connectors/setup/ticketing/pagerduty) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 6 |
| [Platform.sh](/docs/compliance-connectors/setup/cloud-infrastructure/platform-sh) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Proxmox](/docs/compliance-connectors/setup/cloud-infrastructure/proxmox) | `164.308(a)(4)`, `164.308(a)(7)`, `164.312(d)` | 3 |
| [Railway](/docs/compliance-connectors/setup/cloud-infrastructure/railway) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Rollbar](/docs/compliance-connectors/setup/observability/rollbar) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 4 |
| [Salesforce](/docs/compliance-connectors/setup/crm/salesforce) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Shortcut](/docs/compliance-connectors/setup/ticketing/shortcut) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 8 |
| [Site24x7](/docs/compliance-connectors/setup/observability/site24x7) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 4 |
| [Slack](/docs/compliance-connectors/setup/communications-platforms/slack) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [SolarWinds Service Desk](/docs/compliance-connectors/setup/ticketing/solarwinds-service-desk) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 8 |
| [Spaceship](/docs/compliance-connectors/setup/cloud-infrastructure/spaceship) | `164.308(a)(3)`, `164.312(d)`, `164.312(e)(1)` | 3 |
| [Terraform Cloud](/docs/compliance-connectors/setup/infrastructure/terraform-cloud) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Vercel](/docs/compliance-connectors/setup/cloud-infrastructure/vercel) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [VMware Workspace ONE](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-workspace-one) | `164.308(a)(5)`, `164.310(d)(1)`, `164.312(a)(1)` | 7 |
| [YouTrack](/docs/compliance-connectors/setup/ticketing/youtrack) | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(6)` | 8 |
| [Zabbix](/docs/compliance-connectors/setup/observability/zabbix) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(b)` | 4 |
| [Zendesk](/docs/compliance-connectors/setup/ticketing/zendesk) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Zitadel](/docs/compliance-connectors/setup/identity-and-sso/zitadel) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [Zoom](/docs/compliance-connectors/setup/communications-platforms/zoom) | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [15Five](/docs/compliance-connectors/setup/hris/15five) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [1Password](/docs/compliance-connectors/setup/identity-and-sso/1password) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Action1](/docs/compliance-connectors/setup/mdm/action1) | `164.308(a)(5)`, `164.310(d)(1)` | 2 |
| [ActiveCampaign](/docs/compliance-connectors/setup/crm/activecampaign) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Adobe Acrobat Sign](/docs/compliance-connectors/setup/digital-signature/adobe-acrobat-sign) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Aha!](/docs/compliance-connectors/setup/ticketing/aha) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Airbyte](/docs/compliance-connectors/setup/data-export/airbyte) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Aircall](/docs/compliance-connectors/setup/communications-platforms/aircall) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Amplitude](/docs/compliance-connectors/setup/data-export/amplitude) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Ansible](/docs/compliance-connectors/setup/infrastructure/ansible) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Apollo IO](/docs/compliance-connectors/setup/business-applications/apollo-io) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Aptible](/docs/compliance-connectors/setup/cloud-infrastructure/aptible) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Ashby](/docs/compliance-connectors/setup/hris/ashby) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Assembla](/docs/compliance-connectors/setup/version-control/assembla) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Attio](/docs/compliance-connectors/setup/crm/attio) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Baramundi](/docs/compliance-connectors/setup/mdm/baramundi) | `164.308(a)(5)`, `164.310(d)(1)` | 4 |
| [Basecamp](/docs/compliance-connectors/setup/ticketing/basecamp) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Beanstalk](/docs/compliance-connectors/setup/version-control/beanstalk) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Better Stack](/docs/compliance-connectors/setup/observability/better-stack) | `164.308(a)(6)`, `164.312(b)` | 3 |
| [Beyond Identity](/docs/compliance-connectors/setup/identity-and-sso/beyond-identity) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Bitdefender GravityZone](/docs/compliance-connectors/setup/endpoint-detection-and-response/bitdefender-gravityzone) | `164.308(a)(5)`, `164.308(a)(6)` | 5 |
| [BoldSign](/docs/compliance-connectors/setup/digital-signature/boldsign) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Box](/docs/compliance-connectors/setup/cloud-storage-provider/box) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Brex](/docs/compliance-connectors/setup/vendor-procurement/brex) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Canva](/docs/compliance-connectors/setup/business-applications/canva) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Capsule](/docs/compliance-connectors/setup/crm/capsule) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Census](/docs/compliance-connectors/setup/data-export/census) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Citrix Endpoint Management](/docs/compliance-connectors/setup/mdm/citrix-endpoint-management) | `164.308(a)(5)`, `164.310(d)(1)` | 5 |
| [Citrix ShareFile](/docs/compliance-connectors/setup/cloud-storage-provider/citrix-sharefile) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Close](/docs/compliance-connectors/setup/crm/close) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Cobalt](/docs/compliance-connectors/setup/vulnerability-scanning/cobalt) | `164.308(a)(1)`, `164.308(a)(8)` | 3 |
| [Confluence](/docs/compliance-connectors/setup/compliance-as-code/confluence) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Copper](/docs/compliance-connectors/setup/crm/copper) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Cortex XDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/cortex-xdr) | `164.308(a)(5)`, `164.308(a)(6)` | 5 |
| [Coupa](/docs/compliance-connectors/setup/vendor-procurement/coupa) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Culture Amp](/docs/compliance-connectors/setup/hris/culture-amp) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Cybereason](/docs/compliance-connectors/setup/endpoint-detection-and-response/cybereason) | `164.308(a)(5)`, `164.308(a)(6)` | 5 |
| [Databricks](/docs/compliance-connectors/setup/data-export/databricks) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [dbt Cloud](/docs/compliance-connectors/setup/data-export/dbt-cloud) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Deep Instinct](/docs/compliance-connectors/setup/endpoint-detection-and-response/deep-instinct) | `164.308(a)(5)`, `164.308(a)(6)` | 4 |
| [Dialpad](/docs/compliance-connectors/setup/communications-platforms/dialpad) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [DigitalOcean](/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean) | `164.308(a)(7)`, `164.312(e)(1)` | 7 |
| [DocuSign](/docs/compliance-connectors/setup/digital-signature/docusign) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Dropbox](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Dropbox Sign](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox-sign) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Egnyte](/docs/compliance-connectors/setup/cloud-storage-provider/egnyte) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Elastic Security](/docs/compliance-connectors/setup/endpoint-detection-and-response/elastic-security) | `164.308(a)(5)`, `164.308(a)(6)` | 5 |
| [env0](/docs/compliance-connectors/setup/infrastructure/env0) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [ESET Protect](/docs/compliance-connectors/setup/endpoint-detection-and-response/eset-protect) | `164.308(a)(5)`, `164.308(a)(6)` | 4 |
| [Esper](/docs/compliance-connectors/setup/mdm/esper) | `164.308(a)(5)`, `164.310(d)(1)` | 2 |
| [Figma](/docs/compliance-connectors/setup/business-applications/figma) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Fivetran](/docs/compliance-connectors/setup/data-export/fivetran) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [folk](/docs/compliance-connectors/setup/crm/folk) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [ForgeRock](/docs/compliance-connectors/setup/identity-and-sso/forgerock) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Fortinet FortiEDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/fortinet-fortiedr) | `164.308(a)(5)`, `164.308(a)(6)` | 5 |
| [Freshdesk](/docs/compliance-connectors/setup/ticketing/freshdesk) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Freshservice](/docs/compliance-connectors/setup/ticketing/freshservice) | `164.308(a)(3)`, `164.308(a)(6)` | 4 |
| [Front](/docs/compliance-connectors/setup/communications-platforms/front) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [GoHighLevel](/docs/compliance-connectors/setup/crm/gohighlevel) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [GoTo Connect](/docs/compliance-connectors/setup/communications-platforms/goto-connect) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Greenhouse](/docs/compliance-connectors/setup/hris/greenhouse) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Gusto](/docs/compliance-connectors/setup/hris/gusto) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [HashiCorp Consul](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-consul) | `164.312(a)(1)`, `164.312(e)(1)` | 2 |
| [HashiCorp Nomad](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-nomad) | `164.312(a)(1)`, `164.312(e)(1)` | 2 |
| [HashiCorp Vault](/docs/compliance-connectors/setup/infrastructure/hashicorp-vault) | `164.312(b)`, `164.312(d)` | 2 |
| [Hevo Data](/docs/compliance-connectors/setup/data-export/hevo-data) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Hightouch](/docs/compliance-connectors/setup/data-export/hightouch) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Hive](/docs/compliance-connectors/setup/ticketing/hive) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [HubSpot](/docs/compliance-connectors/setup/crm/hubspot) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Huntress](/docs/compliance-connectors/setup/endpoint-detection-and-response/huntress) | `164.308(a)(5)`, `164.308(a)(6)` | 6 |
| [Insightly](/docs/compliance-connectors/setup/crm/insightly) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Intercom](/docs/compliance-connectors/setup/communications-platforms/intercom) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Ironclad](/docs/compliance-connectors/setup/digital-signature/ironclad) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Jamf Protect](/docs/compliance-connectors/setup/endpoint-detection-and-response/jamf-protect) | `164.308(a)(5)`, `164.308(a)(6)` | 4 |
| [Jira Service Management](/docs/compliance-connectors/setup/ticketing/jira-service-management) | `164.308(a)(1)`, `164.308(a)(6)` | 3 |
| [Kaspersky Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/kaspersky-endpoint) | `164.308(a)(5)`, `164.308(a)(6)` | 5 |
| [Keap](/docs/compliance-connectors/setup/crm/keap) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Lattice](/docs/compliance-connectors/setup/hris/lattice) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Launchpad](/docs/compliance-connectors/setup/version-control/launchpad) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Lever](/docs/compliance-connectors/setup/hris/lever) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Loopio](/docs/compliance-connectors/setup/vendor-procurement/loopio) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Microsoft Dynamics 365](/docs/compliance-connectors/setup/crm/microsoft-dynamics-365) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Miro](/docs/compliance-connectors/setup/communications-platforms/miro) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Mixpanel](/docs/compliance-connectors/setup/data-export/mixpanel) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [n8n](/docs/compliance-connectors/setup/security-automation/n8n) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Netlify](/docs/compliance-connectors/setup/cloud-infrastructure/netlify) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Northflank](/docs/compliance-connectors/setup/cloud-infrastructure/northflank) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Notion](/docs/compliance-connectors/setup/compliance-as-code/notion) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Nutanix](/docs/compliance-connectors/setup/cloud-infrastructure/nutanix) | `164.308(a)(4)`, `164.308(a)(7)` | 2 |
| [Nutshell](/docs/compliance-connectors/setup/crm/nutshell) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Oneflow](/docs/compliance-connectors/setup/digital-signature/oneflow) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [OneSpan Sign](/docs/compliance-connectors/setup/digital-signature/onespan-sign) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [OneTrust Vendorpedia](/docs/compliance-connectors/setup/vendor-procurement/onetrust-vendorpedia) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Opal](/docs/compliance-connectors/setup/user-access-review/opal) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [OpenPhone](/docs/compliance-connectors/setup/communications-platforms/openphone) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [PandaDoc](/docs/compliance-connectors/setup/digital-signature/pandadoc) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Pingdom](/docs/compliance-connectors/setup/observability/pingdom) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Pipedrive](/docs/compliance-connectors/setup/crm/pipedrive) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Prey](/docs/compliance-connectors/setup/mdm/prey) | `164.308(a)(5)`, `164.310(d)(1)` | 2 |
| [Productboard](/docs/compliance-connectors/setup/ticketing/productboard) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Pulumi](/docs/compliance-connectors/setup/infrastructure/pulumi) (also Pulumi Cloud) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Qovery](/docs/compliance-connectors/setup/cloud-infrastructure/qovery) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Qualys EDR](/docs/compliance-connectors/setup/vulnerability-scanning/qualys-edr) | `164.308(a)(5)`, `164.308(a)(6)` | 3 |
| [Ramp](/docs/compliance-connectors/setup/vendor-procurement/ramp) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Rancher](/docs/compliance-connectors/setup/cloud-infrastructure/rancher) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Red Canary](/docs/compliance-connectors/setup/endpoint-detection-and-response/red-canary) | `164.308(a)(5)`, `164.308(a)(6)` | 4 |
| [Redmine](/docs/compliance-connectors/setup/ticketing/redmine) | `164.308(a)(3)`, `164.308(a)(6)` | 5 |
| [RingCentral](/docs/compliance-connectors/setup/identity-and-sso/ringcentral) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Rocket.Chat](/docs/compliance-connectors/setup/communications-platforms/rocket-chat) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [SailPoint](/docs/compliance-connectors/setup/identity-and-sso/sailpoint) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Salesflare](/docs/compliance-connectors/setup/crm/salesflare) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Segment](/docs/compliance-connectors/setup/data-export/segment) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [SendGrid](/docs/compliance-connectors/setup/communications-platforms/sendgrid) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Setyl](/docs/compliance-connectors/setup/vendor-procurement/setyl) | `164.308(a)(3)`, `164.310(d)(1)` | 2 |
| [Shuffle](/docs/compliance-connectors/setup/security-automation/shuffle) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [SignNow](/docs/compliance-connectors/setup/digital-signature/signnow) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [SignRequest](/docs/compliance-connectors/setup/digital-signature/signrequest) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Smartsheet](/docs/compliance-connectors/setup/ticketing/smartsheet) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Spacelift](/docs/compliance-connectors/setup/infrastructure/spacelift) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Streak](/docs/compliance-connectors/setup/crm/streak) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [SugarCRM](/docs/compliance-connectors/setup/crm/sugarcrm) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Symantec Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/symantec-endpoint) | `164.308(a)(5)`, `164.308(a)(6)` | 5 |
| [Tanium](/docs/compliance-connectors/setup/endpoint-detection-and-response/tanium) | `164.308(a)(5)`, `164.308(a)(6)` | 4 |
| [Teamwork](/docs/compliance-connectors/setup/ticketing/teamwork) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Telnyx](/docs/compliance-connectors/setup/communications-platforms/telnyx) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [ThreatConnect](/docs/compliance-connectors/setup/security-automation/threatconnect) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Tines](/docs/compliance-connectors/setup/security-automation/tines) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Torii](/docs/compliance-connectors/setup/user-access-review/torii) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Tray.io](/docs/compliance-connectors/setup/security-automation/tray-io) | `164.308(a)(3)`, `164.308(a)(4)` | 2 |
| [Trellix](/docs/compliance-connectors/setup/endpoint-detection-and-response/trellix) | `164.308(a)(5)`, `164.308(a)(6)` | 4 |
| [Trello](/docs/compliance-connectors/setup/ticketing/trello) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Trend Micro Apex One](/docs/compliance-connectors/setup/endpoint-detection-and-response/trend-micro-apex-one) | `164.308(a)(5)`, `164.308(a)(6)` | 5 |
| [VMware Carbon Black](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-carbon-black) | `164.308(a)(5)`, `164.308(a)(6)` | 5 |
| [Vtiger](/docs/compliance-connectors/setup/crm/vtiger) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Wasabi](/docs/compliance-connectors/setup/cloud-storage-provider/wasabi) | `164.308(a)(7)`, `164.312(e)(1)` | 3 |
| [Webex](/docs/compliance-connectors/setup/communications-platforms/webex) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [WithSecure](/docs/compliance-connectors/setup/endpoint-detection-and-response/withsecure) | `164.308(a)(5)`, `164.308(a)(6)` | 5 |
| [Workable](/docs/compliance-connectors/setup/hris/workable) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Workato](/docs/compliance-connectors/setup/security-automation/workato) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Wrike](/docs/compliance-connectors/setup/ticketing/wrike) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Yousign](/docs/compliance-connectors/setup/digital-signature/yousign) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Zendesk Sell](/docs/compliance-connectors/setup/ticketing/zendesk-sell) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Zoho CRM](/docs/compliance-connectors/setup/crm/zoho-crm) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [Zoho Desk](/docs/compliance-connectors/setup/ticketing/zoho-desk) | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [360Learning](/docs/compliance-connectors/setup/security-training/360learning) | `164.308(a)(5)` | 1 |
| [42Gears](/docs/compliance-connectors/setup/mdm/42gears) | `164.310(d)(1)` | 1 |
| [Aikido Security](/docs/compliance-connectors/setup/vulnerability-scanning/aikido-security) | `164.308(a)(1)` | 4 |
| [Anchore](/docs/compliance-connectors/setup/vulnerability-scanning/anchore) | `164.308(a)(1)` | 4 |
| [AppDynamics](/docs/compliance-connectors/setup/observability/appdynamics) | `164.312(b)` | 1 |
| [BambooHR](/docs/compliance-connectors/setup/hris/bamboohr) | `164.308(a)(3)` | 1 |
| [BitSight](/docs/compliance-connectors/setup/vendor-procurement/bitsight) | `164.308(a)(1)` | 2 |
| [Bright Security](/docs/compliance-connectors/setup/vulnerability-scanning/bright-security) | `164.308(a)(1)` | 4 |
| [Bugcrowd](/docs/compliance-connectors/setup/vulnerability-scanning/bugcrowd) | `164.308(a)(1)` | 2 |
| [Burp Suite](/docs/compliance-connectors/setup/vulnerability-scanning/burp-suite) | `164.308(a)(1)` | 3 |
| [Ceridian Dayforce](/docs/compliance-connectors/setup/hris/ceridian-dayforce) | `164.308(a)(3)` | 1 |
| [Check Point CloudGuard](/docs/compliance-connectors/setup/cspm/check-point-cloudguard) | `164.308(a)(1)` | 3 |
| [Check Point Harmony](/docs/compliance-connectors/setup/endpoint-detection-and-response/check-point-harmony) | `164.308(a)(5)` | 2 |
| [Checkmarx](/docs/compliance-connectors/setup/vulnerability-scanning/checkmarx) | `164.308(a)(1)` | 4 |
| [Chronosphere](/docs/compliance-connectors/setup/observability/chronosphere) | `164.312(b)` | 1 |
| [Civo](/docs/compliance-connectors/setup/cloud-infrastructure/civo) | `164.312(e)(1)` | 2 |
| [Contrast Security](/docs/compliance-connectors/setup/vulnerability-scanning/contrast-security) | `164.308(a)(1)` | 4 |
| [Cortex XSOAR](/docs/compliance-connectors/setup/security-automation/cortex-xsoar) | `164.308(a)(6)` | 2 |
| [Cronitor](/docs/compliance-connectors/setup/observability/cronitor) | `164.312(b)` | 1 |
| [CrowdStrike Falcon Cloud](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon-cloud) | `164.308(a)(1)` | 3 |
| [D3 Security](/docs/compliance-connectors/setup/security-automation/d3-security) | `164.308(a)(6)` | 2 |
| [Deel](/docs/compliance-connectors/setup/hris/deel) | `164.308(a)(3)` | 1 |
| [Dependency-Track](/docs/compliance-connectors/setup/vulnerability-scanning/dependency-track) | `164.308(a)(1)` | 4 |
| [Detectify](/docs/compliance-connectors/setup/vulnerability-scanning/detectify) | `164.308(a)(1)` | 3 |
| [Docebo](/docs/compliance-connectors/setup/security-training/docebo) | `164.308(a)(5)` | 1 |
| [Employment Hero](/docs/compliance-connectors/setup/hris/employment-hero) | `164.308(a)(3)` | 1 |
| [Endor Labs](/docs/compliance-connectors/setup/vulnerability-scanning/endor-labs) | `164.308(a)(1)` | 4 |
| [Escape](/docs/compliance-connectors/setup/vulnerability-scanning/escape) | `164.308(a)(1)` | 4 |
| [Factorial](/docs/compliance-connectors/setup/hris/factorial) | `164.308(a)(3)` | 1 |
| [Firebase](/docs/compliance-connectors/setup/infrastructure/firebase) | `164.312(a)(1)` | 1 |
| [GitGuardian](/docs/compliance-connectors/setup/vulnerability-scanning/gitguardian) | `164.308(a)(1)` | 3 |
| [Google Chronicle SOAR](/docs/compliance-connectors/setup/security-automation/google-chronicle-soar) | `164.308(a)(6)` | 2 |
| [Google Drive](/docs/compliance-connectors/setup/cloud-storage-provider/google-drive) | `164.312(a)(1)` | 1 |
| [HackerOne](/docs/compliance-connectors/setup/vulnerability-scanning/hackerone) | `164.308(a)(1)` | 2 |
| [HiBob](/docs/compliance-connectors/setup/hris/hibob) (also Bob) | `164.308(a)(3)` | 1 |
| [Humaans](/docs/compliance-connectors/setup/hris/humaans) | `164.308(a)(3)` | 1 |
| [IBM QRadar SOAR](/docs/compliance-connectors/setup/security-automation/ibm-qradar-soar) | `164.308(a)(6)` | 2 |
| [Intruder](/docs/compliance-connectors/setup/vulnerability-scanning/intruder) | `164.308(a)(1)` | 4 |
| [Invicti](/docs/compliance-connectors/setup/vulnerability-scanning/invicti) | `164.308(a)(1)` | 4 |
| [JFrog Xray](/docs/compliance-connectors/setup/vulnerability-scanning/jfrog-xray) | `164.308(a)(1)` | 3 |
| [Lacework](/docs/compliance-connectors/setup/cspm/lacework) | `164.308(a)(1)` | 3 |
| [Lessonly](/docs/compliance-connectors/setup/security-training/lessonly) | `164.308(a)(5)` | 1 |
| [Malwarebytes](/docs/compliance-connectors/setup/endpoint-detection-and-response/malwarebytes) | `164.308(a)(5)` | 3 |
| [Mend](/docs/compliance-connectors/setup/vulnerability-scanning/mend) | `164.308(a)(1)` | 3 |
| [Nucleus Security](/docs/compliance-connectors/setup/vulnerability-scanning/nucleus-security) | `164.308(a)(1)` | 4 |
| [Ox Security](/docs/compliance-connectors/setup/vulnerability-scanning/ox-security) | `164.308(a)(1)` | 4 |
| [Paychex](/docs/compliance-connectors/setup/hris/paychex) | `164.308(a)(3)` | 1 |
| [Portainer](/docs/compliance-connectors/setup/cloud-infrastructure/portainer) | `164.308(a)(4)` | 2 |
| [Prisma Cloud](/docs/compliance-connectors/setup/cspm/prisma-cloud) | `164.308(a)(1)` | 3 |
| [Probely](/docs/compliance-connectors/setup/vulnerability-scanning/probely) | `164.308(a)(1)` | 4 |
| [Prometheus](/docs/compliance-connectors/setup/observability/prometheus) | `164.312(b)` | 1 |
| [Proofpoint Security Awareness](/docs/compliance-connectors/setup/security-training/proofpoint-security-awareness) | `164.308(a)(5)` | 2 |
| [Prowler](/docs/compliance-connectors/setup/infrastructure/prowler) | `164.308(a)(1)` | 2 |
| [Qualys](/docs/compliance-connectors/setup/vulnerability-scanning/qualys) | `164.308(a)(1)` | 4 |
| [Rapid7 InsightIDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/rapid7-insightidr) | `164.308(a)(6)` | 2 |
| [Rapid7 InsightVM](/docs/compliance-connectors/setup/vulnerability-scanning/rapid7-insightvm) | `164.308(a)(1)` | 4 |
| [Riot](/docs/compliance-connectors/setup/security-training/riot) | `164.308(a)(5)` | 2 |
| [Rippling](/docs/compliance-connectors/setup/hris/rippling) | `164.308(a)(3)` | 1 |
| [Sage HR](/docs/compliance-connectors/setup/hris/sage-hr) | `164.308(a)(3)` | 1 |
| [SAP SuccessFactors](/docs/compliance-connectors/setup/hris/sap-successfactors) | `164.308(a)(3)` | 1 |
| [Sapling](/docs/compliance-connectors/setup/hris/sapling) | `164.308(a)(3)` | 1 |
| [SecurityScorecard Atlas](/docs/compliance-connectors/setup/vendor-procurement/securityscorecard-atlas) | `164.308(a)(1)` | 1 |
| [Semgrep](/docs/compliance-connectors/setup/vulnerability-scanning/semgrep) | `164.308(a)(1)` | 4 |
| [SharePoint](/docs/compliance-connectors/setup/cloud-storage-provider/sharepoint) | `164.312(a)(1)` | 2 |
| [Snyk](/docs/compliance-connectors/setup/vulnerability-scanning/snyk) | `164.308(a)(1)` | 4 |
| [Socket](/docs/compliance-connectors/setup/vulnerability-scanning/socket) | `164.308(a)(1)` | 3 |
| [SonarQube](/docs/compliance-connectors/setup/vulnerability-scanning/sonarqube) | `164.308(a)(1)` | 4 |
| [Splunk SOAR](/docs/compliance-connectors/setup/observability/splunk-soar) | `164.308(a)(6)` | 2 |
| [StackHawk](/docs/compliance-connectors/setup/vulnerability-scanning/stackhawk) | `164.308(a)(1)` | 3 |
| [TalentLMS](/docs/compliance-connectors/setup/security-training/talentlms) | `164.308(a)(5)` | 1 |
| [Tenable](/docs/compliance-connectors/setup/vulnerability-scanning/tenable) | `164.308(a)(1)` | 4 |
| [Torq](/docs/compliance-connectors/setup/security-automation/torq) | `164.308(a)(6)` | 2 |
| [Trend Micro Cloud One](/docs/compliance-connectors/setup/cspm/trend-micro-cloud-one) | `164.308(a)(1)` | 3 |
| [Turbot](/docs/compliance-connectors/setup/cspm/turbot) | `164.308(a)(1)` | 1 |
| [Udemy Business](/docs/compliance-connectors/setup/security-training/udemy-business) | `164.308(a)(5)` | 1 |
| [UKG](/docs/compliance-connectors/setup/hris/ukg) | `164.308(a)(3)` | 1 |
| [UpGuard Vendor Risk](/docs/compliance-connectors/setup/vendor-procurement/upguard-vendor-risk) | `164.308(a)(1)` | 2 |
| [Uptime Robot](/docs/compliance-connectors/setup/observability/uptime-robot) | `164.312(b)` | 1 |
| [Veracode](/docs/compliance-connectors/setup/vulnerability-scanning/veracode) | `164.308(a)(1)` | 4 |
| [Veza](/docs/compliance-connectors/setup/user-access-review/veza) | `164.308(a)(4)` | 1 |
| [VictoriaMetrics](/docs/compliance-connectors/setup/observability/victoriametrics) | `164.312(b)` | 1 |
| [Webroot](/docs/compliance-connectors/setup/endpoint-detection-and-response/webroot) | `164.308(a)(5)` | 2 |
| [Wiz](/docs/compliance-connectors/setup/cspm/wiz) | `164.308(a)(1)` | 3 |
| [Workday](/docs/compliance-connectors/setup/hris/workday) | `164.308(a)(3)` | 1 |
| [Yardstik](/docs/compliance-connectors/setup/background-check-providers/yardstik) | `164.308(a)(3)` | 1 |
| [Zenefits](/docs/compliance-connectors/setup/hris/zenefits) | `164.308(a)(3)` | 1 |
## Evidence by attestation (95)
These systems publish no API for what the tests check. Connect them to record the connection, then attest the result; an accepted attestation counts toward the control.
| Connector | Controls |
| --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| [8x8](/docs/compliance-connectors/setup/communications-platforms/8x8) | `164.308(a)(3)` |
| [Acunetix](/docs/compliance-connectors/setup/vulnerability-scanning/acunetix) | `164.308(a)(1)` |
| [Addigy](/docs/compliance-connectors/setup/mdm/addigy) | `164.310(d)(1)` |
| [Affinity](/docs/compliance-connectors/setup/crm/affinity) | `164.308(a)(3)` |
| [Airbase](/docs/compliance-connectors/setup/vendor-procurement/airbase) | `164.308(a)(3)` |
| [Apiiro](/docs/compliance-connectors/setup/vulnerability-scanning/apiiro) | `164.308(a)(1)` |
| [Aqua Security](/docs/compliance-connectors/setup/cspm/aqua-security) | `164.308(a)(1)` |
| [Arctic Wolf](/docs/compliance-connectors/setup/endpoint-detection-and-response/arctic-wolf) | `164.308(a)(5)` |
| [Arnica](/docs/compliance-connectors/setup/vulnerability-scanning/arnica) | `164.308(a)(1)` |
| [Blackpoint Cyber](/docs/compliance-connectors/setup/endpoint-detection-and-response/blackpoint-cyber) | `164.308(a)(5)` |
| [Bugsnag](/docs/compliance-connectors/setup/observability/bugsnag) | `164.308(a)(3)` |
| [Carta](/docs/compliance-connectors/setup/business-applications/carta) | `164.308(a)(3)` |
| [Checkmk](/docs/compliance-connectors/setup/observability/checkmk) | `164.308(a)(1)`, `164.308(a)(3)` |
| [Cloudanix](/docs/compliance-connectors/setup/cspm/cloudanix) | `164.308(a)(1)` |
| [Cohere](/docs/compliance-connectors/setup/business-applications/cohere) | `164.308(a)(3)` |
| [Concord](/docs/compliance-connectors/setup/digital-signature/concord) | `164.308(a)(3)` |
| [Contractbook](/docs/compliance-connectors/setup/digital-signature/contractbook) | `164.308(a)(3)` |
| [ContractSafe](/docs/compliance-connectors/setup/digital-signature/contractsafe) | `164.308(a)(3)` |
| [CoreStack](/docs/compliance-connectors/setup/cspm/corestack) | `164.308(a)(1)` |
| [CyberArk](/docs/compliance-connectors/setup/identity-and-sso/cyberark) | `164.308(a)(3)`, `164.312(d)` |
| [Cynet](/docs/compliance-connectors/setup/endpoint-detection-and-response/cynet) | `164.308(a)(5)` |
| [Cyscale](/docs/compliance-connectors/setup/cspm/cyscale) | `164.308(a)(1)` |
| [Cyware](/docs/compliance-connectors/setup/security-automation/cyware) | `164.308(a)(6)` |
| [DeepSeek](/docs/compliance-connectors/setup/business-applications/deepseek) | `164.308(a)(3)` |
| [Documenso](/docs/compliance-connectors/setup/digital-signature/documenso) | `164.308(a)(3)` |
| [Edgescan](/docs/compliance-connectors/setup/vulnerability-scanning/edgescan) | `164.308(a)(1)` |
| [Eversign](/docs/compliance-connectors/setup/digital-signature/eversign) | `164.308(a)(3)` |
| [Evisort](/docs/compliance-connectors/setup/digital-signature/evisort) | `164.308(a)(3)` |
| [Foxit eSign](/docs/compliance-connectors/setup/digital-signature/foxit-esign) | `164.308(a)(3)` |
| [Freshsales](/docs/compliance-connectors/setup/crm/freshsales) | `164.308(a)(3)` |
| [Gatekeeper](/docs/compliance-connectors/setup/vendor-procurement/gatekeeper) | `164.308(a)(3)` |
| [GetAccept](/docs/compliance-connectors/setup/digital-signature/getaccept) | `164.308(a)(3)` |
| [GitKraken](/docs/compliance-connectors/setup/version-control/gitkraken) | `164.308(a)(3)` |
| [Groq](/docs/compliance-connectors/setup/business-applications/groq) | `164.308(a)(3)` |
| [Honeycomb](/docs/compliance-connectors/setup/observability/honeycomb) | `164.308(a)(1)` |
| [IBM MaaS360](/docs/compliance-connectors/setup/mdm/ibm-maas360) | `164.310(d)(1)` |
| [IDrive](/docs/compliance-connectors/setup/cloud-storage-provider/idrive) | `164.308(a)(7)` |
| [Juro](/docs/compliance-connectors/setup/digital-signature/juro) | `164.308(a)(3)` |
| [Kion](/docs/compliance-connectors/setup/cspm/kion) | `164.308(a)(1)` |
| [LastPass SSO](/docs/compliance-connectors/setup/identity-and-sso/lastpass-sso) | `164.308(a)(3)`, `164.312(d)` |
| [Legit Security](/docs/compliance-connectors/setup/vulnerability-scanning/legit-security) | `164.308(a)(1)` |
| [Lexion](/docs/compliance-connectors/setup/digital-signature/lexion) | `164.308(a)(3)` |
| [LinkSquares](/docs/compliance-connectors/setup/digital-signature/linksquares) | `164.308(a)(3)` |
| [Lookout](/docs/compliance-connectors/setup/endpoint-detection-and-response/lookout) | `164.308(a)(5)` |
| [Matillion](/docs/compliance-connectors/setup/data-export/matillion) | `164.308(a)(3)` |
| [MessageBird](/docs/compliance-connectors/setup/communications-platforms/messagebird) | `164.308(a)(3)` |
| [Microsoft 365 Copilot](/docs/compliance-connectors/setup/business-applications/microsoft-365-copilot) | `164.308(a)(3)` |
| [Nagios](/docs/compliance-connectors/setup/observability/nagios) | `164.308(a)(1)` |
| [Nessus](/docs/compliance-connectors/setup/vulnerability-scanning/nessus) | `164.308(a)(1)` |
| [Netdata](/docs/compliance-connectors/setup/observability/netdata) | `164.308(a)(3)` |
| [Nextiva](/docs/compliance-connectors/setup/communications-platforms/nextiva) | `164.308(a)(3)` |
| [OpenVAS](/docs/compliance-connectors/setup/vulnerability-scanning/openvas) | `164.308(a)(1)` |
| [Orca Security](/docs/compliance-connectors/setup/cspm/orca-security) | `164.308(a)(1)` |
| [pCloud](/docs/compliance-connectors/setup/cloud-storage-provider/pcloud) | `164.308(a)(3)` |
| [Perplexity](/docs/compliance-connectors/setup/business-applications/perplexity) | `164.308(a)(3)` |
| [Phylum](/docs/compliance-connectors/setup/vulnerability-scanning/phylum) | `164.308(a)(1)` |
| [Pipedream](/docs/compliance-connectors/setup/security-automation/pipedream) | `164.308(a)(3)` |
| [Plivo](/docs/compliance-connectors/setup/communications-platforms/plivo) | `164.308(a)(3)` |
| [Postmark](/docs/compliance-connectors/setup/communications-platforms/postmark) | `164.308(a)(3)` |
| [Precoro](/docs/compliance-connectors/setup/vendor-procurement/precoro) | `164.308(a)(3)` |
| [Rapid7 InsightCloudSec](/docs/compliance-connectors/setup/cspm/rapid7-insightcloudsec) | `164.308(a)(1)` |
| [Rapid7 InsightConnect](/docs/compliance-connectors/setup/security-automation/rapid7-insightconnect) | `164.308(a)(6)` |
| [Raygun](/docs/compliance-connectors/setup/observability/raygun) | `164.308(a)(3)` |
| [Replicate](/docs/compliance-connectors/setup/business-applications/replicate) | `164.308(a)(3)` |
| [Responsive](/docs/compliance-connectors/setup/vendor-procurement/responsive) | `164.308(a)(3)` |
| [RightSignature](/docs/compliance-connectors/setup/digital-signature/rightsignature) | `164.308(a)(3)` |
| [Rippling MDM](/docs/compliance-connectors/setup/hris/rippling-mdm) | `164.310(d)(1)` |
| [RiskRecon](/docs/compliance-connectors/setup/vendor-procurement/riskrecon) | `164.308(a)(1)` |
| [RudderStack](/docs/compliance-connectors/setup/data-export/rudderstack) | `164.308(a)(3)` |
| [SAP Ariba](/docs/compliance-connectors/setup/vendor-procurement/sap-ariba) | `164.308(a)(3)` |
| [Scalefusion](/docs/compliance-connectors/setup/mdm/scalefusion) | `164.310(d)(1)` |
| [Signable](/docs/compliance-connectors/setup/digital-signature/signable) | `164.308(a)(3)` |
| [Signeasy](/docs/compliance-connectors/setup/digital-signature/signeasy) | `164.308(a)(3)` |
| [SignWell](/docs/compliance-connectors/setup/digital-signature/signwell) | `164.308(a)(3)` |
| [Skribble](/docs/compliance-connectors/setup/digital-signature/skribble) | `164.308(a)(3)` |
| [Sonrai Security](/docs/compliance-connectors/setup/cspm/sonrai-security) | `164.308(a)(1)` |
| [SOTI MobiControl](/docs/compliance-connectors/setup/mdm/soti-mobicontrol) | `164.310(d)(1)` |
| [SpotDraft](/docs/compliance-connectors/setup/digital-signature/spotdraft) | `164.308(a)(3)` |
| [Stitch](/docs/compliance-connectors/setup/data-export/stitch) | `164.308(a)(3)` |
| [Storj](/docs/compliance-connectors/setup/cloud-storage-provider/storj) | `164.312(a)(1)` |
| [Stream Security](/docs/compliance-connectors/setup/cspm/stream-security) | `164.308(a)(1)` |
| [Sweet Security](/docs/compliance-connectors/setup/cspm/sweet-security) | `164.308(a)(1)` |
| [Swimlane](/docs/compliance-connectors/setup/security-automation/swimlane) | `164.308(a)(6)` |
| [Sysdig](/docs/compliance-connectors/setup/cspm/sysdig) | `164.308(a)(1)` |
| [Tenable Cloud Security](/docs/compliance-connectors/setup/vulnerability-scanning/tenable-cloud-security) | `164.308(a)(1)` |
| [Together AI](/docs/compliance-connectors/setup/business-applications/together-ai) | `164.308(a)(3)` |
| [Twilio](/docs/compliance-connectors/setup/communications-platforms/twilio) | `164.308(a)(3)` |
| [Uptycs](/docs/compliance-connectors/setup/cspm/uptycs) | `164.308(a)(1)` |
| [Vonage](/docs/compliance-connectors/setup/communications-platforms/vonage) | `164.308(a)(3)` |
| [Wallarm](/docs/compliance-connectors/setup/vulnerability-scanning/wallarm) | `164.308(a)(1)` |
| [Yotta](/docs/compliance-connectors/setup/cloud-infrastructure/yotta) | `164.308(a)(1)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` |
| [Z.ai (Zhipu GLM)](/docs/compliance-connectors/setup/business-applications/z-ai-zhipu-glm) | `164.308(a)(3)` |
| [Zip](/docs/compliance-connectors/setup/vendor-procurement/zip) | `164.308(a)(3)` |
| [Zoho Sign](/docs/compliance-connectors/setup/digital-signature/zoho-sign) | `164.308(a)(3)` |
| [Zscaler Posture Control](/docs/compliance-connectors/setup/cspm/zscaler-posture-control) | `164.308(a)(1)` |
## Controls (14)
| Control | Title | Automated tests | Connectors |
| --------------- | --------------------------------------------------- | --------------- | ---------- |
| `164.308(a)(1)` | Information system activity review | 101 | 114 |
| `164.308(a)(3)` | Termination procedures | 23 | 312 |
| `164.308(a)(4)` | Information access management | 76 | 245 |
| `164.308(a)(5)` | Password management | 37 | 109 |
| `164.308(a)(6)` | Response and reporting | 24 | 71 |
| `164.308(a)(7)` | Data backup plan | 50 | 37 |
| `164.308(a)(8)` | Evaluation | 3 | 3 |
| `164.308(b)(1)` | Business associate contracts and other arrangements | 4 | 3 |
| `164.310(d)(1)` | Device and media controls | 5 | 33 |
| `164.312(a)(1)` | Access control | 147 | 74 |
| `164.312(b)` | Audit controls | 79 | 70 |
| `164.312(c)(1)` | Integrity | 8 | 15 |
| `164.312(d)` | Person or entity authentication | 54 | 99 |
| `164.312(e)(1)` | Transmission security | 65 | 55 |
# Frameworks and connectors (/docs/framework-connectors)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connectors don't attach to a framework directly. A connector feeds **automated tests**, each test checks one thing in a connected system, and each test maps to the controls it provides evidence for. When a test passes, that result is evidence toward every control it maps to, in every framework it maps to. Connect a system once, and its tests count everywhere they apply.
## Frameworks the tests map to
The test catalogue maps every automated test, with a one-sentence rationale an auditor can check, to these frameworks:
| Framework | Controls with tests | Tests | Connectors with automated evidence |
| ------------------------------------------------------------------------------------------- | ------------------- | ----- | ---------------------------------- |
| [SOC2](/docs/framework-connectors/soc2) | 34 | 855 | 360 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | 51 | 850 | 360 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | 14 | 675 | 359 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | 47 | 658 | 343 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | 47 | 835 | 360 |
| [CIS Oracle Cloud Infrastructure Foundations Benchmark](/docs/framework-connectors/cis-oci) | 51 | 40 | 1 |
| [CIS AWS Foundations Benchmark](/docs/framework-connectors/cis-aws) | 41 | 41 | 1 |
| [CIS Microsoft Azure Foundations Benchmark](/docs/framework-connectors/cis-azure) | 85 | 72 | 1 |
| [CIS Google Cloud Platform Foundations Benchmark](/docs/framework-connectors/cis-gcp) | 61 | 49 | 1 |
| [CIS Kubernetes Benchmark](/docs/framework-connectors/cis-k8s) | 60 | 41 | 1 |
Each framework page lists the connectors that provide its evidence, the controls each one covers, and links to every connector's setup steps. On a framework's page in Safeguard, the **Connectors** tab shows the same list for your workspace, with which connectors you have connected and whether each connection is healthy.
## Through the crosswalk
The crosswalk relates controls across SOC2, ISO/IEC 27001, the HIPAA Security Rule, PCI DSS, NIST CSF 2.0 and NIST SP 800-53. Evidence counts toward a control in another of these frameworks only through an **equivalent** crosswalk row that has been reviewed, or that your workspace approved, and only while the evidence is accepted and in date. Every other related row is a **suggestion** for a person to review, never a pass. Credit never chains: evidence that the crosswalk produced is not used as a source again. NIST SP 800-53 has no direct test mappings, so its automated evidence comes through the crosswalk.
## Every other framework
Your framework library has many more frameworks than the ones above (see [Compliance frameworks](/docs/frameworks)). For any of them, link the automated tests you want to count yourself:
1. Open the framework on **Compliance › Frameworks**, then the control.
2. Choose **Link a test**, search for the test, and click **Link**. The test's result then counts toward that control, the same way a catalogue mapping does.
3. To change several at once, use **Edit mappings** on the framework's tests.
Controls that no test checks are evidenced the usual way: policies, uploaded evidence, records in Safeguard and attestations.
How to connect each system: [Compliance connectors](/docs/compliance-connectors).
# ISO/IEC 27001 and connectors (/docs/framework-connectors/iso27001)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard's automated tests map to **51** controls of ISO/IEC 27001:2022 Annex A. **850** tests apply: 797 read a connected system, and 53 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
In the framework library: [ISO/IEC 27001](/docs/frameworks/international/iso27001), with what a scan checks, the controls and the policy templates.
## How to connect for this framework
1. Connect the systems you run from the table below. Each connector links to its setup steps.
2. Open the framework on **Compliance › Frameworks**, then its **Connectors** tab: it lists the connectors that answer this framework's tests, which of them you have connected, and whether each connection is healthy.
3. Tests run on their schedule, or straight away with **Run now** on **Compliance › Tests**. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
## Connectors with automated evidence (360)
| Connector | Controls it provides evidence for | Tests |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [GitHub](/docs/compliance-connectors/setup/version-control/github) (also GitHub Enterprise, GitHub Issues) | `A.5.15`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.19`, `A.5.25`, `A.5.26`, `A.5.27`, `A.5.32`, `A.5.9`, `A.6.5`, `A.8.12`, `A.8.15`, `A.8.2`, `A.8.25`, `A.8.28`, `A.8.29`, `A.8.3`, `A.8.32`, `A.8.4`, `A.8.5`, `A.8.8` | 44 |
| [GitLab](/docs/compliance-connectors/setup/version-control/gitlab) (also GitLab Issues, GitLab Self-Managed) | `A.5.14`, `A.5.15`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.5.3`, `A.5.9`, `A.6.5`, `A.8.12`, `A.8.15`, `A.8.2`, `A.8.24`, `A.8.25`, `A.8.28`, `A.8.29`, `A.8.32`, `A.8.4`, `A.8.5`, `A.8.8` | 46 |
| [Amazon Web Services](/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services) (also AWS GovCloud, AWS CodeCommit, AWS Inspector, Amazon CloudWatch, Amazon S3, AWS Security Hub) | `A.5.12`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.24`, `A.5.25`, `A.8.11`, `A.8.12`, `A.8.13`, `A.8.14`, `A.8.15`, `A.8.16`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.3`, `A.8.32`, `A.8.5`, `A.8.6`, `A.8.8`, `A.8.9` | 148 |
| [Microsoft Azure](/docs/compliance-connectors/setup/cloud-infrastructure/microsoft-azure) (also Microsoft Entra ID, Azure Government) | `A.5.15`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.19`, `A.5.24`, `A.6.5`, `A.8.1`, `A.8.13`, `A.8.15`, `A.8.16`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.3`, `A.8.5`, `A.8.6`, `A.8.7`, `A.8.8`, `A.8.9` | 139 |
| [Google Cloud Platform](/docs/compliance-connectors/setup/cloud-infrastructure/google-cloud-platform) | `A.5.15`, `A.5.17`, `A.5.18`, `A.5.24`, `A.5.3`, `A.5.9`, `A.8.13`, `A.8.14`, `A.8.15`, `A.8.16`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.3`, `A.8.32`, `A.8.5`, `A.8.6`, `A.8.8`, `A.8.9` | 114 |
| [Google Workspace](/docs/compliance-connectors/setup/identity-and-sso/google-workspace) (also Google Cloud Identity, Google SSO) | `A.5.11`, `A.5.14`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.19`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.12`, `A.8.16`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.3`, `A.8.5`, `A.8.7`, `A.8.8`, `A.8.9` | 28 |
| [Azure DevOps](/docs/compliance-connectors/setup/version-control/azure-devops) | `A.5.15`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.5.3`, `A.5.9`, `A.6.5`, `A.8.12`, `A.8.2`, `A.8.25`, `A.8.28`, `A.8.29`, `A.8.32`, `A.8.4`, `A.8.8` | 25 |
| [Oracle Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/oracle-cloud) (also Oracle Cloud Government) | `A.5.15`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.9`, `A.8.13`, `A.8.14`, `A.8.15`, `A.8.16`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.3`, `A.8.32`, `A.8.5`, `A.8.7`, `A.8.8`, `A.8.9` | 66 |
| [Bitbucket](/docs/compliance-connectors/setup/version-control/bitbucket) | `A.5.15`, `A.5.16`, `A.5.18`, `A.5.9`, `A.6.5`, `A.8.12`, `A.8.2`, `A.8.25`, `A.8.28`, `A.8.29`, `A.8.32`, `A.8.4`, `A.8.5`, `A.8.8` | 18 |
| [JumpCloud](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud) (also JumpCloud MDM, JumpCloud SSO) | `A.5.16`, `A.5.17`, `A.5.18`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.5`, `A.8.7`, `A.8.8`, `A.8.9` | 15 |
| [OVHcloud](/docs/compliance-connectors/setup/cloud-infrastructure/ovhcloud) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.15`, `A.8.16`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.3`, `A.8.5`, `A.8.8` | 27 |
| [Cloudflare](/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare) | `A.5.14`, `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.5`, `A.8.9` | 18 |
| [Hetzner](/docs/compliance-connectors/setup/cloud-infrastructure/hetzner) | `A.5.17`, `A.8.13`, `A.8.15`, `A.8.16`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.3`, `A.8.5`, `A.8.8` | 15 |
| [Claude (Anthropic)](/docs/compliance-connectors/setup/business-applications/claude-anthropic) | `A.5.16`, `A.5.17`, `A.5.18`, `A.5.34`, `A.6.5`, `A.8.10`, `A.8.15`, `A.8.2`, `A.8.5` | 10 |
| [Datadog](/docs/compliance-connectors/setup/observability/datadog) (also Datadog CSM) | `A.5.16`, `A.5.18`, `A.5.25`, `A.6.5`, `A.8.15`, `A.8.16`, `A.8.6`, `A.8.8`, `A.8.9` | 11 |
| [ElevenLabs](/docs/compliance-connectors/setup/business-applications/elevenlabs) | `A.5.16`, `A.5.17`, `A.5.18`, `A.5.34`, `A.6.5`, `A.8.10`, `A.8.15`, `A.8.2`, `A.8.5` | 7 |
| [Fireworks AI](/docs/compliance-connectors/setup/business-applications/fireworks-ai) | `A.5.16`, `A.5.17`, `A.5.18`, `A.5.34`, `A.6.5`, `A.8.10`, `A.8.15`, `A.8.2`, `A.8.5` | 10 |
| [GoDaddy](/docs/compliance-connectors/setup/cloud-infrastructure/godaddy) | `A.5.14`, `A.5.15`, `A.5.18`, `A.5.30`, `A.5.34`, `A.8.20`, `A.8.24`, `A.8.5`, `A.8.9` | 11 |
| [IBM Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/ibm-cloud) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.5` | 17 |
| [Jamf](/docs/compliance-connectors/setup/mdm/jamf) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.20`, `A.8.24`, `A.8.7`, `A.8.8`, `A.8.9` | 9 |
| [Jira](/docs/compliance-connectors/setup/ticketing/jira) | `A.5.15`, `A.5.16`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.6.5`, `A.8.3`, `A.8.8` | 10 |
| [Kubernetes](/docs/compliance-connectors/setup/cloud-infrastructure/kubernetes) (also Gatekeeper OPA, Kyverno) | `A.5.17`, `A.8.15`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.32`, `A.8.5`, `A.8.6`, `A.8.9` | 49 |
| [Microsoft Intune](/docs/compliance-connectors/setup/mdm/microsoft-intune) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.20`, `A.8.24`, `A.8.7`, `A.8.8`, `A.8.9` | 10 |
| [Mistral AI](/docs/compliance-connectors/setup/business-applications/mistral-ai) | `A.5.16`, `A.5.17`, `A.5.18`, `A.5.34`, `A.6.5`, `A.8.10`, `A.8.15`, `A.8.2`, `A.8.5` | 9 |
| [MongoDB Atlas](/docs/compliance-connectors/setup/infrastructure/mongodb-atlas) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.15`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.5` | 8 |
| [OpenAI API Platform](/docs/compliance-connectors/setup/business-applications/openai-api-platform) | `A.5.16`, `A.5.17`, `A.5.18`, `A.5.34`, `A.6.5`, `A.8.10`, `A.8.15`, `A.8.2`, `A.8.5` | 12 |
| [ServiceNow](/docs/compliance-connectors/setup/ticketing/servicenow) | `A.5.16`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.6.5`, `A.8.2`, `A.8.32`, `A.8.8` | 9 |
| [Spaceship](/docs/compliance-connectors/setup/cloud-infrastructure/spaceship) | `A.5.14`, `A.5.15`, `A.5.18`, `A.5.30`, `A.5.34`, `A.8.20`, `A.8.24`, `A.8.5`, `A.8.9` | 11 |
| [Asana](/docs/compliance-connectors/setup/ticketing/asana) | `A.5.16`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.6.5`, `A.8.2`, `A.8.8` | 8 |
| [Auth0](/docs/compliance-connectors/setup/identity-and-sso/auth0) (also Auth0 SSO) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.16`, `A.8.2`, `A.8.5` | 12 |
| [ChatGPT](/docs/compliance-connectors/setup/business-applications/chatgpt) | `A.5.16`, `A.5.18`, `A.5.34`, `A.6.5`, `A.8.10`, `A.8.15`, `A.8.2`, `A.8.5` | 6 |
| [Cisco Meraki SM](/docs/compliance-connectors/setup/mdm/cisco-meraki-sm) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.24`, `A.8.7`, `A.8.8`, `A.8.9` | 8 |
| [ClickUp](/docs/compliance-connectors/setup/ticketing/clickup) | `A.5.16`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.6.5`, `A.8.2`, `A.8.8` | 8 |
| [Codeberg](/docs/compliance-connectors/setup/version-control/codeberg) | `A.5.15`, `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.25`, `A.8.32`, `A.8.4` | 6 |
| [CrowdStrike Falcon](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon) | `A.5.16`, `A.5.18`, `A.5.26`, `A.6.5`, `A.8.1`, `A.8.16`, `A.8.7`, `A.8.8` | 15 |
| [Fleet](/docs/compliance-connectors/setup/mdm/fleet) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.20`, `A.8.24`, `A.8.8`, `A.8.9` | 8 |
| [Gitea](/docs/compliance-connectors/setup/version-control/gitea) | `A.5.15`, `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.25`, `A.8.32`, `A.8.4` | 6 |
| [Heroku](/docs/compliance-connectors/setup/cloud-infrastructure/heroku) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.2`, `A.8.24`, `A.8.5`, `A.8.8` | 8 |
| [Hugging Face](/docs/compliance-connectors/setup/business-applications/hugging-face) | `A.5.16`, `A.5.17`, `A.5.18`, `A.5.34`, `A.6.5`, `A.8.10`, `A.8.2`, `A.8.5` | 8 |
| [Ivanti Neurons](/docs/compliance-connectors/setup/mdm/ivanti-neurons) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.24`, `A.8.7`, `A.8.8`, `A.8.9` | 8 |
| [Kandji](/docs/compliance-connectors/setup/mdm/kandji) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.20`, `A.8.24`, `A.8.8`, `A.8.9` | 8 |
| [Kolide](/docs/compliance-connectors/setup/mdm/kolide) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.20`, `A.8.24`, `A.8.8`, `A.8.9` | 8 |
| [Miradore](/docs/compliance-connectors/setup/mdm/miradore) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.24`, `A.8.7`, `A.8.8`, `A.8.9` | 8 |
| [Monday.com](/docs/compliance-connectors/setup/ticketing/monday-com) | `A.5.16`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.6.5`, `A.8.2`, `A.8.8` | 8 |
| [Mosyle](/docs/compliance-connectors/setup/mdm/mosyle) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.20`, `A.8.24`, `A.8.8`, `A.8.9` | 9 |
| [Okta](/docs/compliance-connectors/setup/identity-and-sso/okta) (also Okta SSO) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.16`, `A.8.2`, `A.8.5` | 14 |
| [OpenRouter](/docs/compliance-connectors/setup/business-applications/openrouter) | `A.5.16`, `A.5.17`, `A.5.18`, `A.5.34`, `A.6.5`, `A.8.10`, `A.8.2`, `A.8.5` | 8 |
| [Redis Cloud](/docs/compliance-connectors/setup/infrastructure/redis-cloud) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.5` | 8 |
| [Sentry](/docs/compliance-connectors/setup/observability/sentry) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.11`, `A.8.12`, `A.8.16`, `A.8.2`, `A.8.5` | 6 |
| [Shortcut](/docs/compliance-connectors/setup/ticketing/shortcut) | `A.5.16`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.6.5`, `A.8.2`, `A.8.8` | 8 |
| [SolarWinds Service Desk](/docs/compliance-connectors/setup/ticketing/solarwinds-service-desk) | `A.5.16`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.6.5`, `A.8.2`, `A.8.8` | 8 |
| [Supabase](/docs/compliance-connectors/setup/infrastructure/supabase) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.5` | 7 |
| [YouTrack](/docs/compliance-connectors/setup/ticketing/youtrack) | `A.5.16`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.6.5`, `A.8.2`, `A.8.8` | 8 |
| [Akamai](/docs/compliance-connectors/setup/cloud-infrastructure/akamai) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.5` | 6 |
| [Alibaba Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/alibaba-cloud) | `A.5.17`, `A.8.13`, `A.8.15`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.5` | 20 |
| [Elastic Observability](/docs/compliance-connectors/setup/observability/elastic-observability) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.15`, `A.8.16`, `A.8.2` | 6 |
| [Infisical](/docs/compliance-connectors/setup/infrastructure/infisical) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.2`, `A.8.5` | 9 |
| [Keycloak](/docs/compliance-connectors/setup/identity-and-sso/keycloak) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.2`, `A.8.5` | 7 |
| [Linear](/docs/compliance-connectors/setup/ticketing/linear) | `A.5.16`, `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.6.5`, `A.8.8` | 9 |
| [Linode](/docs/compliance-connectors/setup/cloud-infrastructure/linode) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.2`, `A.8.20`, `A.8.5` | 6 |
| [ManageEngine](/docs/compliance-connectors/setup/mdm/manageengine) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.24`, `A.8.8`, `A.8.9` | 6 |
| [Nextcloud](/docs/compliance-connectors/setup/cloud-storage-provider/nextcloud) | `A.5.14`, `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.3`, `A.8.5` | 5 |
| [NinjaOne](/docs/compliance-connectors/setup/mdm/ninjaone) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.24`, `A.8.8`, `A.8.9` | 6 |
| [PlanetScale](/docs/compliance-connectors/setup/infrastructure/planetscale) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.2`, `A.8.32`, `A.8.5` | 6 |
| [SentinelOne](/docs/compliance-connectors/setup/endpoint-detection-and-response/sentinelone) | `A.5.16`, `A.5.18`, `A.5.26`, `A.6.5`, `A.8.1`, `A.8.16`, `A.8.7` | 8 |
| [SigNoz](/docs/compliance-connectors/setup/observability/signoz) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.16`, `A.8.2` | 7 |
| [Sophos Intercept X](/docs/compliance-connectors/setup/endpoint-detection-and-response/sophos-intercept-x) | `A.5.16`, `A.5.18`, `A.5.26`, `A.6.5`, `A.8.1`, `A.8.16`, `A.8.7` | 9 |
| [StackRox](/docs/compliance-connectors/setup/vulnerability-scanning/stackrox) (also Red Hat Advanced Cluster Security) | `A.5.17`, `A.5.25`, `A.8.16`, `A.8.2`, `A.8.24`, `A.8.8`, `A.8.9` | 13 |
| [Sumo Logic](/docs/compliance-connectors/setup/observability/sumo-logic) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.16`, `A.8.2`, `A.8.5` | 6 |
| [Vercel](/docs/compliance-connectors/setup/cloud-infrastructure/vercel) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.3`, `A.8.5`, `A.8.9` | 6 |
| [Authentik](/docs/compliance-connectors/setup/identity-and-sso/authentik) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 5 |
| [ClickHouse](/docs/compliance-connectors/setup/data-export/clickhouse) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.2`, `A.8.20` | 5 |
| [Docker](/docs/compliance-connectors/setup/infrastructure/docker) | `A.5.15`, `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.3` | 4 |
| [Duo Security](/docs/compliance-connectors/setup/identity-and-sso/duo-security) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 6 |
| [Fastly](/docs/compliance-connectors/setup/cloud-infrastructure/fastly) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.24`, `A.8.5` | 5 |
| [Gerrit](/docs/compliance-connectors/setup/version-control/gerrit) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.25`, `A.8.32` | 5 |
| [Grafana](/docs/compliance-connectors/setup/observability/grafana) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.16`, `A.8.2` | 5 |
| [Hexnode](/docs/compliance-connectors/setup/mdm/hexnode) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1`, `A.8.8`, `A.8.9` | 5 |
| [IBM Verify](/docs/compliance-connectors/setup/identity-and-sso/ibm-verify) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [LogicMonitor](/docs/compliance-connectors/setup/observability/logicmonitor) | `A.5.16`, `A.5.18`, `A.5.24`, `A.6.5`, `A.8.16`, `A.8.2` | 5 |
| [Logz.io](/docs/compliance-connectors/setup/observability/logz-io) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.16`, `A.8.2` | 5 |
| [OneLogin](/docs/compliance-connectors/setup/identity-and-sso/onelogin) (also OneLogin SSO) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 7 |
| [Oracle Identity](/docs/compliance-connectors/setup/identity-and-sso/oracle-identity) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 5 |
| [PingOne](/docs/compliance-connectors/setup/identity-and-sso/pingone) (also Ping Identity) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 6 |
| [Redmine](/docs/compliance-connectors/setup/ticketing/redmine) | `A.5.18`, `A.5.25`, `A.5.26`, `A.5.27`, `A.6.5`, `A.8.8` | 5 |
| [Render](/docs/compliance-connectors/setup/cloud-infrastructure/render) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.2`, `A.8.5` | 5 |
| [Scaleway](/docs/compliance-connectors/setup/cloud-infrastructure/scaleway) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.20`, `A.8.5` | 5 |
| [Snowflake](/docs/compliance-connectors/setup/data-export/snowflake) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.20`, `A.8.5` | 5 |
| [Splunk](/docs/compliance-connectors/setup/observability/splunk) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.16`, `A.8.2` | 5 |
| [Terraform Cloud](/docs/compliance-connectors/setup/infrastructure/terraform-cloud) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.32`, `A.8.5` | 5 |
| [VMware Workspace ONE](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-workspace-one) | `A.5.9`, `A.8.1`, `A.8.24`, `A.8.7`, `A.8.8`, `A.8.9` | 7 |
| [Vultr](/docs/compliance-connectors/setup/cloud-infrastructure/vultr) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.2`, `A.8.20` | 5 |
| [xAI](/docs/compliance-connectors/setup/business-applications/xai) | `A.5.17`, `A.5.18`, `A.5.34`, `A.8.10`, `A.8.15`, `A.8.5` | 5 |
| [Zitadel](/docs/compliance-connectors/setup/identity-and-sso/zitadel) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [Airtable](/docs/compliance-connectors/setup/ticketing/airtable) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [Cisco Secure Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/cisco-secure-endpoint) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7`, `A.8.8` | 6 |
| [Citrix Endpoint Management](/docs/compliance-connectors/setup/mdm/citrix-endpoint-management) | `A.5.9`, `A.8.1`, `A.8.7`, `A.8.8`, `A.8.9` | 5 |
| [DigitalOcean](/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean) | `A.8.13`, `A.8.16`, `A.8.20`, `A.8.24`, `A.8.8` | 10 |
| [env0](/docs/compliance-connectors/setup/infrastructure/env0) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.32` | 4 |
| [Fly.io](/docs/compliance-connectors/setup/cloud-infrastructure/fly-io) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [Freshservice](/docs/compliance-connectors/setup/ticketing/freshservice) | `A.5.18`, `A.5.25`, `A.5.26`, `A.6.5`, `A.8.8` | 4 |
| [FusionAuth](/docs/compliance-connectors/setup/identity-and-sso/fusionauth) | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.5` | 4 |
| [Looker](/docs/compliance-connectors/setup/data-export/looker) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [Mailgun](/docs/compliance-connectors/setup/communications-platforms/mailgun) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [Make](/docs/compliance-connectors/setup/security-automation/make) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [Mattermost](/docs/compliance-connectors/setup/communications-platforms/mattermost) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [Microsoft Defender for Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/microsoft-defender-for-endpoint) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7`, `A.8.8` | 12 |
| [New Relic](/docs/compliance-connectors/setup/observability/new-relic) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.15`, `A.8.16` | 4 |
| [ownCloud](/docs/compliance-connectors/setup/cloud-storage-provider/owncloud) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [PagerDuty](/docs/compliance-connectors/setup/ticketing/pagerduty) | `A.5.16`, `A.5.18`, `A.5.24`, `A.5.26`, `A.6.5` | 6 |
| [Platform.sh](/docs/compliance-connectors/setup/cloud-infrastructure/platform-sh) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [Pulumi](/docs/compliance-connectors/setup/infrastructure/pulumi) (also Pulumi Cloud) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.9` | 4 |
| [Railway](/docs/compliance-connectors/setup/cloud-infrastructure/railway) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [Rollbar](/docs/compliance-connectors/setup/observability/rollbar) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.16`, `A.8.2` | 4 |
| [Salesforce](/docs/compliance-connectors/setup/crm/salesforce) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [SimpleMDM](/docs/compliance-connectors/setup/mdm/simplemdm) | `A.8.1`, `A.8.20`, `A.8.24`, `A.8.8`, `A.8.9` | 5 |
| [Site24x7](/docs/compliance-connectors/setup/observability/site24x7) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.16`, `A.8.2` | 4 |
| [Slack](/docs/compliance-connectors/setup/communications-platforms/slack) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [UpCloud](/docs/compliance-connectors/setup/cloud-infrastructure/upcloud) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.13`, `A.8.20` | 4 |
| [Zabbix](/docs/compliance-connectors/setup/observability/zabbix) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.16`, `A.8.2` | 4 |
| [Zendesk](/docs/compliance-connectors/setup/ticketing/zendesk) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [Zoom](/docs/compliance-connectors/setup/communications-platforms/zoom) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [ActiveCampaign](/docs/compliance-connectors/setup/crm/activecampaign) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Adobe Acrobat Sign](/docs/compliance-connectors/setup/digital-signature/adobe-acrobat-sign) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Aha!](/docs/compliance-connectors/setup/ticketing/aha) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Airbyte](/docs/compliance-connectors/setup/data-export/airbyte) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Ansible](/docs/compliance-connectors/setup/infrastructure/ansible) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Aptible](/docs/compliance-connectors/setup/cloud-infrastructure/aptible) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Ashby](/docs/compliance-connectors/setup/hris/ashby) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Assembla](/docs/compliance-connectors/setup/version-control/assembla) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Attio](/docs/compliance-connectors/setup/crm/attio) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Baramundi](/docs/compliance-connectors/setup/mdm/baramundi) | `A.5.9`, `A.8.1`, `A.8.8`, `A.8.9` | 4 |
| [Basecamp](/docs/compliance-connectors/setup/ticketing/basecamp) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Beanstalk](/docs/compliance-connectors/setup/version-control/beanstalk) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Bitdefender GravityZone](/docs/compliance-connectors/setup/endpoint-detection-and-response/bitdefender-gravityzone) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 5 |
| [BoldSign](/docs/compliance-connectors/setup/digital-signature/boldsign) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Box](/docs/compliance-connectors/setup/cloud-storage-provider/box) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Census](/docs/compliance-connectors/setup/data-export/census) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Citrix ShareFile](/docs/compliance-connectors/setup/cloud-storage-provider/citrix-sharefile) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Close](/docs/compliance-connectors/setup/crm/close) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Cloudflare Access](/docs/compliance-connectors/setup/identity-and-sso/cloudflare-access) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.5` | 3 |
| [Coralogix](/docs/compliance-connectors/setup/observability/coralogix) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.16` | 3 |
| [Cortex XDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/cortex-xdr) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 5 |
| [Coupa](/docs/compliance-connectors/setup/vendor-procurement/coupa) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Cybereason](/docs/compliance-connectors/setup/endpoint-detection-and-response/cybereason) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 5 |
| [Databricks](/docs/compliance-connectors/setup/data-export/databricks) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Deep Instinct](/docs/compliance-connectors/setup/endpoint-detection-and-response/deep-instinct) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 4 |
| [Dialpad](/docs/compliance-connectors/setup/communications-platforms/dialpad) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [DocuSign](/docs/compliance-connectors/setup/digital-signature/docusign) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Dropbox](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Dropbox Sign](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox-sign) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Dynatrace](/docs/compliance-connectors/setup/observability/dynatrace) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.16` | 3 |
| [Egnyte](/docs/compliance-connectors/setup/cloud-storage-provider/egnyte) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Elastic Security](/docs/compliance-connectors/setup/endpoint-detection-and-response/elastic-security) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 5 |
| [ESET Protect](/docs/compliance-connectors/setup/endpoint-detection-and-response/eset-protect) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 4 |
| [Figma](/docs/compliance-connectors/setup/business-applications/figma) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Fivetran](/docs/compliance-connectors/setup/data-export/fivetran) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Fortinet FortiEDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/fortinet-fortiedr) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 5 |
| [Freshdesk](/docs/compliance-connectors/setup/ticketing/freshdesk) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Front](/docs/compliance-connectors/setup/communications-platforms/front) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [GoHighLevel](/docs/compliance-connectors/setup/crm/gohighlevel) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [GoTo Connect](/docs/compliance-connectors/setup/communications-platforms/goto-connect) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Greenhouse](/docs/compliance-connectors/setup/hris/greenhouse) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Hevo Data](/docs/compliance-connectors/setup/data-export/hevo-data) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [HubSpot](/docs/compliance-connectors/setup/crm/hubspot) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Huntress](/docs/compliance-connectors/setup/endpoint-detection-and-response/huntress) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 6 |
| [Insightly](/docs/compliance-connectors/setup/crm/insightly) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Instana](/docs/compliance-connectors/setup/observability/instana) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.16` | 3 |
| [Jamf Protect](/docs/compliance-connectors/setup/endpoint-detection-and-response/jamf-protect) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 4 |
| [Kaspersky Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/kaspersky-endpoint) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 5 |
| [Keap](/docs/compliance-connectors/setup/crm/keap) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Lever](/docs/compliance-connectors/setup/hris/lever) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Loopio](/docs/compliance-connectors/setup/vendor-procurement/loopio) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Microsoft Dynamics 365](/docs/compliance-connectors/setup/crm/microsoft-dynamics-365) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [n8n](/docs/compliance-connectors/setup/security-automation/n8n) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Netlify](/docs/compliance-connectors/setup/cloud-infrastructure/netlify) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Nutshell](/docs/compliance-connectors/setup/crm/nutshell) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [OpenPhone](/docs/compliance-connectors/setup/communications-platforms/openphone) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [OpenStack](/docs/compliance-connectors/setup/cloud-infrastructure/openstack) | `A.8.13`, `A.8.2`, `A.8.20`, `A.8.3` | 4 |
| [Opsgenie Alerts](/docs/compliance-connectors/setup/ticketing/opsgenie-alerts) | `A.5.16`, `A.5.18`, `A.5.24`, `A.6.5` | 5 |
| [PandaDoc](/docs/compliance-connectors/setup/digital-signature/pandadoc) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Pipedrive](/docs/compliance-connectors/setup/crm/pipedrive) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Productboard](/docs/compliance-connectors/setup/ticketing/productboard) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Qovery](/docs/compliance-connectors/setup/cloud-infrastructure/qovery) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Qualys EDR](/docs/compliance-connectors/setup/vulnerability-scanning/qualys-edr) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 3 |
| [Ramp](/docs/compliance-connectors/setup/vendor-procurement/ramp) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Red Canary](/docs/compliance-connectors/setup/endpoint-detection-and-response/red-canary) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 4 |
| [Red Hat OpenShift](/docs/compliance-connectors/setup/cloud-infrastructure/red-hat-openshift) | `A.8.15`, `A.8.2`, `A.8.5`, `A.8.9` | 5 |
| [RingCentral](/docs/compliance-connectors/setup/identity-and-sso/ringcentral) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Rocket.Chat](/docs/compliance-connectors/setup/communications-platforms/rocket-chat) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Segment](/docs/compliance-connectors/setup/data-export/segment) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [SendGrid](/docs/compliance-connectors/setup/communications-platforms/sendgrid) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Setyl](/docs/compliance-connectors/setup/vendor-procurement/setyl) | `A.5.11`, `A.5.9`, `A.6.5`, `A.8.1` | 2 |
| [SignRequest](/docs/compliance-connectors/setup/digital-signature/signrequest) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Smartsheet](/docs/compliance-connectors/setup/ticketing/smartsheet) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Spacelift](/docs/compliance-connectors/setup/infrastructure/spacelift) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.32` | 3 |
| [SugarCRM](/docs/compliance-connectors/setup/crm/sugarcrm) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Symantec Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/symantec-endpoint) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 5 |
| [Tanium](/docs/compliance-connectors/setup/endpoint-detection-and-response/tanium) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 4 |
| [Teamwork](/docs/compliance-connectors/setup/ticketing/teamwork) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Tines](/docs/compliance-connectors/setup/security-automation/tines) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Trellix](/docs/compliance-connectors/setup/endpoint-detection-and-response/trellix) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 4 |
| [Trello](/docs/compliance-connectors/setup/ticketing/trello) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Trend Micro Apex One](/docs/compliance-connectors/setup/endpoint-detection-and-response/trend-micro-apex-one) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 5 |
| [VMware](/docs/compliance-connectors/setup/cloud-infrastructure/vmware) | `A.5.17`, `A.8.13`, `A.8.15`, `A.8.9` | 6 |
| [VMware Carbon Black](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-carbon-black) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 5 |
| [Vtiger](/docs/compliance-connectors/setup/crm/vtiger) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Webex](/docs/compliance-connectors/setup/communications-platforms/webex) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [WithSecure](/docs/compliance-connectors/setup/endpoint-detection-and-response/withsecure) | `A.5.26`, `A.8.1`, `A.8.16`, `A.8.7` | 5 |
| [Workable](/docs/compliance-connectors/setup/hris/workable) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Workato](/docs/compliance-connectors/setup/security-automation/workato) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Wrike](/docs/compliance-connectors/setup/ticketing/wrike) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Yousign](/docs/compliance-connectors/setup/digital-signature/yousign) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Zendesk Sell](/docs/compliance-connectors/setup/ticketing/zendesk-sell) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Zoho CRM](/docs/compliance-connectors/setup/crm/zoho-crm) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [Zoho Desk](/docs/compliance-connectors/setup/ticketing/zoho-desk) | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [15Five](/docs/compliance-connectors/setup/hris/15five) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [1Password](/docs/compliance-connectors/setup/identity-and-sso/1password) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Action1](/docs/compliance-connectors/setup/mdm/action1) | `A.8.1`, `A.8.8`, `A.8.9` | 2 |
| [Aircall](/docs/compliance-connectors/setup/communications-platforms/aircall) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Amplitude](/docs/compliance-connectors/setup/data-export/amplitude) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Apollo IO](/docs/compliance-connectors/setup/business-applications/apollo-io) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Automox](/docs/compliance-connectors/setup/mdm/automox) | `A.8.1`, `A.8.8`, `A.8.9` | 4 |
| [Backblaze](/docs/compliance-connectors/setup/cloud-storage-provider/backblaze) | `A.8.13`, `A.8.20`, `A.8.24` | 3 |
| [Better Stack](/docs/compliance-connectors/setup/observability/better-stack) | `A.5.24`, `A.8.15`, `A.8.16` | 3 |
| [Beyond Identity](/docs/compliance-connectors/setup/identity-and-sso/beyond-identity) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Brex](/docs/compliance-connectors/setup/vendor-procurement/brex) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Canva](/docs/compliance-connectors/setup/business-applications/canva) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Capsule](/docs/compliance-connectors/setup/crm/capsule) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Check Point Harmony](/docs/compliance-connectors/setup/endpoint-detection-and-response/check-point-harmony) | `A.8.1`, `A.8.16`, `A.8.7` | 2 |
| [Confluence](/docs/compliance-connectors/setup/compliance-as-code/confluence) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Copper](/docs/compliance-connectors/setup/crm/copper) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Culture Amp](/docs/compliance-connectors/setup/hris/culture-amp) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [dbt Cloud](/docs/compliance-connectors/setup/data-export/dbt-cloud) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Esper](/docs/compliance-connectors/setup/mdm/esper) | `A.8.1`, `A.8.8`, `A.8.9` | 2 |
| [folk](/docs/compliance-connectors/setup/crm/folk) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [ForgeRock](/docs/compliance-connectors/setup/identity-and-sso/forgerock) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Gusto](/docs/compliance-connectors/setup/hris/gusto) | `A.5.16`, `A.5.18`, `A.8.2` | 2 |
| [HashiCorp Consul](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-consul) | `A.8.20`, `A.8.24`, `A.8.9` | 2 |
| [HashiCorp Nomad](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-nomad) | `A.8.20`, `A.8.24`, `A.8.9` | 2 |
| [Hightouch](/docs/compliance-connectors/setup/data-export/hightouch) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Hive](/docs/compliance-connectors/setup/ticketing/hive) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Intercom](/docs/compliance-connectors/setup/communications-platforms/intercom) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Ironclad](/docs/compliance-connectors/setup/digital-signature/ironclad) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Jira Service Management](/docs/compliance-connectors/setup/ticketing/jira-service-management) | `A.5.26`, `A.5.27`, `A.8.32` | 3 |
| [Lattice](/docs/compliance-connectors/setup/hris/lattice) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Launchpad](/docs/compliance-connectors/setup/version-control/launchpad) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Logto](/docs/compliance-connectors/setup/identity-and-sso/logto) | `A.5.17`, `A.8.2`, `A.8.5` | 6 |
| [Malwarebytes](/docs/compliance-connectors/setup/endpoint-detection-and-response/malwarebytes) | `A.8.1`, `A.8.16`, `A.8.7` | 3 |
| [MinIO](/docs/compliance-connectors/setup/cloud-storage-provider/minio) | `A.8.13`, `A.8.20`, `A.8.24` | 3 |
| [Miro](/docs/compliance-connectors/setup/communications-platforms/miro) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Mixpanel](/docs/compliance-connectors/setup/data-export/mixpanel) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Northflank](/docs/compliance-connectors/setup/cloud-infrastructure/northflank) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Notion](/docs/compliance-connectors/setup/compliance-as-code/notion) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Oneflow](/docs/compliance-connectors/setup/digital-signature/oneflow) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [OneSpan Sign](/docs/compliance-connectors/setup/digital-signature/onespan-sign) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [OneTrust Vendorpedia](/docs/compliance-connectors/setup/vendor-procurement/onetrust-vendorpedia) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Pingdom](/docs/compliance-connectors/setup/observability/pingdom) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Prey](/docs/compliance-connectors/setup/mdm/prey) | `A.8.1`, `A.8.8`, `A.8.9` | 2 |
| [Proxmox](/docs/compliance-connectors/setup/cloud-infrastructure/proxmox) | `A.8.13`, `A.8.2`, `A.8.5` | 3 |
| [SailPoint](/docs/compliance-connectors/setup/identity-and-sso/sailpoint) | `A.5.16`, `A.5.18`, `A.6.5` | 3 |
| [Salesflare](/docs/compliance-connectors/setup/crm/salesflare) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [SharePoint](/docs/compliance-connectors/setup/cloud-storage-provider/sharepoint) | `A.5.14`, `A.5.15`, `A.8.3` | 4 |
| [SignNow](/docs/compliance-connectors/setup/digital-signature/signnow) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Streak](/docs/compliance-connectors/setup/crm/streak) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Telnyx](/docs/compliance-connectors/setup/communications-platforms/telnyx) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Tray.io](/docs/compliance-connectors/setup/security-automation/tray-io) | `A.5.16`, `A.5.18`, `A.6.5` | 2 |
| [Webroot](/docs/compliance-connectors/setup/endpoint-detection-and-response/webroot) | `A.8.1`, `A.8.16`, `A.8.7` | 2 |
| [42Gears](/docs/compliance-connectors/setup/mdm/42gears) | `A.8.1`, `A.8.9` | 1 |
| [Check Point CloudGuard](/docs/compliance-connectors/setup/cspm/check-point-cloudguard) | `A.8.8`, `A.8.9` | 3 |
| [CrowdStrike Falcon Cloud](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon-cloud) | `A.8.8`, `A.8.9` | 3 |
| [Google Drive](/docs/compliance-connectors/setup/cloud-storage-provider/google-drive) | `A.5.14`, `A.8.3` | 1 |
| [HashiCorp Vault](/docs/compliance-connectors/setup/infrastructure/hashicorp-vault) | `A.8.15`, `A.8.5` | 2 |
| [Immersive Labs](/docs/compliance-connectors/setup/security-training/immersive-labs) | `A.6.3`, `A.8.25` | 1 |
| [Nutanix](/docs/compliance-connectors/setup/cloud-infrastructure/nutanix) | `A.8.13`, `A.8.2` | 2 |
| [Opal](/docs/compliance-connectors/setup/user-access-review/opal) | `A.5.18`, `A.6.5` | 2 |
| [Portainer](/docs/compliance-connectors/setup/cloud-infrastructure/portainer) | `A.5.18`, `A.8.2` | 2 |
| [Prowler](/docs/compliance-connectors/setup/infrastructure/prowler) | `A.8.8`, `A.8.9` | 2 |
| [Rancher](/docs/compliance-connectors/setup/cloud-infrastructure/rancher) | `A.5.18`, `A.8.2` | 3 |
| [Rapid7 InsightIDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/rapid7-insightidr) | `A.5.26`, `A.8.16` | 2 |
| [Torii](/docs/compliance-connectors/setup/user-access-review/torii) | `A.5.18`, `A.6.5` | 2 |
| [Trend Micro Cloud One](/docs/compliance-connectors/setup/cspm/trend-micro-cloud-one) | `A.8.8`, `A.8.9` | 3 |
| [Wasabi](/docs/compliance-connectors/setup/cloud-storage-provider/wasabi) | `A.8.13`, `A.8.20` | 3 |
| [360Learning](/docs/compliance-connectors/setup/security-training/360learning) | `A.6.3` | 1 |
| [Aikido Security](/docs/compliance-connectors/setup/vulnerability-scanning/aikido-security) | `A.8.8` | 4 |
| [Anchore](/docs/compliance-connectors/setup/vulnerability-scanning/anchore) | `A.8.8` | 4 |
| [AppDynamics](/docs/compliance-connectors/setup/observability/appdynamics) | `A.8.16` | 1 |
| [BambooHR](/docs/compliance-connectors/setup/hris/bamboohr) | `A.5.16` | 1 |
| [BitSight](/docs/compliance-connectors/setup/vendor-procurement/bitsight) | `A.8.8` | 2 |
| [Bright Security](/docs/compliance-connectors/setup/vulnerability-scanning/bright-security) | `A.8.8` | 4 |
| [Bugcrowd](/docs/compliance-connectors/setup/vulnerability-scanning/bugcrowd) | `A.8.8` | 2 |
| [Burp Suite](/docs/compliance-connectors/setup/vulnerability-scanning/burp-suite) | `A.8.8` | 3 |
| [Ceridian Dayforce](/docs/compliance-connectors/setup/hris/ceridian-dayforce) | `A.5.16` | 1 |
| [Checkmarx](/docs/compliance-connectors/setup/vulnerability-scanning/checkmarx) | `A.8.8` | 4 |
| [Chronosphere](/docs/compliance-connectors/setup/observability/chronosphere) | `A.8.16` | 1 |
| [Civo](/docs/compliance-connectors/setup/cloud-infrastructure/civo) | `A.8.20` | 2 |
| [Cobalt](/docs/compliance-connectors/setup/vulnerability-scanning/cobalt) | `A.8.8` | 3 |
| [Contrast Security](/docs/compliance-connectors/setup/vulnerability-scanning/contrast-security) | `A.8.8` | 4 |
| [Cortex XSOAR](/docs/compliance-connectors/setup/security-automation/cortex-xsoar) | `A.5.26` | 2 |
| [Cronitor](/docs/compliance-connectors/setup/observability/cronitor) | `A.8.16` | 1 |
| [D3 Security](/docs/compliance-connectors/setup/security-automation/d3-security) | `A.5.26` | 2 |
| [Deel](/docs/compliance-connectors/setup/hris/deel) | `A.5.16` | 1 |
| [Dependency-Track](/docs/compliance-connectors/setup/vulnerability-scanning/dependency-track) | `A.8.8` | 4 |
| [Detectify](/docs/compliance-connectors/setup/vulnerability-scanning/detectify) | `A.8.8` | 3 |
| [Docebo](/docs/compliance-connectors/setup/security-training/docebo) | `A.6.3` | 1 |
| [Employment Hero](/docs/compliance-connectors/setup/hris/employment-hero) | `A.5.16` | 1 |
| [Endor Labs](/docs/compliance-connectors/setup/vulnerability-scanning/endor-labs) | `A.8.8` | 4 |
| [Escape](/docs/compliance-connectors/setup/vulnerability-scanning/escape) | `A.8.8` | 4 |
| [Factorial](/docs/compliance-connectors/setup/hris/factorial) | `A.5.16` | 1 |
| [Firebase](/docs/compliance-connectors/setup/infrastructure/firebase) | `A.5.15` | 1 |
| [GitGuardian](/docs/compliance-connectors/setup/vulnerability-scanning/gitguardian) | `A.8.8` | 3 |
| [Google Chronicle SOAR](/docs/compliance-connectors/setup/security-automation/google-chronicle-soar) | `A.5.26` | 2 |
| [HackerOne](/docs/compliance-connectors/setup/vulnerability-scanning/hackerone) | `A.8.8` | 2 |
| [HiBob](/docs/compliance-connectors/setup/hris/hibob) (also Bob) | `A.5.16` | 1 |
| [Humaans](/docs/compliance-connectors/setup/hris/humaans) | `A.5.16` | 1 |
| [IBM QRadar SOAR](/docs/compliance-connectors/setup/security-automation/ibm-qradar-soar) | `A.5.26` | 2 |
| [Intruder](/docs/compliance-connectors/setup/vulnerability-scanning/intruder) | `A.8.8` | 4 |
| [Invicti](/docs/compliance-connectors/setup/vulnerability-scanning/invicti) | `A.8.8` | 4 |
| [JFrog Xray](/docs/compliance-connectors/setup/vulnerability-scanning/jfrog-xray) | `A.8.8` | 3 |
| [Lacework](/docs/compliance-connectors/setup/cspm/lacework) | `A.8.8` | 3 |
| [Lessonly](/docs/compliance-connectors/setup/security-training/lessonly) | `A.6.3` | 1 |
| [Mend](/docs/compliance-connectors/setup/vulnerability-scanning/mend) | `A.8.8` | 3 |
| [Nucleus Security](/docs/compliance-connectors/setup/vulnerability-scanning/nucleus-security) | `A.8.8` | 4 |
| [Ox Security](/docs/compliance-connectors/setup/vulnerability-scanning/ox-security) | `A.8.8` | 4 |
| [Paychex](/docs/compliance-connectors/setup/hris/paychex) | `A.5.16` | 1 |
| [Prisma Cloud](/docs/compliance-connectors/setup/cspm/prisma-cloud) | `A.8.8` | 3 |
| [Probely](/docs/compliance-connectors/setup/vulnerability-scanning/probely) | `A.8.8` | 4 |
| [Prometheus](/docs/compliance-connectors/setup/observability/prometheus) | `A.8.16` | 1 |
| [Proofpoint Security Awareness](/docs/compliance-connectors/setup/security-training/proofpoint-security-awareness) | `A.6.3` | 2 |
| [Qualys](/docs/compliance-connectors/setup/vulnerability-scanning/qualys) | `A.8.8` | 4 |
| [Rapid7 InsightVM](/docs/compliance-connectors/setup/vulnerability-scanning/rapid7-insightvm) | `A.8.8` | 4 |
| [Riot](/docs/compliance-connectors/setup/security-training/riot) | `A.6.3` | 2 |
| [Rippling](/docs/compliance-connectors/setup/hris/rippling) | `A.5.16` | 1 |
| [Sage HR](/docs/compliance-connectors/setup/hris/sage-hr) | `A.5.16` | 1 |
| [SAP SuccessFactors](/docs/compliance-connectors/setup/hris/sap-successfactors) | `A.5.16` | 1 |
| [Sapling](/docs/compliance-connectors/setup/hris/sapling) | `A.5.16` | 1 |
| [SecurityScorecard Atlas](/docs/compliance-connectors/setup/vendor-procurement/securityscorecard-atlas) | `A.8.8` | 1 |
| [Semgrep](/docs/compliance-connectors/setup/vulnerability-scanning/semgrep) | `A.8.8` | 4 |
| [Shuffle](/docs/compliance-connectors/setup/security-automation/shuffle) | `A.5.18` | 2 |
| [Snyk](/docs/compliance-connectors/setup/vulnerability-scanning/snyk) | `A.8.8` | 4 |
| [Socket](/docs/compliance-connectors/setup/vulnerability-scanning/socket) | `A.8.8` | 3 |
| [SonarQube](/docs/compliance-connectors/setup/vulnerability-scanning/sonarqube) | `A.8.8` | 4 |
| [Splunk SOAR](/docs/compliance-connectors/setup/observability/splunk-soar) | `A.5.26` | 2 |
| [StackHawk](/docs/compliance-connectors/setup/vulnerability-scanning/stackhawk) | `A.8.8` | 3 |
| [TalentLMS](/docs/compliance-connectors/setup/security-training/talentlms) | `A.6.3` | 1 |
| [Tenable](/docs/compliance-connectors/setup/vulnerability-scanning/tenable) | `A.8.8` | 4 |
| [ThreatConnect](/docs/compliance-connectors/setup/security-automation/threatconnect) | `A.5.18` | 2 |
| [Torq](/docs/compliance-connectors/setup/security-automation/torq) | `A.5.26` | 2 |
| [Turbot](/docs/compliance-connectors/setup/cspm/turbot) | `A.8.9` | 1 |
| [Udemy Business](/docs/compliance-connectors/setup/security-training/udemy-business) | `A.6.3` | 1 |
| [UKG](/docs/compliance-connectors/setup/hris/ukg) | `A.5.16` | 1 |
| [UpGuard Vendor Risk](/docs/compliance-connectors/setup/vendor-procurement/upguard-vendor-risk) | `A.8.8` | 2 |
| [Uptime Robot](/docs/compliance-connectors/setup/observability/uptime-robot) | `A.8.16` | 1 |
| [Veracode](/docs/compliance-connectors/setup/vulnerability-scanning/veracode) | `A.8.8` | 4 |
| [Veza](/docs/compliance-connectors/setup/user-access-review/veza) | `A.5.18` | 1 |
| [VictoriaMetrics](/docs/compliance-connectors/setup/observability/victoriametrics) | `A.8.16` | 1 |
| [Wiz](/docs/compliance-connectors/setup/cspm/wiz) | `A.8.8` | 3 |
| [Workday](/docs/compliance-connectors/setup/hris/workday) | `A.5.16` | 1 |
| [Yardstik](/docs/compliance-connectors/setup/background-check-providers/yardstik) | `A.6.1` | 1 |
| [Zenefits](/docs/compliance-connectors/setup/hris/zenefits) | `A.5.16` | 1 |
## Evidence by attestation (95)
These systems publish no API for what the tests check. Connect them to record the connection, then attest the result; an accepted attestation counts toward the control.
| Connector | Controls |
| --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| [8x8](/docs/compliance-connectors/setup/communications-platforms/8x8) | `A.5.18` |
| [Acunetix](/docs/compliance-connectors/setup/vulnerability-scanning/acunetix) | `A.8.8` |
| [Addigy](/docs/compliance-connectors/setup/mdm/addigy) | `A.8.1` |
| [Affinity](/docs/compliance-connectors/setup/crm/affinity) | `A.5.18` |
| [Airbase](/docs/compliance-connectors/setup/vendor-procurement/airbase) | `A.5.18` |
| [Apiiro](/docs/compliance-connectors/setup/vulnerability-scanning/apiiro) | `A.8.8` |
| [Aqua Security](/docs/compliance-connectors/setup/cspm/aqua-security) | `A.8.8` |
| [Arctic Wolf](/docs/compliance-connectors/setup/endpoint-detection-and-response/arctic-wolf) | `A.8.7` |
| [Arnica](/docs/compliance-connectors/setup/vulnerability-scanning/arnica) | `A.8.8` |
| [Blackpoint Cyber](/docs/compliance-connectors/setup/endpoint-detection-and-response/blackpoint-cyber) | `A.8.7` |
| [Bugsnag](/docs/compliance-connectors/setup/observability/bugsnag) | `A.5.18` |
| [Carta](/docs/compliance-connectors/setup/business-applications/carta) | `A.5.18` |
| [Checkmk](/docs/compliance-connectors/setup/observability/checkmk) | `A.5.18`, `A.8.16` |
| [Cloudanix](/docs/compliance-connectors/setup/cspm/cloudanix) | `A.8.8` |
| [Cohere](/docs/compliance-connectors/setup/business-applications/cohere) | `A.5.18`, `A.5.34`, `A.8.10` |
| [Concord](/docs/compliance-connectors/setup/digital-signature/concord) | `A.5.18` |
| [Contractbook](/docs/compliance-connectors/setup/digital-signature/contractbook) | `A.5.18` |
| [ContractSafe](/docs/compliance-connectors/setup/digital-signature/contractsafe) | `A.5.18` |
| [CoreStack](/docs/compliance-connectors/setup/cspm/corestack) | `A.8.8` |
| [CyberArk](/docs/compliance-connectors/setup/identity-and-sso/cyberark) | `A.5.18`, `A.8.5` |
| [Cynet](/docs/compliance-connectors/setup/endpoint-detection-and-response/cynet) | `A.8.7` |
| [Cyscale](/docs/compliance-connectors/setup/cspm/cyscale) | `A.8.8` |
| [Cyware](/docs/compliance-connectors/setup/security-automation/cyware) | `A.5.26` |
| [DeepSeek](/docs/compliance-connectors/setup/business-applications/deepseek) | `A.5.18`, `A.5.34`, `A.8.10` |
| [Documenso](/docs/compliance-connectors/setup/digital-signature/documenso) | `A.5.18` |
| [Edgescan](/docs/compliance-connectors/setup/vulnerability-scanning/edgescan) | `A.8.8` |
| [Eversign](/docs/compliance-connectors/setup/digital-signature/eversign) | `A.5.18` |
| [Evisort](/docs/compliance-connectors/setup/digital-signature/evisort) | `A.5.18` |
| [Foxit eSign](/docs/compliance-connectors/setup/digital-signature/foxit-esign) | `A.5.18` |
| [Freshsales](/docs/compliance-connectors/setup/crm/freshsales) | `A.5.18` |
| [Gatekeeper](/docs/compliance-connectors/setup/vendor-procurement/gatekeeper) | `A.5.18` |
| [GetAccept](/docs/compliance-connectors/setup/digital-signature/getaccept) | `A.5.18` |
| [GitKraken](/docs/compliance-connectors/setup/version-control/gitkraken) | `A.5.18` |
| [Groq](/docs/compliance-connectors/setup/business-applications/groq) | `A.5.18`, `A.5.34`, `A.8.10` |
| [Honeycomb](/docs/compliance-connectors/setup/observability/honeycomb) | `A.8.16` |
| [IBM MaaS360](/docs/compliance-connectors/setup/mdm/ibm-maas360) | `A.8.1` |
| [IDrive](/docs/compliance-connectors/setup/cloud-storage-provider/idrive) | `A.8.13` |
| [Juro](/docs/compliance-connectors/setup/digital-signature/juro) | `A.5.18` |
| [Kion](/docs/compliance-connectors/setup/cspm/kion) | `A.8.8` |
| [LastPass SSO](/docs/compliance-connectors/setup/identity-and-sso/lastpass-sso) | `A.5.18`, `A.8.5` |
| [Legit Security](/docs/compliance-connectors/setup/vulnerability-scanning/legit-security) | `A.8.8` |
| [Lexion](/docs/compliance-connectors/setup/digital-signature/lexion) | `A.5.18` |
| [LinkSquares](/docs/compliance-connectors/setup/digital-signature/linksquares) | `A.5.18` |
| [Lookout](/docs/compliance-connectors/setup/endpoint-detection-and-response/lookout) | `A.8.7` |
| [Matillion](/docs/compliance-connectors/setup/data-export/matillion) | `A.5.18` |
| [MessageBird](/docs/compliance-connectors/setup/communications-platforms/messagebird) | `A.5.18` |
| [Microsoft 365 Copilot](/docs/compliance-connectors/setup/business-applications/microsoft-365-copilot) | `A.5.18`, `A.5.34`, `A.8.10` |
| [Nagios](/docs/compliance-connectors/setup/observability/nagios) | `A.8.16` |
| [Nessus](/docs/compliance-connectors/setup/vulnerability-scanning/nessus) | `A.8.8` |
| [Netdata](/docs/compliance-connectors/setup/observability/netdata) | `A.5.18` |
| [Nextiva](/docs/compliance-connectors/setup/communications-platforms/nextiva) | `A.5.18` |
| [OpenVAS](/docs/compliance-connectors/setup/vulnerability-scanning/openvas) | `A.8.8` |
| [Orca Security](/docs/compliance-connectors/setup/cspm/orca-security) | `A.8.8` |
| [pCloud](/docs/compliance-connectors/setup/cloud-storage-provider/pcloud) | `A.5.18` |
| [Perplexity](/docs/compliance-connectors/setup/business-applications/perplexity) | `A.5.18`, `A.5.34`, `A.8.10` |
| [Phylum](/docs/compliance-connectors/setup/vulnerability-scanning/phylum) | `A.8.8` |
| [Pipedream](/docs/compliance-connectors/setup/security-automation/pipedream) | `A.5.18` |
| [Plivo](/docs/compliance-connectors/setup/communications-platforms/plivo) | `A.5.18` |
| [Postmark](/docs/compliance-connectors/setup/communications-platforms/postmark) | `A.5.18` |
| [Precoro](/docs/compliance-connectors/setup/vendor-procurement/precoro) | `A.5.18` |
| [Rapid7 InsightCloudSec](/docs/compliance-connectors/setup/cspm/rapid7-insightcloudsec) | `A.8.8` |
| [Rapid7 InsightConnect](/docs/compliance-connectors/setup/security-automation/rapid7-insightconnect) | `A.5.26` |
| [Raygun](/docs/compliance-connectors/setup/observability/raygun) | `A.5.18` |
| [Replicate](/docs/compliance-connectors/setup/business-applications/replicate) | `A.5.18`, `A.5.34`, `A.8.10` |
| [Responsive](/docs/compliance-connectors/setup/vendor-procurement/responsive) | `A.5.18` |
| [RightSignature](/docs/compliance-connectors/setup/digital-signature/rightsignature) | `A.5.18` |
| [Rippling MDM](/docs/compliance-connectors/setup/hris/rippling-mdm) | `A.8.1` |
| [RiskRecon](/docs/compliance-connectors/setup/vendor-procurement/riskrecon) | `A.8.8` |
| [RudderStack](/docs/compliance-connectors/setup/data-export/rudderstack) | `A.5.18` |
| [SAP Ariba](/docs/compliance-connectors/setup/vendor-procurement/sap-ariba) | `A.5.18` |
| [Scalefusion](/docs/compliance-connectors/setup/mdm/scalefusion) | `A.8.1` |
| [Signable](/docs/compliance-connectors/setup/digital-signature/signable) | `A.5.18` |
| [Signeasy](/docs/compliance-connectors/setup/digital-signature/signeasy) | `A.5.18` |
| [SignWell](/docs/compliance-connectors/setup/digital-signature/signwell) | `A.5.18` |
| [Skribble](/docs/compliance-connectors/setup/digital-signature/skribble) | `A.5.18` |
| [Sonrai Security](/docs/compliance-connectors/setup/cspm/sonrai-security) | `A.8.8` |
| [SOTI MobiControl](/docs/compliance-connectors/setup/mdm/soti-mobicontrol) | `A.8.1` |
| [SpotDraft](/docs/compliance-connectors/setup/digital-signature/spotdraft) | `A.5.18` |
| [Stitch](/docs/compliance-connectors/setup/data-export/stitch) | `A.5.18` |
| [Storj](/docs/compliance-connectors/setup/cloud-storage-provider/storj) | `A.8.3` |
| [Stream Security](/docs/compliance-connectors/setup/cspm/stream-security) | `A.8.8` |
| [Sweet Security](/docs/compliance-connectors/setup/cspm/sweet-security) | `A.8.8` |
| [Swimlane](/docs/compliance-connectors/setup/security-automation/swimlane) | `A.5.26` |
| [Sysdig](/docs/compliance-connectors/setup/cspm/sysdig) | `A.8.8` |
| [Tenable Cloud Security](/docs/compliance-connectors/setup/vulnerability-scanning/tenable-cloud-security) | `A.8.8` |
| [Together AI](/docs/compliance-connectors/setup/business-applications/together-ai) | `A.5.18`, `A.5.34`, `A.8.10` |
| [Twilio](/docs/compliance-connectors/setup/communications-platforms/twilio) | `A.5.18` |
| [Uptycs](/docs/compliance-connectors/setup/cspm/uptycs) | `A.8.8` |
| [Vonage](/docs/compliance-connectors/setup/communications-platforms/vonage) | `A.5.18` |
| [Wallarm](/docs/compliance-connectors/setup/vulnerability-scanning/wallarm) | `A.8.8` |
| [Yotta](/docs/compliance-connectors/setup/cloud-infrastructure/yotta) | `A.5.17`, `A.8.13`, `A.8.15`, `A.8.16`, `A.8.2`, `A.8.20`, `A.8.24`, `A.8.3`, `A.8.5`, `A.8.8` |
| [Z.ai (Zhipu GLM)](/docs/compliance-connectors/setup/business-applications/z-ai-zhipu-glm) | `A.5.18`, `A.5.34`, `A.8.10` |
| [Zip](/docs/compliance-connectors/setup/vendor-procurement/zip) | `A.5.18` |
| [Zoho Sign](/docs/compliance-connectors/setup/digital-signature/zoho-sign) | `A.5.18` |
| [Zscaler Posture Control](/docs/compliance-connectors/setup/cspm/zscaler-posture-control) | `A.8.8` |
## Controls (51)
| Control | Title | Automated tests | Connectors |
| -------- | ---------------------------------------------------------------------- | --------------- | ---------- |
| `A.5.1` | Policies for information security | 4 | 0 |
| `A.5.2` | Information security roles and responsibilities | 2 | 0 |
| `A.5.3` | Segregation of duties | 3 | 5 |
| `A.5.4` | Management responsibilities | 1 | 0 |
| `A.5.9` | Inventory of information and other associated assets | 7 | 33 |
| `A.5.11` | Return of assets | 2 | 16 |
| `A.5.12` | Classification of information | 2 | 7 |
| `A.5.14` | Information transfer | 11 | 12 |
| `A.5.15` | Access control | 12 | 22 |
| `A.5.16` | Identity management | 16 | 240 |
| `A.5.17` | Authentication information | 56 | 66 |
| `A.5.18` | Access rights | 49 | 292 |
| `A.5.19` | Information security in supplier relationships | 6 | 9 |
| `A.5.20` | Addressing information security within supplier agreements | 2 | 0 |
| `A.5.21` | Managing information security in the ICT supply chain | 1 | 0 |
| `A.5.22` | Monitoring, review and change management of supplier services | 3 | 0 |
| `A.5.24` | Information security incident management planning and preparation | 10 | 15 |
| `A.5.25` | Assessment and decision on information security events | 4 | 29 |
| `A.5.26` | Response to information security incidents | 9 | 53 |
| `A.5.27` | Learning from information security incidents | 2 | 18 |
| `A.5.30` | ICT readiness for business continuity | 3 | 2 |
| `A.5.32` | Intellectual property rights | 2 | 3 |
| `A.5.34` | Privacy and protection of personal identifiable information (PII) | 4 | 19 |
| `A.5.36` | Compliance with policies, rules and standards for information security | 1 | 0 |
| `A.6.1` | Screening | 2 | 1 |
| `A.6.2` | Terms and conditions of employment | 2 | 0 |
| `A.6.3` | Information security awareness, education and training | 8 | 8 |
| `A.6.5` | Responsibilities after termination or change of employment | 13 | 231 |
| `A.6.6` | Confidentiality or non-disclosure agreements | 2 | 0 |
| `A.8.1` | User end point devices | 12 | 62 |
| `A.8.2` | Privileged access rights | 63 | 187 |
| `A.8.3` | Information access restriction | 34 | 30 |
| `A.8.4` | Access to source code | 7 | 10 |
| `A.8.5` | Secure authentication | 56 | 99 |
| `A.8.6` | Capacity management | 6 | 16 |
| `A.8.7` | Protection against malware | 12 | 48 |
| `A.8.8` | Management of technical vulnerabilities | 62 | 134 |
| `A.8.9` | Configuration management | 50 | 62 |
| `A.8.10` | Information deletion | 3 | 17 |
| `A.8.11` | Data masking | 2 | 8 |
| `A.8.12` | Data leakage prevention | 11 | 19 |
| `A.8.13` | Information backup | 50 | 37 |
| `A.8.14` | Redundancy of information processing facilities | 4 | 10 |
| `A.8.15` | Logging | 73 | 54 |
| `A.8.16` | Monitoring activities | 85 | 80 |
| `A.8.20` | Networks security | 77 | 55 |
| `A.8.24` | Use of cryptography | 94 | 59 |
| `A.8.25` | Secure development life cycle | 7 | 12 |
| `A.8.28` | Secure coding | 5 | 8 |
| `A.8.29` | Security testing in development and acceptance | 4 | 8 |
| `A.8.32` | Change management | 24 | 30 |
# NIST CSF 2.0 and connectors (/docs/framework-connectors/nist-csf)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard's automated tests map to **47** controls of NIST Cybersecurity Framework 2.0. **835** tests apply: 777 read a connected system, and 58 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
In the framework library: [NIST CSF 2.0 (Full)](/docs/frameworks/americas/nist-csf-2), with what a scan checks, the controls and the policy templates.
## How to connect for this framework
1. Connect the systems you run from the table below. Each connector links to its setup steps.
2. Open the framework on **Compliance › Frameworks**, then its **Connectors** tab: it lists the connectors that answer this framework's tests, which of them you have connected, and whether each connection is healthy.
3. Tests run on their schedule, or straight away with **Run now** on **Compliance › Tests**. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
## Connectors with automated evidence (360)
| Connector | Controls it provides evidence for | Tests |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [Amazon Web Services](/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services) (also AWS GovCloud, AWS CodeCommit, AWS Inspector, Amazon CloudWatch, Amazon S3, AWS Security Hub) | `DE.AE-02`, `DE.CM-01`, `DE.CM-09`, `ID.AM-07`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.IR-03`, `PR.PS-01`, `PR.PS-02`, `PR.PS-04`, `RS.CO-02`, `RS.MA-01` | 148 |
| [Google Cloud Platform](/docs/compliance-connectors/setup/cloud-infrastructure/google-cloud-platform) | `DE.CM-01`, `DE.CM-09`, `ID.AM-02`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.IR-03`, `PR.PS-01`, `PR.PS-02`, `PR.PS-04`, `RS.CO-02` | 112 |
| [Oracle Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/oracle-cloud) (also Oracle Cloud Government) | `DE.AE-02`, `DE.CM-01`, `DE.CM-03`, `DE.CM-09`, `ID.AM-02`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.IR-03`, `PR.PS-01`, `PR.PS-04` | 66 |
| [GitHub](/docs/compliance-connectors/setup/version-control/github) (also GitHub Enterprise, GitHub Issues) | `GV.SC-05`, `ID.AM-02`, `ID.IM-03`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.PS-01`, `PR.PS-02`, `PR.PS-04`, `PR.PS-06`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 44 |
| [Microsoft Azure](/docs/compliance-connectors/setup/cloud-infrastructure/microsoft-azure) (also Microsoft Entra ID, Azure Government) | `DE.CM-01`, `DE.CM-03`, `DE.CM-09`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.PS-01`, `PR.PS-02`, `PR.PS-04`, `RS.CO-02` | 139 |
| [GitLab](/docs/compliance-connectors/setup/version-control/gitlab) (also GitLab Issues, GitLab Self-Managed) | `ID.AM-02`, `ID.IM-03`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.PS-01`, `PR.PS-02`, `PR.PS-04`, `PR.PS-06`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 43 |
| [Google Workspace](/docs/compliance-connectors/setup/identity-and-sso/google-workspace) (also Google Cloud Identity, Google SSO) | `DE.CM-03`, `DE.CM-09`, `GV.SC-04`, `GV.SC-05`, `ID.AM-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.IR-01`, `PR.PS-02` | 24 |
| [Azure DevOps](/docs/compliance-connectors/setup/version-control/azure-devops) | `ID.AM-02`, `ID.IM-03`, `ID.RA-01`, `PR.AA-01`, `PR.AA-05`, `PR.DS-01`, `PR.PS-01`, `PR.PS-06`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 25 |
| [Datadog](/docs/compliance-connectors/setup/observability/datadog) (also Datadog CSM) | `DE.AE-02`, `DE.AE-06`, `DE.CM-01`, `DE.CM-09`, `ID.AM-02`, `ID.RA-01`, `PR.AA-01`, `PR.AA-05`, `PR.PS-01`, `PR.PS-04` | 11 |
| [Hetzner](/docs/compliance-connectors/setup/cloud-infrastructure/hetzner) | `DE.CM-01`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.PS-04` | 15 |
| [Kubernetes](/docs/compliance-connectors/setup/cloud-infrastructure/kubernetes) (also Gatekeeper OPA, Kyverno) | `DE.CM-09`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.IR-01`, `PR.IR-03`, `PR.PS-01` | 49 |
| [OVHcloud](/docs/compliance-connectors/setup/cloud-infrastructure/ovhcloud) | `DE.CM-01`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-11`, `PR.IR-01`, `PR.PS-04` | 25 |
| [Alibaba Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/alibaba-cloud) | `DE.CM-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01` | 20 |
| [CrowdStrike Falcon](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon) | `DE.AE-02`, `DE.CM-09`, `ID.RA-01`, `PR.AA-01`, `PR.AA-05`, `PR.PS-01`, `PR.PS-02`, `RS.MI-02` | 15 |
| [Jira](/docs/compliance-connectors/setup/ticketing/jira) | `ID.IM-03`, `ID.IM-04`, `PR.AA-01`, `PR.AA-05`, `RS.AN-03`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 9 |
| [JumpCloud](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud) (also JumpCloud MDM, JumpCloud SSO) | `DE.CM-09`, `ID.AM-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.IR-01`, `PR.PS-02` | 15 |
| [Linear](/docs/compliance-connectors/setup/ticketing/linear) | `ID.IM-03`, `ID.IM-04`, `PR.AA-01`, `PR.AA-05`, `RS.AN-03`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 9 |
| [Microsoft Intune](/docs/compliance-connectors/setup/mdm/microsoft-intune) | `DE.CM-09`, `ID.AM-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.IR-01`, `PR.PS-01`, `PR.PS-02` | 10 |
| [StackRox](/docs/compliance-connectors/setup/vulnerability-scanning/stackrox) (also Red Hat Advanced Cluster Security) | `DE.AE-02`, `DE.CM-01`, `ID.IM-02`, `ID.RA-01`, `ID.RA-06`, `PR.AA-01`, `PR.AA-05`, `PR.PS-01` | 10 |
| [Bitbucket](/docs/compliance-connectors/setup/version-control/bitbucket) | `ID.AM-02`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.PS-01`, `PR.PS-06` | 18 |
| [Cloudflare](/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare) | `DE.CM-01`, `DE.CM-09`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-02`, `PR.IR-01` | 16 |
| [Jamf](/docs/compliance-connectors/setup/mdm/jamf) | `ID.AM-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.IR-01`, `PR.PS-01`, `PR.PS-02` | 9 |
| [MongoDB Atlas](/docs/compliance-connectors/setup/infrastructure/mongodb-atlas) | `DE.CM-09`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-11`, `PR.IR-01` | 8 |
| [ServiceNow](/docs/compliance-connectors/setup/ticketing/servicenow) | `ID.IM-03`, `PR.AA-01`, `PR.AA-05`, `PR.PS-01`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 9 |
| [Asana](/docs/compliance-connectors/setup/ticketing/asana) | `ID.IM-03`, `PR.AA-01`, `PR.AA-05`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 8 |
| [Cisco Meraki SM](/docs/compliance-connectors/setup/mdm/cisco-meraki-sm) | `ID.AM-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.PS-01`, `PR.PS-02` | 8 |
| [ClickUp](/docs/compliance-connectors/setup/ticketing/clickup) | `ID.IM-03`, `PR.AA-01`, `PR.AA-05`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 8 |
| [Fleet](/docs/compliance-connectors/setup/mdm/fleet) | `ID.AM-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.IR-01`, `PR.PS-02` | 8 |
| [GoDaddy](/docs/compliance-connectors/setup/cloud-infrastructure/godaddy) | `DE.CM-09`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.IR-03` | 11 |
| [Heroku](/docs/compliance-connectors/setup/cloud-infrastructure/heroku) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-02`, `PR.DS-11`, `PR.PS-02` | 8 |
| [IBM Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/ibm-cloud) | `DE.CM-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.IR-01` | 17 |
| [Ivanti Neurons](/docs/compliance-connectors/setup/mdm/ivanti-neurons) | `ID.AM-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.PS-01`, `PR.PS-02` | 8 |
| [Kandji](/docs/compliance-connectors/setup/mdm/kandji) | `ID.AM-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.IR-01`, `PR.PS-02` | 8 |
| [Kolide](/docs/compliance-connectors/setup/mdm/kolide) | `ID.AM-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.IR-01`, `PR.PS-02` | 8 |
| [Microsoft Defender for Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/microsoft-defender-for-endpoint) | `DE.AE-02`, `DE.CM-09`, `ID.RA-01`, `PR.PS-01`, `PR.PS-02`, `RS.MI-02` | 12 |
| [Miradore](/docs/compliance-connectors/setup/mdm/miradore) | `ID.AM-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.PS-01`, `PR.PS-02` | 8 |
| [Monday.com](/docs/compliance-connectors/setup/ticketing/monday-com) | `ID.IM-03`, `PR.AA-01`, `PR.AA-05`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 8 |
| [Mosyle](/docs/compliance-connectors/setup/mdm/mosyle) | `ID.AM-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.IR-01`, `PR.PS-02` | 9 |
| [Redis Cloud](/docs/compliance-connectors/setup/infrastructure/redis-cloud) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01` | 8 |
| [SentinelOne](/docs/compliance-connectors/setup/endpoint-detection-and-response/sentinelone) | `DE.AE-02`, `DE.CM-09`, `PR.AA-01`, `PR.AA-05`, `PR.PS-01`, `RS.MI-02` | 8 |
| [Shortcut](/docs/compliance-connectors/setup/ticketing/shortcut) | `ID.IM-03`, `PR.AA-01`, `PR.AA-05`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 8 |
| [SolarWinds Service Desk](/docs/compliance-connectors/setup/ticketing/solarwinds-service-desk) | `ID.IM-03`, `PR.AA-01`, `PR.AA-05`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 8 |
| [Sophos Intercept X](/docs/compliance-connectors/setup/endpoint-detection-and-response/sophos-intercept-x) | `DE.AE-02`, `DE.CM-09`, `PR.AA-01`, `PR.AA-05`, `PR.PS-01`, `RS.MI-02` | 9 |
| [Spaceship](/docs/compliance-connectors/setup/cloud-infrastructure/spaceship) | `DE.CM-09`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.IR-03` | 11 |
| [Supabase](/docs/compliance-connectors/setup/infrastructure/supabase) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01` | 7 |
| [YouTrack](/docs/compliance-connectors/setup/ticketing/youtrack) | `ID.IM-03`, `PR.AA-01`, `PR.AA-05`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 8 |
| [Akamai](/docs/compliance-connectors/setup/cloud-infrastructure/akamai) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-02`, `PR.IR-01` | 6 |
| [Auth0](/docs/compliance-connectors/setup/identity-and-sso/auth0) (also Auth0 SSO) | `DE.CM-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.PS-04` | 12 |
| [ChatGPT](/docs/compliance-connectors/setup/business-applications/chatgpt) | `DE.CM-09`, `GV.OC-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 6 |
| [Cisco Secure Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/cisco-secure-endpoint) | `DE.AE-02`, `DE.CM-09`, `ID.RA-01`, `PR.PS-02`, `RS.MI-02` | 6 |
| [Claude (Anthropic)](/docs/compliance-connectors/setup/business-applications/claude-anthropic) | `DE.CM-09`, `GV.OC-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 10 |
| [Codeberg](/docs/compliance-connectors/setup/version-control/codeberg) | `PR.AA-01`, `PR.AA-05`, `PR.DS-01`, `PR.PS-01`, `PR.PS-06` | 6 |
| [DigitalOcean](/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean) | `DE.CM-09`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.PS-02` | 10 |
| [Elastic Observability](/docs/compliance-connectors/setup/observability/elastic-observability) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05`, `PR.DS-11`, `PR.PS-04` | 6 |
| [ElevenLabs](/docs/compliance-connectors/setup/business-applications/elevenlabs) | `DE.CM-09`, `GV.OC-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 7 |
| [Fireworks AI](/docs/compliance-connectors/setup/business-applications/fireworks-ai) | `DE.CM-09`, `GV.OC-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 10 |
| [Gitea](/docs/compliance-connectors/setup/version-control/gitea) | `PR.AA-01`, `PR.AA-05`, `PR.DS-01`, `PR.PS-01`, `PR.PS-06` | 6 |
| [Linode](/docs/compliance-connectors/setup/cloud-infrastructure/linode) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-11`, `PR.IR-01` | 6 |
| [Mistral AI](/docs/compliance-connectors/setup/business-applications/mistral-ai) | `DE.CM-09`, `GV.OC-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 9 |
| [Okta](/docs/compliance-connectors/setup/identity-and-sso/okta) (also Okta SSO) | `DE.CM-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.PS-04` | 14 |
| [OpenAI API Platform](/docs/compliance-connectors/setup/business-applications/openai-api-platform) | `DE.CM-09`, `GV.OC-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 12 |
| [PlanetScale](/docs/compliance-connectors/setup/infrastructure/planetscale) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-11`, `PR.PS-01` | 6 |
| [Redmine](/docs/compliance-connectors/setup/ticketing/redmine) | `ID.IM-03`, `PR.AA-05`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 5 |
| [Sentry](/docs/compliance-connectors/setup/observability/sentry) | `DE.CM-09`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01` | 6 |
| [SimpleMDM](/docs/compliance-connectors/setup/mdm/simplemdm) | `ID.AM-01`, `PR.AA-03`, `PR.DS-01`, `PR.IR-01`, `PR.PS-02` | 5 |
| [Sumo Logic](/docs/compliance-connectors/setup/observability/sumo-logic) | `DE.CM-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.PS-04` | 6 |
| [VMware Workspace ONE](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-workspace-one) | `ID.AM-01`, `PR.AA-03`, `PR.DS-01`, `PR.PS-01`, `PR.PS-02` | 7 |
| [xAI](/docs/compliance-connectors/setup/business-applications/xai) | `DE.CM-09`, `GV.OC-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 5 |
| [Bitdefender GravityZone](/docs/compliance-connectors/setup/endpoint-detection-and-response/bitdefender-gravityzone) | `DE.AE-02`, `DE.CM-09`, `PR.PS-01`, `RS.MI-02` | 5 |
| [Check Point CloudGuard](/docs/compliance-connectors/setup/cspm/check-point-cloudguard) | `DE.CM-09`, `ID.AM-02`, `ID.RA-01`, `PR.PS-01` | 3 |
| [ClickHouse](/docs/compliance-connectors/setup/data-export/clickhouse) | `PR.AA-01`, `PR.AA-05`, `PR.DS-11`, `PR.IR-01` | 5 |
| [Cortex XDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/cortex-xdr) | `DE.AE-02`, `DE.CM-09`, `PR.PS-01`, `RS.MI-02` | 5 |
| [CrowdStrike Falcon Cloud](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon-cloud) | `DE.CM-09`, `ID.AM-02`, `ID.RA-01`, `PR.PS-01` | 3 |
| [Cybereason](/docs/compliance-connectors/setup/endpoint-detection-and-response/cybereason) | `DE.AE-02`, `DE.CM-09`, `PR.PS-01`, `RS.MI-02` | 5 |
| [Elastic Security](/docs/compliance-connectors/setup/endpoint-detection-and-response/elastic-security) | `DE.AE-02`, `DE.CM-09`, `PR.PS-01`, `RS.MI-02` | 5 |
| [Fastly](/docs/compliance-connectors/setup/cloud-infrastructure/fastly) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-02` | 5 |
| [Fortinet FortiEDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/fortinet-fortiedr) | `DE.AE-02`, `DE.CM-09`, `PR.PS-01`, `RS.MI-02` | 5 |
| [Freshservice](/docs/compliance-connectors/setup/ticketing/freshservice) | `PR.AA-05`, `RS.MA-02`, `RS.MA-03`, `RS.MI-02` | 4 |
| [Gerrit](/docs/compliance-connectors/setup/version-control/gerrit) | `PR.AA-01`, `PR.AA-05`, `PR.PS-01`, `PR.PS-06` | 5 |
| [Hugging Face](/docs/compliance-connectors/setup/business-applications/hugging-face) | `GV.OC-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 8 |
| [Huntress](/docs/compliance-connectors/setup/endpoint-detection-and-response/huntress) | `DE.AE-02`, `DE.CM-09`, `PR.PS-01`, `RS.MI-02` | 6 |
| [Infisical](/docs/compliance-connectors/setup/infrastructure/infisical) | `DE.CM-09`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 8 |
| [Kaspersky Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/kaspersky-endpoint) | `DE.AE-02`, `DE.CM-09`, `PR.PS-01`, `RS.MI-02` | 5 |
| [Keycloak](/docs/compliance-connectors/setup/identity-and-sso/keycloak) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.PS-04` | 7 |
| [LogicMonitor](/docs/compliance-connectors/setup/observability/logicmonitor) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05`, `RS.MA-01` | 5 |
| [Logz.io](/docs/compliance-connectors/setup/observability/logz-io) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05`, `PR.PS-04` | 5 |
| [ManageEngine](/docs/compliance-connectors/setup/mdm/manageengine) | `ID.AM-01`, `PR.AA-05`, `PR.DS-01`, `PR.PS-02` | 6 |
| [New Relic](/docs/compliance-connectors/setup/observability/new-relic) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05`, `PR.PS-04` | 4 |
| [Nextcloud](/docs/compliance-connectors/setup/cloud-storage-provider/nextcloud) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01` | 5 |
| [NinjaOne](/docs/compliance-connectors/setup/mdm/ninjaone) | `ID.AM-01`, `PR.AA-05`, `PR.DS-01`, `PR.PS-02` | 6 |
| [OpenRouter](/docs/compliance-connectors/setup/business-applications/openrouter) | `GV.OC-03`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 8 |
| [OpenStack](/docs/compliance-connectors/setup/cloud-infrastructure/openstack) | `PR.AA-05`, `PR.DS-01`, `PR.DS-11`, `PR.IR-01` | 4 |
| [Opsgenie Alerts](/docs/compliance-connectors/setup/ticketing/opsgenie-alerts) | `GV.RR-02`, `PR.AA-01`, `PR.AA-05`, `RS.MA-01` | 5 |
| [PagerDuty](/docs/compliance-connectors/setup/ticketing/pagerduty) | `GV.RR-02`, `PR.AA-01`, `PR.AA-05`, `RS.MA-01` | 6 |
| [Red Hat OpenShift](/docs/compliance-connectors/setup/cloud-infrastructure/red-hat-openshift) | `DE.CM-09`, `PR.AA-03`, `PR.AA-05`, `PR.PS-01` | 5 |
| [Render](/docs/compliance-connectors/setup/cloud-infrastructure/render) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-11` | 5 |
| [Scaleway](/docs/compliance-connectors/setup/cloud-infrastructure/scaleway) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.IR-01` | 5 |
| [SigNoz](/docs/compliance-connectors/setup/observability/signoz) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05`, `PR.PS-04` | 7 |
| [Snowflake](/docs/compliance-connectors/setup/data-export/snowflake) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.IR-01` | 5 |
| [Splunk](/docs/compliance-connectors/setup/observability/splunk) | `DE.AE-06`, `PR.AA-01`, `PR.AA-05`, `PR.PS-04` | 5 |
| [Symantec Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/symantec-endpoint) | `DE.AE-02`, `DE.CM-09`, `PR.PS-01`, `RS.MI-02` | 5 |
| [Terraform Cloud](/docs/compliance-connectors/setup/infrastructure/terraform-cloud) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.PS-01` | 5 |
| [UpCloud](/docs/compliance-connectors/setup/cloud-infrastructure/upcloud) | `PR.AA-01`, `PR.AA-05`, `PR.DS-11`, `PR.IR-01` | 4 |
| [Vercel](/docs/compliance-connectors/setup/cloud-infrastructure/vercel) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.PS-01` | 6 |
| [VMware](/docs/compliance-connectors/setup/cloud-infrastructure/vmware) | `DE.CM-09`, `PR.AA-01`, `PR.DS-11`, `PR.PS-01` | 6 |
| [VMware Carbon Black](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-carbon-black) | `DE.AE-02`, `DE.CM-09`, `PR.PS-01`, `RS.MI-02` | 5 |
| [Vultr](/docs/compliance-connectors/setup/cloud-infrastructure/vultr) | `PR.AA-01`, `PR.AA-05`, `PR.DS-11`, `PR.IR-01` | 5 |
| [WithSecure](/docs/compliance-connectors/setup/endpoint-detection-and-response/withsecure) | `DE.AE-02`, `DE.CM-09`, `PR.PS-01`, `RS.MI-02` | 5 |
| [Airtable](/docs/compliance-connectors/setup/ticketing/airtable) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Authentik](/docs/compliance-connectors/setup/identity-and-sso/authentik) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 5 |
| [Automox](/docs/compliance-connectors/setup/mdm/automox) | `ID.AM-01`, `ID.RA-01`, `PR.PS-02` | 4 |
| [Backblaze](/docs/compliance-connectors/setup/cloud-storage-provider/backblaze) | `PR.DS-01`, `PR.DS-11`, `PR.IR-01` | 3 |
| [Better Stack](/docs/compliance-connectors/setup/observability/better-stack) | `DE.CM-01`, `PR.PS-04`, `RS.MA-01` | 3 |
| [Citrix Endpoint Management](/docs/compliance-connectors/setup/mdm/citrix-endpoint-management) | `ID.AM-01`, `PR.PS-01`, `PR.PS-02` | 5 |
| [Cloudflare Access](/docs/compliance-connectors/setup/identity-and-sso/cloudflare-access) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 3 |
| [Cobalt](/docs/compliance-connectors/setup/vulnerability-scanning/cobalt) | `ID.IM-02`, `ID.RA-01`, `ID.RA-06` | 3 |
| [Coralogix](/docs/compliance-connectors/setup/observability/coralogix) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05` | 3 |
| [Deep Instinct](/docs/compliance-connectors/setup/endpoint-detection-and-response/deep-instinct) | `DE.AE-02`, `DE.CM-09`, `RS.MI-02` | 4 |
| [Docker](/docs/compliance-connectors/setup/infrastructure/docker) | `PR.AA-01`, `PR.AA-05`, `PR.DS-01` | 4 |
| [Duo Security](/docs/compliance-connectors/setup/identity-and-sso/duo-security) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 6 |
| [Dynatrace](/docs/compliance-connectors/setup/observability/dynatrace) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05` | 3 |
| [env0](/docs/compliance-connectors/setup/infrastructure/env0) | `PR.AA-01`, `PR.AA-05`, `PR.PS-01` | 4 |
| [ESET Protect](/docs/compliance-connectors/setup/endpoint-detection-and-response/eset-protect) | `DE.AE-02`, `DE.CM-09`, `RS.MI-02` | 4 |
| [Fly.io](/docs/compliance-connectors/setup/cloud-infrastructure/fly-io) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [FusionAuth](/docs/compliance-connectors/setup/identity-and-sso/fusionauth) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Grafana](/docs/compliance-connectors/setup/observability/grafana) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05` | 5 |
| [Gusto](/docs/compliance-connectors/setup/hris/gusto) | `GV.RR-04`, `PR.AA-01`, `PR.AA-05` | 2 |
| [HashiCorp Consul](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-consul) | `PR.AA-05`, `PR.DS-02`, `PR.PS-01` | 2 |
| [HashiCorp Nomad](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-nomad) | `PR.AA-05`, `PR.DS-02`, `PR.PS-01` | 2 |
| [Hexnode](/docs/compliance-connectors/setup/mdm/hexnode) | `ID.AM-01`, `PR.AA-05`, `PR.PS-02` | 5 |
| [IBM Verify](/docs/compliance-connectors/setup/identity-and-sso/ibm-verify) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Instana](/docs/compliance-connectors/setup/observability/instana) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05` | 3 |
| [Jamf Protect](/docs/compliance-connectors/setup/endpoint-detection-and-response/jamf-protect) | `DE.AE-02`, `DE.CM-09`, `RS.MI-02` | 4 |
| [Jira Service Management](/docs/compliance-connectors/setup/ticketing/jira-service-management) | `ID.IM-03`, `PR.PS-01`, `RS.MA-03` | 3 |
| [Logto](/docs/compliance-connectors/setup/identity-and-sso/logto) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Looker](/docs/compliance-connectors/setup/data-export/looker) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Mailgun](/docs/compliance-connectors/setup/communications-platforms/mailgun) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Make](/docs/compliance-connectors/setup/security-automation/make) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Mattermost](/docs/compliance-connectors/setup/communications-platforms/mattermost) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [MinIO](/docs/compliance-connectors/setup/cloud-storage-provider/minio) | `PR.DS-01`, `PR.DS-11`, `PR.IR-01` | 3 |
| [OneLogin](/docs/compliance-connectors/setup/identity-and-sso/onelogin) (also OneLogin SSO) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 7 |
| [Oracle Identity](/docs/compliance-connectors/setup/identity-and-sso/oracle-identity) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 5 |
| [ownCloud](/docs/compliance-connectors/setup/cloud-storage-provider/owncloud) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [PingOne](/docs/compliance-connectors/setup/identity-and-sso/pingone) (also Ping Identity) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 6 |
| [Platform.sh](/docs/compliance-connectors/setup/cloud-infrastructure/platform-sh) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Proxmox](/docs/compliance-connectors/setup/cloud-infrastructure/proxmox) | `PR.AA-03`, `PR.AA-05`, `PR.DS-11` | 3 |
| [Pulumi](/docs/compliance-connectors/setup/infrastructure/pulumi) (also Pulumi Cloud) | `PR.AA-01`, `PR.AA-05`, `PR.PS-01` | 4 |
| [Qualys EDR](/docs/compliance-connectors/setup/vulnerability-scanning/qualys-edr) | `DE.AE-02`, `DE.CM-09`, `RS.MI-02` | 3 |
| [Railway](/docs/compliance-connectors/setup/cloud-infrastructure/railway) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Red Canary](/docs/compliance-connectors/setup/endpoint-detection-and-response/red-canary) | `DE.AE-02`, `DE.CM-09`, `RS.MI-02` | 4 |
| [Rollbar](/docs/compliance-connectors/setup/observability/rollbar) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05` | 4 |
| [Salesforce](/docs/compliance-connectors/setup/crm/salesforce) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Site24x7](/docs/compliance-connectors/setup/observability/site24x7) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05` | 4 |
| [Slack](/docs/compliance-connectors/setup/communications-platforms/slack) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Spacelift](/docs/compliance-connectors/setup/infrastructure/spacelift) | `PR.AA-01`, `PR.AA-05`, `PR.PS-01` | 3 |
| [Tanium](/docs/compliance-connectors/setup/endpoint-detection-and-response/tanium) | `DE.AE-02`, `DE.CM-09`, `RS.MI-02` | 4 |
| [Trellix](/docs/compliance-connectors/setup/endpoint-detection-and-response/trellix) | `DE.AE-02`, `DE.CM-09`, `RS.MI-02` | 4 |
| [Trend Micro Apex One](/docs/compliance-connectors/setup/endpoint-detection-and-response/trend-micro-apex-one) | `DE.AE-02`, `DE.CM-09`, `RS.MI-02` | 5 |
| [Zabbix](/docs/compliance-connectors/setup/observability/zabbix) | `DE.CM-01`, `PR.AA-01`, `PR.AA-05` | 4 |
| [Zendesk](/docs/compliance-connectors/setup/ticketing/zendesk) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Zitadel](/docs/compliance-connectors/setup/identity-and-sso/zitadel) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [Zoom](/docs/compliance-connectors/setup/communications-platforms/zoom) | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
| [15Five](/docs/compliance-connectors/setup/hris/15five) | `PR.AA-01`, `PR.AA-05` | 2 |
| [1Password](/docs/compliance-connectors/setup/identity-and-sso/1password) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Action1](/docs/compliance-connectors/setup/mdm/action1) | `ID.AM-01`, `PR.PS-02` | 2 |
| [ActiveCampaign](/docs/compliance-connectors/setup/crm/activecampaign) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Adobe Acrobat Sign](/docs/compliance-connectors/setup/digital-signature/adobe-acrobat-sign) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Aha!](/docs/compliance-connectors/setup/ticketing/aha) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Aikido Security](/docs/compliance-connectors/setup/vulnerability-scanning/aikido-security) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Airbyte](/docs/compliance-connectors/setup/data-export/airbyte) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Aircall](/docs/compliance-connectors/setup/communications-platforms/aircall) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Amplitude](/docs/compliance-connectors/setup/data-export/amplitude) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Anchore](/docs/compliance-connectors/setup/vulnerability-scanning/anchore) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Ansible](/docs/compliance-connectors/setup/infrastructure/ansible) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Apollo IO](/docs/compliance-connectors/setup/business-applications/apollo-io) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Aptible](/docs/compliance-connectors/setup/cloud-infrastructure/aptible) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Ashby](/docs/compliance-connectors/setup/hris/ashby) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Assembla](/docs/compliance-connectors/setup/version-control/assembla) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Attio](/docs/compliance-connectors/setup/crm/attio) | `PR.AA-01`, `PR.AA-05` | 3 |
| [BambooHR](/docs/compliance-connectors/setup/hris/bamboohr) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Baramundi](/docs/compliance-connectors/setup/mdm/baramundi) | `ID.AM-01`, `PR.PS-02` | 4 |
| [Basecamp](/docs/compliance-connectors/setup/ticketing/basecamp) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Beanstalk](/docs/compliance-connectors/setup/version-control/beanstalk) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Beyond Identity](/docs/compliance-connectors/setup/identity-and-sso/beyond-identity) | `PR.AA-01`, `PR.AA-05` | 2 |
| [BitSight](/docs/compliance-connectors/setup/vendor-procurement/bitsight) | `ID.RA-01`, `ID.RA-06` | 2 |
| [BoldSign](/docs/compliance-connectors/setup/digital-signature/boldsign) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Box](/docs/compliance-connectors/setup/cloud-storage-provider/box) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Brex](/docs/compliance-connectors/setup/vendor-procurement/brex) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Bright Security](/docs/compliance-connectors/setup/vulnerability-scanning/bright-security) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Bugcrowd](/docs/compliance-connectors/setup/vulnerability-scanning/bugcrowd) | `ID.RA-01`, `ID.RA-06` | 2 |
| [Burp Suite](/docs/compliance-connectors/setup/vulnerability-scanning/burp-suite) | `ID.RA-01`, `ID.RA-06` | 3 |
| [Canva](/docs/compliance-connectors/setup/business-applications/canva) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Capsule](/docs/compliance-connectors/setup/crm/capsule) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Census](/docs/compliance-connectors/setup/data-export/census) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Ceridian Dayforce](/docs/compliance-connectors/setup/hris/ceridian-dayforce) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Checkmarx](/docs/compliance-connectors/setup/vulnerability-scanning/checkmarx) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Citrix ShareFile](/docs/compliance-connectors/setup/cloud-storage-provider/citrix-sharefile) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Close](/docs/compliance-connectors/setup/crm/close) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Confluence](/docs/compliance-connectors/setup/compliance-as-code/confluence) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Contrast Security](/docs/compliance-connectors/setup/vulnerability-scanning/contrast-security) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Copper](/docs/compliance-connectors/setup/crm/copper) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Cortex XSOAR](/docs/compliance-connectors/setup/security-automation/cortex-xsoar) | `RS.MA-03`, `RS.MI-02` | 2 |
| [Coupa](/docs/compliance-connectors/setup/vendor-procurement/coupa) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Culture Amp](/docs/compliance-connectors/setup/hris/culture-amp) | `PR.AA-01`, `PR.AA-05` | 2 |
| [D3 Security](/docs/compliance-connectors/setup/security-automation/d3-security) | `RS.MA-03`, `RS.MI-02` | 2 |
| [Databricks](/docs/compliance-connectors/setup/data-export/databricks) | `PR.AA-01`, `PR.AA-05` | 3 |
| [dbt Cloud](/docs/compliance-connectors/setup/data-export/dbt-cloud) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Deel](/docs/compliance-connectors/setup/hris/deel) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Dependency-Track](/docs/compliance-connectors/setup/vulnerability-scanning/dependency-track) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Detectify](/docs/compliance-connectors/setup/vulnerability-scanning/detectify) | `ID.RA-01`, `ID.RA-06` | 3 |
| [Dialpad](/docs/compliance-connectors/setup/communications-platforms/dialpad) | `PR.AA-01`, `PR.AA-05` | 3 |
| [DocuSign](/docs/compliance-connectors/setup/digital-signature/docusign) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Dropbox](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Dropbox Sign](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox-sign) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Egnyte](/docs/compliance-connectors/setup/cloud-storage-provider/egnyte) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Employment Hero](/docs/compliance-connectors/setup/hris/employment-hero) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Endor Labs](/docs/compliance-connectors/setup/vulnerability-scanning/endor-labs) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Escape](/docs/compliance-connectors/setup/vulnerability-scanning/escape) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Esper](/docs/compliance-connectors/setup/mdm/esper) | `ID.AM-01`, `PR.PS-02` | 2 |
| [Factorial](/docs/compliance-connectors/setup/hris/factorial) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Figma](/docs/compliance-connectors/setup/business-applications/figma) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Fivetran](/docs/compliance-connectors/setup/data-export/fivetran) | `PR.AA-01`, `PR.AA-05` | 3 |
| [folk](/docs/compliance-connectors/setup/crm/folk) | `PR.AA-01`, `PR.AA-05` | 2 |
| [ForgeRock](/docs/compliance-connectors/setup/identity-and-sso/forgerock) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Freshdesk](/docs/compliance-connectors/setup/ticketing/freshdesk) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Front](/docs/compliance-connectors/setup/communications-platforms/front) | `PR.AA-01`, `PR.AA-05` | 3 |
| [GitGuardian](/docs/compliance-connectors/setup/vulnerability-scanning/gitguardian) | `ID.RA-01`, `ID.RA-06` | 3 |
| [GoHighLevel](/docs/compliance-connectors/setup/crm/gohighlevel) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Google Chronicle SOAR](/docs/compliance-connectors/setup/security-automation/google-chronicle-soar) | `RS.MA-03`, `RS.MI-02` | 2 |
| [GoTo Connect](/docs/compliance-connectors/setup/communications-platforms/goto-connect) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Greenhouse](/docs/compliance-connectors/setup/hris/greenhouse) | `PR.AA-01`, `PR.AA-05` | 3 |
| [HackerOne](/docs/compliance-connectors/setup/vulnerability-scanning/hackerone) | `ID.RA-01`, `ID.RA-06` | 2 |
| [HashiCorp Vault](/docs/compliance-connectors/setup/infrastructure/hashicorp-vault) | `DE.CM-01`, `PR.AA-03` | 2 |
| [Hevo Data](/docs/compliance-connectors/setup/data-export/hevo-data) | `PR.AA-01`, `PR.AA-05` | 3 |
| [HiBob](/docs/compliance-connectors/setup/hris/hibob) (also Bob) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Hightouch](/docs/compliance-connectors/setup/data-export/hightouch) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Hive](/docs/compliance-connectors/setup/ticketing/hive) | `PR.AA-01`, `PR.AA-05` | 2 |
| [HubSpot](/docs/compliance-connectors/setup/crm/hubspot) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Humaans](/docs/compliance-connectors/setup/hris/humaans) | `GV.RR-04`, `PR.AA-01` | 1 |
| [IBM QRadar SOAR](/docs/compliance-connectors/setup/security-automation/ibm-qradar-soar) | `RS.MA-03`, `RS.MI-02` | 2 |
| [Insightly](/docs/compliance-connectors/setup/crm/insightly) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Intercom](/docs/compliance-connectors/setup/communications-platforms/intercom) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Intruder](/docs/compliance-connectors/setup/vulnerability-scanning/intruder) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Invicti](/docs/compliance-connectors/setup/vulnerability-scanning/invicti) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Ironclad](/docs/compliance-connectors/setup/digital-signature/ironclad) | `PR.AA-01`, `PR.AA-05` | 2 |
| [JFrog Xray](/docs/compliance-connectors/setup/vulnerability-scanning/jfrog-xray) | `ID.RA-01`, `ID.RA-06` | 3 |
| [Keap](/docs/compliance-connectors/setup/crm/keap) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Lacework](/docs/compliance-connectors/setup/cspm/lacework) | `ID.RA-01`, `ID.RA-06` | 3 |
| [Lattice](/docs/compliance-connectors/setup/hris/lattice) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Launchpad](/docs/compliance-connectors/setup/version-control/launchpad) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Lever](/docs/compliance-connectors/setup/hris/lever) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Loopio](/docs/compliance-connectors/setup/vendor-procurement/loopio) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Malwarebytes](/docs/compliance-connectors/setup/endpoint-detection-and-response/malwarebytes) | `DE.CM-09`, `PR.PS-01` | 3 |
| [Mend](/docs/compliance-connectors/setup/vulnerability-scanning/mend) | `ID.RA-01`, `ID.RA-06` | 3 |
| [Microsoft Dynamics 365](/docs/compliance-connectors/setup/crm/microsoft-dynamics-365) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Miro](/docs/compliance-connectors/setup/communications-platforms/miro) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Mixpanel](/docs/compliance-connectors/setup/data-export/mixpanel) | `PR.AA-01`, `PR.AA-05` | 2 |
| [n8n](/docs/compliance-connectors/setup/security-automation/n8n) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Netlify](/docs/compliance-connectors/setup/cloud-infrastructure/netlify) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Northflank](/docs/compliance-connectors/setup/cloud-infrastructure/northflank) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Notion](/docs/compliance-connectors/setup/compliance-as-code/notion) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Nucleus Security](/docs/compliance-connectors/setup/vulnerability-scanning/nucleus-security) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Nutanix](/docs/compliance-connectors/setup/cloud-infrastructure/nutanix) | `PR.AA-05`, `PR.DS-11` | 2 |
| [Nutshell](/docs/compliance-connectors/setup/crm/nutshell) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Oneflow](/docs/compliance-connectors/setup/digital-signature/oneflow) | `PR.AA-01`, `PR.AA-05` | 2 |
| [OneSpan Sign](/docs/compliance-connectors/setup/digital-signature/onespan-sign) | `PR.AA-01`, `PR.AA-05` | 2 |
| [OneTrust Vendorpedia](/docs/compliance-connectors/setup/vendor-procurement/onetrust-vendorpedia) | `PR.AA-01`, `PR.AA-05` | 2 |
| [OpenPhone](/docs/compliance-connectors/setup/communications-platforms/openphone) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Ox Security](/docs/compliance-connectors/setup/vulnerability-scanning/ox-security) | `ID.RA-01`, `ID.RA-06` | 4 |
| [PandaDoc](/docs/compliance-connectors/setup/digital-signature/pandadoc) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Paychex](/docs/compliance-connectors/setup/hris/paychex) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Pingdom](/docs/compliance-connectors/setup/observability/pingdom) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Pipedrive](/docs/compliance-connectors/setup/crm/pipedrive) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Portainer](/docs/compliance-connectors/setup/cloud-infrastructure/portainer) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Prey](/docs/compliance-connectors/setup/mdm/prey) | `ID.AM-01`, `PR.PS-02` | 2 |
| [Prisma Cloud](/docs/compliance-connectors/setup/cspm/prisma-cloud) | `ID.RA-01`, `ID.RA-06` | 3 |
| [Probely](/docs/compliance-connectors/setup/vulnerability-scanning/probely) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Productboard](/docs/compliance-connectors/setup/ticketing/productboard) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Prowler](/docs/compliance-connectors/setup/infrastructure/prowler) | `ID.RA-01`, `PR.PS-01` | 2 |
| [Qovery](/docs/compliance-connectors/setup/cloud-infrastructure/qovery) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Qualys](/docs/compliance-connectors/setup/vulnerability-scanning/qualys) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Ramp](/docs/compliance-connectors/setup/vendor-procurement/ramp) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Rancher](/docs/compliance-connectors/setup/cloud-infrastructure/rancher) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Rapid7 InsightIDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/rapid7-insightidr) | `DE.AE-02`, `RS.MI-02` | 2 |
| [Rapid7 InsightVM](/docs/compliance-connectors/setup/vulnerability-scanning/rapid7-insightvm) | `ID.RA-01`, `ID.RA-06` | 4 |
| [RingCentral](/docs/compliance-connectors/setup/identity-and-sso/ringcentral) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Rippling](/docs/compliance-connectors/setup/hris/rippling) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Rocket.Chat](/docs/compliance-connectors/setup/communications-platforms/rocket-chat) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Sage HR](/docs/compliance-connectors/setup/hris/sage-hr) | `GV.RR-04`, `PR.AA-01` | 1 |
| [SailPoint](/docs/compliance-connectors/setup/identity-and-sso/sailpoint) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Salesflare](/docs/compliance-connectors/setup/crm/salesflare) | `PR.AA-01`, `PR.AA-05` | 2 |
| [SAP SuccessFactors](/docs/compliance-connectors/setup/hris/sap-successfactors) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Sapling](/docs/compliance-connectors/setup/hris/sapling) | `GV.RR-04`, `PR.AA-01` | 1 |
| [SecurityScorecard Atlas](/docs/compliance-connectors/setup/vendor-procurement/securityscorecard-atlas) | `ID.RA-01`, `ID.RA-06` | 1 |
| [Segment](/docs/compliance-connectors/setup/data-export/segment) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Semgrep](/docs/compliance-connectors/setup/vulnerability-scanning/semgrep) | `ID.RA-01`, `ID.RA-06` | 4 |
| [SendGrid](/docs/compliance-connectors/setup/communications-platforms/sendgrid) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Setyl](/docs/compliance-connectors/setup/vendor-procurement/setyl) | `ID.AM-01`, `PR.AA-05` | 2 |
| [SharePoint](/docs/compliance-connectors/setup/cloud-storage-provider/sharepoint) | `PR.AA-05`, `PR.DS-01` | 4 |
| [SignNow](/docs/compliance-connectors/setup/digital-signature/signnow) | `PR.AA-01`, `PR.AA-05` | 2 |
| [SignRequest](/docs/compliance-connectors/setup/digital-signature/signrequest) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Smartsheet](/docs/compliance-connectors/setup/ticketing/smartsheet) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Snyk](/docs/compliance-connectors/setup/vulnerability-scanning/snyk) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Socket](/docs/compliance-connectors/setup/vulnerability-scanning/socket) | `ID.RA-01`, `ID.RA-06` | 3 |
| [SonarQube](/docs/compliance-connectors/setup/vulnerability-scanning/sonarqube) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Splunk SOAR](/docs/compliance-connectors/setup/observability/splunk-soar) | `RS.MA-03`, `RS.MI-02` | 2 |
| [StackHawk](/docs/compliance-connectors/setup/vulnerability-scanning/stackhawk) | `ID.RA-01`, `ID.RA-06` | 3 |
| [Streak](/docs/compliance-connectors/setup/crm/streak) | `PR.AA-01`, `PR.AA-05` | 2 |
| [SugarCRM](/docs/compliance-connectors/setup/crm/sugarcrm) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Teamwork](/docs/compliance-connectors/setup/ticketing/teamwork) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Telnyx](/docs/compliance-connectors/setup/communications-platforms/telnyx) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Tenable](/docs/compliance-connectors/setup/vulnerability-scanning/tenable) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Tines](/docs/compliance-connectors/setup/security-automation/tines) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Torq](/docs/compliance-connectors/setup/security-automation/torq) | `RS.MA-03`, `RS.MI-02` | 2 |
| [Tray.io](/docs/compliance-connectors/setup/security-automation/tray-io) | `PR.AA-01`, `PR.AA-05` | 2 |
| [Trello](/docs/compliance-connectors/setup/ticketing/trello) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Trend Micro Cloud One](/docs/compliance-connectors/setup/cspm/trend-micro-cloud-one) | `ID.RA-01`, `PR.PS-01` | 3 |
| [UKG](/docs/compliance-connectors/setup/hris/ukg) | `GV.RR-04`, `PR.AA-01` | 1 |
| [UpGuard Vendor Risk](/docs/compliance-connectors/setup/vendor-procurement/upguard-vendor-risk) | `ID.RA-01`, `ID.RA-06` | 2 |
| [Veracode](/docs/compliance-connectors/setup/vulnerability-scanning/veracode) | `ID.RA-01`, `ID.RA-06` | 4 |
| [Vtiger](/docs/compliance-connectors/setup/crm/vtiger) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Wasabi](/docs/compliance-connectors/setup/cloud-storage-provider/wasabi) | `PR.DS-11`, `PR.IR-01` | 3 |
| [Webex](/docs/compliance-connectors/setup/communications-platforms/webex) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Wiz](/docs/compliance-connectors/setup/cspm/wiz) | `ID.RA-01`, `ID.RA-06` | 3 |
| [Workable](/docs/compliance-connectors/setup/hris/workable) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Workato](/docs/compliance-connectors/setup/security-automation/workato) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Workday](/docs/compliance-connectors/setup/hris/workday) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Wrike](/docs/compliance-connectors/setup/ticketing/wrike) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Yousign](/docs/compliance-connectors/setup/digital-signature/yousign) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Zendesk Sell](/docs/compliance-connectors/setup/ticketing/zendesk-sell) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Zenefits](/docs/compliance-connectors/setup/hris/zenefits) | `GV.RR-04`, `PR.AA-01` | 1 |
| [Zoho CRM](/docs/compliance-connectors/setup/crm/zoho-crm) | `PR.AA-01`, `PR.AA-05` | 3 |
| [Zoho Desk](/docs/compliance-connectors/setup/ticketing/zoho-desk) | `PR.AA-01`, `PR.AA-05` | 3 |
| [360Learning](/docs/compliance-connectors/setup/security-training/360learning) | `PR.AT-01` | 1 |
| [42Gears](/docs/compliance-connectors/setup/mdm/42gears) | `ID.AM-01` | 1 |
| [AppDynamics](/docs/compliance-connectors/setup/observability/appdynamics) | `DE.CM-01` | 1 |
| [Check Point Harmony](/docs/compliance-connectors/setup/endpoint-detection-and-response/check-point-harmony) | `DE.CM-09` | 2 |
| [Chronosphere](/docs/compliance-connectors/setup/observability/chronosphere) | `DE.CM-01` | 1 |
| [Civo](/docs/compliance-connectors/setup/cloud-infrastructure/civo) | `PR.IR-01` | 2 |
| [Cronitor](/docs/compliance-connectors/setup/observability/cronitor) | `DE.CM-01` | 1 |
| [Docebo](/docs/compliance-connectors/setup/security-training/docebo) | `PR.AT-01` | 1 |
| [Firebase](/docs/compliance-connectors/setup/infrastructure/firebase) | `PR.AA-05` | 1 |
| [Google Drive](/docs/compliance-connectors/setup/cloud-storage-provider/google-drive) | `PR.DS-01` | 1 |
| [Immersive Labs](/docs/compliance-connectors/setup/security-training/immersive-labs) | `PR.AT-02` | 1 |
| [Lessonly](/docs/compliance-connectors/setup/security-training/lessonly) | `PR.AT-01` | 1 |
| [Opal](/docs/compliance-connectors/setup/user-access-review/opal) | `PR.AA-05` | 2 |
| [Prometheus](/docs/compliance-connectors/setup/observability/prometheus) | `DE.CM-01` | 1 |
| [Proofpoint Security Awareness](/docs/compliance-connectors/setup/security-training/proofpoint-security-awareness) | `PR.AT-01` | 2 |
| [Riot](/docs/compliance-connectors/setup/security-training/riot) | `PR.AT-01` | 2 |
| [Shuffle](/docs/compliance-connectors/setup/security-automation/shuffle) | `PR.AA-01` | 2 |
| [TalentLMS](/docs/compliance-connectors/setup/security-training/talentlms) | `PR.AT-01` | 1 |
| [ThreatConnect](/docs/compliance-connectors/setup/security-automation/threatconnect) | `PR.AA-01` | 2 |
| [Torii](/docs/compliance-connectors/setup/user-access-review/torii) | `PR.AA-05` | 2 |
| [Turbot](/docs/compliance-connectors/setup/cspm/turbot) | `PR.PS-01` | 1 |
| [Udemy Business](/docs/compliance-connectors/setup/security-training/udemy-business) | `PR.AT-01` | 1 |
| [Uptime Robot](/docs/compliance-connectors/setup/observability/uptime-robot) | `DE.CM-01` | 1 |
| [Veza](/docs/compliance-connectors/setup/user-access-review/veza) | `PR.AA-05` | 1 |
| [VictoriaMetrics](/docs/compliance-connectors/setup/observability/victoriametrics) | `DE.CM-01` | 1 |
| [Webroot](/docs/compliance-connectors/setup/endpoint-detection-and-response/webroot) | `DE.CM-09` | 2 |
| [Yardstik](/docs/compliance-connectors/setup/background-check-providers/yardstik) | `GV.RR-04` | 1 |
## Evidence by attestation (95)
These systems publish no API for what the tests check. Connect them to record the connection, then attest the result; an accepted attestation counts toward the control.
| Connector | Controls |
| --------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| [8x8](/docs/compliance-connectors/setup/communications-platforms/8x8) | `PR.AA-05` |
| [Acunetix](/docs/compliance-connectors/setup/vulnerability-scanning/acunetix) | `ID.RA-01` |
| [Addigy](/docs/compliance-connectors/setup/mdm/addigy) | `ID.AM-01`, `PR.PS-02` |
| [Affinity](/docs/compliance-connectors/setup/crm/affinity) | `PR.AA-05` |
| [Airbase](/docs/compliance-connectors/setup/vendor-procurement/airbase) | `PR.AA-05` |
| [Apiiro](/docs/compliance-connectors/setup/vulnerability-scanning/apiiro) | `ID.RA-01` |
| [Aqua Security](/docs/compliance-connectors/setup/cspm/aqua-security) | `ID.RA-01` |
| [Arctic Wolf](/docs/compliance-connectors/setup/endpoint-detection-and-response/arctic-wolf) | `DE.CM-09` |
| [Arnica](/docs/compliance-connectors/setup/vulnerability-scanning/arnica) | `ID.RA-01` |
| [Blackpoint Cyber](/docs/compliance-connectors/setup/endpoint-detection-and-response/blackpoint-cyber) | `DE.CM-09` |
| [Bugsnag](/docs/compliance-connectors/setup/observability/bugsnag) | `PR.AA-05` |
| [Carta](/docs/compliance-connectors/setup/business-applications/carta) | `PR.AA-05` |
| [Checkmk](/docs/compliance-connectors/setup/observability/checkmk) | `DE.AE-06`, `PR.AA-05` |
| [Cloudanix](/docs/compliance-connectors/setup/cspm/cloudanix) | `ID.RA-01` |
| [Cohere](/docs/compliance-connectors/setup/business-applications/cohere) | `GV.OC-03`, `PR.AA-05` |
| [Concord](/docs/compliance-connectors/setup/digital-signature/concord) | `PR.AA-05` |
| [Contractbook](/docs/compliance-connectors/setup/digital-signature/contractbook) | `PR.AA-05` |
| [ContractSafe](/docs/compliance-connectors/setup/digital-signature/contractsafe) | `PR.AA-05` |
| [CoreStack](/docs/compliance-connectors/setup/cspm/corestack) | `ID.RA-01` |
| [CyberArk](/docs/compliance-connectors/setup/identity-and-sso/cyberark) | `PR.AA-03`, `PR.AA-05` |
| [Cynet](/docs/compliance-connectors/setup/endpoint-detection-and-response/cynet) | `DE.CM-09` |
| [Cyscale](/docs/compliance-connectors/setup/cspm/cyscale) | `ID.RA-01` |
| [Cyware](/docs/compliance-connectors/setup/security-automation/cyware) | `RS.MA-01` |
| [DeepSeek](/docs/compliance-connectors/setup/business-applications/deepseek) | `GV.OC-03`, `PR.AA-05` |
| [Documenso](/docs/compliance-connectors/setup/digital-signature/documenso) | `PR.AA-05` |
| [Edgescan](/docs/compliance-connectors/setup/vulnerability-scanning/edgescan) | `ID.RA-01` |
| [Eversign](/docs/compliance-connectors/setup/digital-signature/eversign) | `PR.AA-05` |
| [Evisort](/docs/compliance-connectors/setup/digital-signature/evisort) | `PR.AA-05` |
| [Foxit eSign](/docs/compliance-connectors/setup/digital-signature/foxit-esign) | `PR.AA-05` |
| [Freshsales](/docs/compliance-connectors/setup/crm/freshsales) | `PR.AA-05` |
| [Gatekeeper](/docs/compliance-connectors/setup/vendor-procurement/gatekeeper) | `PR.AA-05` |
| [GetAccept](/docs/compliance-connectors/setup/digital-signature/getaccept) | `PR.AA-05` |
| [GitKraken](/docs/compliance-connectors/setup/version-control/gitkraken) | `PR.AA-05` |
| [Groq](/docs/compliance-connectors/setup/business-applications/groq) | `GV.OC-03`, `PR.AA-05` |
| [Honeycomb](/docs/compliance-connectors/setup/observability/honeycomb) | `DE.AE-06` |
| [IBM MaaS360](/docs/compliance-connectors/setup/mdm/ibm-maas360) | `ID.AM-01`, `PR.PS-02` |
| [IDrive](/docs/compliance-connectors/setup/cloud-storage-provider/idrive) | `PR.DS-11` |
| [Juro](/docs/compliance-connectors/setup/digital-signature/juro) | `PR.AA-05` |
| [Kion](/docs/compliance-connectors/setup/cspm/kion) | `ID.RA-01` |
| [LastPass SSO](/docs/compliance-connectors/setup/identity-and-sso/lastpass-sso) | `PR.AA-03`, `PR.AA-05` |
| [Legit Security](/docs/compliance-connectors/setup/vulnerability-scanning/legit-security) | `ID.RA-01` |
| [Lexion](/docs/compliance-connectors/setup/digital-signature/lexion) | `PR.AA-05` |
| [LinkSquares](/docs/compliance-connectors/setup/digital-signature/linksquares) | `PR.AA-05` |
| [Lookout](/docs/compliance-connectors/setup/endpoint-detection-and-response/lookout) | `DE.CM-09` |
| [Matillion](/docs/compliance-connectors/setup/data-export/matillion) | `PR.AA-05` |
| [MessageBird](/docs/compliance-connectors/setup/communications-platforms/messagebird) | `PR.AA-05` |
| [Microsoft 365 Copilot](/docs/compliance-connectors/setup/business-applications/microsoft-365-copilot) | `GV.OC-03`, `PR.AA-05` |
| [Nagios](/docs/compliance-connectors/setup/observability/nagios) | `DE.AE-06` |
| [Nessus](/docs/compliance-connectors/setup/vulnerability-scanning/nessus) | `ID.RA-01` |
| [Netdata](/docs/compliance-connectors/setup/observability/netdata) | `PR.AA-05` |
| [Nextiva](/docs/compliance-connectors/setup/communications-platforms/nextiva) | `PR.AA-05` |
| [OpenVAS](/docs/compliance-connectors/setup/vulnerability-scanning/openvas) | `ID.RA-01` |
| [Orca Security](/docs/compliance-connectors/setup/cspm/orca-security) | `ID.RA-01` |
| [pCloud](/docs/compliance-connectors/setup/cloud-storage-provider/pcloud) | `PR.AA-05` |
| [Perplexity](/docs/compliance-connectors/setup/business-applications/perplexity) | `GV.OC-03`, `PR.AA-05` |
| [Phylum](/docs/compliance-connectors/setup/vulnerability-scanning/phylum) | `ID.RA-01` |
| [Pipedream](/docs/compliance-connectors/setup/security-automation/pipedream) | `PR.AA-05` |
| [Plivo](/docs/compliance-connectors/setup/communications-platforms/plivo) | `PR.AA-05` |
| [Postmark](/docs/compliance-connectors/setup/communications-platforms/postmark) | `PR.AA-05` |
| [Precoro](/docs/compliance-connectors/setup/vendor-procurement/precoro) | `PR.AA-05` |
| [Rapid7 InsightCloudSec](/docs/compliance-connectors/setup/cspm/rapid7-insightcloudsec) | `ID.RA-01` |
| [Rapid7 InsightConnect](/docs/compliance-connectors/setup/security-automation/rapid7-insightconnect) | `RS.MA-01` |
| [Raygun](/docs/compliance-connectors/setup/observability/raygun) | `PR.AA-05` |
| [Replicate](/docs/compliance-connectors/setup/business-applications/replicate) | `GV.OC-03`, `PR.AA-05` |
| [Responsive](/docs/compliance-connectors/setup/vendor-procurement/responsive) | `PR.AA-05` |
| [RightSignature](/docs/compliance-connectors/setup/digital-signature/rightsignature) | `PR.AA-05` |
| [Rippling MDM](/docs/compliance-connectors/setup/hris/rippling-mdm) | `ID.AM-01`, `PR.PS-02` |
| [RiskRecon](/docs/compliance-connectors/setup/vendor-procurement/riskrecon) | `ID.RA-01` |
| [RudderStack](/docs/compliance-connectors/setup/data-export/rudderstack) | `PR.AA-05` |
| [SAP Ariba](/docs/compliance-connectors/setup/vendor-procurement/sap-ariba) | `PR.AA-05` |
| [Scalefusion](/docs/compliance-connectors/setup/mdm/scalefusion) | `ID.AM-01`, `PR.PS-02` |
| [Signable](/docs/compliance-connectors/setup/digital-signature/signable) | `PR.AA-05` |
| [Signeasy](/docs/compliance-connectors/setup/digital-signature/signeasy) | `PR.AA-05` |
| [SignWell](/docs/compliance-connectors/setup/digital-signature/signwell) | `PR.AA-05` |
| [Skribble](/docs/compliance-connectors/setup/digital-signature/skribble) | `PR.AA-05` |
| [Sonrai Security](/docs/compliance-connectors/setup/cspm/sonrai-security) | `ID.RA-01` |
| [SOTI MobiControl](/docs/compliance-connectors/setup/mdm/soti-mobicontrol) | `ID.AM-01`, `PR.PS-02` |
| [SpotDraft](/docs/compliance-connectors/setup/digital-signature/spotdraft) | `PR.AA-05` |
| [Stitch](/docs/compliance-connectors/setup/data-export/stitch) | `PR.AA-05` |
| [Storj](/docs/compliance-connectors/setup/cloud-storage-provider/storj) | `PR.DS-01` |
| [Stream Security](/docs/compliance-connectors/setup/cspm/stream-security) | `ID.RA-01` |
| [Sweet Security](/docs/compliance-connectors/setup/cspm/sweet-security) | `ID.RA-01` |
| [Swimlane](/docs/compliance-connectors/setup/security-automation/swimlane) | `RS.MA-01` |
| [Sysdig](/docs/compliance-connectors/setup/cspm/sysdig) | `ID.RA-01` |
| [Tenable Cloud Security](/docs/compliance-connectors/setup/vulnerability-scanning/tenable-cloud-security) | `ID.RA-01` |
| [Together AI](/docs/compliance-connectors/setup/business-applications/together-ai) | `GV.OC-03`, `PR.AA-05` |
| [Twilio](/docs/compliance-connectors/setup/communications-platforms/twilio) | `PR.AA-05` |
| [Uptycs](/docs/compliance-connectors/setup/cspm/uptycs) | `ID.RA-01` |
| [Vonage](/docs/compliance-connectors/setup/communications-platforms/vonage) | `PR.AA-05` |
| [Wallarm](/docs/compliance-connectors/setup/vulnerability-scanning/wallarm) | `ID.RA-01` |
| [Yotta](/docs/compliance-connectors/setup/cloud-infrastructure/yotta) | `DE.CM-01`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-11`, `PR.IR-01`, `PR.PS-04` |
| [Z.ai (Zhipu GLM)](/docs/compliance-connectors/setup/business-applications/z-ai-zhipu-glm) | `GV.OC-03`, `PR.AA-05` |
| [Zip](/docs/compliance-connectors/setup/vendor-procurement/zip) | `PR.AA-05` |
| [Zoho Sign](/docs/compliance-connectors/setup/digital-signature/zoho-sign) | `PR.AA-05` |
| [Zscaler Posture Control](/docs/compliance-connectors/setup/cspm/zscaler-posture-control) | `ID.RA-01` |
## Controls (47)
| Control | Title | Automated tests | Connectors |
| ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | --------------- | ---------- |
| `DE.AE-02` | Potentially adverse events are analyzed to better understand associated activities | 8 | 37 |
| `DE.AE-06` | Information on adverse events is provided to authorized staff and tools | 3 | 6 |
| `DE.CM-01` | Networks and network services are monitored to find potentially adverse events | 36 | 44 |
| `DE.CM-03` | Personnel activity and technology usage are monitored to find potentially adverse events | 4 | 12 |
| `DE.CM-09` | Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events | 64 | 73 |
| `GV.OC-02` | Internal and external stakeholders are understood, and their needs and expectations regarding cybersecurity risk management are understood and considered | 1 | 0 |
| `GV.OC-03` | Legal, regulatory, and contractual requirements regarding cybersecurity, including privacy and civil liberties obligations, are understood and managed | 3 | 17 |
| `GV.OV-01` | Cybersecurity risk management strategy outcomes are reviewed to inform and adjust strategy and direction | 1 | 0 |
| `GV.PO-01` | Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced | 2 | 0 |
| `GV.PO-02` | Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission | 1 | 0 |
| `GV.RR-02` | Roles, responsibilities, and authorities related to cybersecurity risk management are established, communicated, understood, and enforced | 3 | 2 |
| `GV.RR-04` | Cybersecurity is included in human resources practices | 7 | 18 |
| `GV.SC-04` | Suppliers are known and prioritized by criticality | 3 | 3 |
| `GV.SC-05` | Requirements to address cybersecurity risks in supply chains are established, prioritized, and integrated into contracts and other types of agreements with suppliers and other relevant third parties | 6 | 6 |
| `GV.SC-07` | The risks posed by a supplier, their products and services, and other third parties are understood, recorded, prioritized, assessed, responded to, and monitored over the course of the relationship | 3 | 0 |
| `ID.AM-01` | Inventories of hardware managed by the organization are maintained | 4 | 33 |
| `ID.AM-02` | Inventories of software, services, and systems managed by the organization are maintained | 6 | 15 |
| `ID.AM-05` | Assets are prioritized based on classification, criticality, resources, and impact on the mission | 1 | 0 |
| `ID.AM-07` | Inventories of data and corresponding metadata for designated data types are maintained | 1 | 7 |
| `ID.IM-02` | Improvements are identified from security tests and exercises, including those done in coordination with suppliers and relevant third parties | 5 | 3 |
| `ID.IM-03` | Improvements are identified from execution of operational processes, procedures, and activities | 1 | 18 |
| `ID.IM-04` | Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved | 1 | 2 |
| `ID.RA-01` | Vulnerabilities in assets are identified, validated, and recorded | 43 | 95 |
| `ID.RA-05` | Threats, vulnerabilities, likelihoods, and impacts are used to understand inherent risk and inform risk response prioritization | 2 | 0 |
| `ID.RA-06` | Risk responses are chosen, prioritized, planned, tracked, and communicated | 12 | 38 |
| `ID.RA-07` | Changes and exceptions are managed, assessed for risk impact, recorded, and tracked | 1 | 0 |
| `ID.RA-09` | The authenticity and integrity of hardware and software are assessed prior to acquisition and use | 1 | 0 |
| `PR.AA-01` | Identities and credentials for authorized users, services, and hardware are managed by the organization | 67 | 256 |
| `PR.AA-03` | Users, services, and hardware are authenticated | 43 | 110 |
| `PR.AA-05` | Access permissions, entitlements, and authorizations are defined in a policy, managed, enforced, and reviewed, and incorporate the principles of least privilege and separation of duties | 115 | 320 |
| `PR.AT-01` | Personnel are provided with awareness and training so that they possess the knowledge and skills to perform general tasks with cybersecurity risks in mind | 4 | 7 |
| `PR.AT-02` | Individuals in specialized roles are provided with awareness and training so that they possess the knowledge and skills to perform relevant tasks with cybersecurity risks in mind | 2 | 1 |
| `PR.DS-01` | The confidentiality, integrity, and availability of data-at-rest are protected | 79 | 62 |
| `PR.DS-02` | The confidentiality, integrity, and availability of data-in-transit are protected | 49 | 32 |
| `PR.DS-11` | Backups of data are created, protected, maintained, and tested | 50 | 37 |
| `PR.IR-01` | Networks and environments are protected from unauthorized logical access and usage | 65 | 51 |
| `PR.IR-03` | Mechanisms are implemented to achieve resilience requirements in normal and adverse situations | 7 | 15 |
| `PR.PS-01` | Configuration management practices are established and applied | 62 | 71 |
| `PR.PS-02` | Software is maintained, replaced, and removed commensurate with risk | 22 | 53 |
| `PR.PS-04` | Log records are generated and made available for continuous monitoring | 48 | 36 |
| `PR.PS-06` | Secure software development practices are integrated, and their performance is monitored throughout the software development life cycle | 12 | 11 |
| `RS.AN-03` | Analysis is performed to establish what has taken place during an incident and the root cause of the incident | 1 | 2 |
| `RS.CO-02` | Internal and external stakeholders are notified of incidents | 4 | 11 |
| `RS.MA-01` | The incident response plan is executed in coordination with relevant third parties once an incident is declared | 6 | 14 |
| `RS.MA-02` | Incident reports are triaged and validated | 1 | 18 |
| `RS.MA-03` | Incidents are categorized and prioritized | 5 | 25 |
| `RS.MI-02` | Incidents are eradicated | 5 | 48 |
# PCI DSS and connectors (/docs/framework-connectors/pci-dss)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard's automated tests map to **47** controls of PCI DSS v4.0. **658** tests apply: 626 read a connected system, and 32 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
In the framework library: [PCI DSS v4.0](/docs/frameworks/international/pci-dss), with what a scan checks, the controls and the policy templates.
## How to connect for this framework
1. Connect the systems you run from the table below. Each connector links to its setup steps.
2. Open the framework on **Compliance › Frameworks**, then its **Connectors** tab: it lists the connectors that answer this framework's tests, which of them you have connected, and whether each connection is healthy.
3. Tests run on their schedule, or straight away with **Run now** on **Compliance › Tests**. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
## Connectors with automated evidence (343)
| Connector | Controls it provides evidence for | Tests |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [Microsoft Azure](/docs/compliance-connectors/setup/cloud-infrastructure/microsoft-azure) (also Microsoft Entra ID, Azure Government) | `1.3.1`, `10.2.1`, `10.3.2`, `10.4.1`, `10.5.1`, `11.3.1`, `11.5.1`, `11.5.2`, `2.2.1`, `3.5.1`, `3.7.4`, `4.2.1`, `5.2.1`, `6.3.3`, `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.2.8`, `8.4.1`, `8.4.2`, `8.6.3` | 127 |
| [Amazon Web Services](/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services) (also AWS GovCloud, AWS CodeCommit, AWS Inspector, Amazon CloudWatch, Amazon S3, AWS Security Hub) | `1.3.1`, `10.2.1`, `10.3.2`, `10.5.1`, `11.3.1`, `11.5.1`, `11.5.2`, `3.5.1`, `3.7.4`, `4.2.1`, `6.3.1`, `6.3.3`, `6.4.2`, `6.5.1`, `7.2.1`, `7.2.2`, `8.2.6`, `8.3.6`, `8.4.1`, `8.4.2`, `8.6.3` | 81 |
| [Google Cloud Platform](/docs/compliance-connectors/setup/cloud-infrastructure/google-cloud-platform) | `1.3.1`, `10.2.1`, `10.3.2`, `10.4.1`, `10.5.1`, `11.3.1`, `11.5.2`, `2.2.1`, `3.5.1`, `3.7.4`, `4.2.1`, `6.3.3`, `6.5.1`, `7.2.1`, `7.2.2`, `8.2.6`, `8.4.2`, `8.6.3` | 100 |
| [Google Workspace](/docs/compliance-connectors/setup/identity-and-sso/google-workspace) (also Google Cloud Identity, Google SSO) | `1.5.1`, `10.4.1`, `12.5.1`, `3.5.1`, `5.2.1`, `5.4.1`, `6.3.3`, `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.2.8`, `8.3.4`, `8.3.6`, `8.4.1`, `8.4.2` | 22 |
| [Oracle Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/oracle-cloud) (also Oracle Cloud Government) | `1.3.1`, `10.2.1`, `10.4.1`, `10.5.1`, `11.3.1`, `11.5.1`, `2.2.1`, `3.5.1`, `3.7.4`, `4.2.1`, `7.2.1`, `7.2.2`, `8.2.1`, `8.2.6`, `8.3.6`, `8.4.2`, `8.6.3` | 56 |
| [GitHub](/docs/compliance-connectors/setup/version-control/github) (also GitHub Enterprise, GitHub Issues) | `10.5.1`, `12.10.1`, `12.10.6`, `6.2.4`, `6.3.1`, `6.3.2`, `6.3.3`, `6.5.1`, `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.4.2`, `8.6.3` | 42 |
| [GitLab](/docs/compliance-connectors/setup/version-control/gitlab) (also GitLab Issues, GitLab Self-Managed) | `10.5.1`, `12.10.1`, `12.10.6`, `6.2.4`, `6.3.1`, `6.3.2`, `6.3.3`, `6.5.1`, `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 38 |
| [JumpCloud](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud) (also JumpCloud MDM, JumpCloud SSO) | `1.5.1`, `12.5.1`, `3.5.1`, `5.2.1`, `6.3.3`, `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.2.8`, `8.3.4`, `8.3.6`, `8.4.2`, `8.6.3` | 15 |
| [Auth0](/docs/compliance-connectors/setup/identity-and-sso/auth0) (also Auth0 SSO) | `10.5.1`, `11.5.1`, `7.2.2`, `7.2.4`, `8.2.1`, `8.2.5`, `8.2.6`, `8.2.8`, `8.3.4`, `8.3.6`, `8.4.1`, `8.4.2` | 12 |
| [Azure DevOps](/docs/compliance-connectors/setup/version-control/azure-devops) | `12.10.1`, `12.10.6`, `6.2.4`, `6.3.1`, `6.3.2`, `6.3.3`, `6.5.1`, `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.6.3` | 25 |
| [Okta](/docs/compliance-connectors/setup/identity-and-sso/okta) (also Okta SSO) | `10.5.1`, `11.5.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.2.8`, `8.3.4`, `8.3.6`, `8.4.1`, `8.4.2`, `8.6.3` | 14 |
| [OVHcloud](/docs/compliance-connectors/setup/cloud-infrastructure/ovhcloud) | `1.3.1`, `10.2.1`, `10.5.1`, `11.3.1`, `3.5.1`, `3.7.4`, `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 21 |
| [Hetzner](/docs/compliance-connectors/setup/cloud-infrastructure/hetzner) | `1.3.1`, `10.2.1`, `10.5.1`, `11.3.1`, `3.5.1`, `3.7.4`, `4.2.1`, `7.2.1`, `7.2.2`, `8.4.2`, `8.6.3` | 13 |
| [Alibaba Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/alibaba-cloud) | `1.3.1`, `10.2.1`, `3.5.1`, `3.7.4`, `4.2.1`, `7.2.2`, `8.3.6`, `8.4.2`, `8.6.3` | 19 |
| [Bitbucket](/docs/compliance-connectors/setup/version-control/bitbucket) | `6.2.4`, `6.3.1`, `6.3.2`, `6.5.1`, `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 18 |
| [Cloudflare](/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare) | `10.2.1`, `4.2.1`, `5.4.1`, `6.4.2`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 13 |
| [IBM Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/ibm-cloud) | `1.3.1`, `10.2.1`, `3.7.4`, `7.2.2`, `7.2.4`, `8.2.5`, `8.2.8`, `8.4.2`, `8.6.3` | 17 |
| [Keycloak](/docs/compliance-connectors/setup/identity-and-sso/keycloak) | `10.5.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.2.8`, `8.3.4`, `8.3.6`, `8.4.2` | 7 |
| [Kubernetes](/docs/compliance-connectors/setup/cloud-infrastructure/kubernetes) (also Gatekeeper OPA, Kyverno) | `1.3.1`, `10.2.1`, `2.2.1`, `3.5.1`, `4.2.1`, `6.5.1`, `7.2.2`, `8.6.3` | 48 |
| [OneLogin](/docs/compliance-connectors/setup/identity-and-sso/onelogin) (also OneLogin SSO) | `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.2.8`, `8.3.4`, `8.3.6`, `8.4.2` | 7 |
| [CrowdStrike Falcon](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon) | `12.10.1`, `5.2.1`, `5.3.1`, `5.3.5`, `6.3.3`, `7.2.4`, `8.2.5` | 15 |
| [Datadog](/docs/compliance-connectors/setup/observability/datadog) (also Datadog CSM) | `10.4.1`, `10.5.1`, `11.3.1`, `2.2.1`, `6.3.3`, `7.2.4`, `8.2.5` | 10 |
| [MongoDB Atlas](/docs/compliance-connectors/setup/infrastructure/mongodb-atlas) | `1.3.1`, `10.2.1`, `3.5.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 7 |
| [PingOne](/docs/compliance-connectors/setup/identity-and-sso/pingone) (also Ping Identity) | `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.3.4`, `8.3.6`, `8.4.2` | 6 |
| [ServiceNow](/docs/compliance-connectors/setup/ticketing/servicenow) | `12.10.1`, `12.10.6`, `6.3.3`, `6.5.1`, `7.2.2`, `7.2.4`, `8.2.5` | 9 |
| [Akamai](/docs/compliance-connectors/setup/cloud-infrastructure/akamai) | `4.2.1`, `6.4.2`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 6 |
| [Asana](/docs/compliance-connectors/setup/ticketing/asana) | `12.10.1`, `12.10.6`, `6.3.3`, `7.2.2`, `7.2.4`, `8.2.5` | 8 |
| [Claude (Anthropic)](/docs/compliance-connectors/setup/business-applications/claude-anthropic) | `10.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 7 |
| [ClickUp](/docs/compliance-connectors/setup/ticketing/clickup) | `12.10.1`, `12.10.6`, `6.3.3`, `7.2.2`, `7.2.4`, `8.2.5` | 8 |
| [ElevenLabs](/docs/compliance-connectors/setup/business-applications/elevenlabs) | `10.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 6 |
| [Fireworks AI](/docs/compliance-connectors/setup/business-applications/fireworks-ai) | `10.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 8 |
| [Heroku](/docs/compliance-connectors/setup/cloud-infrastructure/heroku) | `4.2.1`, `6.3.3`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 7 |
| [Infisical](/docs/compliance-connectors/setup/infrastructure/infisical) | `10.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 8 |
| [Jira](/docs/compliance-connectors/setup/ticketing/jira) | `12.10.1`, `12.10.6`, `6.3.3`, `7.2.1`, `7.2.4`, `8.2.5` | 9 |
| [Linear](/docs/compliance-connectors/setup/ticketing/linear) | `12.10.1`, `12.10.6`, `6.3.3`, `7.2.1`, `7.2.4`, `8.2.5` | 9 |
| [Microsoft Intune](/docs/compliance-connectors/setup/mdm/microsoft-intune) | `1.5.1`, `12.5.1`, `3.5.1`, `5.2.1`, `6.3.3`, `8.2.8` | 8 |
| [Mistral AI](/docs/compliance-connectors/setup/business-applications/mistral-ai) | `10.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 7 |
| [Monday.com](/docs/compliance-connectors/setup/ticketing/monday-com) | `12.10.1`, `12.10.6`, `6.3.3`, `7.2.2`, `7.2.4`, `8.2.5` | 8 |
| [OpenAI API Platform](/docs/compliance-connectors/setup/business-applications/openai-api-platform) | `10.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 8 |
| [Redis Cloud](/docs/compliance-connectors/setup/infrastructure/redis-cloud) | `1.3.1`, `4.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 6 |
| [SentinelOne](/docs/compliance-connectors/setup/endpoint-detection-and-response/sentinelone) | `12.10.1`, `5.2.1`, `5.3.1`, `5.3.5`, `7.2.4`, `8.2.5` | 8 |
| [Shortcut](/docs/compliance-connectors/setup/ticketing/shortcut) | `12.10.1`, `12.10.6`, `6.3.3`, `7.2.2`, `7.2.4`, `8.2.5` | 8 |
| [SigNoz](/docs/compliance-connectors/setup/observability/signoz) | `10.4.1`, `10.5.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.6.3` | 7 |
| [SolarWinds Service Desk](/docs/compliance-connectors/setup/ticketing/solarwinds-service-desk) | `12.10.1`, `12.10.6`, `6.3.3`, `7.2.2`, `7.2.4`, `8.2.5` | 8 |
| [Sophos Intercept X](/docs/compliance-connectors/setup/endpoint-detection-and-response/sophos-intercept-x) | `12.10.1`, `5.2.1`, `5.3.1`, `5.3.5`, `7.2.4`, `8.2.5` | 9 |
| [StackRox](/docs/compliance-connectors/setup/vulnerability-scanning/stackrox) (also Red Hat Advanced Cluster Security) | `10.4.1`, `11.3.1`, `2.2.1`, `6.3.3`, `7.2.2`, `8.6.3` | 9 |
| [Sumo Logic](/docs/compliance-connectors/setup/observability/sumo-logic) | `10.4.1`, `10.5.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 6 |
| [Supabase](/docs/compliance-connectors/setup/infrastructure/supabase) | `1.3.1`, `4.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 6 |
| [YouTrack](/docs/compliance-connectors/setup/ticketing/youtrack) | `12.10.1`, `12.10.6`, `6.3.3`, `7.2.2`, `7.2.4`, `8.2.5` | 8 |
| [Authentik](/docs/compliance-connectors/setup/identity-and-sso/authentik) | `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.4.2` | 5 |
| [ChatGPT](/docs/compliance-connectors/setup/business-applications/chatgpt) | `10.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 5 |
| [Codeberg](/docs/compliance-connectors/setup/version-control/codeberg) | `6.5.1`, `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5` | 6 |
| [Duo Security](/docs/compliance-connectors/setup/identity-and-sso/duo-security) | `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.4.2` | 6 |
| [Elastic Observability](/docs/compliance-connectors/setup/observability/elastic-observability) | `10.4.1`, `10.5.1`, `7.2.2`, `7.2.4`, `8.2.5` | 5 |
| [Fastly](/docs/compliance-connectors/setup/cloud-infrastructure/fastly) | `4.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 5 |
| [Fleet](/docs/compliance-connectors/setup/mdm/fleet) | `1.5.1`, `12.5.1`, `3.5.1`, `6.3.3`, `8.2.8` | 7 |
| [Gitea](/docs/compliance-connectors/setup/version-control/gitea) | `6.5.1`, `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5` | 6 |
| [Grafana](/docs/compliance-connectors/setup/observability/grafana) | `10.4.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.6.3` | 5 |
| [Hugging Face](/docs/compliance-connectors/setup/business-applications/hugging-face) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 7 |
| [Jamf](/docs/compliance-connectors/setup/mdm/jamf) | `1.5.1`, `12.5.1`, `3.5.1`, `6.3.3`, `8.2.8` | 7 |
| [Kandji](/docs/compliance-connectors/setup/mdm/kandji) | `1.5.1`, `12.5.1`, `3.5.1`, `6.3.3`, `8.2.8` | 7 |
| [Kolide](/docs/compliance-connectors/setup/mdm/kolide) | `1.5.1`, `12.5.1`, `3.5.1`, `6.3.3`, `8.2.8` | 7 |
| [Linode](/docs/compliance-connectors/setup/cloud-infrastructure/linode) | `1.3.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 5 |
| [LogicMonitor](/docs/compliance-connectors/setup/observability/logicmonitor) | `10.4.1`, `12.10.1`, `7.2.2`, `7.2.4`, `8.2.5` | 5 |
| [Logz.io](/docs/compliance-connectors/setup/observability/logz-io) | `10.4.1`, `10.5.1`, `7.2.2`, `7.2.4`, `8.2.5` | 5 |
| [Microsoft Defender for Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/microsoft-defender-for-endpoint) | `12.10.1`, `5.2.1`, `5.3.1`, `5.3.5`, `6.3.3` | 12 |
| [Mosyle](/docs/compliance-connectors/setup/mdm/mosyle) | `1.5.1`, `12.5.1`, `3.5.1`, `6.3.3`, `8.2.8` | 8 |
| [OpenRouter](/docs/compliance-connectors/setup/business-applications/openrouter) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 6 |
| [Oracle Identity](/docs/compliance-connectors/setup/identity-and-sso/oracle-identity) | `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.4.2` | 5 |
| [PlanetScale](/docs/compliance-connectors/setup/infrastructure/planetscale) | `6.5.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 5 |
| [Scaleway](/docs/compliance-connectors/setup/cloud-infrastructure/scaleway) | `1.3.1`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3` | 5 |
| [Sentry](/docs/compliance-connectors/setup/observability/sentry) | `3.5.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 5 |
| [SimpleMDM](/docs/compliance-connectors/setup/mdm/simplemdm) | `1.5.1`, `12.5.1`, `3.5.1`, `6.3.3`, `8.2.8` | 5 |
| [Snowflake](/docs/compliance-connectors/setup/data-export/snowflake) | `1.3.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 5 |
| [Splunk](/docs/compliance-connectors/setup/observability/splunk) | `10.4.1`, `10.5.1`, `7.2.2`, `7.2.4`, `8.2.5` | 5 |
| [Terraform Cloud](/docs/compliance-connectors/setup/infrastructure/terraform-cloud) | `6.5.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 5 |
| [Airtable](/docs/compliance-connectors/setup/ticketing/airtable) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Cisco Meraki SM](/docs/compliance-connectors/setup/mdm/cisco-meraki-sm) | `12.5.1`, `3.5.1`, `6.3.3`, `8.2.8` | 6 |
| [Cisco Secure Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/cisco-secure-endpoint) | `12.10.1`, `5.2.1`, `5.3.1`, `6.3.3` | 6 |
| [ClickHouse](/docs/compliance-connectors/setup/data-export/clickhouse) | `1.3.1`, `7.2.2`, `7.2.4`, `8.2.5` | 4 |
| [Cobalt](/docs/compliance-connectors/setup/vulnerability-scanning/cobalt) | `11.3.1`, `11.4.2`, `11.4.3`, `6.3.3` | 3 |
| [Docker](/docs/compliance-connectors/setup/infrastructure/docker) | `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5` | 4 |
| [env0](/docs/compliance-connectors/setup/infrastructure/env0) | `6.5.1`, `7.2.2`, `7.2.4`, `8.2.5` | 4 |
| [Fly.io](/docs/compliance-connectors/setup/cloud-infrastructure/fly-io) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [FusionAuth](/docs/compliance-connectors/setup/identity-and-sso/fusionauth) | `7.2.4`, `8.2.5`, `8.2.6`, `8.4.2` | 4 |
| [Gerrit](/docs/compliance-connectors/setup/version-control/gerrit) | `6.5.1`, `7.2.2`, `7.2.4`, `8.2.5` | 5 |
| [Huntress](/docs/compliance-connectors/setup/endpoint-detection-and-response/huntress) | `12.10.1`, `5.2.1`, `5.3.1`, `5.3.5` | 6 |
| [IBM Verify](/docs/compliance-connectors/setup/identity-and-sso/ibm-verify) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Ivanti Neurons](/docs/compliance-connectors/setup/mdm/ivanti-neurons) | `12.5.1`, `3.5.1`, `6.3.3`, `8.2.8` | 6 |
| [Logto](/docs/compliance-connectors/setup/identity-and-sso/logto) | `7.2.2`, `8.3.4`, `8.3.6`, `8.4.2` | 4 |
| [Looker](/docs/compliance-connectors/setup/data-export/looker) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Mailgun](/docs/compliance-connectors/setup/communications-platforms/mailgun) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Make](/docs/compliance-connectors/setup/security-automation/make) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Mattermost](/docs/compliance-connectors/setup/communications-platforms/mattermost) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Miradore](/docs/compliance-connectors/setup/mdm/miradore) | `12.5.1`, `3.5.1`, `6.3.3`, `8.2.8` | 6 |
| [New Relic](/docs/compliance-connectors/setup/observability/new-relic) | `10.4.1`, `10.5.1`, `7.2.4`, `8.2.5` | 4 |
| [Nextcloud](/docs/compliance-connectors/setup/cloud-storage-provider/nextcloud) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [OpenStack](/docs/compliance-connectors/setup/cloud-infrastructure/openstack) | `1.3.1`, `12.10.1`, `7.2.1`, `7.2.2` | 4 |
| [ownCloud](/docs/compliance-connectors/setup/cloud-storage-provider/owncloud) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Platform.sh](/docs/compliance-connectors/setup/cloud-infrastructure/platform-sh) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Pulumi](/docs/compliance-connectors/setup/infrastructure/pulumi) (also Pulumi Cloud) | `2.2.1`, `7.2.2`, `7.2.4`, `8.2.5` | 4 |
| [Railway](/docs/compliance-connectors/setup/cloud-infrastructure/railway) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Redmine](/docs/compliance-connectors/setup/ticketing/redmine) | `12.10.1`, `12.10.6`, `6.3.3`, `8.2.5` | 5 |
| [Render](/docs/compliance-connectors/setup/cloud-infrastructure/render) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Rollbar](/docs/compliance-connectors/setup/observability/rollbar) | `10.4.1`, `7.2.2`, `7.2.4`, `8.2.5` | 4 |
| [Salesforce](/docs/compliance-connectors/setup/crm/salesforce) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Site24x7](/docs/compliance-connectors/setup/observability/site24x7) | `10.4.1`, `7.2.2`, `7.2.4`, `8.2.5` | 4 |
| [Slack](/docs/compliance-connectors/setup/communications-platforms/slack) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Vercel](/docs/compliance-connectors/setup/cloud-infrastructure/vercel) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [VMware](/docs/compliance-connectors/setup/cloud-infrastructure/vmware) | `10.2.1`, `12.10.1`, `2.2.1`, `8.2.6` | 6 |
| [VMware Workspace ONE](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-workspace-one) | `12.5.1`, `3.5.1`, `6.3.3`, `8.2.8` | 6 |
| [Vultr](/docs/compliance-connectors/setup/cloud-infrastructure/vultr) | `1.3.1`, `7.2.2`, `7.2.4`, `8.2.5` | 4 |
| [xAI](/docs/compliance-connectors/setup/business-applications/xai) | `10.2.1`, `7.2.4`, `8.4.2`, `8.6.3` | 4 |
| [Zabbix](/docs/compliance-connectors/setup/observability/zabbix) | `10.4.1`, `7.2.2`, `7.2.4`, `8.2.5` | 4 |
| [Zendesk](/docs/compliance-connectors/setup/ticketing/zendesk) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Zitadel](/docs/compliance-connectors/setup/identity-and-sso/zitadel) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [Zoom](/docs/compliance-connectors/setup/communications-platforms/zoom) | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [ActiveCampaign](/docs/compliance-connectors/setup/crm/activecampaign) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Adobe Acrobat Sign](/docs/compliance-connectors/setup/digital-signature/adobe-acrobat-sign) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Aha!](/docs/compliance-connectors/setup/ticketing/aha) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Airbyte](/docs/compliance-connectors/setup/data-export/airbyte) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Ansible](/docs/compliance-connectors/setup/infrastructure/ansible) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Aptible](/docs/compliance-connectors/setup/cloud-infrastructure/aptible) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Ashby](/docs/compliance-connectors/setup/hris/ashby) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Assembla](/docs/compliance-connectors/setup/version-control/assembla) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Attio](/docs/compliance-connectors/setup/crm/attio) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Basecamp](/docs/compliance-connectors/setup/ticketing/basecamp) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Beanstalk](/docs/compliance-connectors/setup/version-control/beanstalk) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Better Stack](/docs/compliance-connectors/setup/observability/better-stack) | `10.4.1`, `10.5.1`, `12.10.1` | 3 |
| [Bitdefender GravityZone](/docs/compliance-connectors/setup/endpoint-detection-and-response/bitdefender-gravityzone) | `12.10.1`, `5.2.1`, `5.3.1` | 5 |
| [BoldSign](/docs/compliance-connectors/setup/digital-signature/boldsign) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Box](/docs/compliance-connectors/setup/cloud-storage-provider/box) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Census](/docs/compliance-connectors/setup/data-export/census) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Check Point CloudGuard](/docs/compliance-connectors/setup/cspm/check-point-cloudguard) | `11.3.1`, `2.2.1`, `6.3.3` | 3 |
| [Citrix ShareFile](/docs/compliance-connectors/setup/cloud-storage-provider/citrix-sharefile) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Close](/docs/compliance-connectors/setup/crm/close) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Cloudflare Access](/docs/compliance-connectors/setup/identity-and-sso/cloudflare-access) | `7.2.4`, `8.2.5`, `8.4.2` | 3 |
| [Coralogix](/docs/compliance-connectors/setup/observability/coralogix) | `10.4.1`, `7.2.4`, `8.2.5` | 3 |
| [Cortex XDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/cortex-xdr) | `12.10.1`, `5.2.1`, `5.3.1` | 5 |
| [Coupa](/docs/compliance-connectors/setup/vendor-procurement/coupa) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [CrowdStrike Falcon Cloud](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon-cloud) | `11.3.1`, `2.2.1`, `6.3.3` | 3 |
| [Cybereason](/docs/compliance-connectors/setup/endpoint-detection-and-response/cybereason) | `12.10.1`, `5.2.1`, `5.3.1` | 5 |
| [Databricks](/docs/compliance-connectors/setup/data-export/databricks) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Deep Instinct](/docs/compliance-connectors/setup/endpoint-detection-and-response/deep-instinct) | `12.10.1`, `5.2.1`, `5.3.1` | 4 |
| [Dialpad](/docs/compliance-connectors/setup/communications-platforms/dialpad) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [DigitalOcean](/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean) | `1.3.1`, `4.2.1`, `6.3.3` | 6 |
| [DocuSign](/docs/compliance-connectors/setup/digital-signature/docusign) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Dropbox](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Dropbox Sign](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox-sign) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Dynatrace](/docs/compliance-connectors/setup/observability/dynatrace) | `10.4.1`, `7.2.4`, `8.2.5` | 3 |
| [Egnyte](/docs/compliance-connectors/setup/cloud-storage-provider/egnyte) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Elastic Security](/docs/compliance-connectors/setup/endpoint-detection-and-response/elastic-security) | `12.10.1`, `5.2.1`, `5.3.1` | 5 |
| [ESET Protect](/docs/compliance-connectors/setup/endpoint-detection-and-response/eset-protect) | `12.10.1`, `5.2.1`, `5.3.1` | 4 |
| [Figma](/docs/compliance-connectors/setup/business-applications/figma) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Fivetran](/docs/compliance-connectors/setup/data-export/fivetran) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Fortinet FortiEDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/fortinet-fortiedr) | `12.10.1`, `5.2.1`, `5.3.1` | 5 |
| [Freshdesk](/docs/compliance-connectors/setup/ticketing/freshdesk) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Freshservice](/docs/compliance-connectors/setup/ticketing/freshservice) | `12.10.1`, `6.3.3`, `8.2.5` | 4 |
| [Front](/docs/compliance-connectors/setup/communications-platforms/front) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [GoDaddy](/docs/compliance-connectors/setup/cloud-infrastructure/godaddy) | `5.4.1`, `7.2.4`, `8.4.2` | 3 |
| [GoHighLevel](/docs/compliance-connectors/setup/crm/gohighlevel) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [GoTo Connect](/docs/compliance-connectors/setup/communications-platforms/goto-connect) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Greenhouse](/docs/compliance-connectors/setup/hris/greenhouse) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Hevo Data](/docs/compliance-connectors/setup/data-export/hevo-data) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [HubSpot](/docs/compliance-connectors/setup/crm/hubspot) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Insightly](/docs/compliance-connectors/setup/crm/insightly) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Instana](/docs/compliance-connectors/setup/observability/instana) | `10.4.1`, `7.2.4`, `8.2.5` | 3 |
| [Jamf Protect](/docs/compliance-connectors/setup/endpoint-detection-and-response/jamf-protect) | `12.10.1`, `5.2.1`, `5.3.1` | 4 |
| [Jira Service Management](/docs/compliance-connectors/setup/ticketing/jira-service-management) | `12.10.1`, `12.10.6`, `6.5.1` | 3 |
| [Kaspersky Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/kaspersky-endpoint) | `12.10.1`, `5.2.1`, `5.3.1` | 5 |
| [Keap](/docs/compliance-connectors/setup/crm/keap) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Lever](/docs/compliance-connectors/setup/hris/lever) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Loopio](/docs/compliance-connectors/setup/vendor-procurement/loopio) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [ManageEngine](/docs/compliance-connectors/setup/mdm/manageengine) | `12.5.1`, `3.5.1`, `6.3.3` | 5 |
| [Microsoft Dynamics 365](/docs/compliance-connectors/setup/crm/microsoft-dynamics-365) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [n8n](/docs/compliance-connectors/setup/security-automation/n8n) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Netlify](/docs/compliance-connectors/setup/cloud-infrastructure/netlify) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [NinjaOne](/docs/compliance-connectors/setup/mdm/ninjaone) | `12.5.1`, `3.5.1`, `6.3.3` | 5 |
| [Nutshell](/docs/compliance-connectors/setup/crm/nutshell) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [OpenPhone](/docs/compliance-connectors/setup/communications-platforms/openphone) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Opsgenie Alerts](/docs/compliance-connectors/setup/ticketing/opsgenie-alerts) | `12.10.1`, `7.2.4`, `8.2.5` | 5 |
| [PagerDuty](/docs/compliance-connectors/setup/ticketing/pagerduty) | `12.10.1`, `7.2.4`, `8.2.5` | 6 |
| [PandaDoc](/docs/compliance-connectors/setup/digital-signature/pandadoc) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Pipedrive](/docs/compliance-connectors/setup/crm/pipedrive) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Productboard](/docs/compliance-connectors/setup/ticketing/productboard) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Proxmox](/docs/compliance-connectors/setup/cloud-infrastructure/proxmox) | `12.10.1`, `7.2.2`, `8.4.2` | 3 |
| [Qovery](/docs/compliance-connectors/setup/cloud-infrastructure/qovery) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Ramp](/docs/compliance-connectors/setup/vendor-procurement/ramp) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Rancher](/docs/compliance-connectors/setup/cloud-infrastructure/rancher) | `7.2.1`, `7.2.2`, `8.2.5` | 3 |
| [Red Canary](/docs/compliance-connectors/setup/endpoint-detection-and-response/red-canary) | `12.10.1`, `5.2.1`, `5.3.1` | 4 |
| [Red Hat OpenShift](/docs/compliance-connectors/setup/cloud-infrastructure/red-hat-openshift) | `10.2.1`, `2.2.1`, `7.2.2` | 5 |
| [RingCentral](/docs/compliance-connectors/setup/identity-and-sso/ringcentral) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Rocket.Chat](/docs/compliance-connectors/setup/communications-platforms/rocket-chat) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Segment](/docs/compliance-connectors/setup/data-export/segment) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [SendGrid](/docs/compliance-connectors/setup/communications-platforms/sendgrid) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [SignRequest](/docs/compliance-connectors/setup/digital-signature/signrequest) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Smartsheet](/docs/compliance-connectors/setup/ticketing/smartsheet) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Spacelift](/docs/compliance-connectors/setup/infrastructure/spacelift) | `6.5.1`, `7.2.4`, `8.2.5` | 3 |
| [Spaceship](/docs/compliance-connectors/setup/cloud-infrastructure/spaceship) | `5.4.1`, `7.2.4`, `8.4.2` | 3 |
| [SugarCRM](/docs/compliance-connectors/setup/crm/sugarcrm) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Symantec Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/symantec-endpoint) | `12.10.1`, `5.2.1`, `5.3.1` | 5 |
| [Tanium](/docs/compliance-connectors/setup/endpoint-detection-and-response/tanium) | `12.10.1`, `5.2.1`, `5.3.1` | 4 |
| [Teamwork](/docs/compliance-connectors/setup/ticketing/teamwork) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Tines](/docs/compliance-connectors/setup/security-automation/tines) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Trellix](/docs/compliance-connectors/setup/endpoint-detection-and-response/trellix) | `12.10.1`, `5.2.1`, `5.3.1` | 4 |
| [Trello](/docs/compliance-connectors/setup/ticketing/trello) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Trend Micro Apex One](/docs/compliance-connectors/setup/endpoint-detection-and-response/trend-micro-apex-one) | `12.10.1`, `5.2.1`, `5.3.1` | 5 |
| [UpCloud](/docs/compliance-connectors/setup/cloud-infrastructure/upcloud) | `1.3.1`, `7.2.4`, `8.2.5` | 3 |
| [VMware Carbon Black](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-carbon-black) | `12.10.1`, `5.2.1`, `5.3.1` | 5 |
| [Vtiger](/docs/compliance-connectors/setup/crm/vtiger) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Webex](/docs/compliance-connectors/setup/communications-platforms/webex) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [WithSecure](/docs/compliance-connectors/setup/endpoint-detection-and-response/withsecure) | `12.10.1`, `5.2.1`, `5.3.1` | 5 |
| [Workable](/docs/compliance-connectors/setup/hris/workable) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Workato](/docs/compliance-connectors/setup/security-automation/workato) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Wrike](/docs/compliance-connectors/setup/ticketing/wrike) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Yousign](/docs/compliance-connectors/setup/digital-signature/yousign) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Zendesk Sell](/docs/compliance-connectors/setup/ticketing/zendesk-sell) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Zoho CRM](/docs/compliance-connectors/setup/crm/zoho-crm) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [Zoho Desk](/docs/compliance-connectors/setup/ticketing/zoho-desk) | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [15Five](/docs/compliance-connectors/setup/hris/15five) | `7.2.4`, `8.2.5` | 2 |
| [1Password](/docs/compliance-connectors/setup/identity-and-sso/1password) | `7.2.4`, `8.2.5` | 2 |
| [Action1](/docs/compliance-connectors/setup/mdm/action1) | `12.5.1`, `6.3.3` | 2 |
| [Aikido Security](/docs/compliance-connectors/setup/vulnerability-scanning/aikido-security) | `11.3.1`, `6.3.3` | 4 |
| [Aircall](/docs/compliance-connectors/setup/communications-platforms/aircall) | `7.2.4`, `8.2.5` | 2 |
| [Amplitude](/docs/compliance-connectors/setup/data-export/amplitude) | `7.2.4`, `8.2.5` | 2 |
| [Anchore](/docs/compliance-connectors/setup/vulnerability-scanning/anchore) | `11.3.1`, `6.3.3` | 4 |
| [Apollo IO](/docs/compliance-connectors/setup/business-applications/apollo-io) | `7.2.4`, `8.2.5` | 2 |
| [Automox](/docs/compliance-connectors/setup/mdm/automox) | `12.5.1`, `6.3.3` | 4 |
| [Backblaze](/docs/compliance-connectors/setup/cloud-storage-provider/backblaze) | `1.3.1`, `3.5.1` | 2 |
| [Baramundi](/docs/compliance-connectors/setup/mdm/baramundi) | `12.5.1`, `6.3.3` | 4 |
| [Beyond Identity](/docs/compliance-connectors/setup/identity-and-sso/beyond-identity) | `7.2.4`, `8.2.5` | 2 |
| [BitSight](/docs/compliance-connectors/setup/vendor-procurement/bitsight) | `11.3.1`, `6.3.3` | 2 |
| [Brex](/docs/compliance-connectors/setup/vendor-procurement/brex) | `7.2.4`, `8.2.5` | 2 |
| [Bright Security](/docs/compliance-connectors/setup/vulnerability-scanning/bright-security) | `11.3.1`, `6.3.3` | 4 |
| [Bugcrowd](/docs/compliance-connectors/setup/vulnerability-scanning/bugcrowd) | `11.3.1`, `6.3.3` | 2 |
| [Burp Suite](/docs/compliance-connectors/setup/vulnerability-scanning/burp-suite) | `11.3.1`, `6.3.3` | 3 |
| [Canva](/docs/compliance-connectors/setup/business-applications/canva) | `7.2.4`, `8.2.5` | 2 |
| [Capsule](/docs/compliance-connectors/setup/crm/capsule) | `7.2.4`, `8.2.5` | 2 |
| [Check Point Harmony](/docs/compliance-connectors/setup/endpoint-detection-and-response/check-point-harmony) | `5.2.1`, `5.3.1` | 2 |
| [Checkmarx](/docs/compliance-connectors/setup/vulnerability-scanning/checkmarx) | `11.3.1`, `6.3.3` | 4 |
| [Citrix Endpoint Management](/docs/compliance-connectors/setup/mdm/citrix-endpoint-management) | `12.5.1`, `6.3.3` | 4 |
| [Confluence](/docs/compliance-connectors/setup/compliance-as-code/confluence) | `7.2.4`, `8.2.5` | 2 |
| [Contrast Security](/docs/compliance-connectors/setup/vulnerability-scanning/contrast-security) | `11.3.1`, `6.3.3` | 4 |
| [Copper](/docs/compliance-connectors/setup/crm/copper) | `7.2.4`, `8.2.5` | 2 |
| [Culture Amp](/docs/compliance-connectors/setup/hris/culture-amp) | `7.2.4`, `8.2.5` | 2 |
| [dbt Cloud](/docs/compliance-connectors/setup/data-export/dbt-cloud) | `7.2.4`, `8.2.5` | 2 |
| [Dependency-Track](/docs/compliance-connectors/setup/vulnerability-scanning/dependency-track) | `11.3.1`, `6.3.3` | 4 |
| [Detectify](/docs/compliance-connectors/setup/vulnerability-scanning/detectify) | `11.3.1`, `6.3.3` | 3 |
| [Endor Labs](/docs/compliance-connectors/setup/vulnerability-scanning/endor-labs) | `11.3.1`, `6.3.3` | 4 |
| [Escape](/docs/compliance-connectors/setup/vulnerability-scanning/escape) | `11.3.1`, `6.3.3` | 4 |
| [Esper](/docs/compliance-connectors/setup/mdm/esper) | `12.5.1`, `6.3.3` | 2 |
| [folk](/docs/compliance-connectors/setup/crm/folk) | `7.2.4`, `8.2.5` | 2 |
| [ForgeRock](/docs/compliance-connectors/setup/identity-and-sso/forgerock) | `7.2.4`, `8.2.5` | 2 |
| [GitGuardian](/docs/compliance-connectors/setup/vulnerability-scanning/gitguardian) | `11.3.1`, `6.3.3` | 3 |
| [HackerOne](/docs/compliance-connectors/setup/vulnerability-scanning/hackerone) | `11.3.1`, `6.3.3` | 2 |
| [HashiCorp Consul](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-consul) | `2.2.1`, `4.2.1` | 2 |
| [HashiCorp Nomad](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-nomad) | `2.2.1`, `4.2.1` | 2 |
| [HashiCorp Vault](/docs/compliance-connectors/setup/infrastructure/hashicorp-vault) | `10.2.1`, `8.4.2` | 2 |
| [Hexnode](/docs/compliance-connectors/setup/mdm/hexnode) | `12.5.1`, `6.3.3` | 4 |
| [Hightouch](/docs/compliance-connectors/setup/data-export/hightouch) | `7.2.4`, `8.2.5` | 2 |
| [Hive](/docs/compliance-connectors/setup/ticketing/hive) | `7.2.4`, `8.2.5` | 2 |
| [Intercom](/docs/compliance-connectors/setup/communications-platforms/intercom) | `7.2.4`, `8.2.5` | 2 |
| [Intruder](/docs/compliance-connectors/setup/vulnerability-scanning/intruder) | `11.3.1`, `6.3.3` | 4 |
| [Invicti](/docs/compliance-connectors/setup/vulnerability-scanning/invicti) | `11.3.1`, `6.3.3` | 4 |
| [Ironclad](/docs/compliance-connectors/setup/digital-signature/ironclad) | `7.2.4`, `8.2.5` | 2 |
| [JFrog Xray](/docs/compliance-connectors/setup/vulnerability-scanning/jfrog-xray) | `11.3.1`, `6.3.3` | 3 |
| [Lacework](/docs/compliance-connectors/setup/cspm/lacework) | `11.3.1`, `6.3.3` | 3 |
| [Lattice](/docs/compliance-connectors/setup/hris/lattice) | `7.2.4`, `8.2.5` | 2 |
| [Launchpad](/docs/compliance-connectors/setup/version-control/launchpad) | `7.2.4`, `8.2.5` | 2 |
| [Malwarebytes](/docs/compliance-connectors/setup/endpoint-detection-and-response/malwarebytes) | `5.2.1`, `5.3.1` | 3 |
| [Mend](/docs/compliance-connectors/setup/vulnerability-scanning/mend) | `11.3.1`, `6.3.3` | 3 |
| [MinIO](/docs/compliance-connectors/setup/cloud-storage-provider/minio) | `1.3.1`, `3.5.1` | 2 |
| [Miro](/docs/compliance-connectors/setup/communications-platforms/miro) | `7.2.4`, `8.2.5` | 2 |
| [Mixpanel](/docs/compliance-connectors/setup/data-export/mixpanel) | `7.2.4`, `8.2.5` | 2 |
| [Northflank](/docs/compliance-connectors/setup/cloud-infrastructure/northflank) | `7.2.4`, `8.2.5` | 2 |
| [Notion](/docs/compliance-connectors/setup/compliance-as-code/notion) | `7.2.4`, `8.2.5` | 2 |
| [Nucleus Security](/docs/compliance-connectors/setup/vulnerability-scanning/nucleus-security) | `11.3.1`, `6.3.3` | 4 |
| [Nutanix](/docs/compliance-connectors/setup/cloud-infrastructure/nutanix) | `12.10.1`, `7.2.2` | 2 |
| [Oneflow](/docs/compliance-connectors/setup/digital-signature/oneflow) | `7.2.4`, `8.2.5` | 2 |
| [OneSpan Sign](/docs/compliance-connectors/setup/digital-signature/onespan-sign) | `7.2.4`, `8.2.5` | 2 |
| [OneTrust Vendorpedia](/docs/compliance-connectors/setup/vendor-procurement/onetrust-vendorpedia) | `7.2.4`, `8.2.5` | 2 |
| [Opal](/docs/compliance-connectors/setup/user-access-review/opal) | `7.2.4`, `8.2.5` | 2 |
| [Ox Security](/docs/compliance-connectors/setup/vulnerability-scanning/ox-security) | `11.3.1`, `6.3.3` | 4 |
| [Pingdom](/docs/compliance-connectors/setup/observability/pingdom) | `7.2.4`, `8.2.5` | 2 |
| [Portainer](/docs/compliance-connectors/setup/cloud-infrastructure/portainer) | `7.2.1`, `7.2.2` | 2 |
| [Prey](/docs/compliance-connectors/setup/mdm/prey) | `12.5.1`, `6.3.3` | 2 |
| [Prisma Cloud](/docs/compliance-connectors/setup/cspm/prisma-cloud) | `11.3.1`, `6.3.3` | 3 |
| [Probely](/docs/compliance-connectors/setup/vulnerability-scanning/probely) | `11.3.1`, `6.3.3` | 4 |
| [Proofpoint Security Awareness](/docs/compliance-connectors/setup/security-training/proofpoint-security-awareness) | `12.6.1`, `12.6.3.1` | 2 |
| [Prowler](/docs/compliance-connectors/setup/infrastructure/prowler) | `2.2.1`, `6.3.3` | 2 |
| [Qualys](/docs/compliance-connectors/setup/vulnerability-scanning/qualys) | `11.3.1`, `6.3.3` | 4 |
| [Qualys EDR](/docs/compliance-connectors/setup/vulnerability-scanning/qualys-edr) | `12.10.1`, `5.2.1` | 3 |
| [Rapid7 InsightVM](/docs/compliance-connectors/setup/vulnerability-scanning/rapid7-insightvm) | `11.3.1`, `6.3.3` | 4 |
| [Riot](/docs/compliance-connectors/setup/security-training/riot) | `12.6.1`, `12.6.3.1` | 2 |
| [SailPoint](/docs/compliance-connectors/setup/identity-and-sso/sailpoint) | `7.2.4`, `8.2.5` | 3 |
| [Salesflare](/docs/compliance-connectors/setup/crm/salesflare) | `7.2.4`, `8.2.5` | 2 |
| [SecurityScorecard Atlas](/docs/compliance-connectors/setup/vendor-procurement/securityscorecard-atlas) | `11.3.1`, `6.3.3` | 1 |
| [Semgrep](/docs/compliance-connectors/setup/vulnerability-scanning/semgrep) | `11.3.1`, `6.3.3` | 4 |
| [Shuffle](/docs/compliance-connectors/setup/security-automation/shuffle) | `7.2.1`, `8.2.5` | 2 |
| [SignNow](/docs/compliance-connectors/setup/digital-signature/signnow) | `7.2.4`, `8.2.5` | 2 |
| [Snyk](/docs/compliance-connectors/setup/vulnerability-scanning/snyk) | `11.3.1`, `6.3.3` | 4 |
| [Socket](/docs/compliance-connectors/setup/vulnerability-scanning/socket) | `11.3.1`, `6.3.3` | 3 |
| [SonarQube](/docs/compliance-connectors/setup/vulnerability-scanning/sonarqube) | `11.3.1`, `6.3.3` | 4 |
| [StackHawk](/docs/compliance-connectors/setup/vulnerability-scanning/stackhawk) | `11.3.1`, `6.3.3` | 3 |
| [Streak](/docs/compliance-connectors/setup/crm/streak) | `7.2.4`, `8.2.5` | 2 |
| [Telnyx](/docs/compliance-connectors/setup/communications-platforms/telnyx) | `7.2.4`, `8.2.5` | 2 |
| [Tenable](/docs/compliance-connectors/setup/vulnerability-scanning/tenable) | `11.3.1`, `6.3.3` | 4 |
| [ThreatConnect](/docs/compliance-connectors/setup/security-automation/threatconnect) | `7.2.1`, `8.2.5` | 2 |
| [Torii](/docs/compliance-connectors/setup/user-access-review/torii) | `7.2.4`, `8.2.5` | 2 |
| [Tray.io](/docs/compliance-connectors/setup/security-automation/tray-io) | `7.2.4`, `8.2.5` | 2 |
| [Trend Micro Cloud One](/docs/compliance-connectors/setup/cspm/trend-micro-cloud-one) | `2.2.1`, `6.3.3` | 3 |
| [UpGuard Vendor Risk](/docs/compliance-connectors/setup/vendor-procurement/upguard-vendor-risk) | `11.3.1`, `6.3.3` | 2 |
| [Veracode](/docs/compliance-connectors/setup/vulnerability-scanning/veracode) | `11.3.1`, `6.3.3` | 4 |
| [Webroot](/docs/compliance-connectors/setup/endpoint-detection-and-response/webroot) | `5.2.1`, `5.3.1` | 2 |
| [Wiz](/docs/compliance-connectors/setup/cspm/wiz) | `11.3.1`, `6.3.3` | 3 |
| [360Learning](/docs/compliance-connectors/setup/security-training/360learning) | `12.6.1` | 1 |
| [42Gears](/docs/compliance-connectors/setup/mdm/42gears) | `12.5.1` | 1 |
| [AppDynamics](/docs/compliance-connectors/setup/observability/appdynamics) | `10.4.1` | 1 |
| [Chronosphere](/docs/compliance-connectors/setup/observability/chronosphere) | `10.4.1` | 1 |
| [Civo](/docs/compliance-connectors/setup/cloud-infrastructure/civo) | `1.3.1` | 2 |
| [Cortex XSOAR](/docs/compliance-connectors/setup/security-automation/cortex-xsoar) | `12.10.1` | 2 |
| [Cronitor](/docs/compliance-connectors/setup/observability/cronitor) | `10.4.1` | 1 |
| [D3 Security](/docs/compliance-connectors/setup/security-automation/d3-security) | `12.10.1` | 2 |
| [Docebo](/docs/compliance-connectors/setup/security-training/docebo) | `12.6.1` | 1 |
| [Firebase](/docs/compliance-connectors/setup/infrastructure/firebase) | `7.2.1` | 1 |
| [Google Chronicle SOAR](/docs/compliance-connectors/setup/security-automation/google-chronicle-soar) | `12.10.1` | 2 |
| [Gusto](/docs/compliance-connectors/setup/hris/gusto) | `7.2.4` | 1 |
| [IBM QRadar SOAR](/docs/compliance-connectors/setup/security-automation/ibm-qradar-soar) | `12.10.1` | 2 |
| [Immersive Labs](/docs/compliance-connectors/setup/security-training/immersive-labs) | `6.2.2` | 1 |
| [Lessonly](/docs/compliance-connectors/setup/security-training/lessonly) | `12.6.1` | 1 |
| [Prometheus](/docs/compliance-connectors/setup/observability/prometheus) | `10.4.1` | 1 |
| [Rapid7 InsightIDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/rapid7-insightidr) | `12.10.1` | 2 |
| [Setyl](/docs/compliance-connectors/setup/vendor-procurement/setyl) | `12.5.1` | 1 |
| [Splunk SOAR](/docs/compliance-connectors/setup/observability/splunk-soar) | `12.10.1` | 2 |
| [TalentLMS](/docs/compliance-connectors/setup/security-training/talentlms) | `12.6.1` | 1 |
| [Torq](/docs/compliance-connectors/setup/security-automation/torq) | `12.10.1` | 2 |
| [Turbot](/docs/compliance-connectors/setup/cspm/turbot) | `2.2.1` | 1 |
| [Udemy Business](/docs/compliance-connectors/setup/security-training/udemy-business) | `12.6.1` | 1 |
| [Uptime Robot](/docs/compliance-connectors/setup/observability/uptime-robot) | `10.4.1` | 1 |
| [Veza](/docs/compliance-connectors/setup/user-access-review/veza) | `7.2.4` | 1 |
| [VictoriaMetrics](/docs/compliance-connectors/setup/observability/victoriametrics) | `10.4.1` | 1 |
| [Wasabi](/docs/compliance-connectors/setup/cloud-storage-provider/wasabi) | `1.3.1` | 1 |
| [Yardstik](/docs/compliance-connectors/setup/background-check-providers/yardstik) | `12.7.1` | 1 |
## Evidence by attestation (94)
These systems publish no API for what the tests check. Connect them to record the connection, then attest the result; an accepted attestation counts toward the control.
| Connector | Controls |
| --------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| [8x8](/docs/compliance-connectors/setup/communications-platforms/8x8) | `7.2.4` |
| [Acunetix](/docs/compliance-connectors/setup/vulnerability-scanning/acunetix) | `11.3.1`, `6.3.3` |
| [Addigy](/docs/compliance-connectors/setup/mdm/addigy) | `12.5.1` |
| [Affinity](/docs/compliance-connectors/setup/crm/affinity) | `7.2.4` |
| [Airbase](/docs/compliance-connectors/setup/vendor-procurement/airbase) | `7.2.4` |
| [Apiiro](/docs/compliance-connectors/setup/vulnerability-scanning/apiiro) | `11.3.1`, `6.3.3` |
| [Aqua Security](/docs/compliance-connectors/setup/cspm/aqua-security) | `11.3.1`, `6.3.3` |
| [Arctic Wolf](/docs/compliance-connectors/setup/endpoint-detection-and-response/arctic-wolf) | `5.2.1` |
| [Arnica](/docs/compliance-connectors/setup/vulnerability-scanning/arnica) | `11.3.1`, `6.3.3` |
| [Blackpoint Cyber](/docs/compliance-connectors/setup/endpoint-detection-and-response/blackpoint-cyber) | `5.2.1` |
| [Bugsnag](/docs/compliance-connectors/setup/observability/bugsnag) | `7.2.4` |
| [Carta](/docs/compliance-connectors/setup/business-applications/carta) | `7.2.4` |
| [Checkmk](/docs/compliance-connectors/setup/observability/checkmk) | `10.4.1`, `7.2.4` |
| [Cloudanix](/docs/compliance-connectors/setup/cspm/cloudanix) | `11.3.1`, `6.3.3` |
| [Cohere](/docs/compliance-connectors/setup/business-applications/cohere) | `7.2.4` |
| [Concord](/docs/compliance-connectors/setup/digital-signature/concord) | `7.2.4` |
| [Contractbook](/docs/compliance-connectors/setup/digital-signature/contractbook) | `7.2.4` |
| [ContractSafe](/docs/compliance-connectors/setup/digital-signature/contractsafe) | `7.2.4` |
| [CoreStack](/docs/compliance-connectors/setup/cspm/corestack) | `11.3.1`, `6.3.3` |
| [CyberArk](/docs/compliance-connectors/setup/identity-and-sso/cyberark) | `7.2.4`, `8.4.2` |
| [Cynet](/docs/compliance-connectors/setup/endpoint-detection-and-response/cynet) | `5.2.1` |
| [Cyscale](/docs/compliance-connectors/setup/cspm/cyscale) | `11.3.1`, `6.3.3` |
| [Cyware](/docs/compliance-connectors/setup/security-automation/cyware) | `12.10.1` |
| [DeepSeek](/docs/compliance-connectors/setup/business-applications/deepseek) | `7.2.4` |
| [Documenso](/docs/compliance-connectors/setup/digital-signature/documenso) | `7.2.4` |
| [Edgescan](/docs/compliance-connectors/setup/vulnerability-scanning/edgescan) | `11.3.1`, `6.3.3` |
| [Eversign](/docs/compliance-connectors/setup/digital-signature/eversign) | `7.2.4` |
| [Evisort](/docs/compliance-connectors/setup/digital-signature/evisort) | `7.2.4` |
| [Foxit eSign](/docs/compliance-connectors/setup/digital-signature/foxit-esign) | `7.2.4` |
| [Freshsales](/docs/compliance-connectors/setup/crm/freshsales) | `7.2.4` |
| [Gatekeeper](/docs/compliance-connectors/setup/vendor-procurement/gatekeeper) | `7.2.4` |
| [GetAccept](/docs/compliance-connectors/setup/digital-signature/getaccept) | `7.2.4` |
| [GitKraken](/docs/compliance-connectors/setup/version-control/gitkraken) | `7.2.4` |
| [Groq](/docs/compliance-connectors/setup/business-applications/groq) | `7.2.4` |
| [Honeycomb](/docs/compliance-connectors/setup/observability/honeycomb) | `10.4.1` |
| [IBM MaaS360](/docs/compliance-connectors/setup/mdm/ibm-maas360) | `12.5.1` |
| [Juro](/docs/compliance-connectors/setup/digital-signature/juro) | `7.2.4` |
| [Kion](/docs/compliance-connectors/setup/cspm/kion) | `11.3.1`, `6.3.3` |
| [LastPass SSO](/docs/compliance-connectors/setup/identity-and-sso/lastpass-sso) | `7.2.4`, `8.4.2` |
| [Legit Security](/docs/compliance-connectors/setup/vulnerability-scanning/legit-security) | `11.3.1`, `6.3.3` |
| [Lexion](/docs/compliance-connectors/setup/digital-signature/lexion) | `7.2.4` |
| [LinkSquares](/docs/compliance-connectors/setup/digital-signature/linksquares) | `7.2.4` |
| [Lookout](/docs/compliance-connectors/setup/endpoint-detection-and-response/lookout) | `5.2.1` |
| [Matillion](/docs/compliance-connectors/setup/data-export/matillion) | `7.2.4` |
| [MessageBird](/docs/compliance-connectors/setup/communications-platforms/messagebird) | `7.2.4` |
| [Microsoft 365 Copilot](/docs/compliance-connectors/setup/business-applications/microsoft-365-copilot) | `7.2.4` |
| [Nagios](/docs/compliance-connectors/setup/observability/nagios) | `10.4.1` |
| [Nessus](/docs/compliance-connectors/setup/vulnerability-scanning/nessus) | `11.3.1`, `6.3.3` |
| [Netdata](/docs/compliance-connectors/setup/observability/netdata) | `7.2.4` |
| [Nextiva](/docs/compliance-connectors/setup/communications-platforms/nextiva) | `7.2.4` |
| [OpenVAS](/docs/compliance-connectors/setup/vulnerability-scanning/openvas) | `11.3.1`, `6.3.3` |
| [Orca Security](/docs/compliance-connectors/setup/cspm/orca-security) | `11.3.1`, `6.3.3` |
| [pCloud](/docs/compliance-connectors/setup/cloud-storage-provider/pcloud) | `7.2.4` |
| [Perplexity](/docs/compliance-connectors/setup/business-applications/perplexity) | `7.2.4` |
| [Phylum](/docs/compliance-connectors/setup/vulnerability-scanning/phylum) | `11.3.1`, `6.3.3` |
| [Pipedream](/docs/compliance-connectors/setup/security-automation/pipedream) | `7.2.4` |
| [Plivo](/docs/compliance-connectors/setup/communications-platforms/plivo) | `7.2.4` |
| [Postmark](/docs/compliance-connectors/setup/communications-platforms/postmark) | `7.2.4` |
| [Precoro](/docs/compliance-connectors/setup/vendor-procurement/precoro) | `7.2.4` |
| [Rapid7 InsightCloudSec](/docs/compliance-connectors/setup/cspm/rapid7-insightcloudsec) | `11.3.1`, `6.3.3` |
| [Rapid7 InsightConnect](/docs/compliance-connectors/setup/security-automation/rapid7-insightconnect) | `12.10.1` |
| [Raygun](/docs/compliance-connectors/setup/observability/raygun) | `7.2.4` |
| [Replicate](/docs/compliance-connectors/setup/business-applications/replicate) | `7.2.4` |
| [Responsive](/docs/compliance-connectors/setup/vendor-procurement/responsive) | `7.2.4` |
| [RightSignature](/docs/compliance-connectors/setup/digital-signature/rightsignature) | `7.2.4` |
| [Rippling MDM](/docs/compliance-connectors/setup/hris/rippling-mdm) | `12.5.1` |
| [RiskRecon](/docs/compliance-connectors/setup/vendor-procurement/riskrecon) | `11.3.1`, `6.3.3` |
| [RudderStack](/docs/compliance-connectors/setup/data-export/rudderstack) | `7.2.4` |
| [SAP Ariba](/docs/compliance-connectors/setup/vendor-procurement/sap-ariba) | `7.2.4` |
| [Scalefusion](/docs/compliance-connectors/setup/mdm/scalefusion) | `12.5.1` |
| [Signable](/docs/compliance-connectors/setup/digital-signature/signable) | `7.2.4` |
| [Signeasy](/docs/compliance-connectors/setup/digital-signature/signeasy) | `7.2.4` |
| [SignWell](/docs/compliance-connectors/setup/digital-signature/signwell) | `7.2.4` |
| [Skribble](/docs/compliance-connectors/setup/digital-signature/skribble) | `7.2.4` |
| [Sonrai Security](/docs/compliance-connectors/setup/cspm/sonrai-security) | `11.3.1`, `6.3.3` |
| [SOTI MobiControl](/docs/compliance-connectors/setup/mdm/soti-mobicontrol) | `12.5.1` |
| [SpotDraft](/docs/compliance-connectors/setup/digital-signature/spotdraft) | `7.2.4` |
| [Stitch](/docs/compliance-connectors/setup/data-export/stitch) | `7.2.4` |
| [Storj](/docs/compliance-connectors/setup/cloud-storage-provider/storj) | `7.2.1` |
| [Stream Security](/docs/compliance-connectors/setup/cspm/stream-security) | `11.3.1`, `6.3.3` |
| [Sweet Security](/docs/compliance-connectors/setup/cspm/sweet-security) | `11.3.1`, `6.3.3` |
| [Swimlane](/docs/compliance-connectors/setup/security-automation/swimlane) | `12.10.1` |
| [Sysdig](/docs/compliance-connectors/setup/cspm/sysdig) | `11.3.1`, `6.3.3` |
| [Tenable Cloud Security](/docs/compliance-connectors/setup/vulnerability-scanning/tenable-cloud-security) | `11.3.1`, `6.3.3` |
| [Together AI](/docs/compliance-connectors/setup/business-applications/together-ai) | `7.2.4` |
| [Twilio](/docs/compliance-connectors/setup/communications-platforms/twilio) | `7.2.4` |
| [Uptycs](/docs/compliance-connectors/setup/cspm/uptycs) | `11.3.1`, `6.3.3` |
| [Vonage](/docs/compliance-connectors/setup/communications-platforms/vonage) | `7.2.4` |
| [Wallarm](/docs/compliance-connectors/setup/vulnerability-scanning/wallarm) | `11.3.1`, `6.3.3` |
| [Yotta](/docs/compliance-connectors/setup/cloud-infrastructure/yotta) | `1.3.1`, `10.2.1`, `10.5.1`, `11.3.1`, `3.5.1`, `3.7.4`, `7.2.1`, `7.2.2`, `8.4.2`, `8.6.3` |
| [Z.ai (Zhipu GLM)](/docs/compliance-connectors/setup/business-applications/z-ai-zhipu-glm) | `7.2.4` |
| [Zip](/docs/compliance-connectors/setup/vendor-procurement/zip) | `7.2.4` |
| [Zoho Sign](/docs/compliance-connectors/setup/digital-signature/zoho-sign) | `7.2.4` |
| [Zscaler Posture Control](/docs/compliance-connectors/setup/cspm/zscaler-posture-control) | `11.3.1`, `6.3.3` |
## Controls (47)
| Control | Title | Automated tests | Connectors |
| ---------- | --------------------------------------------------------------------------------------------------------------------------------- | --------------- | ---------- |
| `1.3.1` | Inbound traffic to the CDE is restricted to only that which is necessary | 58 | 36 |
| `1.5.1` | Security controls are implemented on computing devices that connect to both untrusted networks and the CDE | 1 | 13 |
| `2.2.1` | Configuration standards are developed, implemented, and maintained | 49 | 24 |
| `3.5.1` | PAN is rendered unreadable anywhere it is stored | 22 | 43 |
| `3.7.4` | Cryptographic keys are changed at the end of their defined cryptoperiod | 21 | 18 |
| `4.2.1` | Strong cryptography protects PAN during transmission over open, public networks | 40 | 27 |
| `5.2.1` | An anti-malware solution is deployed on all system components, except those evaluated as not at risk | 7 | 40 |
| `5.3.1` | The anti-malware solution is kept current via automatic updates | 1 | 25 |
| `5.3.5` | Anti-malware mechanisms cannot be disabled or altered by users unless specifically authorized | 1 | 5 |
| `5.4.1` | Processes and automated mechanisms detect and protect personnel against phishing attacks | 1 | 6 |
| `6.2.2` | Software development personnel are trained at least once every 12 months | 2 | 1 |
| `6.2.4` | Software engineering techniques prevent or mitigate common software attacks | 4 | 8 |
| `6.3.1` | Security vulnerabilities are identified and assigned a risk ranking | 5 | 15 |
| `6.3.2` | An inventory of bespoke and custom software and its third-party components is maintained | 5 | 8 |
| `6.3.3` | System components are protected from known vulnerabilities by installing applicable patches | 40 | 128 |
| `6.4.2` | An automated technical solution detects and prevents web-based attacks for public-facing web applications | 3 | 9 |
| `6.5.1` | Changes to production system components follow established change procedures | 18 | 28 |
| `7.2.1` | An access control model is defined | 44 | 39 |
| `7.2.2` | Access is assigned based on job classification and least privilege | 50 | 186 |
| `7.2.4` | User accounts and access privileges are reviewed at least once every six months | 15 | 276 |
| `8.2.1` | Every user is assigned a unique ID | 2 | 4 |
| `8.2.5` | Access for terminated users is immediately revoked | 14 | 221 |
| `8.2.6` | Inactive user accounts are removed or disabled within 90 days of inactivity | 9 | 35 |
| `8.2.8` | Sessions idle for more than 15 minutes require re-authentication | 3 | 28 |
| `8.3.4` | Invalid authentication attempts are limited (lockout after not more than 10 attempts) | 1 | 16 |
| `8.3.6` | Passwords meet minimum complexity (12 characters, numeric and alphabetic) | 5 | 26 |
| `8.4.1` | MFA for all non-console access into the CDE for personnel with administrative access | 3 | 17 |
| `8.4.2` | MFA for all access into the CDE | 26 | 95 |
| `8.6.3` | Passwords for application and system accounts are protected against misuse | 37 | 48 |
| `10.2.1` | Audit logs are enabled and active for all system components and cardholder data | 52 | 34 |
| `10.3.2` | Audit log files are protected to prevent modifications by individuals | 4 | 11 |
| `10.4.1` | Security-event and critical-component audit logs are reviewed at least once daily | 36 | 37 |
| `10.5.1` | Audit log history is retained for at least 12 months, three months immediately available | 15 | 36 |
| `11.3.1` | Internal vulnerability scans are performed at least once every three months | 21 | 82 |
| `11.4.2` | Internal penetration testing is performed at least once every 12 months and after significant changes | 1 | 1 |
| `11.4.3` | External penetration testing is performed at least once every 12 months and after significant changes | 1 | 1 |
| `11.5.1` | Intrusion-detection and/or intrusion-prevention techniques detect and/or prevent intrusions | 15 | 16 |
| `11.5.2` | A change-detection mechanism alerts personnel to unauthorized modification of critical files | 4 | 11 |
| `12.1.1` | An overall information security policy is established, published, maintained, and disseminated | 2 | 0 |
| `12.1.2` | The information security policy is reviewed at least once every 12 months | 1 | 0 |
| `12.5.1` | An inventory of in-scope system components, with a description of function or use, is maintained and kept current | 5 | 33 |
| `12.6.1` | A formal security awareness program is implemented | 3 | 7 |
| `12.6.3.1` | Security awareness training covers threats such as phishing and social engineering | 1 | 2 |
| `12.7.1` | Potential personnel with access to the CDE are screened prior to hire | 2 | 1 |
| `12.10.1` | An incident response plan exists and is ready to be activated in the event of a suspected or confirmed incident | 18 | 60 |
| `12.10.2` | The incident response plan is reviewed and tested at least once every 12 months | 1 | 0 |
| `12.10.6` | The security incident response plan is modified and evolved according to lessons learned and to incorporate industry developments | 2 | 18 |
# SOC2 and connectors (/docs/framework-connectors/soc2)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Safeguard's automated tests map to **34** controls of SOC2 Trust Services Criteria (2017, revised points of focus 2022). **855** tests apply: 797 read a connected system, and 58 read Safeguard's own records (policies, people, training and devices), so they need no connector. A passing result is evidence toward a control, not proof that the control is met on its own.
The same criteria serve **SOC2 Type 1** and **SOC2 Type 2**.
In the framework library: [SOC2 Type 1](/docs/frameworks/americas/soc2) and [SOC2 Type 2](/docs/frameworks/americas/soc2-type2), with what a scan checks, the controls and the policy templates.
## How to connect for this framework
1. Connect the systems you run from the table below. Each connector links to its setup steps.
2. Open the framework on **Compliance › Frameworks** (**SOC2 Type 1** or **SOC2 Type 2**), then its **Connectors** tab: it lists the connectors that answer this framework's tests, which of them you have connected, and whether each connection is healthy.
3. Tests run on their schedule, or straight away with **Run now** on **Compliance › Tests**. A passing test counts toward its controls once its preview period has ended.
Automated tests are switched on per workspace by the Safeguard team.
## Connectors with automated evidence (360)
| Connector | Controls it provides evidence for | Tests |
| ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [Amazon Web Services](/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services) (also AWS GovCloud, AWS CodeCommit, AWS Inspector, Amazon CloudWatch, Amazon S3, AWS Security Hub) | `A1.1`, `A1.2`, `A1.3`, `C1.1`, `CC2.3`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1`, `CC7.2`, `CC7.3`, `CC7.4`, `CC8.1` | 148 |
| [Google Cloud Platform](/docs/compliance-connectors/setup/cloud-infrastructure/google-cloud-platform) | `A1.1`, `A1.2`, `C1.1`, `CC2.1`, `CC2.3`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC6.8`, `CC7.1`, `CC7.2`, `CC7.3`, `CC8.1` | 114 |
| [Microsoft Azure](/docs/compliance-connectors/setup/cloud-infrastructure/microsoft-azure) (also Microsoft Entra ID, Azure Government) | `A1.1`, `A1.2`, `C1.1`, `CC2.3`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC6.8`, `CC7.1`, `CC7.2`, `CC7.3` | 139 |
| [GitHub](/docs/compliance-connectors/setup/version-control/github) (also GitHub Enterprise, GitHub Issues) | `C1.1`, `CC2.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.8`, `CC7.1`, `CC7.2`, `CC7.3`, `CC7.4`, `CC7.5`, `CC8.1` | 44 |
| [GitLab](/docs/compliance-connectors/setup/version-control/gitlab) (also GitLab Issues, GitLab Self-Managed) | `C1.1`, `CC2.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.7`, `CC7.1`, `CC7.2`, `CC7.3`, `CC7.4`, `CC7.5`, `CC8.1` | 46 |
| [Google Workspace](/docs/compliance-connectors/setup/identity-and-sso/google-workspace) (also Google Cloud Identity, Google SSO) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.5`, `CC6.6`, `CC6.7`, `CC6.8`, `CC7.1`, `CC7.2`, `CC9.2` | 28 |
| [Oracle Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/oracle-cloud) (also Oracle Cloud Government) | `A1.2`, `C1.1`, `CC2.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC6.8`, `CC7.1`, `CC7.2` | 66 |
| [Azure DevOps](/docs/compliance-connectors/setup/version-control/azure-devops) | `C1.1`, `CC2.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5`, `CC8.1` | 25 |
| [Kubernetes](/docs/compliance-connectors/setup/cloud-infrastructure/kubernetes) (also Gatekeeper OPA, Kyverno) | `A1.1`, `C1.1`, `CC6.1`, `CC6.3`, `CC6.6`, `CC6.7`, `CC6.8`, `CC7.2`, `CC8.1` | 49 |
| [Hetzner](/docs/compliance-connectors/setup/cloud-infrastructure/hetzner) | `A1.2`, `C1.1`, `CC6.1`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1`, `CC7.2` | 15 |
| [Jamf](/docs/compliance-connectors/setup/mdm/jamf) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.6`, `CC6.7`, `CC6.8`, `CC7.1` | 9 |
| [Microsoft Intune](/docs/compliance-connectors/setup/mdm/microsoft-intune) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.6`, `CC6.7`, `CC6.8`, `CC7.1` | 10 |
| [OVHcloud](/docs/compliance-connectors/setup/cloud-infrastructure/ovhcloud) | `A1.2`, `C1.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC7.1`, `CC7.2` | 27 |
| [StackRox](/docs/compliance-connectors/setup/vulnerability-scanning/stackrox) (also Red Hat Advanced Cluster Security) | `CC4.1`, `CC6.1`, `CC6.3`, `CC6.7`, `CC6.8`, `CC7.1`, `CC7.2`, `CC7.3` | 13 |
| [Bitbucket](/docs/compliance-connectors/setup/version-control/bitbucket) | `C1.1`, `CC2.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC7.1`, `CC8.1` | 18 |
| [Cisco Meraki SM](/docs/compliance-connectors/setup/mdm/cisco-meraki-sm) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.7`, `CC6.8`, `CC7.1` | 8 |
| [Cloudflare](/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare) | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1`, `CC7.2` | 18 |
| [Fleet](/docs/compliance-connectors/setup/mdm/fleet) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.6`, `CC6.8`, `CC7.1` | 8 |
| [GoDaddy](/docs/compliance-connectors/setup/cloud-infrastructure/godaddy) | `A1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1` | 11 |
| [Ivanti Neurons](/docs/compliance-connectors/setup/mdm/ivanti-neurons) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.7`, `CC6.8`, `CC7.1` | 8 |
| [Jira](/docs/compliance-connectors/setup/ticketing/jira) | `C1.1`, `CC6.1`, `CC6.2`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5` | 10 |
| [JumpCloud](/docs/compliance-connectors/setup/identity-and-sso/jumpcloud) (also JumpCloud MDM, JumpCloud SSO) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.8`, `CC7.1` | 15 |
| [Kandji](/docs/compliance-connectors/setup/mdm/kandji) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.6`, `CC6.8`, `CC7.1` | 8 |
| [Kolide](/docs/compliance-connectors/setup/mdm/kolide) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.6`, `CC6.8`, `CC7.1` | 8 |
| [Miradore](/docs/compliance-connectors/setup/mdm/miradore) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.7`, `CC6.8`, `CC7.1` | 8 |
| [MongoDB Atlas](/docs/compliance-connectors/setup/infrastructure/mongodb-atlas) | `A1.2`, `C1.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC7.2` | 8 |
| [Mosyle](/docs/compliance-connectors/setup/mdm/mosyle) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.6`, `CC6.8`, `CC7.1` | 9 |
| [ServiceNow](/docs/compliance-connectors/setup/ticketing/servicenow) | `CC6.2`, `CC6.3`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5`, `CC8.1` | 9 |
| [Spaceship](/docs/compliance-connectors/setup/cloud-infrastructure/spaceship) | `A1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1` | 11 |
| [Alibaba Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/alibaba-cloud) | `A1.2`, `CC6.1`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.2` | 20 |
| [Asana](/docs/compliance-connectors/setup/ticketing/asana) | `CC6.2`, `CC6.3`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5` | 8 |
| [ChatGPT](/docs/compliance-connectors/setup/business-applications/chatgpt) | `C1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.5`, `CC7.2` | 6 |
| [Claude (Anthropic)](/docs/compliance-connectors/setup/business-applications/claude-anthropic) | `C1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.5`, `CC7.2` | 10 |
| [ClickUp](/docs/compliance-connectors/setup/ticketing/clickup) | `CC6.2`, `CC6.3`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5` | 8 |
| [CrowdStrike Falcon](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon) | `CC6.2`, `CC6.8`, `CC7.1`, `CC7.2`, `CC7.3`, `CC7.4` | 15 |
| [Datadog](/docs/compliance-connectors/setup/observability/datadog) (also Datadog CSM) | `A1.1`, `CC6.2`, `CC7.1`, `CC7.2`, `CC7.3`, `CC7.4` | 11 |
| [ElevenLabs](/docs/compliance-connectors/setup/business-applications/elevenlabs) | `C1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.5`, `CC7.2` | 7 |
| [Fireworks AI](/docs/compliance-connectors/setup/business-applications/fireworks-ai) | `C1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.5`, `CC7.2` | 10 |
| [Heroku](/docs/compliance-connectors/setup/cloud-infrastructure/heroku) | `A1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.7`, `CC7.1` | 8 |
| [ManageEngine](/docs/compliance-connectors/setup/mdm/manageengine) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.8`, `CC7.1` | 6 |
| [Mistral AI](/docs/compliance-connectors/setup/business-applications/mistral-ai) | `C1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.5`, `CC7.2` | 9 |
| [Monday.com](/docs/compliance-connectors/setup/ticketing/monday-com) | `CC6.2`, `CC6.3`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5` | 8 |
| [NinjaOne](/docs/compliance-connectors/setup/mdm/ninjaone) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.5`, `CC6.8`, `CC7.1` | 6 |
| [OpenAI API Platform](/docs/compliance-connectors/setup/business-applications/openai-api-platform) | `C1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.5`, `CC7.2` | 12 |
| [Redis Cloud](/docs/compliance-connectors/setup/infrastructure/redis-cloud) | `A1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7` | 8 |
| [Shortcut](/docs/compliance-connectors/setup/ticketing/shortcut) | `CC6.2`, `CC6.3`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5` | 8 |
| [SolarWinds Service Desk](/docs/compliance-connectors/setup/ticketing/solarwinds-service-desk) | `CC6.2`, `CC6.3`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5` | 8 |
| [Supabase](/docs/compliance-connectors/setup/infrastructure/supabase) | `A1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7` | 7 |
| [VMware Workspace ONE](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-workspace-one) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.7`, `CC6.8`, `CC7.1` | 7 |
| [xAI](/docs/compliance-connectors/setup/business-applications/xai) | `C1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.5`, `CC7.2` | 5 |
| [YouTrack](/docs/compliance-connectors/setup/ticketing/youtrack) | `CC6.2`, `CC6.3`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5` | 8 |
| [Akamai](/docs/compliance-connectors/setup/cloud-infrastructure/akamai) | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7` | 6 |
| [Auth0](/docs/compliance-connectors/setup/identity-and-sso/auth0) (also Auth0 SSO) | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC7.2` | 12 |
| [Cisco Secure Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/cisco-secure-endpoint) | `CC6.8`, `CC7.1`, `CC7.2`, `CC7.3`, `CC7.4` | 6 |
| [Codeberg](/docs/compliance-connectors/setup/version-control/codeberg) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC8.1` | 6 |
| [DigitalOcean](/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean) | `A1.2`, `CC6.6`, `CC6.7`, `CC7.1`, `CC7.2` | 10 |
| [Gitea](/docs/compliance-connectors/setup/version-control/gitea) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC8.1` | 6 |
| [Hugging Face](/docs/compliance-connectors/setup/business-applications/hugging-face) | `C1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.5` | 8 |
| [IBM Cloud](/docs/compliance-connectors/setup/cloud-infrastructure/ibm-cloud) | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC7.2` | 17 |
| [Linear](/docs/compliance-connectors/setup/ticketing/linear) | `CC6.2`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5` | 9 |
| [Linode](/docs/compliance-connectors/setup/cloud-infrastructure/linode) | `A1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6` | 6 |
| [Microsoft Defender for Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/microsoft-defender-for-endpoint) | `CC6.8`, `CC7.1`, `CC7.2`, `CC7.3`, `CC7.4` | 12 |
| [Okta](/docs/compliance-connectors/setup/identity-and-sso/okta) (also Okta SSO) | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC7.2` | 14 |
| [OpenRouter](/docs/compliance-connectors/setup/business-applications/openrouter) | `C1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.5` | 8 |
| [PlanetScale](/docs/compliance-connectors/setup/infrastructure/planetscale) | `A1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC8.1` | 6 |
| [Red Hat OpenShift](/docs/compliance-connectors/setup/cloud-infrastructure/red-hat-openshift) | `CC6.1`, `CC6.3`, `CC6.6`, `CC6.8`, `CC7.2` | 5 |
| [Redmine](/docs/compliance-connectors/setup/ticketing/redmine) | `CC6.2`, `CC7.1`, `CC7.3`, `CC7.4`, `CC7.5` | 5 |
| [SentinelOne](/docs/compliance-connectors/setup/endpoint-detection-and-response/sentinelone) | `CC6.2`, `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 8 |
| [Sentry](/docs/compliance-connectors/setup/observability/sentry) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.3`, `CC7.2` | 6 |
| [Sophos Intercept X](/docs/compliance-connectors/setup/endpoint-detection-and-response/sophos-intercept-x) | `CC6.2`, `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 9 |
| [Bitdefender GravityZone](/docs/compliance-connectors/setup/endpoint-detection-and-response/bitdefender-gravityzone) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 5 |
| [Citrix Endpoint Management](/docs/compliance-connectors/setup/mdm/citrix-endpoint-management) | `CC6.2`, `CC6.7`, `CC6.8`, `CC7.1` | 5 |
| [ClickHouse](/docs/compliance-connectors/setup/data-export/clickhouse) | `A1.2`, `CC6.2`, `CC6.3`, `CC6.6` | 5 |
| [Cortex XDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/cortex-xdr) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 5 |
| [Cybereason](/docs/compliance-connectors/setup/endpoint-detection-and-response/cybereason) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 5 |
| [Deep Instinct](/docs/compliance-connectors/setup/endpoint-detection-and-response/deep-instinct) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 4 |
| [Docker](/docs/compliance-connectors/setup/infrastructure/docker) | `C1.1`, `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Elastic Observability](/docs/compliance-connectors/setup/observability/elastic-observability) | `A1.2`, `CC6.2`, `CC6.3`, `CC7.2` | 6 |
| [Elastic Security](/docs/compliance-connectors/setup/endpoint-detection-and-response/elastic-security) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 5 |
| [ESET Protect](/docs/compliance-connectors/setup/endpoint-detection-and-response/eset-protect) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 4 |
| [Fastly](/docs/compliance-connectors/setup/cloud-infrastructure/fastly) | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.7` | 5 |
| [Fortinet FortiEDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/fortinet-fortiedr) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 5 |
| [Freshservice](/docs/compliance-connectors/setup/ticketing/freshservice) | `CC6.2`, `CC7.1`, `CC7.3`, `CC7.4` | 4 |
| [Grafana](/docs/compliance-connectors/setup/observability/grafana) | `CC6.1`, `CC6.2`, `CC6.3`, `CC7.2` | 5 |
| [Gusto](/docs/compliance-connectors/setup/hris/gusto) | `CC1.3`, `CC2.1`, `CC6.2`, `CC6.3` | 2 |
| [Hexnode](/docs/compliance-connectors/setup/mdm/hexnode) | `CC6.2`, `CC6.5`, `CC6.8`, `CC7.1` | 5 |
| [Huntress](/docs/compliance-connectors/setup/endpoint-detection-and-response/huntress) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 6 |
| [Infisical](/docs/compliance-connectors/setup/infrastructure/infisical) | `CC6.1`, `CC6.2`, `CC6.3`, `CC7.2` | 9 |
| [Jamf Protect](/docs/compliance-connectors/setup/endpoint-detection-and-response/jamf-protect) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 4 |
| [Kaspersky Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/kaspersky-endpoint) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 5 |
| [Keycloak](/docs/compliance-connectors/setup/identity-and-sso/keycloak) | `CC6.1`, `CC6.2`, `CC6.3`, `CC7.2` | 7 |
| [LogicMonitor](/docs/compliance-connectors/setup/observability/logicmonitor) | `CC6.2`, `CC6.3`, `CC7.2`, `CC7.4` | 5 |
| [Nextcloud](/docs/compliance-connectors/setup/cloud-storage-provider/nextcloud) | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.7` | 5 |
| [OpenStack](/docs/compliance-connectors/setup/cloud-infrastructure/openstack) | `A1.2`, `CC6.1`, `CC6.3`, `CC6.6` | 4 |
| [Red Canary](/docs/compliance-connectors/setup/endpoint-detection-and-response/red-canary) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 4 |
| [Render](/docs/compliance-connectors/setup/cloud-infrastructure/render) | `A1.2`, `CC6.1`, `CC6.2`, `CC6.3` | 5 |
| [Scaleway](/docs/compliance-connectors/setup/cloud-infrastructure/scaleway) | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6` | 5 |
| [SigNoz](/docs/compliance-connectors/setup/observability/signoz) | `CC6.1`, `CC6.2`, `CC6.3`, `CC7.2` | 7 |
| [SimpleMDM](/docs/compliance-connectors/setup/mdm/simplemdm) | `C1.1`, `CC6.1`, `CC6.6`, `CC7.1` | 5 |
| [Snowflake](/docs/compliance-connectors/setup/data-export/snowflake) | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6` | 5 |
| [Splunk](/docs/compliance-connectors/setup/observability/splunk) | `CC6.2`, `CC6.3`, `CC7.2`, `CC7.3` | 5 |
| [Sumo Logic](/docs/compliance-connectors/setup/observability/sumo-logic) | `CC6.1`, `CC6.2`, `CC6.3`, `CC7.2` | 6 |
| [Symantec Endpoint](/docs/compliance-connectors/setup/endpoint-detection-and-response/symantec-endpoint) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 5 |
| [Tanium](/docs/compliance-connectors/setup/endpoint-detection-and-response/tanium) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 4 |
| [Terraform Cloud](/docs/compliance-connectors/setup/infrastructure/terraform-cloud) | `CC6.1`, `CC6.2`, `CC6.3`, `CC8.1` | 5 |
| [Trellix](/docs/compliance-connectors/setup/endpoint-detection-and-response/trellix) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 4 |
| [Trend Micro Apex One](/docs/compliance-connectors/setup/endpoint-detection-and-response/trend-micro-apex-one) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 5 |
| [UpCloud](/docs/compliance-connectors/setup/cloud-infrastructure/upcloud) | `A1.2`, `CC6.2`, `CC6.3`, `CC6.6` | 4 |
| [Vercel](/docs/compliance-connectors/setup/cloud-infrastructure/vercel) | `CC6.1`, `CC6.2`, `CC6.3`, `CC8.1` | 6 |
| [VMware Carbon Black](/docs/compliance-connectors/setup/cloud-infrastructure/vmware-carbon-black) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 5 |
| [Vultr](/docs/compliance-connectors/setup/cloud-infrastructure/vultr) | `A1.2`, `CC6.2`, `CC6.3`, `CC6.6` | 5 |
| [WithSecure](/docs/compliance-connectors/setup/endpoint-detection-and-response/withsecure) | `CC6.8`, `CC7.2`, `CC7.3`, `CC7.4` | 5 |
| [Airtable](/docs/compliance-connectors/setup/ticketing/airtable) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Authentik](/docs/compliance-connectors/setup/identity-and-sso/authentik) | `CC6.1`, `CC6.2`, `CC6.3` | 5 |
| [Backblaze](/docs/compliance-connectors/setup/cloud-storage-provider/backblaze) | `A1.2`, `CC6.1`, `CC6.6` | 3 |
| [BambooHR](/docs/compliance-connectors/setup/hris/bamboohr) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [Baramundi](/docs/compliance-connectors/setup/mdm/baramundi) | `CC6.2`, `CC6.8`, `CC7.1` | 4 |
| [Ceridian Dayforce](/docs/compliance-connectors/setup/hris/ceridian-dayforce) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [Cloudflare Access](/docs/compliance-connectors/setup/identity-and-sso/cloudflare-access) | `CC6.1`, `CC6.2`, `CC6.3` | 3 |
| [Coralogix](/docs/compliance-connectors/setup/observability/coralogix) | `CC6.2`, `CC6.3`, `CC7.2` | 3 |
| [Deel](/docs/compliance-connectors/setup/hris/deel) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [Duo Security](/docs/compliance-connectors/setup/identity-and-sso/duo-security) | `CC6.1`, `CC6.2`, `CC6.3` | 6 |
| [Dynatrace](/docs/compliance-connectors/setup/observability/dynatrace) | `CC6.2`, `CC6.3`, `CC7.2` | 3 |
| [Employment Hero](/docs/compliance-connectors/setup/hris/employment-hero) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [env0](/docs/compliance-connectors/setup/infrastructure/env0) | `CC6.2`, `CC6.3`, `CC8.1` | 4 |
| [Factorial](/docs/compliance-connectors/setup/hris/factorial) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [Fly.io](/docs/compliance-connectors/setup/cloud-infrastructure/fly-io) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [FusionAuth](/docs/compliance-connectors/setup/identity-and-sso/fusionauth) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Gerrit](/docs/compliance-connectors/setup/version-control/gerrit) | `CC6.2`, `CC6.3`, `CC8.1` | 5 |
| [HashiCorp Consul](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-consul) | `CC6.1`, `CC6.6`, `CC6.7` | 2 |
| [HashiCorp Nomad](/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-nomad) | `CC6.1`, `CC6.6`, `CC6.7` | 2 |
| [HiBob](/docs/compliance-connectors/setup/hris/hibob) (also Bob) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [Humaans](/docs/compliance-connectors/setup/hris/humaans) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [IBM Verify](/docs/compliance-connectors/setup/identity-and-sso/ibm-verify) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Instana](/docs/compliance-connectors/setup/observability/instana) | `CC6.2`, `CC6.3`, `CC7.2` | 3 |
| [Jira Service Management](/docs/compliance-connectors/setup/ticketing/jira-service-management) | `CC7.4`, `CC7.5`, `CC8.1` | 3 |
| [Logz.io](/docs/compliance-connectors/setup/observability/logz-io) | `CC6.2`, `CC6.3`, `CC7.2` | 5 |
| [Looker](/docs/compliance-connectors/setup/data-export/looker) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Mailgun](/docs/compliance-connectors/setup/communications-platforms/mailgun) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Make](/docs/compliance-connectors/setup/security-automation/make) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Mattermost](/docs/compliance-connectors/setup/communications-platforms/mattermost) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [MinIO](/docs/compliance-connectors/setup/cloud-storage-provider/minio) | `A1.2`, `CC6.1`, `CC6.6` | 3 |
| [New Relic](/docs/compliance-connectors/setup/observability/new-relic) | `CC6.2`, `CC6.3`, `CC7.2` | 4 |
| [OneLogin](/docs/compliance-connectors/setup/identity-and-sso/onelogin) (also OneLogin SSO) | `CC6.1`, `CC6.2`, `CC6.3` | 7 |
| [Opsgenie Alerts](/docs/compliance-connectors/setup/ticketing/opsgenie-alerts) | `A1.1`, `CC6.2`, `CC7.4` | 5 |
| [Oracle Identity](/docs/compliance-connectors/setup/identity-and-sso/oracle-identity) | `CC6.1`, `CC6.2`, `CC6.3` | 5 |
| [ownCloud](/docs/compliance-connectors/setup/cloud-storage-provider/owncloud) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [PagerDuty](/docs/compliance-connectors/setup/ticketing/pagerduty) | `A1.1`, `CC6.2`, `CC7.4` | 6 |
| [Paychex](/docs/compliance-connectors/setup/hris/paychex) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [PingOne](/docs/compliance-connectors/setup/identity-and-sso/pingone) (also Ping Identity) | `CC6.1`, `CC6.2`, `CC6.3` | 6 |
| [Platform.sh](/docs/compliance-connectors/setup/cloud-infrastructure/platform-sh) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Proxmox](/docs/compliance-connectors/setup/cloud-infrastructure/proxmox) | `A1.2`, `CC6.1`, `CC6.3` | 3 |
| [Pulumi](/docs/compliance-connectors/setup/infrastructure/pulumi) (also Pulumi Cloud) | `CC6.2`, `CC6.3`, `CC8.1` | 4 |
| [Qualys EDR](/docs/compliance-connectors/setup/vulnerability-scanning/qualys-edr) | `CC6.8`, `CC7.3`, `CC7.4` | 3 |
| [Railway](/docs/compliance-connectors/setup/cloud-infrastructure/railway) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Rippling](/docs/compliance-connectors/setup/hris/rippling) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [Rollbar](/docs/compliance-connectors/setup/observability/rollbar) | `CC6.2`, `CC6.3`, `CC7.2` | 4 |
| [Sage HR](/docs/compliance-connectors/setup/hris/sage-hr) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [Salesforce](/docs/compliance-connectors/setup/crm/salesforce) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [SAP SuccessFactors](/docs/compliance-connectors/setup/hris/sap-successfactors) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [Sapling](/docs/compliance-connectors/setup/hris/sapling) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [SharePoint](/docs/compliance-connectors/setup/cloud-storage-provider/sharepoint) | `C1.1`, `CC6.1`, `CC6.7` | 4 |
| [Site24x7](/docs/compliance-connectors/setup/observability/site24x7) | `CC6.2`, `CC6.3`, `CC7.2` | 4 |
| [Slack](/docs/compliance-connectors/setup/communications-platforms/slack) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Spacelift](/docs/compliance-connectors/setup/infrastructure/spacelift) | `CC6.2`, `CC6.3`, `CC8.1` | 3 |
| [UKG](/docs/compliance-connectors/setup/hris/ukg) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [VMware](/docs/compliance-connectors/setup/cloud-infrastructure/vmware) | `A1.2`, `CC6.1`, `CC7.2` | 6 |
| [Workday](/docs/compliance-connectors/setup/hris/workday) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [Zabbix](/docs/compliance-connectors/setup/observability/zabbix) | `CC6.2`, `CC6.3`, `CC7.2` | 4 |
| [Zendesk](/docs/compliance-connectors/setup/ticketing/zendesk) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Zenefits](/docs/compliance-connectors/setup/hris/zenefits) | `CC1.3`, `CC2.1`, `CC6.2` | 1 |
| [Zitadel](/docs/compliance-connectors/setup/identity-and-sso/zitadel) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [Zoom](/docs/compliance-connectors/setup/communications-platforms/zoom) | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [15Five](/docs/compliance-connectors/setup/hris/15five) | `CC6.2`, `CC6.3` | 2 |
| [1Password](/docs/compliance-connectors/setup/identity-and-sso/1password) | `CC6.2`, `CC6.3` | 2 |
| [360Learning](/docs/compliance-connectors/setup/security-training/360learning) | `CC1.4`, `CC2.2` | 1 |
| [ActiveCampaign](/docs/compliance-connectors/setup/crm/activecampaign) | `CC6.2`, `CC6.3` | 3 |
| [Adobe Acrobat Sign](/docs/compliance-connectors/setup/digital-signature/adobe-acrobat-sign) | `CC6.2`, `CC6.3` | 3 |
| [Aha!](/docs/compliance-connectors/setup/ticketing/aha) | `CC6.2`, `CC6.3` | 3 |
| [Airbyte](/docs/compliance-connectors/setup/data-export/airbyte) | `CC6.2`, `CC6.3` | 3 |
| [Aircall](/docs/compliance-connectors/setup/communications-platforms/aircall) | `CC6.2`, `CC6.3` | 2 |
| [Amplitude](/docs/compliance-connectors/setup/data-export/amplitude) | `CC6.2`, `CC6.3` | 2 |
| [Ansible](/docs/compliance-connectors/setup/infrastructure/ansible) | `CC6.2`, `CC6.3` | 3 |
| [Apollo IO](/docs/compliance-connectors/setup/business-applications/apollo-io) | `CC6.2`, `CC6.3` | 2 |
| [Aptible](/docs/compliance-connectors/setup/cloud-infrastructure/aptible) | `CC6.2`, `CC6.3` | 3 |
| [Ashby](/docs/compliance-connectors/setup/hris/ashby) | `CC6.2`, `CC6.3` | 3 |
| [Assembla](/docs/compliance-connectors/setup/version-control/assembla) | `CC6.2`, `CC6.3` | 3 |
| [Attio](/docs/compliance-connectors/setup/crm/attio) | `CC6.2`, `CC6.3` | 3 |
| [Basecamp](/docs/compliance-connectors/setup/ticketing/basecamp) | `CC6.2`, `CC6.3` | 3 |
| [Beanstalk](/docs/compliance-connectors/setup/version-control/beanstalk) | `CC6.2`, `CC6.3` | 3 |
| [Better Stack](/docs/compliance-connectors/setup/observability/better-stack) | `CC7.2`, `CC7.4` | 3 |
| [Beyond Identity](/docs/compliance-connectors/setup/identity-and-sso/beyond-identity) | `CC6.2`, `CC6.3` | 2 |
| [BoldSign](/docs/compliance-connectors/setup/digital-signature/boldsign) | `CC6.2`, `CC6.3` | 3 |
| [Box](/docs/compliance-connectors/setup/cloud-storage-provider/box) | `CC6.2`, `CC6.3` | 3 |
| [Brex](/docs/compliance-connectors/setup/vendor-procurement/brex) | `CC6.2`, `CC6.3` | 2 |
| [Canva](/docs/compliance-connectors/setup/business-applications/canva) | `CC6.2`, `CC6.3` | 2 |
| [Capsule](/docs/compliance-connectors/setup/crm/capsule) | `CC6.2`, `CC6.3` | 2 |
| [Census](/docs/compliance-connectors/setup/data-export/census) | `CC6.2`, `CC6.3` | 3 |
| [Check Point Harmony](/docs/compliance-connectors/setup/endpoint-detection-and-response/check-point-harmony) | `CC6.8`, `CC7.2` | 2 |
| [Citrix ShareFile](/docs/compliance-connectors/setup/cloud-storage-provider/citrix-sharefile) | `CC6.2`, `CC6.3` | 3 |
| [Close](/docs/compliance-connectors/setup/crm/close) | `CC6.2`, `CC6.3` | 3 |
| [Cobalt](/docs/compliance-connectors/setup/vulnerability-scanning/cobalt) | `CC4.1`, `CC7.1` | 3 |
| [Confluence](/docs/compliance-connectors/setup/compliance-as-code/confluence) | `CC6.2`, `CC6.3` | 2 |
| [Copper](/docs/compliance-connectors/setup/crm/copper) | `CC6.2`, `CC6.3` | 2 |
| [Cortex XSOAR](/docs/compliance-connectors/setup/security-automation/cortex-xsoar) | `CC7.3`, `CC7.4` | 2 |
| [Coupa](/docs/compliance-connectors/setup/vendor-procurement/coupa) | `CC6.2`, `CC6.3` | 3 |
| [Culture Amp](/docs/compliance-connectors/setup/hris/culture-amp) | `CC6.2`, `CC6.3` | 2 |
| [D3 Security](/docs/compliance-connectors/setup/security-automation/d3-security) | `CC7.3`, `CC7.4` | 2 |
| [Databricks](/docs/compliance-connectors/setup/data-export/databricks) | `CC6.2`, `CC6.3` | 3 |
| [dbt Cloud](/docs/compliance-connectors/setup/data-export/dbt-cloud) | `CC6.2`, `CC6.3` | 2 |
| [Dialpad](/docs/compliance-connectors/setup/communications-platforms/dialpad) | `CC6.2`, `CC6.3` | 3 |
| [Docebo](/docs/compliance-connectors/setup/security-training/docebo) | `CC1.4`, `CC2.2` | 1 |
| [DocuSign](/docs/compliance-connectors/setup/digital-signature/docusign) | `CC6.2`, `CC6.3` | 3 |
| [Dropbox](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox) | `CC6.2`, `CC6.3` | 3 |
| [Dropbox Sign](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox-sign) | `CC6.2`, `CC6.3` | 3 |
| [Egnyte](/docs/compliance-connectors/setup/cloud-storage-provider/egnyte) | `CC6.2`, `CC6.3` | 3 |
| [Figma](/docs/compliance-connectors/setup/business-applications/figma) | `CC6.2`, `CC6.3` | 3 |
| [Fivetran](/docs/compliance-connectors/setup/data-export/fivetran) | `CC6.2`, `CC6.3` | 3 |
| [folk](/docs/compliance-connectors/setup/crm/folk) | `CC6.2`, `CC6.3` | 2 |
| [ForgeRock](/docs/compliance-connectors/setup/identity-and-sso/forgerock) | `CC6.2`, `CC6.3` | 2 |
| [Freshdesk](/docs/compliance-connectors/setup/ticketing/freshdesk) | `CC6.2`, `CC6.3` | 3 |
| [Front](/docs/compliance-connectors/setup/communications-platforms/front) | `CC6.2`, `CC6.3` | 3 |
| [GoHighLevel](/docs/compliance-connectors/setup/crm/gohighlevel) | `CC6.2`, `CC6.3` | 3 |
| [Google Chronicle SOAR](/docs/compliance-connectors/setup/security-automation/google-chronicle-soar) | `CC7.3`, `CC7.4` | 2 |
| [Google Drive](/docs/compliance-connectors/setup/cloud-storage-provider/google-drive) | `CC6.1`, `CC6.7` | 1 |
| [GoTo Connect](/docs/compliance-connectors/setup/communications-platforms/goto-connect) | `CC6.2`, `CC6.3` | 3 |
| [Greenhouse](/docs/compliance-connectors/setup/hris/greenhouse) | `CC6.2`, `CC6.3` | 3 |
| [HashiCorp Vault](/docs/compliance-connectors/setup/infrastructure/hashicorp-vault) | `CC6.1`, `CC7.2` | 2 |
| [Hevo Data](/docs/compliance-connectors/setup/data-export/hevo-data) | `CC6.2`, `CC6.3` | 3 |
| [Hightouch](/docs/compliance-connectors/setup/data-export/hightouch) | `CC6.2`, `CC6.3` | 2 |
| [Hive](/docs/compliance-connectors/setup/ticketing/hive) | `CC6.2`, `CC6.3` | 2 |
| [HubSpot](/docs/compliance-connectors/setup/crm/hubspot) | `CC6.2`, `CC6.3` | 3 |
| [IBM QRadar SOAR](/docs/compliance-connectors/setup/security-automation/ibm-qradar-soar) | `CC7.3`, `CC7.4` | 2 |
| [Immersive Labs](/docs/compliance-connectors/setup/security-training/immersive-labs) | `CC1.4`, `CC8.1` | 1 |
| [Insightly](/docs/compliance-connectors/setup/crm/insightly) | `CC6.2`, `CC6.3` | 3 |
| [Intercom](/docs/compliance-connectors/setup/communications-platforms/intercom) | `CC6.2`, `CC6.3` | 2 |
| [Ironclad](/docs/compliance-connectors/setup/digital-signature/ironclad) | `CC6.2`, `CC6.3` | 2 |
| [Keap](/docs/compliance-connectors/setup/crm/keap) | `CC6.2`, `CC6.3` | 3 |
| [Lattice](/docs/compliance-connectors/setup/hris/lattice) | `CC6.2`, `CC6.3` | 2 |
| [Launchpad](/docs/compliance-connectors/setup/version-control/launchpad) | `CC6.2`, `CC6.3` | 2 |
| [Lessonly](/docs/compliance-connectors/setup/security-training/lessonly) | `CC1.4`, `CC2.2` | 1 |
| [Lever](/docs/compliance-connectors/setup/hris/lever) | `CC6.2`, `CC6.3` | 3 |
| [Logto](/docs/compliance-connectors/setup/identity-and-sso/logto) | `CC6.1`, `CC6.3` | 6 |
| [Loopio](/docs/compliance-connectors/setup/vendor-procurement/loopio) | `CC6.2`, `CC6.3` | 3 |
| [Malwarebytes](/docs/compliance-connectors/setup/endpoint-detection-and-response/malwarebytes) | `CC6.8`, `CC7.2` | 3 |
| [Microsoft Dynamics 365](/docs/compliance-connectors/setup/crm/microsoft-dynamics-365) | `CC6.2`, `CC6.3` | 3 |
| [Miro](/docs/compliance-connectors/setup/communications-platforms/miro) | `CC6.2`, `CC6.3` | 2 |
| [Mixpanel](/docs/compliance-connectors/setup/data-export/mixpanel) | `CC6.2`, `CC6.3` | 2 |
| [n8n](/docs/compliance-connectors/setup/security-automation/n8n) | `CC6.2`, `CC6.3` | 3 |
| [Netlify](/docs/compliance-connectors/setup/cloud-infrastructure/netlify) | `CC6.2`, `CC6.3` | 3 |
| [Northflank](/docs/compliance-connectors/setup/cloud-infrastructure/northflank) | `CC6.2`, `CC6.3` | 2 |
| [Notion](/docs/compliance-connectors/setup/compliance-as-code/notion) | `CC6.2`, `CC6.3` | 2 |
| [Nutanix](/docs/compliance-connectors/setup/cloud-infrastructure/nutanix) | `A1.2`, `CC6.3` | 2 |
| [Nutshell](/docs/compliance-connectors/setup/crm/nutshell) | `CC6.2`, `CC6.3` | 3 |
| [Oneflow](/docs/compliance-connectors/setup/digital-signature/oneflow) | `CC6.2`, `CC6.3` | 2 |
| [OneSpan Sign](/docs/compliance-connectors/setup/digital-signature/onespan-sign) | `CC6.2`, `CC6.3` | 2 |
| [OneTrust Vendorpedia](/docs/compliance-connectors/setup/vendor-procurement/onetrust-vendorpedia) | `CC6.2`, `CC6.3` | 2 |
| [Opal](/docs/compliance-connectors/setup/user-access-review/opal) | `CC6.2`, `CC6.3` | 2 |
| [OpenPhone](/docs/compliance-connectors/setup/communications-platforms/openphone) | `CC6.2`, `CC6.3` | 3 |
| [PandaDoc](/docs/compliance-connectors/setup/digital-signature/pandadoc) | `CC6.2`, `CC6.3` | 3 |
| [Pingdom](/docs/compliance-connectors/setup/observability/pingdom) | `CC6.2`, `CC6.3` | 2 |
| [Pipedrive](/docs/compliance-connectors/setup/crm/pipedrive) | `CC6.2`, `CC6.3` | 3 |
| [Portainer](/docs/compliance-connectors/setup/cloud-infrastructure/portainer) | `CC6.2`, `CC6.3` | 2 |
| [Productboard](/docs/compliance-connectors/setup/ticketing/productboard) | `CC6.2`, `CC6.3` | 3 |
| [Proofpoint Security Awareness](/docs/compliance-connectors/setup/security-training/proofpoint-security-awareness) | `CC1.4`, `CC2.2` | 2 |
| [Qovery](/docs/compliance-connectors/setup/cloud-infrastructure/qovery) | `CC6.2`, `CC6.3` | 3 |
| [Ramp](/docs/compliance-connectors/setup/vendor-procurement/ramp) | `CC6.2`, `CC6.3` | 3 |
| [Rancher](/docs/compliance-connectors/setup/cloud-infrastructure/rancher) | `CC6.2`, `CC6.3` | 3 |
| [Rapid7 InsightIDR](/docs/compliance-connectors/setup/endpoint-detection-and-response/rapid7-insightidr) | `CC7.3`, `CC7.4` | 2 |
| [RingCentral](/docs/compliance-connectors/setup/identity-and-sso/ringcentral) | `CC6.2`, `CC6.3` | 3 |
| [Riot](/docs/compliance-connectors/setup/security-training/riot) | `CC1.4`, `CC2.2` | 2 |
| [Rocket.Chat](/docs/compliance-connectors/setup/communications-platforms/rocket-chat) | `CC6.2`, `CC6.3` | 3 |
| [SailPoint](/docs/compliance-connectors/setup/identity-and-sso/sailpoint) | `CC6.2`, `CC6.3` | 3 |
| [Salesflare](/docs/compliance-connectors/setup/crm/salesflare) | `CC6.2`, `CC6.3` | 2 |
| [Segment](/docs/compliance-connectors/setup/data-export/segment) | `CC6.2`, `CC6.3` | 3 |
| [SendGrid](/docs/compliance-connectors/setup/communications-platforms/sendgrid) | `CC6.2`, `CC6.3` | 3 |
| [Setyl](/docs/compliance-connectors/setup/vendor-procurement/setyl) | `CC6.2`, `CC6.5` | 2 |
| [Shuffle](/docs/compliance-connectors/setup/security-automation/shuffle) | `CC6.2`, `CC6.3` | 2 |
| [SignNow](/docs/compliance-connectors/setup/digital-signature/signnow) | `CC6.2`, `CC6.3` | 2 |
| [SignRequest](/docs/compliance-connectors/setup/digital-signature/signrequest) | `CC6.2`, `CC6.3` | 3 |
| [Smartsheet](/docs/compliance-connectors/setup/ticketing/smartsheet) | `CC6.2`, `CC6.3` | 3 |
| [Splunk SOAR](/docs/compliance-connectors/setup/observability/splunk-soar) | `CC7.3`, `CC7.4` | 2 |
| [Streak](/docs/compliance-connectors/setup/crm/streak) | `CC6.2`, `CC6.3` | 2 |
| [SugarCRM](/docs/compliance-connectors/setup/crm/sugarcrm) | `CC6.2`, `CC6.3` | 3 |
| [TalentLMS](/docs/compliance-connectors/setup/security-training/talentlms) | `CC1.4`, `CC2.2` | 1 |
| [Teamwork](/docs/compliance-connectors/setup/ticketing/teamwork) | `CC6.2`, `CC6.3` | 3 |
| [Telnyx](/docs/compliance-connectors/setup/communications-platforms/telnyx) | `CC6.2`, `CC6.3` | 2 |
| [ThreatConnect](/docs/compliance-connectors/setup/security-automation/threatconnect) | `CC6.2`, `CC6.3` | 2 |
| [Tines](/docs/compliance-connectors/setup/security-automation/tines) | `CC6.2`, `CC6.3` | 3 |
| [Torii](/docs/compliance-connectors/setup/user-access-review/torii) | `CC6.2`, `CC6.3` | 2 |
| [Torq](/docs/compliance-connectors/setup/security-automation/torq) | `CC7.3`, `CC7.4` | 2 |
| [Tray.io](/docs/compliance-connectors/setup/security-automation/tray-io) | `CC6.2`, `CC6.3` | 2 |
| [Trello](/docs/compliance-connectors/setup/ticketing/trello) | `CC6.2`, `CC6.3` | 3 |
| [Udemy Business](/docs/compliance-connectors/setup/security-training/udemy-business) | `CC1.4`, `CC2.2` | 1 |
| [Veza](/docs/compliance-connectors/setup/user-access-review/veza) | `CC6.2`, `CC6.3` | 1 |
| [Vtiger](/docs/compliance-connectors/setup/crm/vtiger) | `CC6.2`, `CC6.3` | 3 |
| [Wasabi](/docs/compliance-connectors/setup/cloud-storage-provider/wasabi) | `A1.2`, `CC6.6` | 3 |
| [Webex](/docs/compliance-connectors/setup/communications-platforms/webex) | `CC6.2`, `CC6.3` | 3 |
| [Webroot](/docs/compliance-connectors/setup/endpoint-detection-and-response/webroot) | `CC6.8`, `CC7.2` | 2 |
| [Workable](/docs/compliance-connectors/setup/hris/workable) | `CC6.2`, `CC6.3` | 3 |
| [Workato](/docs/compliance-connectors/setup/security-automation/workato) | `CC6.2`, `CC6.3` | 3 |
| [Wrike](/docs/compliance-connectors/setup/ticketing/wrike) | `CC6.2`, `CC6.3` | 3 |
| [Yousign](/docs/compliance-connectors/setup/digital-signature/yousign) | `CC6.2`, `CC6.3` | 3 |
| [Zendesk Sell](/docs/compliance-connectors/setup/ticketing/zendesk-sell) | `CC6.2`, `CC6.3` | 3 |
| [Zoho CRM](/docs/compliance-connectors/setup/crm/zoho-crm) | `CC6.2`, `CC6.3` | 3 |
| [Zoho Desk](/docs/compliance-connectors/setup/ticketing/zoho-desk) | `CC6.2`, `CC6.3` | 3 |
| [42Gears](/docs/compliance-connectors/setup/mdm/42gears) | `CC7.1` | 1 |
| [Action1](/docs/compliance-connectors/setup/mdm/action1) | `CC7.1` | 2 |
| [Aikido Security](/docs/compliance-connectors/setup/vulnerability-scanning/aikido-security) | `CC7.1` | 4 |
| [Anchore](/docs/compliance-connectors/setup/vulnerability-scanning/anchore) | `CC7.1` | 4 |
| [AppDynamics](/docs/compliance-connectors/setup/observability/appdynamics) | `CC7.2` | 1 |
| [Automox](/docs/compliance-connectors/setup/mdm/automox) | `CC7.1` | 4 |
| [BitSight](/docs/compliance-connectors/setup/vendor-procurement/bitsight) | `CC7.1` | 2 |
| [Bright Security](/docs/compliance-connectors/setup/vulnerability-scanning/bright-security) | `CC7.1` | 4 |
| [Bugcrowd](/docs/compliance-connectors/setup/vulnerability-scanning/bugcrowd) | `CC7.1` | 2 |
| [Burp Suite](/docs/compliance-connectors/setup/vulnerability-scanning/burp-suite) | `CC7.1` | 3 |
| [Check Point CloudGuard](/docs/compliance-connectors/setup/cspm/check-point-cloudguard) | `CC7.1` | 3 |
| [Checkmarx](/docs/compliance-connectors/setup/vulnerability-scanning/checkmarx) | `CC7.1` | 4 |
| [Chronosphere](/docs/compliance-connectors/setup/observability/chronosphere) | `CC7.2` | 1 |
| [Civo](/docs/compliance-connectors/setup/cloud-infrastructure/civo) | `CC6.6` | 2 |
| [Contrast Security](/docs/compliance-connectors/setup/vulnerability-scanning/contrast-security) | `CC7.1` | 4 |
| [Cronitor](/docs/compliance-connectors/setup/observability/cronitor) | `CC7.2` | 1 |
| [CrowdStrike Falcon Cloud](/docs/compliance-connectors/setup/endpoint-detection-and-response/crowdstrike-falcon-cloud) | `CC7.1` | 3 |
| [Dependency-Track](/docs/compliance-connectors/setup/vulnerability-scanning/dependency-track) | `CC7.1` | 4 |
| [Detectify](/docs/compliance-connectors/setup/vulnerability-scanning/detectify) | `CC7.1` | 3 |
| [Endor Labs](/docs/compliance-connectors/setup/vulnerability-scanning/endor-labs) | `CC7.1` | 4 |
| [Escape](/docs/compliance-connectors/setup/vulnerability-scanning/escape) | `CC7.1` | 4 |
| [Esper](/docs/compliance-connectors/setup/mdm/esper) | `CC7.1` | 2 |
| [Firebase](/docs/compliance-connectors/setup/infrastructure/firebase) | `CC6.1` | 1 |
| [GitGuardian](/docs/compliance-connectors/setup/vulnerability-scanning/gitguardian) | `CC7.1` | 3 |
| [HackerOne](/docs/compliance-connectors/setup/vulnerability-scanning/hackerone) | `CC7.1` | 2 |
| [Intruder](/docs/compliance-connectors/setup/vulnerability-scanning/intruder) | `CC7.1` | 4 |
| [Invicti](/docs/compliance-connectors/setup/vulnerability-scanning/invicti) | `CC7.1` | 4 |
| [JFrog Xray](/docs/compliance-connectors/setup/vulnerability-scanning/jfrog-xray) | `CC7.1` | 3 |
| [Lacework](/docs/compliance-connectors/setup/cspm/lacework) | `CC7.1` | 3 |
| [Mend](/docs/compliance-connectors/setup/vulnerability-scanning/mend) | `CC7.1` | 3 |
| [Nucleus Security](/docs/compliance-connectors/setup/vulnerability-scanning/nucleus-security) | `CC7.1` | 4 |
| [Ox Security](/docs/compliance-connectors/setup/vulnerability-scanning/ox-security) | `CC7.1` | 4 |
| [Prey](/docs/compliance-connectors/setup/mdm/prey) | `CC7.1` | 2 |
| [Prisma Cloud](/docs/compliance-connectors/setup/cspm/prisma-cloud) | `CC7.1` | 3 |
| [Probely](/docs/compliance-connectors/setup/vulnerability-scanning/probely) | `CC7.1` | 4 |
| [Prometheus](/docs/compliance-connectors/setup/observability/prometheus) | `CC7.2` | 1 |
| [Prowler](/docs/compliance-connectors/setup/infrastructure/prowler) | `CC7.1` | 2 |
| [Qualys](/docs/compliance-connectors/setup/vulnerability-scanning/qualys) | `CC7.1` | 4 |
| [Rapid7 InsightVM](/docs/compliance-connectors/setup/vulnerability-scanning/rapid7-insightvm) | `CC7.1` | 4 |
| [SecurityScorecard Atlas](/docs/compliance-connectors/setup/vendor-procurement/securityscorecard-atlas) | `CC7.1` | 1 |
| [Semgrep](/docs/compliance-connectors/setup/vulnerability-scanning/semgrep) | `CC7.1` | 4 |
| [Snyk](/docs/compliance-connectors/setup/vulnerability-scanning/snyk) | `CC7.1` | 4 |
| [Socket](/docs/compliance-connectors/setup/vulnerability-scanning/socket) | `CC7.1` | 3 |
| [SonarQube](/docs/compliance-connectors/setup/vulnerability-scanning/sonarqube) | `CC7.1` | 4 |
| [StackHawk](/docs/compliance-connectors/setup/vulnerability-scanning/stackhawk) | `CC7.1` | 3 |
| [Tenable](/docs/compliance-connectors/setup/vulnerability-scanning/tenable) | `CC7.1` | 4 |
| [Trend Micro Cloud One](/docs/compliance-connectors/setup/cspm/trend-micro-cloud-one) | `CC7.1` | 3 |
| [Turbot](/docs/compliance-connectors/setup/cspm/turbot) | `CC7.1` | 1 |
| [UpGuard Vendor Risk](/docs/compliance-connectors/setup/vendor-procurement/upguard-vendor-risk) | `CC7.1` | 2 |
| [Uptime Robot](/docs/compliance-connectors/setup/observability/uptime-robot) | `CC7.2` | 1 |
| [Veracode](/docs/compliance-connectors/setup/vulnerability-scanning/veracode) | `CC7.1` | 4 |
| [VictoriaMetrics](/docs/compliance-connectors/setup/observability/victoriametrics) | `CC7.2` | 1 |
| [Wiz](/docs/compliance-connectors/setup/cspm/wiz) | `CC7.1` | 3 |
| [Yardstik](/docs/compliance-connectors/setup/background-check-providers/yardstik) | `CC1.4` | 1 |
## Evidence by attestation (95)
These systems publish no API for what the tests check. Connect them to record the connection, then attest the result; an accepted attestation counts toward the control.
| Connector | Controls |
| --------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- |
| [8x8](/docs/compliance-connectors/setup/communications-platforms/8x8) | `CC6.2`, `CC6.3` |
| [Acunetix](/docs/compliance-connectors/setup/vulnerability-scanning/acunetix) | `CC7.1` |
| [Addigy](/docs/compliance-connectors/setup/mdm/addigy) | `CC6.8`, `CC7.1` |
| [Affinity](/docs/compliance-connectors/setup/crm/affinity) | `CC6.2`, `CC6.3` |
| [Airbase](/docs/compliance-connectors/setup/vendor-procurement/airbase) | `CC6.2`, `CC6.3` |
| [Apiiro](/docs/compliance-connectors/setup/vulnerability-scanning/apiiro) | `CC7.1` |
| [Aqua Security](/docs/compliance-connectors/setup/cspm/aqua-security) | `CC7.1` |
| [Arctic Wolf](/docs/compliance-connectors/setup/endpoint-detection-and-response/arctic-wolf) | `CC6.8` |
| [Arnica](/docs/compliance-connectors/setup/vulnerability-scanning/arnica) | `CC7.1` |
| [Blackpoint Cyber](/docs/compliance-connectors/setup/endpoint-detection-and-response/blackpoint-cyber) | `CC6.8` |
| [Bugsnag](/docs/compliance-connectors/setup/observability/bugsnag) | `CC6.2`, `CC6.3` |
| [Carta](/docs/compliance-connectors/setup/business-applications/carta) | `CC6.2`, `CC6.3` |
| [Checkmk](/docs/compliance-connectors/setup/observability/checkmk) | `CC6.2`, `CC6.3`, `CC7.2` |
| [Cloudanix](/docs/compliance-connectors/setup/cspm/cloudanix) | `CC7.1` |
| [Cohere](/docs/compliance-connectors/setup/business-applications/cohere) | `C1.2`, `CC6.2`, `CC6.3`, `CC6.5` |
| [Concord](/docs/compliance-connectors/setup/digital-signature/concord) | `CC6.2`, `CC6.3` |
| [Contractbook](/docs/compliance-connectors/setup/digital-signature/contractbook) | `CC6.2`, `CC6.3` |
| [ContractSafe](/docs/compliance-connectors/setup/digital-signature/contractsafe) | `CC6.2`, `CC6.3` |
| [CoreStack](/docs/compliance-connectors/setup/cspm/corestack) | `CC7.1` |
| [CyberArk](/docs/compliance-connectors/setup/identity-and-sso/cyberark) | `CC6.1`, `CC6.2`, `CC6.3` |
| [Cynet](/docs/compliance-connectors/setup/endpoint-detection-and-response/cynet) | `CC6.8` |
| [Cyscale](/docs/compliance-connectors/setup/cspm/cyscale) | `CC7.1` |
| [Cyware](/docs/compliance-connectors/setup/security-automation/cyware) | `CC7.4` |
| [DeepSeek](/docs/compliance-connectors/setup/business-applications/deepseek) | `C1.2`, `CC6.2`, `CC6.3`, `CC6.5` |
| [Documenso](/docs/compliance-connectors/setup/digital-signature/documenso) | `CC6.2`, `CC6.3` |
| [Edgescan](/docs/compliance-connectors/setup/vulnerability-scanning/edgescan) | `CC7.1` |
| [Eversign](/docs/compliance-connectors/setup/digital-signature/eversign) | `CC6.2`, `CC6.3` |
| [Evisort](/docs/compliance-connectors/setup/digital-signature/evisort) | `CC6.2`, `CC6.3` |
| [Foxit eSign](/docs/compliance-connectors/setup/digital-signature/foxit-esign) | `CC6.2`, `CC6.3` |
| [Freshsales](/docs/compliance-connectors/setup/crm/freshsales) | `CC6.2`, `CC6.3` |
| [Gatekeeper](/docs/compliance-connectors/setup/vendor-procurement/gatekeeper) | `CC6.2`, `CC6.3` |
| [GetAccept](/docs/compliance-connectors/setup/digital-signature/getaccept) | `CC6.2`, `CC6.3` |
| [GitKraken](/docs/compliance-connectors/setup/version-control/gitkraken) | `CC6.2`, `CC6.3` |
| [Groq](/docs/compliance-connectors/setup/business-applications/groq) | `C1.2`, `CC6.2`, `CC6.3`, `CC6.5` |
| [Honeycomb](/docs/compliance-connectors/setup/observability/honeycomb) | `CC7.2` |
| [IBM MaaS360](/docs/compliance-connectors/setup/mdm/ibm-maas360) | `CC6.8`, `CC7.1` |
| [IDrive](/docs/compliance-connectors/setup/cloud-storage-provider/idrive) | `A1.2` |
| [Juro](/docs/compliance-connectors/setup/digital-signature/juro) | `CC6.2`, `CC6.3` |
| [Kion](/docs/compliance-connectors/setup/cspm/kion) | `CC7.1` |
| [LastPass SSO](/docs/compliance-connectors/setup/identity-and-sso/lastpass-sso) | `CC6.1`, `CC6.2`, `CC6.3` |
| [Legit Security](/docs/compliance-connectors/setup/vulnerability-scanning/legit-security) | `CC7.1` |
| [Lexion](/docs/compliance-connectors/setup/digital-signature/lexion) | `CC6.2`, `CC6.3` |
| [LinkSquares](/docs/compliance-connectors/setup/digital-signature/linksquares) | `CC6.2`, `CC6.3` |
| [Lookout](/docs/compliance-connectors/setup/endpoint-detection-and-response/lookout) | `CC6.8` |
| [Matillion](/docs/compliance-connectors/setup/data-export/matillion) | `CC6.2`, `CC6.3` |
| [MessageBird](/docs/compliance-connectors/setup/communications-platforms/messagebird) | `CC6.2`, `CC6.3` |
| [Microsoft 365 Copilot](/docs/compliance-connectors/setup/business-applications/microsoft-365-copilot) | `C1.2`, `CC6.2`, `CC6.3`, `CC6.5` |
| [Nagios](/docs/compliance-connectors/setup/observability/nagios) | `CC7.2` |
| [Nessus](/docs/compliance-connectors/setup/vulnerability-scanning/nessus) | `CC7.1` |
| [Netdata](/docs/compliance-connectors/setup/observability/netdata) | `CC6.2`, `CC6.3` |
| [Nextiva](/docs/compliance-connectors/setup/communications-platforms/nextiva) | `CC6.2`, `CC6.3` |
| [OpenVAS](/docs/compliance-connectors/setup/vulnerability-scanning/openvas) | `CC7.1` |
| [Orca Security](/docs/compliance-connectors/setup/cspm/orca-security) | `CC7.1` |
| [pCloud](/docs/compliance-connectors/setup/cloud-storage-provider/pcloud) | `CC6.2`, `CC6.3` |
| [Perplexity](/docs/compliance-connectors/setup/business-applications/perplexity) | `C1.2`, `CC6.2`, `CC6.3`, `CC6.5` |
| [Phylum](/docs/compliance-connectors/setup/vulnerability-scanning/phylum) | `CC7.1` |
| [Pipedream](/docs/compliance-connectors/setup/security-automation/pipedream) | `CC6.2`, `CC6.3` |
| [Plivo](/docs/compliance-connectors/setup/communications-platforms/plivo) | `CC6.2`, `CC6.3` |
| [Postmark](/docs/compliance-connectors/setup/communications-platforms/postmark) | `CC6.2`, `CC6.3` |
| [Precoro](/docs/compliance-connectors/setup/vendor-procurement/precoro) | `CC6.2`, `CC6.3` |
| [Rapid7 InsightCloudSec](/docs/compliance-connectors/setup/cspm/rapid7-insightcloudsec) | `CC7.1` |
| [Rapid7 InsightConnect](/docs/compliance-connectors/setup/security-automation/rapid7-insightconnect) | `CC7.4` |
| [Raygun](/docs/compliance-connectors/setup/observability/raygun) | `CC6.2`, `CC6.3` |
| [Replicate](/docs/compliance-connectors/setup/business-applications/replicate) | `C1.2`, `CC6.2`, `CC6.3`, `CC6.5` |
| [Responsive](/docs/compliance-connectors/setup/vendor-procurement/responsive) | `CC6.2`, `CC6.3` |
| [RightSignature](/docs/compliance-connectors/setup/digital-signature/rightsignature) | `CC6.2`, `CC6.3` |
| [Rippling MDM](/docs/compliance-connectors/setup/hris/rippling-mdm) | `CC6.8`, `CC7.1` |
| [RiskRecon](/docs/compliance-connectors/setup/vendor-procurement/riskrecon) | `CC7.1` |
| [RudderStack](/docs/compliance-connectors/setup/data-export/rudderstack) | `CC6.2`, `CC6.3` |
| [SAP Ariba](/docs/compliance-connectors/setup/vendor-procurement/sap-ariba) | `CC6.2`, `CC6.3` |
| [Scalefusion](/docs/compliance-connectors/setup/mdm/scalefusion) | `CC6.8`, `CC7.1` |
| [Signable](/docs/compliance-connectors/setup/digital-signature/signable) | `CC6.2`, `CC6.3` |
| [Signeasy](/docs/compliance-connectors/setup/digital-signature/signeasy) | `CC6.2`, `CC6.3` |
| [SignWell](/docs/compliance-connectors/setup/digital-signature/signwell) | `CC6.2`, `CC6.3` |
| [Skribble](/docs/compliance-connectors/setup/digital-signature/skribble) | `CC6.2`, `CC6.3` |
| [Sonrai Security](/docs/compliance-connectors/setup/cspm/sonrai-security) | `CC7.1` |
| [SOTI MobiControl](/docs/compliance-connectors/setup/mdm/soti-mobicontrol) | `CC6.8`, `CC7.1` |
| [SpotDraft](/docs/compliance-connectors/setup/digital-signature/spotdraft) | `CC6.2`, `CC6.3` |
| [Stitch](/docs/compliance-connectors/setup/data-export/stitch) | `CC6.2`, `CC6.3` |
| [Storj](/docs/compliance-connectors/setup/cloud-storage-provider/storj) | `C1.1`, `CC6.1` |
| [Stream Security](/docs/compliance-connectors/setup/cspm/stream-security) | `CC7.1` |
| [Sweet Security](/docs/compliance-connectors/setup/cspm/sweet-security) | `CC7.1` |
| [Swimlane](/docs/compliance-connectors/setup/security-automation/swimlane) | `CC7.4` |
| [Sysdig](/docs/compliance-connectors/setup/cspm/sysdig) | `CC7.1` |
| [Tenable Cloud Security](/docs/compliance-connectors/setup/vulnerability-scanning/tenable-cloud-security) | `CC7.1` |
| [Together AI](/docs/compliance-connectors/setup/business-applications/together-ai) | `C1.2`, `CC6.2`, `CC6.3`, `CC6.5` |
| [Twilio](/docs/compliance-connectors/setup/communications-platforms/twilio) | `CC6.2`, `CC6.3` |
| [Uptycs](/docs/compliance-connectors/setup/cspm/uptycs) | `CC7.1` |
| [Vonage](/docs/compliance-connectors/setup/communications-platforms/vonage) | `CC6.2`, `CC6.3` |
| [Wallarm](/docs/compliance-connectors/setup/vulnerability-scanning/wallarm) | `CC7.1` |
| [Yotta](/docs/compliance-connectors/setup/cloud-infrastructure/yotta) | `A1.2`, `C1.1`, `CC6.1`, `CC6.3`, `CC6.6`, `CC7.1`, `CC7.2` |
| [Z.ai (Zhipu GLM)](/docs/compliance-connectors/setup/business-applications/z-ai-zhipu-glm) | `C1.2`, `CC6.2`, `CC6.3`, `CC6.5` |
| [Zip](/docs/compliance-connectors/setup/vendor-procurement/zip) | `CC6.2`, `CC6.3` |
| [Zoho Sign](/docs/compliance-connectors/setup/digital-signature/zoho-sign) | `CC6.2`, `CC6.3` |
| [Zscaler Posture Control](/docs/compliance-connectors/setup/cspm/zscaler-posture-control) | `CC7.1` |
## Controls (34)
| Control | Title | Automated tests | Connectors |
| ------- | ------------------------------------------------------------------------------------------------------------------------------------- | --------------- | ---------- |
| `A1.1` | Management of processing capacity and use of system components to meet availability objectives | 7 | 18 |
| `A1.2` | Environmental protections, software, data back-up processes, and recovery infrastructure | 58 | 39 |
| `A1.3` | Testing of recovery plan procedures supporting system recovery | 3 | 7 |
| `C1.1` | Identification and maintenance of confidential information | 54 | 54 |
| `C1.2` | Disposal of confidential information to meet the entity's objectives related to confidentiality | 3 | 17 |
| `CC1.1` | Commitment to integrity and ethical values | 4 | 0 |
| `CC1.2` | Board independence from management and oversight of internal control | 1 | 0 |
| `CC1.3` | Management structures, reporting lines, authorities and responsibilities | 3 | 17 |
| `CC1.4` | Commitment to attract, develop, and retain competent individuals | 9 | 9 |
| `CC1.5` | Holding individuals accountable for their internal control responsibilities | 1 | 0 |
| `CC2.1` | Obtaining or generating and using relevant, quality information to support internal control | 6 | 28 |
| `CC2.2` | Internal communication of information, including objectives and responsibilities for internal control | 6 | 7 |
| `CC2.3` | Communication with external parties regarding matters affecting the functioning of internal control | 5 | 11 |
| `CC3.2` | Identification and analysis of risks to the achievement of objectives | 3 | 0 |
| `CC3.3` | Consideration of the potential for fraud in assessing risks | 1 | 0 |
| `CC3.4` | Identification and assessment of changes that could significantly affect internal control | 1 | 0 |
| `CC4.1` | Selection, development and performance of ongoing and/or separate evaluations of internal control components | 3 | 3 |
| `CC4.2` | Evaluation and timely communication of internal control deficiencies for corrective action | 1 | 0 |
| `CC5.3` | Deployment of control activities through policies and procedures | 4 | 0 |
| `CC6.1` | Logical access security software, infrastructure, and architectures over protected information assets | 202 | 131 |
| `CC6.2` | Registration and authorization of users before credentials are issued, and removal of credentials when access is no longer authorized | 56 | 324 |
| `CC6.3` | Authorization, modification, and removal of access based on roles, least privilege, and segregation of duties | 75 | 294 |
| `CC6.5` | Discontinuing protections over assets only after data has been removed or recovered | 5 | 33 |
| `CC6.6` | Logical access security measures against threats from sources outside system boundaries | 81 | 60 |
| `CC6.7` | Restriction and protection of information during transmission, movement, or removal | 58 | 47 |
| `CC6.8` | Prevention or detection of, and action on, unauthorized or malicious software | 34 | 71 |
| `CC7.1` | Detection and monitoring of configuration changes that introduce vulnerabilities and of newly discovered vulnerabilities | 82 | 144 |
| `CC7.2` | Monitoring of system components for anomalies indicative of malicious acts, natural disasters, and errors | 152 | 103 |
| `CC7.3` | Evaluation of security events to determine whether they are security incidents | 15 | 64 |
| `CC7.4` | Response to identified security incidents through a defined incident-response program | 17 | 65 |
| `CC7.5` | Activities to recover from identified security incidents | 3 | 18 |
| `CC8.1` | Authorization, design, development, testing, approval, and implementation of changes | 42 | 32 |
| `CC9.1` | Risk mitigation activities for potential business disruptions | 3 | 0 |
| `CC9.2` | Assessment and management of risks associated with vendors and business partners | 9 | 3 |
# Attestation (/docs/esscm/attestation)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Attestation
The Attestation tab displays supply chain verification information for each component, including the Safeguard Component Attestation Level (SCAL) which indicates the trustworthiness of a component's origin and build process.
## Overview
Attestation helps you understand:
* Where a component came from
* How it was built
* Whether it can be trusted
* If the build is reproducible
## SCAL Levels
Safeguard Component Attestation Level (SCAL) rates components from 0-5, where lower is better:
| Level | Name | Description |
| ---------- | ----------------------- | --------------------------------------------------------------------------------------------------------- |
| **SCAL 0** | Fully Attested | Complete attestation chain including reproducible builds, signatures, and transparency logs. Lowest risk. |
| **SCAL 1** | Attested Build & Source | Build provenance and source code are verified. |
| **SCAL 2** | Attested Component | Component has basic attestation (e.g., signed package). |
| **SCAL 3** | Known Component | Component is identified in registries but has no attestation. |
| **SCAL 4** | Partially Unknown | Component has limited verification. |
| **SCAL 5** | Unknown Component | Component origin cannot be verified. Highest risk. |
### SCAL Visual Indicators
| Level | Color | Meaning |
| ------ | --------- | -------------------------------- |
| SCAL 0 | 🟢 Green | Excellent - Fully verified |
| SCAL 1 | 🟢 Green | Good - Well attested |
| SCAL 2 | 🟡 Yellow | Fair - Partial attestation |
| SCAL 3 | 🟠 Orange | Poor - Known but unverified |
| SCAL 4 | 🟠 Orange | Very Poor - Limited verification |
| SCAL 5 | 🔴 Red | Critical - Unknown origin |
## Viewing Attestations
### In Explore SBOM
1. Open a project from the **Projects** page
2. Navigate to **Explore SBOM**
3. Click the **Attestation** tab
4. View SCAL levels for all components
### Attestation Dashboard
The Attestation tab displays:
| Column | Description |
| -------------------- | ----------------------------- |
| **Component** | Package name and version |
| **SCAL Level** | Attestation level (0-5) |
| **Attestation Type** | SLSA, Sigstore, In-toto, etc. |
| **Signature Status** | Verified/Unverified/None |
| **Provenance** | Build origin information |
### Filtering
* **By SCAL Level** - Show only specific levels
* **By Attestation Type** - Filter by SLSA, Sigstore, etc.
* **Unattested Only** - Show SCAL 3-5 components
* **Search** - Find specific components
## Attestation Details
Click on any component to view full attestation details:
### Summary
| Field | Description |
| ----------------------- | ---------------------------- |
| **SCAL Level** | Current attestation level |
| **Attestation Type** | Type of attestation found |
| **Last Verified** | When attestation was checked |
| **Verification Status** | Pass/Fail/Partial |
### Provenance Information
| Field | Description |
| --------------------- | ----------------------------- |
| **Build Platform** | Where component was built |
| **Source Repository** | Original source code location |
| **Build Trigger** | What initiated the build |
| **Build Timestamp** | When it was built |
| **Builder Identity** | Who/what built it |
### Signature Details
| Field | Description |
| --------------------- | ------------------------ |
| **Signature Type** | PGP, Sigstore, etc. |
| **Signer Identity** | Who signed the artifact |
| **Signature Status** | Valid/Invalid/Expired |
| **Certificate Chain** | Trust chain verification |
### Transparency Log
| Field | Description |
| ------------------- | -------------------------------- |
| **Log Entry** | Rekor or similar log entry |
| **Entry ID** | Unique log identifier |
| **Inclusion Proof** | Cryptographic proof of inclusion |
## Attestation Types
### SLSA Provenance
Supply-chain Levels for Software Artifacts:
| SLSA Level | SCAL Mapping | Requirements |
| ---------- | ------------ | --------------------------------- |
| SLSA 4 | SCAL 0 | Two-party review, hermetic builds |
| SLSA 3 | SCAL 0-1 | Hardened build platform |
| SLSA 2 | SCAL 1 | Hosted build, signed provenance |
| SLSA 1 | SCAL 2 | Documented build process |
### Sigstore
Keyless signing with:
* OIDC-based identity
* Fulcio certificates
* Rekor transparency log
* Timestamp authority
### In-toto
Framework providing:
* Layout definitions
* Step attestations
* Multi-party verification
* Custom policies
### Package Signatures
Traditional signatures:
* PGP/GPG signatures
* Package manager signatures
* Publisher certificates
## Improving SCAL Levels
### For SCAL 5 Components
1. **Identify alternatives** - Find similar packages with attestation
2. **Contact maintainers** - Request they add attestation
3. **Document risk** - If must use, add mitigation
4. **Consider forking** - Build your own attested version
### For SCAL 3-4 Components
1. **Check for updates** - Newer versions may have attestation
2. **Use Gold Directory** - Find pre-verified alternatives
3. **Add to watchlist** - Monitor for attestation additions
### For Your Own Packages
Add attestation using:
```bash
# Using Sigstore cosign
cosign sign --key cosign.key mypackage.tar.gz
# Using SLSA GitHub Action
- uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v1.4.0
```
## Attestation Policies
### Setting Requirements
Create policies requiring maximum SCAL levels:
1. Go to **Policies & Gates**
2. Create new rule
3. Set maximum SCAL level
4. Choose enforcement (warn/fail)
### Policy Examples
| Policy | Requirement |
| -------------------- | ------------------------------ |
| **Production** | All components SCAL 2 or lower |
| **Critical Systems** | All components SCAL 1 or lower |
| **Development** | Warn on SCAL 5 |
## Verification Process
When Safeguard analyzes a component:
1. **Fetch Attestations** - Download from registries, transparency logs
2. **Verify Signatures** - Check cryptographic validity
3. **Validate Claims** - Ensure claims match component
4. **Check Revocation** - Verify not revoked
5. **Assign SCAL** - Calculate attestation level
## API Access
```bash
# Get attestation data for a project
curl -X GET https://api.safeguard.sh/v1/projects/{id}/attestations \
-H "Authorization: Bearer $API_KEY"
# Get attestation details for a component
curl -X GET https://api.safeguard.sh/v1/projects/{id}/components/{component}/attestation \
-H "Authorization: Bearer $API_KEY"
# Verify a specific attestation
curl -X POST https://api.safeguard.sh/v1/attestations/verify \
-H "Authorization: Bearer $API_KEY" \
-d '{"attestation": "base64-encoded-attestation"}'
```
## Best Practices
### Monitoring
* Track SCAL distribution across projects
* Alert on new SCAL 5 components
* Review attestation trends
### Selection
* Prefer SCAL 0-1 packages
* Use Gold Directory for verified components
* Document exceptions for high-SCAL packages
### Compliance
* Set maximum SCAL requirements
* Include in security gates
* Report on attestation coverage
## Next Steps
* [Risk Score (RS)](/docs/esscm/risk-score)
* [Security Posture](/docs/esscm/security-posture)
* [Gold Directory](/docs/osm/gold-directory)
# AI Remediate (/docs/esscm/auto-fix)
# AI Remediate
AI Remediate uses Griffin AI to automatically generate and apply security fixes, reducing remediation time from days to minutes.
## How AI Remediate Works
1. **Analysis** - Griffin AI analyzes the vulnerability and your codebase
2. **Solution Generation** - AI determines the safest upgrade path
3. **Impact Assessment** - Breaking changes and compatibility checked
4. **PR Creation** - Automated Pull Request with all changes
5. **Validation** - Automated tests run to verify the fix
## AI Remediate Capabilities
### Dependency Upgrades
Griffin AI can automatically:
* Upgrade vulnerable packages to fixed versions
* Handle transitive dependency conflicts
* Update lock files appropriately
* Maintain compatibility with existing code
### Configuration Fixes
For configuration-based vulnerabilities:
* Update security headers
* Patch insecure defaults
* Apply recommended settings
### Code Modifications
In some cases, Griffin AI can:
* Replace deprecated function calls
* Update API usage patterns
* Apply security patches to code
## Using AI Remediate
### Single Vulnerability
1. Navigate to the vulnerability
2. Click **AI Remediate**
3. Review the proposed changes
4. Click **Create Pull Request**
### Bulk AI Remediate
Fix multiple vulnerabilities at once:
1. Select vulnerabilities to fix
2. Click **AI Remediate Selected**
3. Griffin AI batches compatible fixes
4. Review all changes
5. Create PRs (one per repository)
### Page-Level AI Remediate
From the Vulnerabilities page:
1. Click the **AI Remediate** button at the top
2. Griffin AI analyzes all fixable vulnerabilities
3. Review the comprehensive remediation plan
4. Approve and create Pull Requests
## AI Remediate Settings
Configure AI Remediate behavior in **Settings** → **AI Remediate**:
| Setting | Description |
| -------------------------- | --------------------------------------- |
| **Auto-Create PRs** | Automatically create PRs for safe fixes |
| **Require Approval** | Require manual approval before PRs |
| **Test Integration** | Run tests before creating PRs |
| **Breaking Change Policy** | How to handle breaking changes |
| **Branch Naming** | PR branch naming convention |
## Supported Ecosystems
| Ecosystem | Package Manager | AI Remediate Support |
| ---------- | ------------------- | -------------------- |
| JavaScript | npm, yarn, pnpm | Full |
| Python | pip, poetry, pipenv | Full |
| Java | Maven, Gradle | Full |
| Go | Go modules | Full |
| Rust | Cargo | Full |
| Ruby | Bundler | Full |
| .NET | NuGet | Full |
| PHP | Composer | Full |
## Breaking Change Detection
Griffin AI analyzes potential breaking changes:
* **Safe** - No breaking changes expected
* **Minor** - Minor API changes, low risk
* **Major** - Significant changes, review recommended
* **Critical** - High risk of breaking, manual review required
## PR Details
Auto-generated PRs include:
* Clear title with CVE reference
* Detailed description of the vulnerability
* Summary of changes made
* Breaking change warnings (if any)
* Test results (if configured)
* Links to relevant advisories
## Best Practices
* **Enable tests** - Catch regressions automatically
* **Start with safe fixes** - Build confidence gradually
* **Review major changes** - Don't auto-merge breaking changes
* **Monitor metrics** - Track fix success rate
# Code Quality (/docs/esscm/code-quality)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Code Quality
The Code Quality tab provides insights into maintainability, technical debt, and code health metrics for your project's dependencies.
## Overview
Code quality analysis helps you:
* Assess dependency maintainability
* Identify technical debt
* Evaluate community health
* Make informed upgrade decisions
* Track quality trends over time
## Quality Metrics
### Maintainability Index
A composite score (0-100) measuring how easy dependencies are to maintain:
| Score | Rating | Description |
| ------ | --------- | ---------------------------------------- |
| 80-100 | Excellent | Well-maintained, active development |
| 60-79 | Good | Regular updates, responsive maintainers |
| 40-59 | Fair | Occasional updates, some concerns |
| 20-39 | Poor | Infrequent updates, maintenance concerns |
| 0-19 | Critical | Abandoned or severely neglected |
### Calculation Factors
| Factor | Weight | Description |
| ----------------------- | ------ | ---------------------------- |
| **Update Frequency** | 25% | How often package is updated |
| **Issue Response Time** | 20% | Time to respond to issues |
| **PR Merge Time** | 15% | Time to merge pull requests |
| **Documentation** | 15% | Quality of documentation |
| **Test Coverage** | 15% | Available test coverage data |
| **Community Size** | 10% | Contributors and users |
## Dependency Health
### Health Indicators
| Indicator | Status | Meaning |
| ----------------- | -------- | --------------------------------------- |
| 🟢 **Healthy** | Active | Regular updates, responsive maintainers |
| 🟡 **Aging** | Stale | No updates in 6-12 months |
| 🟠 **Deprecated** | Warning | Officially deprecated by maintainer |
| 🔴 **Abandoned** | Critical | No updates in 12+ months |
### Viewing Health Status
1. Open project
2. Navigate to **Code Quality** tab
3. View dependency health overview
4. Click individual dependencies for details
## Technical Debt Assessment
### Debt Categories
| Category | Description |
| -------------------- | ---------------------------------- |
| **Version Debt** | Dependencies behind latest stable |
| **Security Debt** | Unfixed vulnerabilities |
| **Maintenance Debt** | Dependencies with poor maintenance |
| **License Debt** | License compliance issues |
### Debt Score
Each project receives a technical debt score:
* **Low Debt** (0-20) - Well-maintained, current
* **Moderate Debt** (21-50) - Some updates needed
* **High Debt** (51-80) - Significant updates required
* **Critical Debt** (81-100) - Major refactoring needed
## Analyzing Dependencies
### Dependency Cards
Each dependency shows:
| Field | Description |
| -------------------- | ------------------------------ |
| **Name & Version** | Package identifier |
| **Latest Version** | Most recent stable release |
| **Health Status** | Current maintenance status |
| **Last Updated** | When package was last released |
| **Maintainers** | Number of active maintainers |
| **Weekly Downloads** | Usage popularity |
### Deep Analysis
Click a dependency for detailed analysis:
* Version history
* Changelog highlights
* Breaking changes
* Migration guides
* Community metrics
## Recommendations
### Update Recommendations
Safeguard provides upgrade recommendations:
| Priority | Recommendation |
| ------------ | ----------------------------------------- |
| **Critical** | Security update required |
| **High** | Major version behind, upgrade recommended |
| **Medium** | Minor version available |
| **Low** | Patch available |
### Breaking Change Detection
Before upgrading, view:
* API changes
* Deprecated functions
* Required code changes
* Migration complexity
## Reports
### Code Quality Report
Generate comprehensive reports:
1. Click **Export** → **Code Quality Report**
2. Select report scope
3. Choose format (PDF, CSV)
4. Download report
### Report Contents
* Overall quality score
* Dependency health summary
* Technical debt breakdown
* Update recommendations
* Risk assessment
## Tracking Over Time
### Quality Trends
View how code quality changes:
* Monthly quality score trends
* Debt accumulation/reduction
* Dependency freshness over time
* Maintenance status changes
### Setting Goals
Set quality improvement goals:
1. Go to **Settings** → **Quality Goals**
2. Set target metrics
3. Track progress in dashboard
4. Receive alerts when off-track
## Integration with CI/CD
### Quality Gates
Quality thresholds are evaluated by the platform on the scans it runs for
your connected repositories. The CLI has no quality command, so there is no
pipeline step to add for this.
### Quality Metrics in PRs
View quality impact in pull requests:
* New dependencies added
* Dependencies updated
* Quality score change
* Technical debt impact
## API Access
```bash
# Get code quality metrics
curl -X GET https://api.safeguard.sh/v1/projects/{id}/code-quality \
-H "Authorization: Bearer $API_KEY"
# Get dependency health
curl -X GET https://api.safeguard.sh/v1/projects/{id}/dependencies/health \
-H "Authorization: Bearer $API_KEY"
```
## Best Practices
### Regular Reviews
* Review code quality monthly
* Address critical health issues promptly
* Plan dependency updates proactively
* Budget time for technical debt
### Update Strategy
* Update dependencies regularly
* Test updates in staging first
* Use semantic versioning
* Document breaking changes
### Monitoring
* Set up quality alerts
* Track trends over time
* Compare across projects
* Benchmark against industry
## Next Steps
* [Security Posture](/docs/esscm/security-posture)
* [Vulnerabilities](/docs/esscm/vulnerabilities)
* [AI Remediate](/docs/esscm/auto-fix)
# Dashboard (/docs/esscm/dashboard)
# Dashboard
The Enterprise ESCM Dashboard provides a comprehensive overview of your organization's software supply chain security posture.
## Overview Widgets
### Security Score
Your organization-wide security score (0-100) based on:
* Vulnerability severity and count
* Fix rate and remediation speed
* Policy compliance
* Component health
### Vulnerability Summary
Real-time vulnerability counts:
* Total vulnerabilities across all projects
* Breakdown by severity
* Trend over time (improving/declining)
* New vulnerabilities this week
### Top Risks
Prioritized list of highest-impact issues:
* Critical vulnerabilities in production
* Actively exploited CVEs
* Compliance violations
* Aging vulnerabilities
## Trend Charts
### Vulnerability Trends
Line chart showing:
* Total vulnerabilities over time
* By severity level
* Mean time to remediation
### Fix Rate
Track remediation progress:
* Vulnerabilities fixed per week
* AI Remediate vs manual fixes
* Time to fix by severity
### Component Health
Monitor dependency health:
* Outdated components over time
* License compliance trends
* New components added
## Project Overview
Table of all projects with key metrics:
| Column | Description |
| ------------- | ---------------------------- |
| **Project** | Project name |
| **Last Scan** | Most recent SBOM generation |
| **Critical** | Critical vulnerability count |
| **High** | High vulnerability count |
| **Score** | Project security score |
| **Status** | Compliant/Non-compliant |
## Alerts
Configure alerts for:
* New critical vulnerabilities
* Policy violations
* SBOM generation failures
* Score degradation
## Export & Reporting
* **PDF Export** - Formatted dashboard report
* **Scheduled Reports** - Weekly/monthly email reports
* **API Access** - Programmatic data access
# EO 14028 Compliance Checks (/docs/esscm/eo-14028-checks)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# EO 14028 Compliance Checks
Safeguard automatically validates your SBOMs against Executive Order 14028 requirements, ensuring your software meets federal cybersecurity standards.
## Overview
Executive Order 14028, "Improving the Nation's Cybersecurity," establishes requirements for software sold to the federal government. Safeguard helps you:
* Validate SBOM completeness against NTIA minimum elements
* Verify secure software development practices
* Generate compliance reports
* Track compliance status over time
## NTIA Minimum Elements
The NTIA defines minimum elements required in an SBOM:
### Data Fields
| Element | Description | Status |
| ---------------------------- | --------------------------------------------------------- | ------- |
| **Supplier Name** | Entity that creates, defines, and identifies components | Checked |
| **Component Name** | Designation assigned to a unit of software | Checked |
| **Version** | Identifier used to specify a change from previous version | Checked |
| **Other Unique Identifiers** | Other identifiers (e.g., PURL, CPE) | Checked |
| **Dependency Relationship** | Characterization of the relationship | Checked |
| **Author of SBOM Data** | Name of the entity that creates the SBOM | Checked |
| **Timestamp** | Date and time the SBOM was assembled | Checked |
### Automation Support
| Requirement | Description | Status |
| --------------------------- | ----------------------------------------------- | --------- |
| **Machine-Readable Format** | SPDX or CycloneDX format | Validated |
| **Automated Generation** | Ability to generate without manual intervention | Supported |
| **Automated Consumption** | Ability to ingest programmatically | Supported |
## Compliance Dashboard
View EO 14028 compliance status in the project dashboard:
### Compliance Score
Each project receives a compliance score based on:
* **Data Completeness** - Percentage of required fields populated
* **Format Compliance** - Valid SPDX/CycloneDX structure
* **Component Coverage** - All components have minimum data
* **Update Frequency** - SBOM freshness
### Compliance Status
| Status | Meaning |
| -------------------------- | ------------------------------- |
| ✅ **Compliant** | Meets all EO 14028 requirements |
| ⚠️ **Partially Compliant** | Some requirements not met |
| ❌ **Non-Compliant** | Missing critical requirements |
## Viewing Compliance Checks
### Project Level
1. Open a project from the **Projects** page
2. Navigate to the **Compliance** tab
3. View detailed compliance status
### Organization Level
1. Go to **Dashboard**
2. View the **EO 14028 Compliance** widget
3. See aggregate compliance across all projects
## Compliance Report
Generate compliance reports for federal procurement:
### Report Contents
1. **Executive Summary** - Overall compliance status
2. **SBOM Details** - Format, timestamp, author
3. **Component Analysis** - Data completeness per component
4. **Gap Analysis** - Missing or incomplete data
5. **Remediation Steps** - How to achieve compliance
### Generate Report
1. Open project
2. Click **Export** → **EO 14028 Compliance Report**
3. Select format (PDF, HTML, JSON)
4. Download report
### CLI Generation
There is no CLI command for this yet.
## Common Compliance Issues
### Missing Supplier Names
**Problem:** Components lack supplier identification
**Solution:**
* Use package URLs (PURLs) which include supplier info
* Manually add supplier data for proprietary components
* Contact vendors for accurate supplier information
### Incomplete Version Data
**Problem:** Components have vague or missing versions
**Solution:**
* Use lock files to capture exact versions
* Avoid version ranges in manifests
* Pin dependencies to specific versions
### Missing Unique Identifiers
**Problem:** Components lack PURLs or CPEs
**Solution:**
* Generate SBOMs from source with modern tools
* Enrich existing SBOMs with identifier lookup
* Use Safeguard enrichment features
### Outdated SBOMs
**Problem:** SBOM timestamp is stale
**Solution:**
* Enable continuous scanning
* Configure webhooks for automatic updates
* Set up scheduled SBOM generation
## SSDF Alignment
Safeguard also tracks alignment with the Secure Software Development Framework (SSDF):
| Practice | Description | Supported |
| --------- | ------------------------------ | ---------------------- |
| **PO.1** | Security Requirements | Via policies |
| **PS.1** | Protect Software | Vulnerability scanning |
| **PS.2** | Secure Development Environment | Integration tracking |
| **PW\.4** | Source Code Review | Via integrations |
| **PW\.6** | Verify Third-Party Components | SBOM analysis |
| **RV.1** | Identify Vulnerabilities | Continuous scanning |
| **RV.2** | Assess Vulnerabilities | Risk scoring |
| **RV.3** | Remediate Vulnerabilities | AI Remediate |
## Attestation Letters
Generate attestation letters for federal customers:
1. Go to **Compliance** → **Attestations**
2. Select project and version
3. Choose attestation template
4. Review and sign
5. Export signed attestation
## Best Practices
### For SBOM Generation
* Generate SBOMs from source code when possible
* Use CycloneDX 1.5+ or SPDX 2.3+ formats
* Include lock files in source repositories
* Automate SBOM generation in CI/CD
### For Compliance
* Review compliance status weekly
* Address gaps before federal delivery
* Keep SBOMs updated with each release
* Document compliance processes
### For Reporting
* Generate reports for each major release
* Archive reports for audit purposes
* Include compliance reports in delivery packages
* Maintain compliance history
## Federal Procurement
When selling to federal agencies:
1. **Pre-Contract:** Demonstrate compliance capability
2. **Contract Award:** Provide initial SBOMs
3. **Ongoing:** Supply updated SBOMs per contract terms
4. **Audit:** Provide compliance reports on request
## API Access
Access compliance data programmatically:
```bash
# Get compliance status
curl -X GET https://api.safeguard.sh/v1/projects/{id}/compliance/eo14028 \
-H "Authorization: Bearer $API_KEY"
# Generate compliance report
curl -X POST https://api.safeguard.sh/v1/projects/{id}/compliance/report \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"format": "pdf", "standard": "eo14028"}'
```
## Resources
* [Executive Order 14028 Full Text](https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/)
* [NTIA SBOM Minimum Elements](https://www.ntia.doc.gov/report/2021/minimum-elements-software-bill-materials-sbom)
* [NIST SSDF (SP 800-218)](https://csrc.nist.gov/publications/detail/sp/800-218/final)
## Next Steps
* [Explore SBOM](/docs/esscm/explore-sbom)
* [Compliance Overview](/docs/compliance)
* [Portal Compliance](/docs/portal/compliance)
# Explore SBOM (/docs/esscm/explore-sbom)
# Explore SBOM
Once your SBOM is generated, explore every component, dependency, and potential risk through the Project Overview page.
## Project Overview
Click on any project from the Projects list to access the detailed Project Overview page. The page is organized into multiple tabs for comprehensive analysis.
## Info Tab
The Info tab provides at-a-glance information about your project:
### Project Details
| Field | Description |
| -------------------------- | --------------------------------------------------- |
| **Project Name** | The name of your project |
| **Project Version** | Current version or branch (e.g., main) |
| **Created On** | Date and time the project was created |
| **Created By** | User who created the project |
| **Generation Method** | How the SBOM was generated (SCM, Container, Manual) |
| **Source Code Repository** | Link to the source repository |
| **Branch/Tag** | The branch or tag that was scanned |
| **Organization** | Organization the project belongs to |
### Visual Analytics
The Info tab includes several charts:
* **Findings by Severity** - Distribution of findings across severity levels
* **Vulnerabilities by Severity** - Critical, High, Medium, Low breakdown
* **Supply Chain Risk by Components** - Component-level risk assessment
* **Findings by Gate** - Policy gate pass/fail status
## Attestation Tab
View supply chain attestation and provenance verification:
### Attestation Score vs Risk Score
| Score Type | Description |
| --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Attestation Score** | Measures the integrity and trustworthiness of a package based on malicious package detection, supply chain verification, and provenance attestation |
| **Risk Score** | Overall security scoring based on the package itself, including vulnerability count, severity distribution, maintenance status, and community trust |
* **SLSA Provenance** - Supply chain Levels for Software Artifacts verification
* **Sigstore Signatures** - Code signing verification status
* **Build Reproducibility** - Build attestation information
* **Malicious Package Detection** - Detection of potentially malicious packages
## Dependencies Tab
View the complete dependency tree:
### Tree View
Hierarchical visualization showing:
* Parent-child relationships
* Dependency depth
* Version information
* Vulnerability indicators
### Table View
Sortable and filterable list with:
* Component name and version
* License type
* Vulnerability count
* Last updated date
## Provenance Tab
Track the origin and build information of components:
* **Source Repository** - Where the code came from
* **Build System** - How it was built
* **Commit Information** - Git commit details
* **Build Timestamps** - When builds occurred
## Vulnerabilities Tab
Comprehensive vulnerability management:
* Total vulnerability count
* Breakdown by severity (Critical, High, Medium, Low)
* Affected component details
* Fix recommendations
* **AI Remediate** button for automated fixes
[Learn more about Vulnerabilities →](/docs/esscm/vulnerabilities)
## Mitigations Tab
Track applied mitigations and accepted risks:
* Active mitigations
* Risk acceptances with expiration dates
* False positive markings
* Mitigation history
## Security Posture Tab
Overall security assessment:
* Security posture score
* Compliance status
* Security recommendations
* Trend analysis
## Code Quality Tab
Code quality metrics:
* Code quality issues
* Maintainability index
* Technical debt assessment
## Suppliers & Licenses Tab
License compliance and supplier information:
* License distribution
* License compatibility analysis
* Supplier information
* Attribution requirements
## Findings Tab
All findings across security gates and policies:
* Gate status (pass/fail)
* Policy violations
* Recommended actions
* Finding history
## Export Options
Export your SBOM data in 30+ formats:
* **SPDX** - JSON, XML, RDF
* **CycloneDX** - JSON, XML
* **CSV** - Spreadsheet compatible
* **Excel** - Full workbook with multiple sheets
* **PDF** - Formatted report
* **JSON** - Raw data export
# Findings (/docs/esscm/findings)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Findings
The Findings tab consolidates all security issues discovered during analysis, including policy violations, gate failures, and other actionable findings.
## Overview
Findings provide a unified view of:
* Security policy violations
* Gate check failures
* Configuration issues
* Compliance gaps
* Best practice recommendations
## Finding Types
### Security Findings
| Type | Description | Severity |
| --------------------- | ------------------------------- | ------------- |
| **Vulnerability** | Known CVE in component | Based on CVSS |
| **Malicious Package** | Potentially malicious component | Critical |
| **Supply Chain Risk** | Attestation or provenance issue | High-Critical |
| **Secret Exposure** | Credentials in code/config | Critical |
### Policy Findings
| Type | Description | Severity |
| --------------------- | --------------------------- | ----------- |
| **License Violation** | Prohibited license detected | Medium-High |
| **Version Violation** | Version policy not met | Low-Medium |
| **Age Violation** | Component too old | Medium |
| **Maintenance Issue** | Abandoned dependency | Medium |
### Compliance Findings
| Type | Description | Severity |
| ------------------------ | ------------------------ | -------- |
| **SBOM Incomplete** | Missing required data | Medium |
| **EO 14028 Gap** | Federal compliance issue | High |
| **NTIA Element Missing** | Minimum element absent | Medium |
## Viewing Findings
### Findings Tab
1. Open project
2. Navigate to **Findings** tab
3. View all findings for the project
### Finding Card
Each finding displays:
| Field | Description |
| ---------------------- | ------------------------ |
| **Title** | Brief description |
| **Type** | Category of finding |
| **Severity** | Critical/High/Medium/Low |
| **Status** | Open/Resolved/Mitigated |
| **Affected Component** | Component(s) involved |
| **Gate** | Which gate caught this |
| **First Seen** | When first detected |
## Filtering and Sorting
### Filter Options
| Filter | Options |
| ------------- | --------------------------------- |
| **Severity** | Critical, High, Medium, Low |
| **Type** | Vulnerability, Policy, Compliance |
| **Status** | Open, Resolved, Mitigated |
| **Gate** | Specific policy gate |
| **Component** | Specific component |
### Sort Options
* Severity (highest first)
* Date discovered (newest first)
* Component name
* Status
## Finding Details
Click a finding for full details:
### Detail View
| Section | Contents |
| ------------------- | ----------------------------- |
| **Summary** | Issue description and context |
| **Impact** | What this finding means |
| **Evidence** | How it was detected |
| **Recommendations** | How to resolve |
| **References** | Related CVEs, articles |
| **History** | Timeline of changes |
### Actions
From the detail view:
* **Resolve** - Mark as fixed
* **Mitigate** - Add mitigation
* **Suppress** - Hide from view
* **Assign** - Assign to team member
* **Export** - Export finding data
## Managing Findings
### Status Workflow
```
Open → In Progress → Resolved
↓ ↓
Mitigated Suppressed
```
### Bulk Actions
Select multiple findings to:
* Change status
* Assign to user
* Add to sprint/ticket
* Export selected
* Bulk mitigate
### Assignment
Assign findings to team members:
1. Select finding(s)
2. Click **Assign**
3. Select team member
4. Add optional note
5. Assignee receives notification
## Gate Integration
Findings relate to policy gates:
### Gate Status
| Status | Meaning |
| ----------- | ------------------------------------ |
| **Pass** | No findings violate gate |
| **Fail** | Findings exceed gate threshold |
| **Warning** | Findings present but below threshold |
### Viewing Gate Results
1. Go to **Policies & Gates**
2. See overall gate status
3. Click gate for related findings
## Notifications
### Alert Configuration
Configure alerts for findings:
1. Go to **Settings** → **Notifications**
2. Set finding alert rules
3. Choose delivery method
### Alert Triggers
| Trigger | Description |
| ---------------- | --------------------------- |
| **New Critical** | Any new critical finding |
| **New High** | New high severity finding |
| **Threshold** | Finding count exceeds limit |
| **Gate Failure** | Security gate fails |
## Reports
### Findings Report
Generate findings reports:
1. Click **Export** → **Findings Report**
2. Select filters and date range
3. Choose format
4. Download report
### Report Contents
* Executive summary
* Findings by severity
* Findings by type
* Resolution status
* Trend analysis
* Recommendations
## API Access
```bash
# List findings for a project
curl -X GET "https://api.safeguard.sh/v1/projects/{id}/findings?severity=critical,high" \
-H "Authorization: Bearer $API_KEY"
# Get finding details
curl -X GET https://api.safeguard.sh/v1/findings/{finding_id} \
-H "Authorization: Bearer $API_KEY"
# Update finding status
curl -X PATCH https://api.safeguard.sh/v1/findings/{finding_id} \
-H "Authorization: Bearer $API_KEY" \
-d '{"status": "resolved"}'
```
## Integration with Issue Trackers
Export findings to external systems:
| Integration | Actions |
| ----------------- | -------------------------- |
| **JIRA** | Create issues, sync status |
| **GitHub Issues** | Create/link issues |
| **Azure DevOps** | Create work items |
| **ServiceNow** | Create incidents |
See [JIRA Integration](/docs/esscm/jira-integration) for details.
## Best Practices
### Triage
* Review critical findings daily
* Triage high findings weekly
* Have clear ownership
* Set SLAs by severity
### Resolution
* Fix critical findings immediately
* Document mitigations properly
* Verify fixes with rescans
* Track resolution metrics
### Prevention
* Enable security gates
* Review findings in PRs
* Train team on common issues
* Improve processes based on patterns
## Next Steps
* [Vulnerabilities](/docs/esscm/vulnerabilities)
* [Policies & Gates](/docs/esscm/policies-gates)
* [JIRA Integration](/docs/esscm/jira-integration)
# Generate SBOM (/docs/esscm/generate-sbom)
# Generate SBOM
Enterprise Software Supply Chain Manager (ESSCM) supports generating SBOMs from multiple source types with continuous scanning and intelligent analysis.
## Integrations Page Overview
Navigate to **Integrations** from the sidebar to access all available integration options. The page includes tabs for different functions:
* **Add Project/Product** - Connect new integrations and add projects
* **Deployment** - Manage deployment configurations
* **Configure Scanner** - Set up scanner settings
* **Notification** - Configure alerts and notifications
You can filter integrations by type using the filter buttons: **All**, **Source Code (SCM)**, **Container Image**, **AI Model**, **Upload**, or **Reset**.
## Available Integrations
### Source Code Management (SCM)
| Integration | Description |
| ------------- | ------------------------------------------------ |
| **Bitbucket** | Connect public or private Bitbucket repositories |
| **Git** | Generic Git URL for any Git repository |
| **GitHub** | Connect public and private GitHub repositories |
| **GitLab** | Self-hosted or cloud GitLab instances |
### Container Images
| Integration | Description |
| -------------------- | ----------------------------------------------- |
| **Amazon ECR** | AWS Elastic Container Registry images |
| **Docker Hub** | Docker Hub repositories |
| **GCP Cloud Source** | Google Cloud container sources |
| **OCI Registry** | Open Container Initiative compatible registries |
### AI Models
| Integration | Description |
| ---------------- | -------------------------- |
| **Hugging Face** | Connect and scan AI models |
### File Uploads
| Integration | Description |
| ------------------------ | --------------------------------------------------------------- |
| **Upload CSAF/VEX** | Upload CSAF or VEX files for analysis |
| **Upload APK** | Upload and scan Android APK files |
| **Upload Manifest File** | Upload package manifests (package.json, requirements.txt, etc.) |
***
## Example: Adding a Bitbucket Repository
This example demonstrates how to connect a Bitbucket repository. The process differs slightly for public vs private repositories.
### Adding a Public Repository
#### Step 1: Click Connect on Bitbucket
From the Integrations page, click the **Connect** button on the Bitbucket card.
#### Step 2: Enter Repository Details
1. Select **Public** tab
2. Enter a **Name** for this configuration
3. Optionally add a **Description**
4. Enter the **public URL** of the repository (e.g., `https://bitbucket.org/atlassian/aui`)
5. The system will validate the URL and show "Repository URL is valid"
6. Click **Add** to add the URL to the list
#### Step 3: Review Added URLs
Your added repository URLs will appear in the **Added URLs** table showing the Repository URL and when it was added.
Click **Next** to proceed to the review step.
#### Step 4: Review & Configure Repositories
Review and configure the repositories to be connected:
* Select which repositories to include using checkboxes
* Configure **Branch/Tag** for each repository
* Set the **Project Name** (defaults to repository name)
* Set the **Version** (defaults to 1.0.0)
Click **Connect** to complete the integration.
#### Step 5: View Configuration
After connecting, your configuration appears in the **Project Configurations** table at the bottom of the Integrations page.
***
### Adding a Private Repository
For private repositories, you'll need to provide authentication credentials.
#### Step 1: Click Connect on Bitbucket
From the Integrations page, click the **Connect** button on the Bitbucket card.
#### Step 2: Enter Credentials
1. Select **Private** tab
2. Enter a **Name** for this configuration
3. Optionally add a **Description**
4. Enter your **Bitbucket Credentials**:
* **Username** - Your Bitbucket username
* **Access Token / App Password** - Your Bitbucket app password or access token
5. Click **Verify Credentials**
#### Step 3: Credentials Verified
Once credentials are verified successfully, you'll see "Credentials verified successfully!" message. Click **Next** to proceed.
#### Step 4: Select Workspace and Repositories
1. **Select Workspace** - Choose the Bitbucket workspace to access repositories from
2. **Review & Configure Repositories** - Select repositories, configure branch/tag, project name, and version
Click **Connect** to complete the integration.
#### Step 5: View All Configurations
Your new configuration will appear alongside any existing configurations in the **Project Configurations** table.
***
## Viewing Your Projects
After adding integrations, navigate to **Projects** from the sidebar to see all your added projects. The Projects table displays:
| Column | Description |
| ------------------- | ------------------------------------------- |
| **Project Name** | Name of the project (click to view details) |
| **Version** | Version tag or branch |
| **Status** | Active or inactive status |
| **Organizations** | Organization assignment |
| **Findings** | Summary counts (E, C, H, M, L) |
| **Vulnerabilities** | Vulnerability count |
Use the search bar, column selector, and export options to manage your projects list.
## Generation Options
| Option | Description |
| ---------------------------- | ----------------------------------------- |
| **Project Name** | Identifier for this SBOM |
| **Version** | Version tag (auto-detected from git tags) |
| **Branch/Tag** | Specific branch or tag to scan |
| **Include Dev Dependencies** | Include development dependencies |
| **Deep Analysis** | Enable Griffin AI deep analysis |
## Generation Times
| Project Size | Approximate Time |
| ------------------------------ | ---------------- |
| Small (under 100 dependencies) | Under 1 minute |
| Medium (100-500 dependencies) | 2-5 minutes |
| Large (500+ dependencies) | 5-15 minutes |
## Continuous Scanning
Safeguard performs daily continuous scanning of all your projects to detect new vulnerabilities as they are disclosed. This ensures your security posture is always up-to-date.
Enable additional scanning triggers:
* **On Push** - Scan on every commit to monitored branches
* **Scheduled** - Daily, weekly, or custom schedule
* **On Release** - Scan when new tags are created
## CLI Usage
```bash
# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash
# Open the terminal, then type /login and /scan .
safeguard
# Or scan from the command line, writing results under ./output
safeguard scan --dir .
```
A scan from the interactive terminal while signed in uploads the SBOM and
findings to the platform; your source never leaves the machine.
[Full CLI documentation](/docs/cli/usage)
# Enterprise Software Supply Chain Manager (ESSCM) (/docs/esscm)
# Enterprise Software Supply Chain Manager (ESSCM)
Your code, containers, AI models, and CI/CD pipelines—all potential attack vectors. Enterprise ESSCM delivers complete visibility with continuous scanning, intelligent prioritization, and AI Remediate capabilities.
**Know what's in your software before attackers do.**
## Key Features
### Complete Visibility
* **Source Code Analysis** - Scan repositories across GitHub, GitLab, Bitbucket, and Azure Repos
* **Container Scanning** - Analyze images from Docker Hub, ECR, GCR, ACR, and private registries
* **AI Model Dependencies** - Track ML model dependencies and their vulnerabilities
* **CI/CD Pipeline Security** - Integrate security into your build process
### Intelligent Prioritization
* **Risk-Based Scoring** - Focus on what matters most with Griffin AI analysis
* **Reachability Analysis** - Understand if vulnerabilities are actually exploitable
* **Exploit Intelligence** - Know which CVEs are being actively exploited
### AI Remediate
* **Automated Pull Requests** - Griffin AI generates fix PRs automatically
* **Upgrade Recommendations** - Smart suggestions for safe version upgrades
* **Breaking Change Detection** - Know the impact before you upgrade
## What's Included
## Getting Started
1. [Create an account](/docs/getting-started/create-account)
2. [Configure your credentials](/docs/getting-started/onboarding-workflow)
3. [Generate your first SBOM](/docs/esscm/generate-sbom)
4. [Review vulnerabilities](/docs/esscm/vulnerabilities)
5. [Enable AI Remediate](/docs/esscm/auto-fix)
## Supported Sources
| Source Type | Examples |
| ----------------- | ------------------------------------------------ |
| Source Code | GitHub, GitLab, Bitbucket, Azure Repos |
| Container Images | Docker Hub, ECR, GCR, ACR, private registries |
| AI Models | TensorFlow, PyTorch, Hugging Face models |
| CI/CD Pipelines | GitHub Actions, GitLab CI, Jenkins, Azure DevOps |
| Package Manifests | package.json, requirements.txt, pom.xml, go.mod |
| Binaries | Windows (.exe, .dll), Android (.apk) |
# JIRA Integration (/docs/esscm/jira-integration)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# JIRA Integration
Integrate Safeguard with Atlassian JIRA to automatically create issues for vulnerabilities and track remediation progress.
## Overview
JIRA integration enables:
* Automatic issue creation for findings
* Bidirectional status synchronization
* Custom field mapping
* Workflow automation
* Team assignment rules
## Supported JIRA Versions
| Version | Support |
| -------------------- | -------------- |
| **JIRA Cloud** | ✅ Full Support |
| **JIRA Server 8.x+** | ✅ Full Support |
| **JIRA Data Center** | ✅ Full Support |
## Setting Up Integration
### Step 1: Create API Token (JIRA Cloud)
1. Go to [Atlassian Account Settings](https://id.atlassian.com/manage-profile/security/api-tokens)
2. Click **Create API token**
3. Enter a label (e.g., "Safeguard Integration")
4. Copy the token (shown only once)
### Step 1: Create Personal Access Token (JIRA Server/Data Center)
1. Go to your JIRA profile → **Personal Access Tokens**
2. Click **Create token**
3. Enter a name and expiry
4. Copy the token
### Step 2: Configure in Safeguard
1. Go to **Settings** → **Integrations** → **JIRA**
2. Click **Connect JIRA**
3. Enter connection details:
| Field | Description |
| ------------- | -------------------------------------------- |
| **JIRA URL** | Your JIRA instance URL |
| **Email** | Your JIRA email (Cloud) or username (Server) |
| **API Token** | The token you created |
4. Click **Test Connection**
5. Click **Save**
### Step 3: Configure Project Mapping
Map Safeguard organizations to JIRA projects:
1. Click **Configure Projects**
2. For each organization, select:
* **JIRA Project** - Target project for issues
* **Issue Type** - Bug, Task, Security, etc.
* **Default Assignee** - Auto-assign issues
## Automatic Issue Creation
### Trigger Rules
Configure when issues are created:
| Trigger | Description |
| ------------------------------ | ---------------------------------- |
| **New Critical Vulnerability** | Create issue for critical CVEs |
| **New High Vulnerability** | Create issue for high severity |
| **Gate Failure** | Create issue when gate fails |
| **Policy Violation** | Create issue for policy violations |
### Issue Template
Customize the issue content:
```
Summary: [SEVERITY] CVE-XXXX-XXXXX in {component}
Description:
*Vulnerability Details*
- CVE: {cve_id}
- Severity: {severity}
- CVSS Score: {cvss_score}
- Component: {component}@{version}
- Project: {project_name}
*Description*
{vulnerability_description}
*Remediation*
{remediation_advice}
*Links*
- [View in Safeguard|{safeguard_url}]
- [NVD Entry|{nvd_url}]
```
### Custom Fields
Map Safeguard data to JIRA custom fields:
| Safeguard Field | JIRA Field |
| --------------- | ----------------------- |
| Severity | Priority / Custom Field |
| CVE ID | Custom Field |
| Component | Labels / Custom Field |
| CVSS Score | Custom Field |
| Project | Labels |
## Status Synchronization
### JIRA → Safeguard
When JIRA issues are updated:
| JIRA Status | Safeguard Action |
| --------------- | ----------------------------------- |
| Done / Resolved | Mark finding as resolved |
| Won't Fix | Create mitigation (risk acceptance) |
| Duplicate | Link to existing finding |
### Safeguard → JIRA
When findings are updated:
| Safeguard Action | JIRA Update |
| ---------------- | ------------------------ |
| Finding resolved | Transition to Done |
| Mitigation added | Add comment with details |
| Severity changed | Update priority |
### Configuring Sync
1. Go to JIRA integration settings
2. Click **Status Mapping**
3. Map statuses between systems
4. Enable bidirectional sync
## Manual Issue Creation
Create JIRA issues manually:
### From Findings Tab
1. Select finding(s)
2. Click **Actions** → **Create JIRA Issue**
3. Review/edit issue details
4. Click **Create**
### From Vulnerability Details
1. Open vulnerability details
2. Click **Create JIRA Issue** button
3. Customize as needed
4. Click **Create**
## Bulk Operations
### Bulk Issue Creation
Create issues for multiple findings:
1. Filter findings
2. Select multiple items
3. Click **Bulk Actions** → **Create JIRA Issues**
4. Review and confirm
### Bulk Linking
Link existing JIRA issues:
1. Select findings
2. Click **Link JIRA Issues**
3. Enter JIRA issue keys
4. Confirm links
## Workflow Automation
### JIRA Automation Rules
Create JIRA automation rules that trigger on Safeguard issues:
**Example: Auto-assign security issues**
```
When: Issue created
If: Labels contains "safeguard-critical"
Then: Assign to Security Team
```
**Example: Due date based on severity**
```
When: Issue created
If: Labels contains "safeguard"
Then: Set due date based on priority
- Critical: +3 days
- High: +7 days
- Medium: +14 days
```
### Safeguard Automation
Configure automatic actions in Safeguard:
| Condition | Action |
| ----------------- | --------------- |
| JIRA issue closed | Rescan project |
| Issue reopened | Reopen finding |
| Comment added | Sync to finding |
## Reporting
### JIRA Dashboards
Create JIRA dashboards for security metrics:
* Open security issues by severity
* Issues by component
* Remediation velocity
* SLA compliance
### JQL Queries
Use JQL to find Safeguard issues:
```sql
# All Safeguard issues
labels = "safeguard"
# Critical security issues
labels = "safeguard-critical" AND status != Done
# Issues for specific project
labels = "safeguard" AND labels = "project-myapp"
# Overdue security issues
labels = "safeguard" AND due < now() AND status != Done
```
## Troubleshooting
### Connection Issues
| Issue | Solution |
| ----------------------- | --------------------------------------- |
| "Authentication failed" | Verify API token is correct |
| "Project not found" | Check project key exists |
| "Permission denied" | Verify user has create issue permission |
### Sync Issues
| Issue | Solution |
| --------------------- | --------------------------- |
| Status not updating | Check webhook configuration |
| Duplicate issues | Enable duplicate detection |
| Missing custom fields | Verify field mapping |
## API Access
```bash
# List JIRA issues for a finding
curl -X GET https://api.safeguard.sh/v1/findings/{id}/jira-issues \
-H "Authorization: Bearer $API_KEY"
# Create JIRA issue from finding
curl -X POST https://api.safeguard.sh/v1/findings/{id}/jira-issues \
-H "Authorization: Bearer $API_KEY" \
-d '{"project_key": "SEC", "issue_type": "Bug"}'
```
## Best Practices
### Issue Management
* Use consistent labels for filtering
* Set appropriate priorities
* Include all relevant details
* Link related issues
### Workflow
* Define clear status transitions
* Set SLAs based on severity
* Assign to appropriate teams
* Track resolution metrics
### Security
* Use dedicated service account
* Limit API token permissions
* Rotate tokens regularly
* Audit integration activity
## Next Steps
* [Findings](/docs/esscm/findings)
* [Vulnerabilities](/docs/esscm/vulnerabilities)
* [AI Remediate](/docs/esscm/auto-fix)
# Mitigations (/docs/esscm/mitigations)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Mitigations
The Mitigations tab allows you to track applied fixes, document risk acceptances, and manage false positives for vulnerabilities in your projects.
## Overview
Not every vulnerability requires immediate remediation. Mitigations help you:
* Document why certain vulnerabilities don't apply
* Track accepted risks with expiration dates
* Mark false positives
* Record applied workarounds
* Maintain audit trails
## Accessing Mitigations
1. Open a project from the **Projects** page
2. Navigate to the **Mitigations** tab
3. View all mitigation records
## Mitigation Types
### Risk Acceptance
Accept the risk of a vulnerability when:
* Vulnerability is not exploitable in your context
* Cost of remediation exceeds risk
* Fix would break critical functionality
* Temporary acceptance while planning remediation
### False Positive
Mark as false positive when:
* Scanner incorrectly identified the vulnerability
* Component is not actually present
* Version detection was incorrect
* Different component with same name
### Workaround Applied
Document workarounds when:
* Configuration change mitigates the issue
* Network controls prevent exploitation
* Compensating controls are in place
* Partial remediation applied
### Not Applicable
Mark as not applicable when:
* Vulnerable code path is not used
* Feature is disabled
* Component is only in development
* Platform doesn't apply
## Creating a Mitigation
### From Vulnerabilities Tab
1. Navigate to **Vulnerabilities** tab
2. Find the vulnerability to mitigate
3. Click the **⋮** menu → **Add Mitigation**
4. Fill in mitigation details
5. Click **Save**
### Mitigation Form
| Field | Description | Required |
| ------------------- | ------------------------------------------------ | -------- |
| **Type** | Risk Acceptance, False Positive, Workaround, N/A | Yes |
| **Justification** | Reason for the mitigation | Yes |
| **Expiration Date** | When to review/expire (Risk Acceptance only) | No |
| **Approved By** | Who approved this mitigation | Yes |
| **Evidence** | Supporting documentation | No |
| **Scope** | This version only, or all versions | Yes |
## Managing Mitigations
### Mitigation Status
| Status | Meaning |
| -------------- | ---------------------------------- |
| **Active** | Mitigation is currently in effect |
| **Expired** | Past expiration date, needs review |
| **Revoked** | Manually cancelled |
| **Superseded** | Replaced by fix or new mitigation |
### Editing Mitigations
1. Click on a mitigation to view details
2. Click **Edit**
3. Update fields as needed
4. Click **Save**
### Revoking Mitigations
1. Click on a mitigation
2. Click **Revoke**
3. Provide revocation reason
4. Mitigation becomes inactive
## Bulk Mitigations
Apply mitigations to multiple vulnerabilities:
1. In Vulnerabilities tab, select multiple items
2. Click **Bulk Actions** → **Add Mitigation**
3. Fill in common mitigation details
4. Click **Apply to Selected**
## Mitigation Policies
Create policies to auto-apply mitigations:
### Policy Types
| Policy | Description |
| ---------------------- | ---------------------------------- |
| **CVE Exemptions** | Specific CVEs always mitigated |
| **Package Exemptions** | Specific packages always mitigated |
| **Severity Threshold** | Auto-accept below severity level |
| **Development Only** | Auto-accept in dev environments |
### Creating a Policy
1. Go to **Settings** → **Mitigation Policies**
2. Click **+ New Policy**
3. Configure policy rules
4. Set scope (organization or project)
5. Click **Save**
## Expiration and Review
### Setting Expiration
For risk acceptances, set an expiration date:
* **30 days** - Short-term acceptance
* **90 days** - Quarterly review cycle
* **180 days** - Semi-annual review
* **365 days** - Annual review
* **Custom** - Specific date
### Expiration Notifications
Safeguard notifies you before expiration:
* 14 days before expiration
* 7 days before expiration
* On expiration date
### Reviewing Expired Mitigations
1. Go to **Mitigations** tab
2. Filter by **Status: Expired**
3. For each expired mitigation:
* Extend expiration if still valid
* Revoke if no longer applicable
* Upgrade to fix if available
## Audit Trail
All mitigation actions are logged:
| Event | Logged Information |
| ------------ | ------------------------ |
| **Created** | Who, when, justification |
| **Modified** | Who, when, changes |
| **Approved** | Approver, timestamp |
| **Expired** | Automatic expiration |
| **Revoked** | Who, when, reason |
### Viewing Audit Trail
1. Click on a mitigation
2. Click **History** tab
3. View all changes
## Reporting
### Mitigation Reports
Generate mitigation reports:
1. Go to **Reports** → **Mitigations**
2. Select date range and filters
3. Choose format (PDF, CSV, Excel)
4. Download report
### Report Contents
* Active mitigations summary
* Expired mitigations requiring review
* Mitigation by type breakdown
* Approver summary
* Expiration timeline
## API Access
Manage mitigations via API:
```bash
# List mitigations for a project
curl -X GET https://api.safeguard.sh/v1/projects/{id}/mitigations \
-H "Authorization: Bearer $API_KEY"
# Create a mitigation
curl -X POST https://api.safeguard.sh/v1/projects/{id}/mitigations \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{
"vulnerability_id": "CVE-2024-1234",
"type": "risk_acceptance",
"justification": "Not exploitable in our configuration",
"expires_at": "2025-06-01T00:00:00Z"
}'
```
## Best Practices
### Documentation
* Provide detailed justifications
* Reference external analysis if available
* Include ticket/issue numbers
* Document compensating controls
### Review Process
* Require approval for risk acceptances
* Set appropriate expiration dates
* Review expirations promptly
* Re-evaluate when context changes
### Organization
* Use consistent mitigation categories
* Define organizational policies
* Train team on mitigation process
* Regular mitigation audits
## Integration with Gates
Mitigations affect security gate results:
* Active mitigations exclude vulnerabilities from gate failures
* Expired mitigations do not exclude vulnerabilities
* Policy-based mitigations apply automatically
## Next Steps
* [Vulnerabilities](/docs/esscm/vulnerabilities)
* [Policies & Gates](/docs/esscm/policies-gates)
* [AI Remediate](/docs/esscm/auto-fix)
# Organization & User Management (/docs/esscm/organization-management)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Organization & User Management
Configure your organizational structure, manage teams, and control user access across Safeguard products.
## Organization Structure
### Overview
Safeguard uses a hierarchical structure:
```
Tenant
└── Organization(s)
└── Project(s)
└── Version(s)
```
### Tenant
The top-level container for your company:
* Single billing entity
* Global settings
* SSO configuration
* API key management
### Organizations
Logical groupings within your tenant:
* Separate business units
* Different teams
* Project portfolios
* Access boundaries
### Projects
Individual software projects:
* SBOM generation targets
* Security scanning units
* Policy application scope
## Managing Organizations
### Creating an Organization
1. Go to **Settings** → **Organizations**
2. Click **+ New Organization**
3. Enter details:
| Field | Description |
| --------------- | --------------------- |
| **Name** | Organization name |
| **Description** | Purpose/description |
| **Contact** | Primary contact email |
4. Click **Create**
### Organization Settings
Configure per-organization settings:
| Setting | Description |
| ------------------------- | ----------------------- |
| **Default Policy** | Default security policy |
| **Notification Settings** | Alert configuration |
| **Integration Defaults** | Default integrations |
| **Data Retention** | Retention period |
### Deleting an Organization
1. Go to organization settings
2. Click **Delete Organization**
3. Confirm deletion (this removes all projects)
## User Management
### User Roles
| Role | Permissions |
| ---------------- | ---------------------------------------------- |
| **Tenant Admin** | Full access to all organizations and settings |
| **Manager** | Manage specific organizations, users, policies |
| **User** | View and interact with assigned projects |
| **Viewer** | Read-only access to assigned projects |
### Role Permissions Matrix
| Action | Tenant Admin | Manager | User | Viewer |
| ---------------------- | ------------ | ------- | ---- | ------ |
| Manage tenant settings | ✅ | ❌ | ❌ | ❌ |
| Manage organizations | ✅ | ✅\* | ❌ | ❌ |
| Invite users | ✅ | ✅\* | ❌ | ❌ |
| Create projects | ✅ | ✅ | ✅ | ❌ |
| Configure integrations | ✅ | ✅ | ✅ | ❌ |
| View projects | ✅ | ✅ | ✅ | ✅ |
| Export data | ✅ | ✅ | ✅ | ✅ |
| Manage mitigations | ✅ | ✅ | ✅ | ❌ |
\*Within assigned organizations
### Inviting Users
1. Go to **Settings** → **Members**
2. Click **+ Invite Member**
3. Enter:
| Field | Description |
| ----------------- | ----------------------- |
| **Email** | User's email address |
| **Role** | Select user role |
| **Organizations** | Assign to organizations |
4. Click **Send Invitation**
### Managing Members
The Members page shows:
* Member name and email
* Status (Active/Pending/Disabled)
* Role assignment
* Organization membership
* Last active date
### Modifying User Access
1. Click on a user
2. Modify role or organizations
3. Save changes
### Removing Users
1. Click on a user
2. Click **Remove Access**
3. Confirm removal
## Teams
### Creating Teams
Group users into teams for easier management:
1. Go to **Settings** → **Teams**
2. Click **+ New Team**
3. Enter team name and description
4. Add team members
5. Assign organizations
### Team Permissions
Teams can be assigned:
* Organization access
* Project access
* Notification preferences
* Policy ownership
## Access Control
### Project-Level Access
Control who can access specific projects:
1. Open project settings
2. Go to **Access** tab
3. Add users or teams
4. Set permission level
### Permission Levels
| Level | Capabilities |
| --------- | -------------------- |
| **Admin** | Full project control |
| **Write** | Modify project data |
| **Read** | View project data |
## SSO Integration
### Automatic Provisioning
With SSO configured:
* Users auto-created on first login
* Group mappings assign roles
* Attributes set permissions
### Group Mapping
Map SSO groups to Safeguard roles:
1. Go to **Settings** → **SSO** → **Group Mappings**
2. Add mapping:
| SSO Group | Safeguard Role | Organizations |
| ------------- | -------------- | ------------- |
| security-team | Manager | All |
| developers | User | Engineering |
| auditors | Viewer | All |
## Audit Trail
### User Activity Logs
Track user actions:
| Event | Logged Data |
| --------------- | ---------------------------- |
| Login | User, time, IP |
| Project access | User, project, action |
| Setting changes | User, setting, old/new value |
| Role changes | Admin, user, role change |
### Viewing Logs
1. Go to **Settings** → **Audit Log**
2. Filter by user, action, date
3. Export logs as needed
## API Access
```bash
# List users
curl -X GET https://api.safeguard.sh/v1/users \
-H "Authorization: Bearer $API_KEY"
# Invite user
curl -X POST https://api.safeguard.sh/v1/users/invite \
-H "Authorization: Bearer $API_KEY" \
-d '{"email": "user@example.com", "role": "user", "organizations": ["org-id"]}'
# List organizations
curl -X GET https://api.safeguard.sh/v1/organizations \
-H "Authorization: Bearer $API_KEY"
# Create organization
curl -X POST https://api.safeguard.sh/v1/organizations \
-H "Authorization: Bearer $API_KEY" \
-d '{"name": "Engineering", "description": "Engineering team projects"}'
```
## Best Practices
### Organization Design
* Align with business structure
* Keep hierarchy simple
* Plan for growth
* Document ownership
### User Management
* Use SSO when possible
* Apply least privilege
* Review access regularly
* Remove inactive users
### Security
* Enable MFA for all users
* Review audit logs periodically
* Document access policies
* Train users on security
## Next Steps
* [Configure SSO](/docs/sso-authentication)
* [Policies & Gates](/docs/esscm/policies-gates)
* [Portal User Roles](/docs/portal/user-roles)
# Policies & Gates (/docs/esscm/policies-gates)
# Policies & Gates
Policies and Gates allow you to define security requirements and automatically enforce them across your software supply chain.
## Understanding Policies vs Gates
### Policies
Rules that evaluate your SBOMs and generate findings:
* Define acceptable risk thresholds
* Specify required security controls
* Can be advisory or blocking
### Gates
Checkpoints that enforce policies:
* Block deployments when policies fail
* Integrate with CI/CD pipelines
* Require approvals for exceptions
## Creating Policies
### Policy Builder
1. Navigate to **Settings** → **Policies**
2. Click **Create Policy**
3. Define conditions using the visual builder or YAML
4. Set severity and actions
5. Save and enable
### Policy Conditions
| Condition | Example |
| -------------------------- | --------------------------------- |
| **Vulnerability Severity** | No critical CVEs |
| **CVSS Score** | No vulnerabilities above 7.0 |
| **EPSS Score** | No actively exploited CVEs |
| **License** | No GPL licenses |
| **Component Age** | No components older than 2 years |
| **Maintenance** | No abandoned packages |
| **SLSA Level** | Require SLSA Level 2 attestations |
### Policy Templates
Pre-built templates for common requirements:
* **No Critical Vulnerabilities** - Block critical CVEs
* **License Compliance** - Enforce approved licenses
* **FedRAMP Ready** - Federal compliance requirements
* **EO 14028 Compliance** - Executive Order requirements
* **SLSA Level 2** - Supply chain attestations
* **No Abandoned Packages** - Block unmaintained dependencies
## Gate Configuration
### CI/CD Integration
Gates are evaluated by the platform on the scans it runs for your connected
repositories. There is no published pipeline action or CLI command that
evaluates a gate inside your own CI job yet. See
[CI/CD Integration](/docs/cicd-integration) for what you can run in a
pipeline today.
### Gate Actions
When a gate fails:
| Action | Description |
| -------------------- | ------------------------ |
| **Block** | Prevent deployment |
| **Warn** | Allow with warning |
| **Notify** | Send notification only |
| **Require Approval** | Wait for manual approval |
## Policy Exceptions
### Requesting Exceptions
When a legitimate exception is needed:
1. Click **Request Exception**
2. Select the policy and finding
3. Provide business justification
4. Set expiration date
5. Submit for approval
### Exception Workflow
1. Request created by developer
2. Notification sent to approvers
3. Approver reviews and decides
4. Exception granted or denied
5. Audit trail recorded
## Compliance Reporting
Track policy compliance with reports:
* Compliance status by policy
* Exception history
* Violation trends
* Audit documentation
# Risk Score (RS) (/docs/esscm/risk-score)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Risk Score (RS)
The Risk Score (RS) provides a comprehensive risk assessment for each component in your SBOM, helping you identify and prioritize supply chain security concerns.
## Overview
RS evaluates components based on multiple risk factors to generate an overall integrity score. Unlike vulnerability scores which focus on known CVEs, RS assesses the trustworthiness and supply chain integrity of each component.
## RS Score Range
| Score | Risk Level | Description |
| ----- | ------------- | ------------------------------------------ |
| 0-2 | Low Risk | High integrity, well-attested |
| 3-4 | Moderate Risk | Some concerns, review recommended |
| 5-6 | Elevated Risk | Multiple concerns, attention needed |
| 7-8 | High Risk | Significant concerns, remediation advised |
| 9-10 | Critical Risk | Severe concerns, immediate action required |
## Risk Factors
### Supply Chain Attestation (SCAL)
The SCAL (Safeguard Component Attestation Level) is a key factor in RS calculation:
| Level | Name | Description | Risk Impact |
| ---------- | ----------------------- | --------------------------------------------------- | ----------- |
| **SCAL 0** | Fully Attested | Complete build & source attestation with signatures | Lowest |
| **SCAL 1** | Attested Build & Source | Build provenance and source verification | Low |
| **SCAL 2** | Attested Component | Component has some attestation | Moderate |
| **SCAL 3** | Known Component | Component is identified but unattested | High |
| **SCAL 4** | Partially Unknown | Component has limited verification | Higher |
| **SCAL 5** | Unknown Component | Component cannot be verified | Highest |
### Provenance Verification
| Factor | Low Risk | High Risk |
| ------------------------- | ------------------- | ---------------- |
| **Build Source** | Official CI/CD | Unknown origin |
| **Signature** | Verified signatures | No signatures |
| **Transparency Log** | In public log | Not logged |
| **Build Reproducibility** | Reproducible | Not reproducible |
### Package Health
| Factor | Low Risk | High Risk |
| ----------------- | ------------------ | -------------------- |
| **Maintenance** | Active development | Abandoned |
| **Community** | Large, active | Small, inactive |
| **Age** | Mature, stable | Very new or very old |
| **Typosquatting** | No similar names | Potential typosquat |
### Behavioral Analysis
| Factor | Low Risk | High Risk |
| -------------------- | -------------- | ------------------------ |
| **Install Scripts** | None or safe | Suspicious scripts |
| **Network Access** | None | Unexpected network calls |
| **File System** | Limited access | Broad file access |
| **Code Obfuscation** | None | Heavily obfuscated |
## Viewing RS
### In Explore SBOM
1. Open a project from the **Projects** page
2. Navigate to **Explore SBOM**
3. Click the **RS** tab
4. View RS scores for all components
### RS Dashboard
The RS tab displays:
| Column | Description |
| -------------------- | ----------------------------------- |
| **Component** | Package name and version |
| **RS Score** | Numeric risk score (0-10) |
| **Risk Level** | Low/Moderate/Elevated/High/Critical |
| **SCAL Level** | Attestation level (0-5) |
| **Top Risk Factors** | Primary contributors to score |
### Filtering and Sorting
* **Filter by Risk Level** - Show only High/Critical components
* **Filter by SCAL** - Show components above a certain attestation level
* **Sort by RS** - Highest risk first
* **Search** - Find specific components
## RS Details
Click on any component to view detailed RS breakdown:
### Risk Breakdown
| Category | Weight | Score |
| ------------------ | ------ | -------------------- |
| Attestation (SCAL) | 30% | Based on SCAL level |
| Provenance | 25% | Build verification |
| Package Health | 20% | Maintenance status |
| Behavioral | 15% | Runtime behavior |
| Historical | 10% | Past security issues |
### Evidence
View specific evidence for each risk factor:
* Attestation documents found/missing
* Signature verification results
* Provenance chain details
* Behavioral analysis findings
## Improving RS Scores
### Quick Improvements
1. **Update to attested versions** - Use versions with SCAL 0-1
2. **Replace unknown components** - Swap SCAL 5 for verified alternatives
3. **Remove unused dependencies** - Reduce attack surface
4. **Pin specific versions** - Avoid version ranges
### Long-term Strategy
1. **Prefer Gold Directory packages** - Pre-verified components
2. **Establish component policies** - Require maximum SCAL levels
3. **Monitor RS trends** - Track improvements over time
4. **Vendor engagement** - Request attestations from suppliers
## RS Policies
### Setting RS Thresholds
Create policies based on RS:
1. Go to **Policies & Gates**
2. Create new policy rule
3. Set RS threshold (e.g., fail if any component > 6)
4. Apply to projects
### Policy Examples
| Policy | Rule |
| -------------------- | ----------------------------------- |
| **Production** | No components with RS > 5 |
| **Development** | Warn on RS > 7 |
| **Critical Systems** | Require SCAL 0-1 for all components |
## API Access
```bash
# Get RS scores for a project
curl -X GET https://api.safeguard.sh/v1/projects/{id}/rs \
-H "Authorization: Bearer $API_KEY"
# Get RS details for a component
curl -X GET https://api.safeguard.sh/v1/projects/{id}/components/{component}/rs \
-H "Authorization: Bearer $API_KEY"
```
## Best Practices
### Monitoring
* Review high RS components weekly
* Set up alerts for RS increases
* Track RS trends in dashboards
### Remediation
* Prioritize SCAL 5 components first
* Create tickets for high RS components
* Document accepted risks with mitigations
### Prevention
* Include RS checks in CI/CD
* Block high RS components in security gates
* Train developers on component selection
## Next Steps
* [Attestation](/docs/esscm/attestation)
* [Security Posture](/docs/esscm/security-posture)
* [Policies & Gates](/docs/esscm/policies-gates)
# Search (/docs/esscm/search)
# Search
Search across all your SBOMs, components, and vulnerabilities with Griffin AI-powered natural language queries instead of building filters by hand.
## AI-Powered Search
The Search page is powered by Safeguard's Griffin AI models, purpose-built for software supply chain security — see [Griffin AI](/docs/griffin-ai) for more on the model itself. Griffin is tuned to understand:
* Security context and vulnerability semantics
* Component relationships and dependency chains
* License compliance requirements
* Supply chain risk factors
You can switch between available model tiers from the model picker in the search bar; each tier trades off speed against depth of analysis:
| Tier | Best for |
| ----------- | ------------------------------------- |
| **Griffin** | Complex, multi-step security analysis |
| **Eagle** | Everyday queries |
| **Lino** | Quick answers, instant results |
Previous-generation versions of each tier stay available after a new one ships, and upcoming tiers may appear in the picker ahead of release — those are disabled until launch.
## Natural Language Search
Griffin AI understands natural language queries:
```
"Show me all critical vulnerabilities in production"
```
```
"Find components with GPL licenses"
```
```
"What packages are affected by Log4j?"
```
```
"Show outdated dependencies in the payments service"
```
```
"Which projects have exploitable vulnerabilities?"
```
```
"List all components from untrusted suppliers"
```
## Search Syntax
### Basic Queries
You don't need special syntax for a simple lookup — plain terms work as-is:
```
lodash # Find component named lodash
CVE-2021-23337 # Find specific CVE
react 18.2.0 # Find specific version
```
### Filters, expressed in plain English
Search isn't built around a query DSL with operators you have to memorize — Griffin reads filter-like intent (severity, license, project, reachability, exploitability, and so on) directly out of a natural-language sentence:
```
critical vulnerabilities in my-app # severity + project
MIT-licensed components # license
reachable and exploitable vulnerabilities only # reachable + exploitable
lodash, but not deprecated versions # exclusion
critical or high severity findings # either/or
```
### Inline mentions
While typing, a few trigger characters open a picker to reference something specific instead of describing it in words:
| Trigger | References |
| ------- | ----------------------------------------------------- |
| `@` | a project |
| `#` | an SCM config |
| `/` | a skill |
| `>` | a workspace |
| `&` | a connector |
| `:` | a specific entity (e.g. a component or vulnerability) |
For example, typing `@` and a few letters lets you pick a project to scope the query to, without typing its full name.
## Search Results
Results are organized by type:
### Components
* Package name and version
* Projects where it's used
* Vulnerability count
* License information
### Vulnerabilities
* CVE identifier
* Severity and CVSS score
* Affected components
* Fix availability
### Projects
* Project name
* Last scan date
* Security score
* Compliance status
## Starred Searches
Save frequently used queries as starred searches:
1. Perform your search
2. Click the **Star** icon on the conversation
3. Access it later from **Starred searches** in the sidebar
### The Search sidebar
The Search sidebar gives you:
* **New chat** — start a new search conversation
* **All chats** — every previous search conversation
* **Starred searches** — quick access to conversations you've starred
* **Connectors**, **Skills**, and **Workspaces** — jump to the connectors, skills, and workspaces available to your search
Within the conversation list itself, anything you've starred is grouped under **Starred conversations**, with everything else listed under **Recent chats**.
Starred searches are most useful for queries you come back to regularly — a recurring triage sweep, a saved vulnerability filter, or a findings query you check on a set cadence.
## Search Conversations
Griffin supports conversational search:
1. Start with a query
2. Ask follow-up questions
3. Refine your search through dialogue
4. Griffin maintains context throughout the conversation
Example conversation:
```
You: "Show me critical vulnerabilities"
Griffin: [Lists critical vulnerabilities]
You: "Which of these are exploitable?"
Griffin: [Filters to exploitable vulnerabilities]
You: "Can you fix the top 3?"
Griffin: [Provides AI Remediate options]
```
## Programmatic Access
The Search page itself is a UI-driven, conversational experience rather than a REST endpoint you call directly. If you need to pull the same findings, vulnerabilities, and SBOM data programmatically — for example, to reproduce a saved search as part of a script or pipeline — use the hosted [MCP server](/docs/mcp) instead. Safeguard has no public REST API or client SDKs yet; see [API Reference](/docs/api-reference#rest-api) and [SDKs](/docs/sdks).
## Export Results
Export search results in multiple formats:
* JSON - Raw data
* CSV - Spreadsheet compatible
* PDF - Formatted report
## FAQ & Troubleshooting
**My query returns no results even though I know the component/CVE exists.**
Search runs against your indexed SBOM and scan data, so results are limited to projects and scans you have access to and that have already been processed — a component from a scan still in progress may not show up yet. Try a broader, plain-English version of the query before assuming the data is missing.
**Do I need to learn filter syntax, or can I just type a question?**
Just type a question — Search doesn't use a formal query language with operators to memorize. Describe what you want (severity, license, project, reachability, exploitability, and so on) in plain English and Griffin extracts the filters for you. The one exception is inline mentions (`@`, `#`, `/`, `>`, `&`, `:`), which open a picker to reference a specific project, config, skill, workspace, connector, or entity mid-query.
**Which model tier should I use?**
Use Lino for quick lookups, Eagle for everyday queries, and Griffin when you need deeper reasoning over complex, multi-condition security questions.
## Related
* [Griffin AI](/docs/griffin-ai) — more on the AI model that powers Search.
* [Vulnerabilities](/docs/esscm/vulnerabilities) — browse and triage vulnerabilities outside of Search.
* [Explore SBOM](/docs/esscm/explore-sbom) — navigate SBOM data directly.
* [Findings](/docs/esscm/findings) — security findings surfaced across your projects.
# Security Posture (/docs/esscm/security-posture)
# Security Posture
The Security Posture tab shows how your project's components and security-posture checks break down — by classification and by severity — so you can spot where risk is concentrated and jump straight into the underlying data.
## Overview
The Security Posture tab helps you:
* See your component mix at a glance (Open Source, Third Party, Private, Unknown)
* See your security-posture checks broken down by severity
* Drill into any group's underlying components or checks via Griffin AI Search
* Scope the same view to a project, a product, or a single component's dependency subtree
## Viewing Security Posture
1. Open a project from the **Projects** page
2. Navigate to the **Security Posture** tab
3. View the component and security-posture-check distribution breakdowns
The Security Posture view is available at three levels — **project**, **product**, and **component** — from the corresponding tab on each entity's detail page. At the component level, the view includes the selected component's full subtree of child components.
### Dashboard Elements
| Element | Description |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Component Distribution** | Stat cards showing your total component count, broken down by classification: **Open Source**, **Third Party**, **Private**, and **Unknown** (anything that doesn't resolve to a known classification) |
| **Security Posture Distribution** | Stat cards showing your total security posture check count, broken down by severity: **Critical**, **High**, **Medium**, **Low**, and **Unknown** |
| **Chart** button | On the Security Posture Distribution panel — opens a donut chart ("Security Posture Severity Breakdown") plotting checks by severity |
| **Security Postures table** | A sortable, filterable, paginated table of the underlying security posture checks, below the two panels, with export and refresh controls |
Each stat card shows a raw count for its group along with that group's percentage of the panel's total.
**Example.** Say a project's Component Distribution panel shows a total of 640 components, split 410 Open Source / 150 Third Party / 60 Private / 20 Unknown (roughly 64% / 23% / 9% / 3% of the total). If you instead open the Security Posture tab on one component within that project, the panel re-scopes to that component's full subtree — the component itself plus every descendant component in its dependency tree — so the counts reflect just that branch, not the whole project.
## Drilling in with Griffin AI Search
Every group card in the Component Distribution and Security Posture Distribution panels — and each panel's total — is clickable. Clicking one doesn't just highlight a number; it sends a natural-language prompt into [Griffin AI Search](/docs/esscm/search) and takes you straight to the matching results, so you don't have to construct the equivalent search yourself.
| Click target | Prompt sent to Griffin |
| ----------------------------------- | ----------------------------------------------- |
| Component Distribution total | "show all components" |
| **Open Source** group | "show open source components" |
| **Third Party** group | "show third party components" |
| **Private** group | "show internal components" |
| **Unknown** component group | "show unknown components" |
| Security Posture Distribution total | "show all security posture checks" |
| **Critical** group | "show critical security posture checks" |
| **High** group | "show high severity security posture checks" |
| **Medium** group | "show medium severity security posture checks" |
| **Low** group | "show low severity security posture checks" |
| **Unknown** severity group | "show unknown severity security posture checks" |
## FAQ & Troubleshooting
**The panels briefly show all zeros when I open a component's Security Posture tab.**
At the component level, the panels first need to resolve the component's full subtree (itself plus every descendant component) before they can query counts. Stats loading is held until that resolution finishes, so a short zero/loading state right after navigating in is expected — it fills in once the subtree is ready.
**A component's Security Posture numbers seem lower than I'd expect for how large its dependency tree looks.**
Subtree resolution is bounded so a pathological or extremely large dependency graph can't run away: it walks a maximum of 12 levels deep and stops collecting once it reaches 5,000 total component ids. On most components this is far more than enough, but an unusually deep or wide tree could see counts reflecting a bounded subset rather than the literal entire tree.
**The percentages shown on the stat cards for a panel don't add up to exactly 100%.**
Each group's percentage is rounded independently, so small rounding differences (e.g., several groups each rounding up half a point) can make the displayed percentages sum to 99% or 101% even though the underlying counts are exact.
**Clicking the "Private" component group sends a Griffin search for "internal" components — is that a bug?**
No — it's an intentional (if inconsistent-looking) mapping. The panel labels the group **Private**, but the prompt it hands to Griffin AI Search is literally `"show internal components"`. See the prompt table above for the exact wording sent by every group.
**The Security Postures table says "No security postures found for this project/product/component."**
This reflects the table's current filters, not necessarily an absence of data — check whether any column filters are applied (via the filter/column controls) before assuming there's nothing to see, then use the refresh control to re-run the query.
**I clicked Export on the Security Postures table but nothing downloaded.**
Exports are queued rather than generated synchronously — clicking a format (CSV, TSV, JSON, NDJSON, Excel, Parquet, PDF, XML, HTML, Markdown, or SQL) submits the export job and confirms it was queued; the file isn't streamed back immediately in the browser.
## Improving Your Security Posture
### Quick Wins
1. **Update critical dependencies** - Fix critical CVEs first
2. **Enable AI Remediate** - Auto-generate fix PRs
3. **Remove unused dependencies** - Reduce attack surface
### Long-term Improvements
1. **Establish a patching cadence** - Regular update schedule
2. **Implement security gates** - Block vulnerable deployments
3. **Improve SBOM completeness** - Better component data
4. **Adopt attested packages** - Use verified components
## Related
* [Vulnerabilities](/docs/esscm/vulnerabilities) — detailed CVE-level data for the same components tracked here.
* [AI Remediate](/docs/esscm/auto-fix) — generate fix PRs for issues surfaced here.
* [Policies & Gates](/docs/esscm/policies-gates) — define and enforce security requirements across your components.
* [Griffin AI Search](/docs/esscm/search) — the natural-language search every panel group links into.
* [Griffin AI](/docs/griffin-ai) — more on the model that powers that search.
* [Explore SBOM](/docs/esscm/explore-sbom) — navigate the project/product/component structure this tab is scoped to.
* [Risk Score (RS)](/docs/esscm/risk-score) — a related, separately-calculated component integrity score.
* [Dashboard](/docs/esscm/dashboard) — organization-wide security overview.
# Suppliers & Licenses (/docs/esscm/suppliers-licenses)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Suppliers & Licenses
The Suppliers & Licenses tab provides comprehensive information about your dependencies' origins and licensing, helping you maintain compliance and manage supplier relationships.
## Overview
Track suppliers and licenses to:
* Ensure license compliance
* Identify supplier relationships
* Manage attribution requirements
* Assess supplier risk
* Meet legal requirements
## Supplier Information
### Supplier Data
For each component, view:
| Field | Description |
| ----------------- | ------------------------------ |
| **Supplier Name** | Organization or individual |
| **Supplier URL** | Official website or repository |
| **Contact** | Support or security contact |
| **Verification** | Identity verification status |
### Supplier Types
| Type | Description |
| ----------------------- | -------------------------------- |
| **Open Source Project** | Community-maintained projects |
| **Commercial Vendor** | Paid software suppliers |
| **Internal** | Components built in-house |
| **Unknown** | Supplier information unavailable |
## License Information
### License Summary
View license distribution across your project:
| Metric | Description |
| ------------------------ | --------------------------------------- |
| **Total Licenses** | Number of distinct licenses |
| **License Types** | Categories (Permissive, Copyleft, etc.) |
| **Compliance Status** | Overall compliance state |
| **Attribution Required** | Licenses requiring attribution |
### License Categories
| Category | Examples | Characteristics |
| ------------------- | -------------------- | -------------------- |
| **Permissive** | MIT, Apache 2.0, BSD | Minimal restrictions |
| **Weak Copyleft** | LGPL, MPL | File-level copyleft |
| **Strong Copyleft** | GPL, AGPL | Full copyleft |
| **Commercial** | Proprietary | Paid/restricted |
| **Public Domain** | Unlicense, CC0 | No restrictions |
## License Compliance
### Compliance Status
| Status | Meaning |
| -------------------- | ------------------------------- |
| ✅ **Compliant** | All licenses compatible |
| ⚠️ **Review Needed** | Some licenses need review |
| ❌ **Violation** | License conflict detected |
| ❓ **Unknown** | License could not be determined |
### Common Compliance Issues
| Issue | Description | Resolution |
| ----------------------- | ------------------------------ | ----------------------------- |
| **GPL in Proprietary** | GPL component in closed-source | Replace or open-source |
| **AGPL Network Use** | AGPL with network distribution | Review usage or replace |
| **Missing Attribution** | Attribution not provided | Add required notices |
| **License Conflict** | Incompatible licenses | Replace conflicting component |
## Viewing License Details
1. Open project
2. Navigate to **Suppliers & Licenses** tab
3. View license summary
4. Click individual components for details
### Component License View
For each component:
* License identifier (SPDX)
* License text
* Obligations
* Attribution requirements
* Compatibility analysis
## License Policies
### Creating License Policies
Define acceptable licenses:
1. Go to **Settings** → **License Policies**
2. Click **+ New Policy**
3. Configure allowed/blocked licenses
4. Set scope (organization or project)
5. Save policy
### Policy Rules
| Rule Type | Description |
| --------------- | ------------------------------- |
| **Allowlist** | Only these licenses permitted |
| **Blocklist** | These licenses prohibited |
| **Review List** | These licenses require approval |
### Policy Enforcement
License policies can:
* Generate warnings in UI
* Fail security gates
* Block deployments
* Send notifications
## Attribution Generation
### Generating Attribution
Create attribution documents:
1. Click **Export** → **Attribution Notice**
2. Select format (TXT, HTML, Markdown)
3. Customize template
4. Download attribution file
### Attribution Contents
* Component name and version
* License type
* Copyright notices
* License text (if required)
* Supplier information
### Automatic Updates
Enable automatic attribution updates:
* Generate with each SBOM update
* Include in build artifacts
* Publish to documentation
## Supplier Analysis
### Supplier Risk Assessment
Evaluate supplier risk:
| Factor | Assessment |
| -------------- | ----------------------- |
| **Reputation** | Known, trusted supplier |
| **Longevity** | Time in market |
| **Support** | Support availability |
| **Security** | Security track record |
| **Compliance** | Regulatory compliance |
### Supplier Concentration
Identify supplier concentration risk:
* Top suppliers by component count
* Single points of failure
* Geographic distribution
* Organizational diversity
## Reports
### License Report
Generate license reports:
1. Click **Export** → **License Report**
2. Select scope and format
3. Download report
### Report Types
| Report | Contents |
| --------------- | ------------------------------- |
| **Summary** | License overview and compliance |
| **Detailed** | Full license for each component |
| **Attribution** | Attribution notices |
| **Compliance** | Policy compliance status |
## API Access
```bash
# Get license information
curl -X GET https://api.safeguard.sh/v1/projects/{id}/licenses \
-H "Authorization: Bearer $API_KEY"
# Get supplier information
curl -X GET https://api.safeguard.sh/v1/projects/{id}/suppliers \
-H "Authorization: Bearer $API_KEY"
# Generate attribution
curl -X POST https://api.safeguard.sh/v1/projects/{id}/attribution \
-H "Authorization: Bearer $API_KEY" \
-d '{"format": "markdown"}'
```
## Best Practices
### License Management
* Define license policy early
* Review new dependencies for license
* Keep attribution up to date
* Train team on license types
### Supplier Management
* Document supplier relationships
* Assess supplier risk regularly
* Have alternatives for critical suppliers
* Monitor supplier health
### Compliance
* Automate license checking
* Include in security gates
* Review regularly with legal
* Maintain compliance documentation
## Integration with TPRM
Link supplier data with Third Party Risk Manager:
* Track vendor relationships
* Manage supplier SBOMs
* Monitor supplier security
* Assess vendor risk
## Next Steps
* [Explore SBOM](/docs/esscm/explore-sbom)
* [License Compliance (OSM)](/docs/osm/license-compliance)
* [Third Party Risk Manager](/docs/tprm)
# Vulnerabilities (/docs/esscm/vulnerabilities)
# Vulnerabilities
Enterprise Software Supply Chain Manager (ESSCM) provides comprehensive vulnerability detection with intelligent prioritization powered by Griffin AI.
## Vulnerability Overview
The Vulnerabilities tab shows vulnerability distribution across five categories:
* **Critical** - Highest severity, immediate action required
* **High** - Serious vulnerabilities to address promptly
* **Medium** - Moderate risk issues
* **Low** - Lower priority vulnerabilities
* **Exploitable** - Vulnerabilities with known active exploitation in the wild
## Continuous Scanning
Safeguard performs **daily continuous scanning** of all your projects to detect new vulnerabilities as they are disclosed. When new CVEs are published, your projects are automatically re-evaluated to determine if they are affected.
This ensures:
* Up-to-date vulnerability information
* Immediate alerts on new threats
* Proactive security posture management
## Vulnerability Prioritization
Griffin AI intelligently prioritizes vulnerabilities to help you focus on what truly matters. Not all vulnerabilities require immediate action—Griffin AI helps determine **if a vulnerability really needs to be fixed** based on:
### Exploitability
* **EPSS Score** - Exploit Prediction Scoring System
* **Active Exploitation** - Known exploitation in the wild (CISA KEV)
* **Exploit Availability** - Public exploits available
* **Exploitable Status** - Whether the vulnerability is actively exploitable
### Reachability
* **Call Path Analysis** - Is the vulnerable code actually called?
* **Runtime Context** - Production vs development usage
* **Configuration Impact** - Feature flags and settings
### Business Context
* **Asset Criticality** - Importance of affected systems
* **Data Sensitivity** - Type of data at risk
* **Exposure Level** - Internet-facing vs internal
## Vulnerability Details
For each vulnerability:
| Field | Description |
| ---------------------- | ----------------------------------------------- |
| **CVE ID** | Common Vulnerabilities and Exposures identifier |
| **CVSS Score** | Severity score (0-10) |
| **EPSS Score** | Exploit probability percentage |
| **Exploitable** | Whether actively exploited in the wild |
| **Affected Component** | Package name and version |
| **Fixed Version** | Version that resolves the issue |
| **Description** | Detailed vulnerability description |
| **References** | Links to advisories and documentation |
| **Reachability** | Whether the code path is reachable |
## Filtering & Search
Filter vulnerabilities by:
* Severity level
* CVSS score range
* EPSS score range
* Exploitable status
* Component name
* Fix availability
* Reachability status
* Date range
Use Griffin AI natural language search:
```
"Show me critical vulnerabilities in production that are actively exploited"
```
## Vulnerability Actions
### AI Remediate
Click the **AI Remediate** button to let Griffin AI automatically generate fixes:
1. Click **AI Remediate** at the top of the Vulnerabilities page
2. Griffin AI analyzes all vulnerabilities and generates remediation plans
3. Review the proposed changes
4. Create Pull Requests automatically
[Learn more about AI Remediate →](/docs/esscm/auto-fix)
### View Fix Options
1. Click on a vulnerability
2. Select **View Fix**
3. Review upgrade options
4. See breaking change warnings
### Mark as False Positive
If a vulnerability doesn't apply:
1. Click **Mark False Positive**
2. Provide justification
3. Submit for approval (if required by policy)
### Accept Risk
Temporarily accept a vulnerability:
1. Click **Accept Risk**
2. Set expiration date
3. Documentation the business justification
4. Submit for approval
## Data Sources
We aggregate vulnerability data from:
* National Vulnerability Database (NVD)
* GitHub Security Advisories
* OSV (Open Source Vulnerabilities)
* CISA KEV (Known Exploited Vulnerabilities)
* Vendor security bulletins
* Security researcher disclosures
# Report a bug (/docs/help-and-support/bug-reports)
# Report a bug
1. Open the **Help & Feedback** sheet (the question-mark icon at the top right, or **Get Help** in your user menu) and select the **Bug Report** tab.
2. Choose the **Severity**: Low, Medium, High or Critical.
3. Write a **Subject** that names the problem, and under **Steps to Reproduce / Details** say what you did, what you expected, and what happened instead.
4. Optional, and often the quickest way to show it: under **Attach evidence**, add a **Screenshot** or a short recording of the problem. See [Attach a screenshot or recording](/docs/help-and-support/support-requests#attach-a-screenshot-or-recording).
5. Select **Send**.
The sheet shows **Your ticket reference**. The report then appears in **Messages › Support**, where you follow it, reply and rate the answer like any other request ([how](/docs/help-and-support/support-requests#follow-your-request)).
## What Safeguard adds to your report
So that the team can reproduce the problem, the report carries, for the Safeguard team only:
* the page you were on, without its query string;
* your workspace's tenant, organization and product identifiers;
* your browser's user-agent string;
* the version of the Safeguard app you were using.
## When a page fails on its own
When something fails in the app, such as a screen that crashes, a script error or a request to Safeguard that fails, the app reports the failure to Safeguard's engineering team by itself. You don't need to do anything, and you don't get a ticket or an email for it.
The report carries no personal data: no page content, request bodies, headers, cookies, tokens, query strings, email addresses or names. It holds the error message with personal details removed, the start of the technical trace, the app version, the browser and operating system family and, for a failed request, its method, status and a path template such as `/projects/:id`. The same failure is reported at most once every five minutes.
If the error screen shows an **Error ID**, include it when you report the problem: it lets the team find that exact failure.
## Related
* [Support requests](/docs/help-and-support/support-requests)
* [Feedback and requests](/docs/help-and-support/feedback-and-requests)
# From the CLI and AI assistants (/docs/help-and-support/cli-and-assistants)
# From the CLI and AI assistants
The CLI and the MCP server file the same tickets as the product's Help & Feedback sheet. Whatever you send appears in **Messages › Support** in the app, under your account.
## Safeguard CLI
Sign in first (`safeguard login`). Then:
| Command | What it does |
| ----------------------------------------------------------- | ---------------------------------------------------------------- |
| `safeguard support ask ""` | Ask support for help. `new` and `request` work as well as `ask`. |
| `safeguard support bug ""` | Report a bug. |
| `safeguard support feedback ""` | Send feedback. |
| `safeguard support list` | Your requests, newest first. |
| `safeguard support show ` | One request and its thread. |
| `safeguard support reply ""` | Answer support on one of your requests. |
Options for every `support` command:
* `--priority low|normal|high|urgent`: how urgent the request is (default `normal`).
* `--yes`: answer the confirmation in advance, for scripts.
In the interactive terminal, `/bug` reports a bug, `/feedback` sends feedback, and `/support` (or `/requests`) asks for help and shows your requests. More on the CLI: [Usage](/docs/cli/usage).
## AI assistants (Safeguard MCP server)
An assistant connected to the [Safeguard MCP server](/docs/mcp) can file and follow requests for you:
| Tool | What it does |
| ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `safeguard_create_support_request` | Ask support for help: a subject, a description and an urgency. |
| `safeguard_report_bug` | Report a bug: a summary, and optionally the steps to reproduce, what you expected, what happened and a severity. |
| `safeguard_submit_feedback` | Send feedback, a feature request, praise or a complaint. |
| `safeguard_list_my_support_tickets` | Your requests, optionally only open or closed ones. |
| `safeguard_get_support_ticket` | One request and its thread, by its `SUP-XXXX-XXXX` reference. |
| `safeguard_request_capability`, `safeguard_request_framework` | Ask for a framework, integration, connector, scanner, language or report style that is missing. The assistant must confirm with you before it sends one. |
These tools work for a person signed in to the MCP server; a connection made with an API key alone can't file requests. A workspace administrator can switch the **Support and requests** and **Capability requests** tool groups off in **Settings › MCP access**. Each person can file up to 30 requests an hour this way.
## Related
* [Help and support](/docs/help-and-support)
* [Support requests](/docs/help-and-support/support-requests)
# Feedback and requests (/docs/help-and-support/feedback-and-requests)
# Feedback and requests
## Send feedback
1. Open the **Help & Feedback** sheet (the question-mark icon at the top right, or **Get Help** in your user menu). It opens on the **Feedback** tab.
2. Write a **Subject** and a **Message**: what you think, what works, what gets in your way, what you would change.
3. Optional: add a **Screenshot** or a short recording under **Attach evidence**.
4. Select **Send**.
Your feedback reaches the Safeguard team as a ticket and appears in **Messages › Support**, where the team can reply. Feedback is read by people and is not rated.
## Rate an AI answer
Under an answer in **Search**, select the thumbs up or the thumbs down. **Thanks for the feedback!** appears once your rating is saved; if it could not be saved, Safeguard says why and the thumbs go back to how they were. Select the same thumb again to remove your rating, or the other one to change it.
You have one rating per answer, and your ratings are there when you come back to the conversation. Deleting a conversation deletes its ratings. An answer in a **Private Chat** isn't saved, so it has no thumbs.
## Ask for something that is missing
Wherever Safeguard lists things you can add, such as integrations, compliance frameworks, scanners, platforms, reports or billing plans, a **Request more** button lets you ask for one that isn't there yet.
1. Select **Request more**. The dialog's title says what you are asking for, for example **Request an integration** or **Request a framework**.
2. Say which one you need. Filling in **Why do you need it? (optional)** helps the team weigh the request.
3. Select **Submit request**.
Safeguard confirms the request with its ticket reference, and it appears in **Messages › Support** with your other requests.
## In-app surveys
From time to time the Safeguard team may ask a one-question survey in a small card at the corner of the page, for example how likely you are to recommend Safeguard, or how easy it was to get what you needed. Pick a score, add a comment if you like, and select **Send**; **Not now** or the close button dismisses it. Each survey is shown to you at most once.
## Related
* [Support requests](/docs/help-and-support/support-requests)
* [Report a bug](/docs/help-and-support/bug-reports)
* [From the CLI and AI assistants](/docs/help-and-support/cli-and-assistants)
# Help and support (/docs/help-and-support)
# Help and support
Everything you send the Safeguard team from the product goes through one place, the **Help & Feedback** sheet, and every request you send becomes a ticket you can follow in **Messages › Support**.
## Open the Help & Feedback sheet
* Select the **question-mark icon** at the top right of any page (its tooltip says **Help & Feedback**), or
* open your user menu (your name and avatar at the bottom of the left sidebar) and select **Get Help**, or
* go to **Settings › Help & Support**, which opens the same sheet on the tab you choose.
The sheet has five tabs:
| Tab | Use it to |
| -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Feedback** | Tell the Safeguard team what you think, or what would make the product better. See [Feedback and requests](/docs/help-and-support/feedback-and-requests). |
| **Bug Report** | Report something that is broken, with steps to reproduce and a screenshot or recording. See [Report a bug](/docs/help-and-support/bug-reports). |
| **Support** | Ask for help with something you are trying to do. See [Support requests](/docs/help-and-support/support-requests). |
| **Messages** | Chat with your team, and follow the requests you have sent. |
| **Help** | Read answers from the Safeguard support team, grouped by topic, with a search box. |
The sheet opens on **Feedback**. A link of the form `https://app.safeguard.sh/?help=` opens it on the **Help** tab at that article, so a reply from the Safeguard team can point you straight to an answer.
## Follow what you sent
Feedback, bug reports, support requests and anything you ask for with **Request more** all appear in **Messages › Support** (the **Messages** button at the top of the page, then **Support**). You see only the requests you sent yourself. How to read, reply to, rate and escalate a request is on [Support requests](/docs/help-and-support/support-requests#follow-your-request).
## Other ways to reach Safeguard
* **Email**: [hi@safeguard.sh](mailto:hi@safeguard.sh).
* **Community**: if your deployment has a Safeguard community on Discord, the **Help** tab shows **Join the community on Discord**.
* **From the command line or an AI assistant**: the Safeguard CLI and MCP server file the same tickets. See [From the CLI and AI assistants](/docs/help-and-support/cli-and-assistants).
Auditor accounts open only the audit workspace and do not have the Help & Feedback sheet; an auditor can email [hi@safeguard.sh](mailto:hi@safeguard.sh). If you don't see the question-mark icon, help is turned off for your workspace: ask your Safeguard administrator.
# Support requests (/docs/help-and-support/support-requests)
# Support requests
## Ask for help
1. Open the **Help & Feedback** sheet (the question-mark icon at the top right, or **Get Help** in your user menu) and select the **Support** tab.
2. Choose the **Urgency**: Low, Medium, High or Critical. Medium is selected to start with.
3. Write a **Subject** (up to 120 characters) and a **Message** (up to 2,000 characters) that says what you are trying to do and where you are stuck. **Send** stays unavailable until both have text.
4. Optional: under **Attach evidence**, add a **Screenshot** and one recording. See [Attach a screenshot or recording](#attach-a-screenshot-or-recording).
5. Select **Send**.
While you type, the sheet may show **These might answer your question** with up to three help articles. Opening one keeps your draft.
When the request is filed, the sheet shows **Your ticket reference**, in the form `SUP-XXXX-XXXX`. Quote it if you follow up by email. If a reference could not be assigned, the sheet says the request was still received.
You get no email when the request is filed. You do get one when the Safeguard team replies, resolves the request or escalates it; their subjects start with your reference, for example `[SUP-7KQ4-M2XD]`.
## Attach a screenshot or recording
**Attach evidence** works the same way on the Support, Bug Report and Feedback tabs:
* **Screenshot**: one image of your screen.
* One recording. **What to record**: **Screen**, **Screen + camera**, **Camera** or **Voice only**. You can set the **Quality** (**Original**, **1080p**, **720p** or **480p · smallest**), a **Countdown** before it starts, and **Include microphone** for screen recordings.
* A recording stops at 60 seconds or 45 MB, whichever comes first. While the screen is recording, a small control lets you **Stop recording** or **Discard**.
The browser asks for permission before it captures your screen, camera or microphone. Nothing is captured until you allow it.
## Follow your request
Open **Messages › Support**: the **Messages** button at the top of any page, then **Support** (or the **Messages** tab of the Help & Feedback sheet). You see the requests you sent yourself, newest first; colleagues' requests are not shown.
| Status | What it means |
| ------------ | ------------------------------- |
| **Open** | Waiting on the Safeguard team. |
| **Pending** | Waiting on you. |
| **Resolved** | The team considers it answered. |
| **Closed** | Finished. |
Open a request to read its thread. Your messages are marked **You**; the team's show the person's name, or **Support**. Until someone answers, the thread says **No reply yet. We will answer here.** An open thread refreshes by itself about every 20 seconds.
### Reply
Type in **Add a reply…** and select **Send reply**. **Attach files** adds up to six files of up to 50 MB each: images, video, audio, PDF, plain text, logs, JSON, HAR network captures or ZIP archives. Replying to a request that is **Resolved** or **Closed** opens it again.
### Rate the answer
When a request is **Resolved** or **Closed**, it asks **How was your experience?** Choose **Good**, **OK** or **Bad**, and optionally tell the team more (up to 2,000 characters). You can change your rating later. The email that tells you a request is resolved has the same three choices.
Feedback can't be rated, and neither can a request that was merged into another one.
### Escalate
If a request is still **Open** and needs more attention, you can escalate it once it has waited long enough; until then it says **You can escalate in** followed by the time left.
1. On the request, select **Escalate**.
2. Answer **Why does this need escalating?** (required). You can also pick a **Business impact (optional)**: **Not sure**, **Blocking production**, **Major impact**, **Minor** or **Just need an update**.
3. Select **Escalate this request**.
Escalating raises the request's priority and alerts a senior member of the team; the dialog says how soon they will reply, and an escalated request shows **Escalated**. There is a daily limit on escalations: past it, the request asks you to reply on it instead, and the team picks it up from there.
### Merged requests
If the team finds that two of your requests are about the same thing, one is merged into the other. The merged one stays in your list as **Closed**; follow the other one.
## Related
* [Report a bug](/docs/help-and-support/bug-reports)
* [Feedback and requests](/docs/help-and-support/feedback-and-requests)
* [From the CLI and AI assistants](/docs/help-and-support/cli-and-assistants)
# Payments & procurement (/docs/mcp/agent-payments)
Safeguard's MCP server includes four billing tools that let a connected agent run the complete procurement journey against the same self-serve payment APIs the web app's billing page uses. An agent can discover the plans offered to your workspace (with correct regional pricing), compare tiers and what each unlocks, start a Stripe Checkout session, and verify afterwards that the invoice settled and the tier's features activated.
| Tool | Type | What it does |
| ----------------------------------------- | ----- | ------------------------------------------------------------------------------------------------------------------- |
| `safeguard_list_pricing_plans` | read | Plans your tenant may purchase, grouped by product — prices, tier, audience, per-tier features. Multi-region aware. |
| `safeguard_purchase_plan` | write | Creates a Stripe Checkout session for a plan and returns the hosted payment URL. |
| `safeguard_list_billing_invoices` | read | Your paid and open invoices, with hosted payment links and PDF receipts. |
| `safeguard_get_subscription_entitlements` | read | The feature flags currently enabled for your tenant — confirms a purchased tier is live. |
All four tools are **opt-in per tenant** — an administrator enables them via their [per-tool feature flags](/docs/mcp/tool-gating) (`mcp:tool:safeguard_purchase_plan`, etc.) in the admin console. Only six read-only tools are on by default; a workspace turns on exactly the billing tools it wants (e.g. enable pricing/invoice reads but leave `safeguard_purchase_plan` off to forbid agent-initiated checkout).
New here entirely without an account? The signup tools (`safeguard_signup`, `safeguard_verify_email`, `safeguard_resend_verification`) are available without authentication on the dedicated `https://mcp.safeguard.sh/mcp/signup` endpoint: create the account and verify the email address there, then connect the main endpoint `https://mcp.safeguard.sh/mcp`, sign in with OAuth, and continue below.
## Regional pricing
Plans are priced per region. `safeguard_list_pricing_plans` accepts **every location signal the agent knows about its user** — not just a country code:
```json
{
"location": {
"country_name": "India",
"locale": "en-IN",
"timezone": "Asia/Kolkata",
"continent": "Asia",
"city": "Bengaluru",
"district_or_state": "Karnataka",
"currency": "INR",
"ip_address": "203.0.113.9"
}
}
```
The server resolves these offline to a single pricing country (precedence: explicit ISO code → country name → locale region → timezone → unambiguous currency) and the response states which signal decided the region and why others were ignored. Signals that can't safely pick one country — a continent alone, a city alone, an IP alone — fall back to **GLOBAL** pricing rather than guessing. No location data leaves the MCP server; only the resolved country code reaches the pricing API.
## Tiers and audiences
Each plan carries a **tier** (for example `PRO`, `MAX`, `5X`, `20X`, `ENTERPRISE`) and an **audience** category:
* `INDIVIDUAL` — single-user plans
* `TEAM` — team plans
* `ENTERPRISE` — enterprise plans
* `SHARED` — offered to every audience
Pass `audience` to filter (`SHARED` plans are always included), and read each plan's feature list to compare what the tiers unlock. After a purchase activates, the tier's features are enabled as feature flags — verify with `safeguard_get_subscription_entitlements`.
## The purchase flow
1. **Discover** — `safeguard_list_pricing_plans` with the user's location and (optionally) audience. Pick a plan id.
2. **Checkout** — `safeguard_purchase_plan` with `plan_id` and optional `interval` (`month` or `year`; yearly saves 20% when no explicit yearly price is set). The tool returns a **Stripe-hosted payment URL**.
3. **Pay** — the user (or a saved payment method) completes payment on Stripe's page. Card data never passes through the MCP server, the agent, or the model.
4. **Activate** — on payment, the subscription activates automatically: usage limits raised, product license granted, tier feature flags enabled, paused scans resumable.
5. **Verify** — `safeguard_list_billing_invoices` shows the invoice as `paid` (the procurement receipt), and `safeguard_get_subscription_entitlements` lists the features now enabled.
## Tenant isolation
The purchase, invoice, and entitlement tools take the tenant from the authenticated session context. There is **no tenant argument** — an agent can only buy for, and see the invoices and entitlements of, the workspace it is signed into.
## Auditing
Every billing call — including read-only plan, invoice, and entitlement pulls — emits a structured audit record (`billing.plans.list`, `billing.checkout.create`, `billing.invoices.list`, `billing.entitlements.get`) with tenant, organization, user, parameters, and outcome. Tokens and card data are never logged. The durable money-event trail (subscription activated, license granted, activation failures) is written by the payment activation flow to the platform audit log.
## Troubleshooting
| Symptom | Cause & fix |
| ----------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ |
| `Tool "safeguard_purchase_plan" is not enabled for this tenant` | The per-tool flag is off — an administrator enables it under Feature Flags. |
| `This plan isn't purchasable online yet (no price set). Contact sales.` | The plan has no online price or linked Stripe price — use the plan's contact-sales channel. |
| Checkout session created without a payment URL | Stripe isn't configured for the environment — contact [sales@safeguard.sh](mailto:sales@safeguard.sh). |
| Plans look wrong for the user's country | Pass a better location signal (explicit ISO code wins); the response explains which signal was used. |
# Aleph Alpha (/docs/mcp/aleph-alpha)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Aleph Alpha](https://aleph-alpha.com) (Germany) directly to your software supply chain security data and ask questions in plain language. The endpoint is `https://mcp.safeguard.sh/mcp`. Once connected, any Aleph Alpha MCP-capable client can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. Open the MCP configuration in your Aleph Alpha MCP-capable client.
3. Add a remote MCP server (Streamable HTTP) with the URL `https://mcp.safeguard.sh/mcp`.
4. If the client supports OAuth for MCP servers, it opens Safeguard's sign-in page: sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**. If it can only send a fixed header, use an MCP key instead (see [Authentication](#authentication)).
5. Reload your client — your enabled Safeguard security tools are now available. Start asking questions.
Nothing needs installing: Safeguard hosts the server. Safeguard does not publish an npm package or a local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). The Safeguard MCP server accepts two kinds of credential:
* OAuth 2.0: when your client supports it, it opens Safeguard's sign-in page. Sign in, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy.
* MCP key: for a client that can only send a fixed header. In Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| MCP endpoint | `https://mcp.safeguard.sh/mcp` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# Anthropic (/docs/mcp/anthropic)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Claude](https://claude.ai) by [Anthropic](https://www.anthropic.com) directly to your software supply chain security data and ask questions in plain language. This is the same connector as the [Claude](/docs/mcp/claude) page — the Anthropic connector URL is `https://mcp.safeguard.sh/mcp/anthropic`. Once connected, Claude can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates — all through a connector named Safeguard Security. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. In Claude, open **Customize → Connectors**, click **+ Add**, then **Add custom connector**.
3. Enter the name `Safeguard Security` and the URL `https://mcp.safeguard.sh/mcp/anthropic`, then click **Continue**.
4. Claude detects that Safeguard signs in with OAuth; click **Continue**. Under **Authentication**, choose **Sign in now** or **Sign in when needed**. Under **OAuth client**, choose **Register automatically**: Safeguard accepts only client IDs it issued itself. Click **Add**.
5. When Claude sends you to Safeguard, sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**.
6. That's it. Your enabled Safeguard security tools are now available to Claude. Start asking questions.
On a Team or Enterprise plan, an Owner or Primary Owner adds the connector first under **Organization settings → Connectors** (**Add**, then **Custom**, then **Web**, with the same name, URL and settings). Members then open **Customize → Connectors**, find **Safeguard Security** and click **Connect**. On the Free plan you can add one custom connector.
### Claude Desktop
Claude Desktop uses the connectors in your Claude account: once you add Safeguard Security as above, it is available in Claude Desktop too. Don't add Safeguard to `claude_desktop_config.json`. That file is for local servers only, Safeguard's server is hosted, and Safeguard publishes no npm package or local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). Claude connects with OAuth 2.0: when you add the Safeguard Security connector, Claude sends you to Safeguard, where you sign in (or create your account), check the app name and the host the page says the authorization code will be sent to, and click **Authorize access**. No keys to copy.
For a client that can only send a fixed header, the Safeguard MCP server also accepts an MCP key: in Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| Anthropic connector URL | `https://mcp.safeguard.sh/mcp/anthropic` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# Claude (/docs/mcp/claude)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Claude](https://claude.ai) by [Anthropic](https://www.anthropic.com) directly to your software supply chain security data and ask questions in plain language. The Claude connector URL is `https://mcp.safeguard.sh/mcp/anthropic` — our MCP endpoint purpose-built for Claude. Once connected, Claude can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates — all through a connector named Safeguard Security. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Add from Claude's connector directory
Safeguard is listed in Claude's connector directory. This is the shortest route — there is no URL to paste:
1. Open the directory entry: [Safeguard in Claude's connector directory](https://claude.ai/directory/connectors/297550a9-dcd9-4d5c-a4ab-7f96c92cc495).
2. Select **Safeguard** and connect.
3. Sign in to Safeguard, check the app name and the host the authorization code will be sent to, then click **Authorize access**.
The directory lives inside Claude and needs you signed in to claude.ai — opened without a session, the link lands on the Claude home instead. If the directory isn't available on your Claude plan or in your workspace, the manual steps below always work.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. In Claude, open **Customize → Connectors**, click **+ Add**, then **Add custom connector**.
3. Enter the name `Safeguard Security` and the URL `https://mcp.safeguard.sh/mcp/anthropic`, then click **Continue**.
4. Claude detects that Safeguard signs in with OAuth; click **Continue**. Under **Authentication**, choose **Sign in now** or **Sign in when needed**. Under **OAuth client**, choose **Register automatically**: Safeguard accepts only client IDs it issued itself. Click **Add**.
5. When Claude sends you to Safeguard, sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**.
6. That's it. Your enabled Safeguard security tools are now available to Claude. Start asking questions.
On a Team or Enterprise plan, an Owner or Primary Owner adds the connector first under **Organization settings → Connectors** (**Add**, then **Custom**, then **Web**, with the same name, URL and settings). Members then open **Customize → Connectors**, find **Safeguard Security** and click **Connect**. On the Free plan you can add one custom connector.
### Claude Desktop
Claude Desktop uses the connectors in your Claude account: once you add Safeguard Security as above, it is available in Claude Desktop too. Don't add Safeguard to `claude_desktop_config.json`. That file is for local servers only, Safeguard's server is hosted, and Safeguard publishes no npm package or local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). Claude connects with OAuth 2.0: when you add the Safeguard Security connector, Claude sends you to Safeguard, where you sign in (or create your account), check the app name and the host the page says the authorization code will be sent to, and click **Authorize access**. No keys to copy.
For a client that can only send a fixed header, the Safeguard MCP server also accepts an MCP key: in Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| Claude connector URL | `https://mcp.safeguard.sh/mcp/anthropic` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# Cohere (/docs/mcp/cohere)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Cohere](https://cohere.com) (North America) directly to your software supply chain security data and ask questions in plain language. The endpoint is `https://mcp.safeguard.sh/mcp`. Once connected, any Cohere MCP-capable client can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. Open the MCP configuration in your Cohere MCP-capable client.
3. Add a remote MCP server (Streamable HTTP) with the URL `https://mcp.safeguard.sh/mcp`.
4. If the client supports OAuth for MCP servers, it opens Safeguard's sign-in page: sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**. If it can only send a fixed header, use an MCP key instead (see [Authentication](#authentication)).
5. Reload your client — your enabled Safeguard security tools are now available. Start asking questions.
Nothing needs installing: Safeguard hosts the server. Safeguard does not publish an npm package or a local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). The Safeguard MCP server accepts two kinds of credential:
* OAuth 2.0: when your client supports it, it opens Safeguard's sign-in page. Sign in, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy.
* MCP key: for a client that can only send a fixed header. In Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| MCP endpoint | `https://mcp.safeguard.sh/mcp` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# Connector Setup (Claude, ChatGPT, Others) (/docs/mcp/connectors)
# Connector Setup
Safeguard hosts its MCP server, so there is nothing to install:
* **MCP endpoint (Streamable HTTP):** `https://mcp.safeguard.sh/mcp`
* **Claude connector URL:** `https://mcp.safeguard.sh/mcp/anthropic`
* **Sign-in:** OAuth 2.0. Your client opens Safeguard's sign-in page: sign in, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**.
* **MCP key**, only for a client that can only send a fixed header: in Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
There is no SSE endpoint, and the server never reads environment variables such as `SAFEGUARD_API_KEY` from your machine. Safeguard does not publish an npm package or a local bridge for its MCP server; treat any package that claims to be one as untrusted.
## Claude (claude.ai and Claude Desktop)
1. In Claude, open **Customize → Connectors**, click **+ Add**, then **Add custom connector**.
2. Enter the name `Safeguard Security` and the URL `https://mcp.safeguard.sh/mcp/anthropic`, then click **Continue**.
3. Claude detects that Safeguard signs in with OAuth; click **Continue**. Under **Authentication**, choose **Sign in now** or **Sign in when needed**. Under **OAuth client**, choose **Register automatically**: Safeguard accepts only client IDs it issued itself. Click **Add**.
4. Sign in to Safeguard, check the app name and host, then click **Authorize access**.
On a Team or Enterprise plan, an Owner or Primary Owner adds the connector under **Organization settings → Connectors** first; members then connect it from **Customize → Connectors**. Claude Desktop uses the same connectors, so there is nothing to add to `claude_desktop_config.json`. Full guide: [Claude](/docs/mcp/claude).
## Claude Code
```bash
claude mcp add --transport http safeguard https://mcp.safeguard.sh/mcp
```
Then run `/mcp` in Claude Code and follow the steps in your browser to sign in. To use an MCP key instead, add `--header "Authorization: Bearer sg_sk_..."` to the command.
## ChatGPT
1. In ChatGPT, open **Plugins**, select the plus button, then **Add custom MCP server**.
2. Enter a name and description, and under **Connection** enter `https://mcp.safeguard.sh/mcp`.
3. Configure authentication with OAuth (ChatGPT registers itself; there is no client ID to copy), review the risk warning, select **I understand and want to continue**, then **Create as a plugin**.
4. Sign in to Safeguard, check the app name and host, then click **Authorize access**.
Account and workspace policies apply to custom MCP servers in ChatGPT. A Custom GPT Action that imports `https://mcp.safeguard.sh/openapi.json` with an MCP key is an alternative: see [ChatGPT](/docs/mcp/openai).
For the OpenAI API, add an `mcp` tool to a Responses API request with `server_url` set to `https://mcp.safeguard.sh/mcp`. Safeguard needs a credential on every request; OpenAI's [MCP and connectors guide](https://developers.openai.com/api/docs/guides/tools-connectors-mcp) describes how to pass one.
## Cursor
Add this to `~/.cursor/mcp.json` (all projects) or `.cursor/mcp.json` (one project):
```json
{
"mcpServers": {
"safeguard": {
"url": "https://mcp.safeguard.sh/mcp"
}
}
}
```
Cursor opens Safeguard's sign-in page when it connects. Full guide: [Cursor](/docs/mcp/cursor).
## VS Code (GitHub Copilot)
Add this to `.vscode/mcp.json`, or run **MCP: Open User Configuration** to add it for every workspace:
```json
{
"servers": {
"safeguard": {
"type": "http",
"url": "https://mcp.safeguard.sh/mcp"
}
}
}
```
On the first connection VS Code opens a browser window to sign in.
## Gemini CLI
```bash
gemini mcp add --transport http safeguard https://mcp.safeguard.sh/mcp/gemini
```
Or add `"safeguard": { "httpUrl": "https://mcp.safeguard.sh/mcp/gemini" }` under `mcpServers` in `~/.gemini/settings.json`. Gemini CLI discovers Safeguard's OAuth sign-in when it first connects. Full guide: [Gemini](/docs/mcp/gemini).
## Other clients
Add a remote MCP server (Streamable HTTP) with the URL `https://mcp.safeguard.sh/mcp`. If the client supports OAuth for MCP servers, it opens Safeguard's sign-in page; otherwise send an MCP key in the `Authorization` header. Per-assistant guides are listed under [MCP Integrations](/docs/mcp).
## Verifying the Connection
In any client, ask: *"What Safeguard tools do you have?"*
A working connection lists tools such as `safeguard_list_projects` and `safeguard_list_vulnerabilities`. A new workspace starts with six read-only tools, and an administrator turns on more (see [Tool availability & gating](/docs/mcp/tool-gating)). If the list is empty, see [FAQ & Troubleshooting](/docs/mcp#faq--troubleshooting) on the MCP index page.
## Related
* [MCP Server overview](/docs/mcp) — the full tool surface and feature matrix.
* [API Reference](/docs/api-reference) — direct REST API if you prefer not to use MCP.
* [Desktop Application](/docs/desktop-app) — pairs well with any MCP-aware client.
# Microsoft Copilot (/docs/mcp/copilot)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Microsoft Copilot](https://copilot.microsoft.com) by [Microsoft](https://www.microsoft.com) (USA) directly to your software supply chain security data and ask questions in plain language. The endpoint is `https://mcp.safeguard.sh/mcp`. Once connected via the Copilot Studio MCP connector, Copilot can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. Open the Copilot Studio MCP connector configuration.
3. Add a remote MCP server (Streamable HTTP) with the URL `https://mcp.safeguard.sh/mcp`.
4. If the connector supports OAuth, it opens Safeguard's sign-in page: sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**. If it can only send a fixed header, use an MCP key instead (see [Authentication](#authentication)).
5. Reload Copilot — your enabled Safeguard security tools are now available. Start asking questions.
Nothing needs installing: Safeguard hosts the server. Safeguard does not publish an npm package or a local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## GitHub Copilot in VS Code
VS Code connects to remote MCP servers natively. Add Safeguard to `.vscode/mcp.json` in your workspace, or run **MCP: Open User Configuration** to add it for every workspace:
```json
{
"servers": {
"safeguard": {
"type": "http",
"url": "https://mcp.safeguard.sh/mcp"
}
}
}
```
On the first connection VS Code opens a browser window to sign in. Sign in to Safeguard, check the app name and the host the authorization code will be sent to, then click **Authorize access**.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). The Safeguard MCP server accepts two kinds of credential:
* OAuth 2.0: when your client supports it, it opens Safeguard's sign-in page. Sign in, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy.
* MCP key: for a client that can only send a fixed header. In Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...` (in VS Code, a `"headers"` object on the server entry; keep it in your user configuration, not a workspace file you commit). If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| MCP endpoint | `https://mcp.safeguard.sh/mcp` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# Cursor (/docs/mcp/cursor)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Cursor](https://cursor.com) directly to your software supply chain security data and ask questions in plain language. Cursor connects to `https://mcp.safeguard.sh/mcp` and signs in with OAuth, so there is nothing to install and no key to copy. Once connected, Cursor can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. Open `~/.cursor/mcp.json` (all projects) or `.cursor/mcp.json` in a project, and add this entry:
```json
{
"mcpServers": {
"safeguard": {
"url": "https://mcp.safeguard.sh/mcp"
}
}
}
```
3. Cursor supports OAuth for MCP servers. When it connects, it opens Safeguard's sign-in page: sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**.
4. Your enabled Safeguard security tools are now available in Cursor. Start asking questions.
Earlier versions of this page used `https://mcp.safeguard.sh/mcp/cursor`. That address reaches the same server, so an existing entry keeps working. Remove any `npx`/`mcp-remote` entry and `SAFEGUARD_API_KEY` setting from older instructions: Safeguard hosts the server, publishes no npm package or local bridge for it, and never reads that variable.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). The Safeguard MCP server accepts two kinds of credential:
* OAuth 2.0 (what Cursor uses): sign in to Safeguard when Cursor asks, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy.
* MCP key: only if you can't use OAuth. In Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and add `"headers": { "Authorization": "Bearer sg_sk_..." }` to the entry above. Keep that file out of source control. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| MCP endpoint | `https://mcp.safeguard.sh/mcp` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# Gemini (Google) (/docs/mcp/gemini)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Gemini](https://gemini.google.com) by [Google](https://www.google.com) directly to your software supply chain security data and ask questions in plain language. The Gemini endpoint is `https://mcp.safeguard.sh/mcp/gemini`. Once connected, Gemini can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. In Gemini CLI, add Safeguard as an HTTP server:
```bash
gemini mcp add --transport http safeguard https://mcp.safeguard.sh/mcp/gemini
```
Or add it to `~/.gemini/settings.json` (all projects) or `.gemini/settings.json` (one project) yourself:
```json
{
"mcpServers": {
"safeguard": {
"httpUrl": "https://mcp.safeguard.sh/mcp/gemini"
}
}
}
```
`httpUrl` is Gemini CLI's field for a Streamable HTTP server. Don't use `url`, which Gemini CLI reserves for SSE: Safeguard has no SSE endpoint.
3. Gemini CLI discovers Safeguard's OAuth sign-in when it first connects (`/mcp auth safeguard` starts it by hand). Sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**.
4. Your enabled Safeguard security tools are now available. Start asking questions.
Other Gemini tooling that supports remote MCP servers uses the same URL. Nothing needs installing: Safeguard hosts the server. Safeguard does not publish an npm package or a local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). The Safeguard MCP server accepts two kinds of credential:
* OAuth 2.0: when your client supports it, it opens Safeguard's sign-in page. Sign in, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy.
* MCP key: for a client that can only send a fixed header. In Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace. In Gemini CLI the header goes in the server's `headers` object.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| Gemini MCP endpoint | `https://mcp.safeguard.sh/mcp/gemini` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# Grok (xAI) (/docs/mcp/grok)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Grok](https://grok.com) by [xAI](https://x.ai) directly to your software supply chain security data and ask questions in plain language. The Grok endpoint is `https://mcp.safeguard.sh/mcp/grok`. Once connected, Grok can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. Open Grok's MCP configuration for your tooling.
3. Add a remote MCP server (Streamable HTTP) with the URL `https://mcp.safeguard.sh/mcp/grok`.
4. If the client supports OAuth for MCP servers, it opens Safeguard's sign-in page: sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**. If it can only send a fixed header, use an MCP key instead (see [Authentication](#authentication)).
5. Reload Grok — your enabled Safeguard security tools are now available. Start asking questions.
Nothing needs installing: Safeguard hosts the server. Safeguard does not publish an npm package or a local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). The Safeguard MCP server accepts two kinds of credential:
* OAuth 2.0: when your client supports it, it opens Safeguard's sign-in page. Sign in, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy.
* MCP key: for a client that can only send a fixed header. In Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| Grok MCP endpoint | `https://mcp.safeguard.sh/mcp/grok` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# MCP Integrations (/docs/mcp)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect your favorite AI assistant directly to your software supply chain security data and ask questions in plain language. Once connected, your assistant can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server registers hundreds of tools and also supports MCP resources and prompts. Tool availability is governed per tenant — a curated set is enabled by default and administrators enable more per workspace (see [Tool availability & gating](/docs/mcp/tool-gating)). Agents can even onboard and procure Safeguard itself — create the account through the unauthenticated `https://mcp.safeguard.sh/mcp/signup` endpoint (signup and email verification only), sign in with OAuth on the main endpoint, browse regional pricing, compare tiers, start a Stripe checkout, verify activation, and read the user's notifications (see [Payments & procurement](/docs/mcp/agent-payments) and the [Agents & LLMs guide](/docs/agents)).
## Choose your assistant
Pick your AI assistant below for step-by-step connection instructions. The guides span both US and European model companies. Every page uses an endpoint on the `mcp.safeguard.sh` host.
| Assistant | Guide |
| ------------------ | ---------------------------------------------- |
| Claude (Anthropic) | [/docs/mcp/claude](/docs/mcp/claude) |
| ChatGPT (OpenAI) | [/docs/mcp/openai](/docs/mcp/openai) |
| Le Chat (Mistral) | [/docs/mcp/mistral](/docs/mcp/mistral) |
| Aleph Alpha | [/docs/mcp/aleph-alpha](/docs/mcp/aleph-alpha) |
| Microsoft Copilot | [/docs/mcp/copilot](/docs/mcp/copilot) |
| Meta AI (Llama) | [/docs/mcp/meta](/docs/mcp/meta) |
| Perplexity | [/docs/mcp/perplexity](/docs/mcp/perplexity) |
| Cohere | [/docs/mcp/cohere](/docs/mcp/cohere) |
| Gemini (Google) | [/docs/mcp/gemini](/docs/mcp/gemini) |
| Grok (xAI) | [/docs/mcp/grok](/docs/mcp/grok) |
| Cursor | [/docs/mcp/cursor](/docs/mcp/cursor) |
## Authentication
You need a Safeguard account first. Safeguard hosts the MCP server at `https://mcp.safeguard.sh/mcp` (Claude's connector URL is `https://mcp.safeguard.sh/mcp/anthropic`), so there is nothing to install. There are two ways to authenticate:
* **OAuth 2.0 (recommended).** Add the URL to your assistant. It sends you to Safeguard's sign-in page: sign in at [https://app.safeguard.sh](https://app.safeguard.sh), check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy. Claude, ChatGPT, Cursor, VS Code and Gemini CLI all sign in this way.
* **MCP key.** For a client that can only send a fixed header. In Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. The key is shown once. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
Safeguard does not publish an npm package or a local bridge for its MCP server, and none is needed. Treat any package that claims to be the Safeguard MCP server as untrusted. The server also never reads environment variables such as `SAFEGUARD_API_KEY` from your machine.
Either way, your assistant acts as you: it can see and do only what your Safeguard role allows, within the tools your workspace has turned on. Two things to know about MCP keys:
* **An MCP key acts as the member who created it**, across the whole workspace. Give it only to a client you trust, and keep it out of source control.
* **Revoking takes effect within a minute.** Revoke a key under **Settings → Developer**. The server checks each key at least once a minute, so a revoked key, a key whose owner's account is closed, or a key in a workspace whose API-key access is turned off stops working within a minute.
The server registers hundreds of tools for vulnerability scanning, SBOM analysis, AI-powered remediation, SCM integration, and policy enforcement. Which of them your assistant can see and call is controlled per tenant — see [Tool availability & gating](/docs/mcp/tool-gating).
## Example prompts
Once connected, plain-language prompts work the same regardless of which assistant you picked above — this is the same starter list used across every per-assistant guide:
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Enforcing policy on MCP tool calls
Connecting an assistant to Safeguard's MCP server and gating which of Safeguard's own tools it can see (the previous section) is one layer of control, and it only governs Safeguard's own bundled tool surface. **Guard** is a separate product that adds a second, complementary layer: live enforcement on MCP tool calls in general — including MCP servers and agents you build or operate yourself, not just Safeguard's — evaluated against your organization's live Safeguard policy in real time rather than a fixed allow-list.
> Tool gating and Guard are independent mechanisms. Disabling one of Safeguard's own tools under **Feature Flags** does not create or change a Guard policy, and a Guard policy does not touch Safeguard's tool feature flags. Use Feature Flags to control access to Safeguard's own MCP tools; use Guard when you need the same kind of discovery-time/call-time control over MCP servers and agents you build or operate.
There are two ways to add Guard enforcement to an MCP server or agent:
* **[Guard SDK](/docs/guard-sdk)** (not published yet): a library for enforcing your policy inside your own MCP server or agent process. There is no Guard SDK package on PyPI, npm or the Go module proxy, so there is nothing to install today, and any package that claims to be it did not come from Safeguard.
* **[Guard Proxy](/docs/guard-proxy)** — run Guard as a standalone reverse-proxy gateway in front of one or more MCP servers you don't control the code of (or that are written in a language without a Guard SDK yet). Point your agent's MCP client at a proxy URL instead of the upstream server — `POST https:///p/{slug}/message` — and Guard evaluates every JSON-RPC call before forwarding allowed ones on.
Both approaches enforce the same underlying policy, authored in your Safeguard workspace rather than as files you check into source control. From there:
* **[Guard Policies](/docs/guard-policies)** covers how rules are authored: each one matches on method, tool name (glob wildcards), and/or agent ID, then resolves to **allow**, **deny**, or **monitor**, evaluated in priority order with first-match-wins. Rules can also carry input filters (block a pattern, cap request size, catch jailbreak phrasing) and output filters (mask PII in responses, redact fields, cap row counts) that run against tool traffic.
* **[Guard for servers & agents](/docs/guard-servers-agents)** covers registering the MCP servers and agents in your environment as first-class records, so policy can target a specific server or agent, tool discovery can run against a registered server, and an individual agent can be blocked, unblocked, or quarantined directly.
* **[Guard Audit & Alerts](/docs/guard-audit-alerts)** covers the append-only trail Guard writes for every request it evaluates — allow, deny, and monitor alike — plus alert rules that watch signals like jailbreak score, anomaly score, and blocked-request ratio.
* **[Guard Webhooks](/docs/guard-webhooks)** covers delivering those alerts to your own endpoint as a signed HTTP webhook, separate from the platform-wide [Webhooks & Events](/docs/webhooks-events) system.
## FAQ & Troubleshooting
**My assistant connects, but the tools menu is empty.**
First confirm the connection itself succeeded: you clicked **Authorize access** on Safeguard's sign-in page (OAuth), or your client sends a valid MCP key in the `Authorization` header. If the connection is fine, remember tool visibility is gated per tenant too: a fresh workspace only exposes a small curated default set until an administrator enables more. See [Tool availability & gating](/docs/mcp/tool-gating#whats-enabled-by-default).
**I only see a handful of tools, not the full catalog.**
That's expected, not a bug. A new workspace starts with six read-only tools for browsing products, projects, vulnerabilities and findings; every other tool stays off until an administrator turns it on per tool under **Feature Flags**. See [Tool availability & gating](/docs/mcp/tool-gating#enabling-more-tools).
**Should I use OAuth or an MCP key?**
Use OAuth wherever your client supports it, which includes Claude (web and Desktop), ChatGPT, Cursor, VS Code and Gemini CLI: there's no key to copy, store or rotate. Use an MCP key only for a client that can only send a fixed `Authorization` header.
**My assistant authenticated fine yesterday, but every call fails today.**
If you connected with OAuth, sign in again from your client. If you use an MCP key, check whether it was revoked, whether the member who created it still has an active account, and whether your workspace still has API-key access to MCP: a key stops working within a minute of any of those changing. Create a new key under **Settings → Developer** if you need one.
**Do I need `SAFEGUARD_API_KEY`, `npx` or an npm package?**
No. The server is hosted and never reads environment variables from your machine, and Safeguard publishes no package for it. Instructions that set `SAFEGUARD_API_KEY` or start a local bridge with `npx` are out of date: use the server URL with OAuth, or an MCP key in the `Authorization` header.
**Do I need Guard as well as connecting my assistant, or is one enough?**
They solve different problems. Connecting your assistant plus [tool gating](/docs/mcp/tool-gating) controls what Safeguard's *own* MCP server exposes to that one assistant. [Guard](#enforcing-policy-on-mcp-tool-calls) is a separate product for enforcing live policy on MCP traffic in general, including servers and agents that have nothing to do with Safeguard's own tool surface. Most teams only need Guard once they're building or operating MCP servers/agents of their own — connecting an assistant to Safeguard alone doesn't require it.
## Related
* [Tool availability & gating](/docs/mcp/tool-gating) — the per-tenant feature flags that decide which of Safeguard's own tools an assistant can see and call.
* [Guard SDK](/docs/guard-sdk) — embed live policy enforcement directly inside an MCP server or agent process you control.
* [Guard Proxy](/docs/guard-proxy) — enforce policy in front of MCP servers you don't control the code of.
* [Guard Policies](/docs/guard-policies) — how allow/deny/monitor rules and input/output filters are authored.
* [Servers & Agents](/docs/guard-servers-agents) — register the MCP servers and agents Guard policy can target.
* [Audit Trail & Alerts](/docs/guard-audit-alerts) — every decision Guard makes, plus alert rules for jailbreak, anomaly, and blocked-ratio spikes.
* [Guard Webhooks](/docs/guard-webhooks) — deliver Guard alerts to your own endpoint over a signed webhook.
* [RBAC & Teams](/docs/rbac-teams) — the roles and permissions that decide what a connected assistant can see and do.
* [SDKs](/docs/sdks): Safeguard publishes no language SDKs yet; the page lists what to use instead.
# Meta AI (Llama) (/docs/mcp/meta)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Meta AI](https://www.meta.ai) (Llama) by [Meta](https://www.meta.com) (USA) directly to your software supply chain security data and ask questions in plain language. The endpoint is `https://mcp.safeguard.sh/mcp`. Once connected, any Llama-based MCP-capable client can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. Open the MCP configuration in your Meta AI / Llama MCP-capable client.
3. Add a remote MCP server (Streamable HTTP) with the URL `https://mcp.safeguard.sh/mcp`.
4. If the client supports OAuth for MCP servers, it opens Safeguard's sign-in page: sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**. If it can only send a fixed header, use an MCP key instead (see [Authentication](#authentication)).
5. Reload your client — your enabled Safeguard security tools are now available. Start asking questions.
Nothing needs installing: Safeguard hosts the server. Safeguard does not publish an npm package or a local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). The Safeguard MCP server accepts two kinds of credential:
* OAuth 2.0: when your client supports it, it opens Safeguard's sign-in page. Sign in, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy.
* MCP key: for a client that can only send a fixed header. In Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| MCP endpoint | `https://mcp.safeguard.sh/mcp` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# Le Chat (Mistral) (/docs/mcp/mistral)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Le Chat](https://chat.mistral.ai) by [Mistral AI](https://mistral.ai) (France) directly to your software supply chain security data and ask questions in plain language. The endpoint is `https://mcp.safeguard.sh/mcp`. Once connected, Le Chat — or any Mistral MCP-capable client — can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. Open the MCP configuration in Le Chat, or any Mistral MCP-capable client.
3. Add a remote MCP server (Streamable HTTP) with the URL `https://mcp.safeguard.sh/mcp`.
4. If the client supports OAuth for MCP servers, it opens Safeguard's sign-in page: sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**. If it can only send a fixed header, use an MCP key instead (see [Authentication](#authentication)).
5. Reload Le Chat — your enabled Safeguard security tools are now available. Start asking questions.
Nothing needs installing: Safeguard hosts the server. Safeguard does not publish an npm package or a local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). The Safeguard MCP server accepts two kinds of credential:
* OAuth 2.0: when your client supports it, it opens Safeguard's sign-in page. Sign in, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy.
* MCP key: for a client that can only send a fixed header. In Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| MCP endpoint | `https://mcp.safeguard.sh/mcp` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# ChatGPT (OpenAI) (/docs/mcp/openai)
Safeguard exposes a REST/OpenAPI surface and an MCP (Model Context Protocol) server, so you can bring your software supply chain security data into [ChatGPT](https://chatgpt.com) by [OpenAI](https://openai.com). The recommended path is to add Safeguard to ChatGPT as a custom MCP server at `https://mcp.safeguard.sh/mcp` and sign in with OAuth. A Custom GPT Action that imports Safeguard's OpenAPI schema from `https://mcp.safeguard.sh/openapi.json` is an alternative with a smaller set of tools. Once connected, ChatGPT can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server offers hundreds of tools; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. In ChatGPT, open **Plugins**, select the plus button, then **Add custom MCP server**.
3. Enter a name (for example `Safeguard Security`) and a description.
4. Under **Connection**, enter the MCP server URL `https://mcp.safeguard.sh/mcp`.
5. Configure authentication with OAuth. ChatGPT registers itself with Safeguard, so there is no client ID or key to copy. Review the risk warning, select **I understand and want to continue**, then select **Create as a plugin**.
6. When ChatGPT sends you to Safeguard, sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**.
7. Your enabled Safeguard security tools are now available in ChatGPT. Start asking questions.
Account and workspace policies apply to adding and using custom MCP servers in ChatGPT. If you don't see the option, ask your ChatGPT workspace administrator. Nothing needs installing: Safeguard hosts the server. Safeguard does not publish an npm package or a local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
### Alternative: Custom GPT Action
A Custom GPT Action calls the tools in Safeguard's OpenAPI schema with a fixed key:
1. In ChatGPT, create a Custom GPT and open the Configure tab, then Actions, then Create new action.
2. Choose Import from URL and enter the OpenAPI schema URL `https://mcp.safeguard.sh/openapi.json`.
3. Under Authentication, select API Key with Auth Type Bearer, and paste a Safeguard MCP key (`sg_sk_...`, see [Authentication](#authentication)).
4. Save the GPT. Your enabled Safeguard tools from the schema are now available.
The action uses the one key you paste for everyone who can use that GPT, and the key acts as you. Keep the GPT private.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). The Safeguard MCP server accepts two kinds of credential:
* OAuth 2.0 (the custom MCP server above): sign in to Safeguard when ChatGPT asks, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy.
* MCP key (the Custom GPT Action): in Safeguard, open **Settings → Developer** and create a key of the type **MCP key**. It is sent as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ---------------------------------- | ---------------------------------------- |
| OpenAPI schema (Custom GPT Action) | `https://mcp.safeguard.sh/openapi.json` |
| MCP endpoint (custom MCP server) | `https://mcp.safeguard.sh/mcp` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# Perplexity (/docs/mcp/perplexity)
Safeguard ships its own remote MCP (Model Context Protocol) server, so you can connect [Perplexity](https://www.perplexity.ai) (USA) directly to your software supply chain security data and ask questions in plain language. The endpoint is `https://mcp.safeguard.sh/mcp`. Once connected, any Perplexity MCP-capable client can query your vulnerabilities, SBOMs, packages, licenses, findings, and compliance data, generate AI remediation plans, compare SBOMs, manage SCM integrations, and enforce policy gates. The server offers hundreds of tools and also supports MCP resources and prompts; a new workspace starts with a small read-only set, and an administrator turns on the rest per tool.
## What you can do
* Query vulnerabilities, SBOMs, packages, licenses, findings, and compliance data across your tenant.
* Generate AI-powered remediation plans for npm, pip, Maven, Go, and Cargo projects.
* Compare SBOMs in both CycloneDX and SPDX formats.
* Manage SCM integrations: GitHub, GitLab, Bitbucket, and Azure DevOps.
* Run risk scoring and compliance reporting.
* Enforce policy-gate checks for deployment readiness.
## Connect
1. Create your Safeguard account at [https://app.safeguard.sh](https://app.safeguard.sh), or sign in if you already have one.
2. Open the MCP configuration in your Perplexity MCP-capable client.
3. Add a remote MCP server (Streamable HTTP) with the URL `https://mcp.safeguard.sh/mcp`.
4. If the client supports OAuth for MCP servers, it opens Safeguard's sign-in page: sign in, check the app name and the host the authorization code will be sent to, then click **Authorize access**. If it can only send a fixed header, use an MCP key instead (see [Authentication](#authentication)).
5. Reload your client — your enabled Safeguard security tools are now available. Start asking questions.
Nothing needs installing: Safeguard hosts the server. Safeguard does not publish an npm package or a local bridge for it, so treat any package that claims to be the Safeguard MCP server as untrusted.
## Authentication
You need a Safeguard account first. If you don't have one, create it at [https://app.safeguard.sh](https://app.safeguard.sh). The Safeguard MCP server accepts two kinds of credential:
* OAuth 2.0: when your client supports it, it opens Safeguard's sign-in page. Sign in, check the app name and the host the page says the authorization code will be sent to, then click **Authorize access**. No keys to copy.
* MCP key: for a client that can only send a fixed header. In Safeguard, open **Settings → Developer**, create a key of the type **MCP key**, and send it as `Authorization: Bearer sg_sk_...`. If you don't see the Developer tab or the MCP key type, ask your Safeguard administrator: API-key access to MCP is turned on per workspace.
## Example prompts
```text
List my security projects
Find critical vulnerabilities
Show me all SBOMs
Generate a remediation plan for my npm project
Which packages violate my license policy?
```
## Endpoints
| Endpoint | URL |
| ------------------------------- | ---------------------------------------- |
| MCP endpoint | `https://mcp.safeguard.sh/mcp` |
| MCP keys (Settings → Developer) | `https://app.safeguard.sh/escm/settings` |
| Safeguard account | `https://app.safeguard.sh` |
# Docs, downloads, pricing, Gold and Academy tools (/docs/mcp/product-tools)
# Docs, downloads, pricing, Gold and Academy tools
These read-only tools let an assistant connected to the [Safeguard MCP server](/docs/mcp) answer questions about Safeguard itself: where to download a client, what a plan costs, what Gold knows about a package, which Academy course to take. None of them changes anything, and none reads your workspace's data except **Gold requests**, which reads your organization's own requests.
Each tool is **off until an administrator switches it on** for your workspace, like every MCP tool outside the default set. See [Tool availability & gating](/docs/mcp/tool-gating).
## Documentation
| Tool | What it does |
| ------------------------ | ---------------------------------------------------------------------- |
| `safeguard_search_docs` | Searches docs.safeguard.sh and returns the matching pages, with links. |
| `safeguard_get_doc_page` | Reads one docs page, so the assistant can answer from its exact text. |
## Downloads
| Tool | What it does |
| ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `safeguard_get_download_links` | The links to install Safeguard: the desktop app for Windows, macOS and Linux, the CLI install commands, the iOS and Android apps, the Chrome extensions, and the VS Code, Open VSX and JetBrains extensions. Filter by platform. |
| `safeguard_get_client_versions` | The latest published version of each client, from Safeguard's release feed. |
Every link is one Safeguard checked answers, and a client that is not published yet is reported as such rather than linked. The same links are on [safeguard.sh/download](https://safeguard.sh/download).
## Pricing
| Tool | What it does |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `safeguard_get_pricing` | The plans and prices on [safeguard.sh/pricing](https://safeguard.sh/pricing), shown as the page shows them, with local-currency amounts for a country when you ask (those are indicative conversions). Business, Enterprise and Sovereign read **Contact us**, as on the page. |
| `safeguard_pricing_calculator` | A pricing calculator: works out which published plan fits your usage (users, components scanned and fix pull requests a month) and what it costs monthly and yearly. MCP tool calls are unlimited on every plan, Free included, and never charged, so they never decide the plan. When your usage is beyond the self-serve plans, it says you need a custom plan, which Safeguard quotes per customer, and prepares a summary of your usage to send to sales. It never invents a price for a custom plan. |
| `safeguard_list_available_plans` | The plans an administrator has made available for your workspace to buy. |
The pricing tools repeat the pricing page's own note that all figures are proposed pending final sign-off, so an assistant never states a price more firmly than the page does.
## Gold
| Tool | What it does |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `safeguard_search_gold` | Searches [Safeguard Gold](/docs/gold-registry) for packages, CVEs and actively exploited vulnerabilities. |
| `safeguard_get_gold_package` | One package's known vulnerabilities, with which are on the CISA Known Exploited Vulnerabilities list, and whether it shows as Gold Certified (no known vulnerabilities and not deprecated). |
| `safeguard_list_gold_requests` | Your organization's Gold requests from Open Source Manager, with their status. It never shows who made a request. |
## Safeguard Academy
| Tool | What it does |
| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `safeguard_list_academy_courses` | Courses and certifications on academy.safeguard.sh, filterable by type, level and audience. |
| `safeguard_get_academy_course` | One course's outline: its modules and lessons, and the certification it leads to. |
| `safeguard_verify_academy_certificate` | Checks a certificate by the ID printed on it. |
| `safeguard_list_academy_sessions` | Upcoming and past live sessions and meetups, with times in UTC. Join links are on academy.safeguard.sh/events, not in the tool. |
## Blog, press and events
| Tool | What it does |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
| `safeguard_list_blog_posts`, `safeguard_get_blog_post` | Safeguard's blog posts, by search, category or tag. |
| `safeguard_list_press_releases` | Safeguard's press releases. |
| `safeguard_list_events` | Safeguard's upcoming and past events. The tool never registers you; registration is on the event's page. |
Only published items appear: a post scheduled for a later date is left out until it is live.
## Related
* [Tool availability & gating](/docs/mcp/tool-gating)
* [From the CLI and AI assistants](/docs/help-and-support/cli-and-assistants): filing support requests from an assistant.
# Tool availability & gating (/docs/mcp/tool-gating)
Safeguard's MCP server registers **hundreds of tools** spanning vulnerability management, SBOM and supply-chain analysis, findings, compliance, cloud and API security, secrets, and more. Not every tool is exposed to every workspace. Instead, tool availability is **governed per tenant** so administrators decide exactly which capabilities their assistants can use.
## How it works
Each MCP tool has its own feature flag of the form `mcp:tool:`. When your assistant connects, the server resolves the set of tools **enabled for your tenant** and uses that set for both:
* **Discovery** (`tools/list`) — only enabled tools are advertised to the assistant, and
* **Execution** (`tools/call`) — a call to a tool that is not enabled for your tenant is rejected.
Both surfaces resolve from the same source, so an assistant can never see a tool it cannot call, or call a tool it cannot see.
### What a rejected call looks like
If your assistant calls a tool your tenant hasn't enabled, the server doesn't fail the connection — it returns a normal tool result with an error flag rather than a transport-level error:
```json
{
"content": [
{
"type": "text",
"text": "Tool \"safeguard_scan_manifest\" is not enabled for this tenant. An administrator can enable it via MCP tool feature flags."
}
],
"isError": true
}
```
Most assistants surface that message directly, so the fastest path from "my assistant says a tool isn't available" to fixed is usually: copy the tool name out of the message and search for it under **Feature Flags**.
## What's enabled by default
A new workspace starts with a default set of six read-only tools. Every one is a read, so a client can approve the whole set at once and nothing in it can create, change or delete anything, or handle a credential. Every other MCP tool, including the ones that add an integration or start a scan, ships **disabled by default** and is enabled per tenant by an administrator (see below). The default set:
| Tool | What it does |
| -------------------------------- | -------------------------------------------------------------------------------------- |
| `safeguard_list_products` | List products (top-level software offerings) in the tenant |
| `safeguard_list_projects` | List projects in the current org/product |
| `safeguard_get_project` | Get details for one project, including components and vulnerabilities |
| `safeguard_list_vulnerabilities` | List vulnerabilities, filterable by severity, ecosystem, CVSS score, or exploit status |
| `safeguard_get_vulnerability` | Get details for one CVE, including CVSS score and remediation |
| `safeguard_list_findings` | List findings (vulnerability occurrences) in an SBOM or project |
Each of these corresponds to a `mcp:tool:` flag that's on by default for a new tenant, for example `mcp:tool:safeguard_list_vulnerabilities`. Any default-on tool can also be turned **off** per tenant. Every other tool stays registered on the server but is **off until an administrator turns it on** for the tenant, which is how you switch on scanning, integrations, billing, notifications, admin CRUD and the consoles for your workspace. A tool that isn't enabled doesn't show up in `tools/list` at all; there's no separate "disabled" entry indicating it exists but is off.
Workspaces created before the default set was narrowed may still have `safeguard_add_integration`, `safeguard_scan_repository`, `safeguard_get_current_context` and `safeguard_switch_organization` switched on. Check **Feature Flags** to see what yours has.
## Enabling more tools
Administrators enable or disable any tool per tenant from the Safeguard admin console, under **Feature Flags** — search by name or filter by category (per-tool MCP flags are grouped under the `mcp` category), toggle the tool on, and save. Toggling a tool creates a tenant-specific override; toggling it back to match the platform default (or using **Reset to Defaults**) removes the override so the tenant simply inherits whatever the platform default is going forward. This lets teams start narrow and widen access deliberately as they build trust in each capability.
Enabled-tool resolution is re-checked periodically (on the order of a minute) rather than only once per connection, so a change usually reaches an already-connected assistant session without reconnecting. The more common source of delay is the assistant client itself: many MCP clients fetch `tools/list` once when a session starts and cache it locally, so if a newly enabled tool still doesn't show up, reconnect or restart your assistant to force it to re-fetch the current list.
Feature Flags is an administrative screen, managed on your tenant's behalf rather than a self-service toggle every teammate sees — if you need a tool enabled and don't have access to it yourself, ask whoever administers your Safeguard tenant.
## Design principles
* **Least privilege by default.** Only six read-only tools are on out of the box; everything else — billing, account, notifications, admin CRUD, the consoles, and more — is opt-in per tenant, and any default can be switched off.
* **Tenant isolation.** Enabled-tool resolution is scoped to your tenant, organization, and product context — one workspace's configuration never affects another's.
* **Fail safe, never fail open.** If tool resolution cannot complete (for example, a transient outage), the server falls back to the small default set rather than exposing anything wider. An outage can never broaden what your assistant can do.
* **Stateless enforcement.** The MCP server holds no database of its own; it resolves your enabled tools from Safeguard's authentication service on demand (cached briefly per session, as described above) rather than storing them locally.
{/* Tool availability is governed by mcp:tool: feature flags resolved per tenant; see the admin Feature Flags screen. */}
## FAQ & Troubleshooting
**My assistant tries to use a tool and gets an error saying it's "not enabled for this tenant."**
That's the tool-gating check on `tools/call` doing its job — the tool exists and is registered on the server, but your tenant hasn't turned it on. The error comes back as a normal tool result rather than a connection failure (see [What a rejected call looks like](#what-a-rejected-call-looks-like) above), so most assistants will just relay the message. Copy the tool name and ask an administrator to enable it under **Feature Flags**.
**I just enabled a tool in Feature Flags, but my assistant still says it isn't available.**
Give it a little time — enabled-tool resolution is cached briefly (on the order of a minute) rather than re-checked on every call, so a just-toggled flag can take a moment to take effect even on a session that's already connected. If it's still missing after that, the more likely cause is the assistant client: many MCP clients fetch `tools/list` once when a session starts and cache the result, so reconnect or restart your assistant to force a re-fetch.
**How do I find the exact tool name to search for in Feature Flags?**
Tool names follow the pattern `safeguard__` — for example, `safeguard_scan_manifest` or `safeguard_list_sboms`. If you don't know the exact name, ask your assistant what it can currently do, or search Feature Flags by a keyword for the capability you want (e.g. "sbom" or "secrets") rather than the exact tool name.
**Can I enable different tools for different users, or only for the whole tenant?**
Tool gating resolves per tenant, not per individual user — everyone connecting under the same tenant (and the same organization/product, if your session switches context with `safeguard_switch_organization` or `safeguard_switch_product`) sees the same enabled-tool set. If you need finer-grained, per-agent control, that's what Guard (below) is for.
**Does turning a tool off here also block it in Guard, or does a Guard policy change affect what's enabled here?**
No — the two are independent mechanisms. See the callout in [How this relates to Guard](#how-this-relates-to-guard) below.
## How this relates to Guard
Everything above describes tool gating for **Safeguard's own MCP server** — the platform's own tools and the per-tenant feature flags that decide which of them a given workspace can see and call. If you're building or operating MCP servers of your own (or fronting third-party ones) and want that same kind of control — deciding which tools an agent may discover or invoke — that's what **Guard** provides as a product for MCP traffic in general.
Guard implements enforcement in the same two shapes tool gating conceptually splits into, discovery-time and call-time control, just generalized beyond Safeguard's own tools:
* **[Guard SDK](/docs/guard-sdk)** — embed enforcement directly inside your own MCP server or agent process. Your code calls `analyze_request` (or the TypeScript/Go equivalent) before a tool call executes, and the SDK applies your live policy in-process, continuously pulled in the background with no restarts to roll out a change.
* **[Guard Proxy](/docs/guard-proxy)** — run Guard as a standalone reverse-proxy gateway in front of one or more MCP servers you don't control the code of. Point your agent at the proxy instead of the upstream server, and every JSON-RPC call is evaluated against policy before it's forwarded on.
Both modes enforce the same underlying policy, authored in your Safeguard workspace rather than as files you check into source control — see **[Guard Policies](/docs/guard-policies)** for how rules are structured. A Guard policy rule can match on tool name (with glob wildcards) and resolve to `allow`, `deny`, or `monitor` — the general-purpose counterpart to the enabled/disabled decision the `mcp:tool:` feature flags above make specifically for Safeguard's bundled tools. Guard policies can also go further than allow/deny alone, filtering request and response content: masking PII in tool responses, redacting fields, capping row counts, or catching jailbreak attempts in tool inputs.
> Feature-flag-based tool gating (this page) and Guard policy enforcement are independent mechanisms. Disabling a Safeguard tool under **Feature Flags** does not create or change a Guard policy, and enforcing a Guard policy against your own MCP server does not touch Safeguard's tool feature flags. Use Feature Flags to control access to Safeguard's own MCP tools; use Guard (SDK or Proxy) when you need the same kind of control over MCP servers and agents you build or operate yourself.
## Related
* [MCP Integrations overview](/docs/mcp)
* [Guardrails enforcement](/docs/guardrails-enforcement)
* [Guard SDK](/docs/guard-sdk) — embed policy enforcement directly in an MCP server or agent process you control.
* [Guard Proxy](/docs/guard-proxy) — enforce policy in front of MCP servers without modifying their code.
* [Guard Policies](/docs/guard-policies) — how allow/deny/monitor rules are authored and matched against tool calls.
* [RBAC, Teams & Organizations](/docs/rbac-teams) — how Safeguard's organization roles and permissions work more broadly.
# Attestation (/docs/osm/attestation)
# Attestation
Attestations provide cryptographic proof of how software was built, ensuring supply chain integrity and preventing tampering.
## What is Attestation?
Software attestation provides signed statements about:
* **Where** was this built?
* **What** source code was used?
* **How** was it built?
* **Who** triggered the build?
## Supported Attestation Types
### SLSA Provenance
Supply chain Levels for Software Artifacts (SLSA):
| Level | Description |
| ---------- | --------------------------------- |
| **SLSA 1** | Documentation of build process |
| **SLSA 2** | Hosted build, signed provenance |
| **SLSA 3** | Hardened build platform |
| **SLSA 4** | Two-party review, hermetic builds |
Gold packages require minimum SLSA Level 2.
### Sigstore
Sigstore-based attestations provide:
* Keyless signing with OIDC
* Transparency log (Rekor)
* Certificate verification
* Timestamp authority
### In-toto
In-toto framework attestations for:
* Source code verification
* Build step documentation
* Multi-party verification
* Custom policies
## Verification Process
When you install a Gold package:
1. **Fetch Attestation** - Download associated attestations
2. **Verify Signature** - Check cryptographic signatures
3. **Validate Claims** - Ensure build claims match
4. **Check Transparency** - Verify in public logs
5. **Confirm Identity** - Validate builder identity
## Viewing Attestations
For any Gold package:
1. Open the package in Gold Directory
2. Navigate to **Attestations** tab
3. View:
* Attestation type
* Signer identity
* Build information
* Verification status
## CLI Verification
There is no CLI or npm package for verifying attestations yet. Check a package's attestation status on its page in the platform, as described above.
## Missing Attestations
Packages without attestations:
* Cannot achieve Gold status
* Show warning in Enterprise ESCM
* Are flagged in risk assessments
## Creating Attestations
For your own packages, use:
* GitHub Actions with SLSA generator
* Sigstore cosign
* In-toto tooling
[See our guide on creating attestations →](/docs/api-reference)
# Security Database (/docs/osm/gold-directory)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Security Database
The OSM Security Database provides comprehensive security intelligence for open source packages, similar to [Snyk's vulnerability database](https://security.snyk.io/). Search and explore security information to make informed decisions about your dependencies.
## Package Security Information
Search for any open source package to view:
### Security Overview
| Field | Description |
| ----------------------- | ----------------------------------- |
| **Security Score** | Overall security assessment (0-100) |
| **Vulnerability Count** | Total known vulnerabilities |
| **Critical/High CVEs** | Count of severe vulnerabilities |
| **Last Updated** | Most recent security scan |
| **Maintenance Status** | Active/Inactive/Abandoned |
### Vulnerability Details
For each vulnerability:
* **CVE ID** - Unique identifier
* **Severity** - Critical, High, Medium, Low
* **CVSS Score** - Numerical severity (0-10)
* **Description** - What the vulnerability does
* **Affected Versions** - Which versions are impacted
* **Fixed Version** - Version that resolves the issue
* **Exploit Status** - Known exploits available
* **References** - Links to advisories
### Version History
Track security across versions:
* Timeline of releases
* Vulnerability introduction points
* Security improvements over time
* Recommended upgrade paths
## Searching the Database
### By Package Name
```
lodash
express
django
spring-boot
```
### By CVE
```
CVE-2021-44228
CVE-2023-1234
```
### By Ecosystem
Filter by package ecosystem:
* npm (JavaScript)
* PyPI (Python)
* Maven (Java)
* NuGet (.NET)
* Go modules
* RubyGems
* Cargo (Rust)
* Packagist (PHP)
## Package Page
Each package page includes:
### Security Tab
* Current vulnerabilities
* Historical vulnerabilities
* Fix recommendations
### Dependencies Tab
* Direct dependencies
* Transitive dependencies
* Dependency vulnerabilities
### Versions Tab
* All versions with security status
* Recommended versions
* Deprecated versions
### License Tab
* License type
* License obligations
* Compatibility notes
### Attestation Tab
* Build provenance
* Signature verification
* SLSA level
## Use Cases
### Before Installing a Package
1. Search for the package
2. Check vulnerability count
3. Review license
4. Verify attestation
5. Make informed decision
### Responding to Security Alerts
1. Search for the CVE
2. See all affected packages
3. Review impact
4. Plan remediation
### Compliance Auditing
1. Export package list
2. Review licenses
3. Check attestations
4. Documentation compliance
## API Access
Query the security database programmatically:
```bash
# Get package security info
curl "https://api.safeguard.sh/v1/packages/npm/lodash" \
-H "Authorization: Bearer $API_KEY"
# Search vulnerabilities
curl "https://api.safeguard.sh/v1/vulnerabilities?cve=CVE-2021-44228" \
-H "Authorization: Bearer $API_KEY"
```
# Open Source Manager (/docs/osm)
# Open Source Manager (OSM)
Open source is everywhere—and so are its vulnerabilities. OSM provides comprehensive open source security intelligence, similar to [Snyk's vulnerability database](https://security.snyk.io/), giving you detailed information about package security, vulnerabilities, and compliance.
**Make informed decisions about your dependencies.**
## Key Features
### Open Source Security Database
* Comprehensive vulnerability database
* Package security intelligence
* Real-time vulnerability tracking
* Historical security data
### Vulnerability Intelligence
* CVE details and analysis
* CVSS scoring and severity
* Exploit availability information
* Fix recommendations
* Affected version ranges
### Attestation Verification
* SLSA provenance verification
* Sigstore signature validation
* Build reproducibility
* Supply chain integrity
### License Compliance
* License detection and classification
* Compatibility analysis
* Policy enforcement
* Attribution generation
## What's Included
## Open Source Security Database
Search and browse security information for open source packages:
### Package Information
| Field | Description |
| ------------------------- | ------------------------------------------- |
| **Package Name** | Name and ecosystem (npm, PyPI, Maven, etc.) |
| **Version History** | All versions with security status |
| **Vulnerabilities** | Known CVEs affecting the package |
| **Severity Distribution** | Critical, High, Medium, Low breakdown |
| **License** | SPDX license identifier |
| **Maintainer Status** | Active maintenance indicator |
| **Security Advisories** | Related security bulletins |
### Vulnerability Details
For each vulnerability:
* CVE identifier and description
* Affected version ranges
* Fixed versions
* CVSS score and vector
* Exploit information
* Remediation guidance
## Getting Started
1. Navigate to the OSM security database
2. Search for packages by name or CVE
3. Review security information
4. Check attestation status
5. Verify license compliance
## Use Cases
### Pre-Installation Review
Before adding a new dependency, check its security posture:
* Known vulnerabilities
* Maintenance status
* License compatibility
### Vulnerability Research
When responding to security alerts:
* Detailed CVE analysis
* Impact assessment
* Remediation options
### Compliance Auditing
For regulatory requirements:
* License inventory
* Security attestation
* Supply chain verification
## Integration with ESSCM
OSM data is integrated into Enterprise Software Supply Chain Manager (ESSCM):
* Automatic vulnerability matching
* License policy enforcement
* Attestation verification during SBOM generation
# License Compliance (/docs/osm/license-compliance)
# License Compliance
Ensure your use of open source software complies with license obligations and organizational policies.
## License Detection
OSM automatically detects licenses from:
* LICENSE files
* Package manifests
* Source code headers
* SPDX declarations
## License Categories
### Permissive Licenses
Low obligation, business-friendly:
* MIT
* Apache 2.0
* BSD (2-clause, 3-clause)
* ISC
### Copyleft Licenses
Require source disclosure:
* GPL v2/v3
* LGPL v2.1/v3
* AGPL v3
* MPL 2.0
### Proprietary/Commercial
Require commercial agreements:
* Custom EULA
* Commercial licenses
* Dual-licensed packages
## License Policies
Define organizational policies:
### Creating Policies
1. Navigate to **Settings** → **License Policies**
2. Click **Create Policy**
3. Configure:
* Allowed licenses
* Blocked licenses
* Exceptions
* Actions (warn, block)
### Policy Examples
**Enterprise-Friendly Policy:**
```
Allow: MIT, Apache-2.0, BSD-*, ISC
Block: GPL-*, AGPL-*
Action: Block on violation
```
**Copyleft-Aware Policy:**
```
Allow: MIT, Apache-2.0, LGPL-*, MPL-2.0
Block: GPL-3.0, AGPL-*
Warn: GPL-2.0
```
## Compatibility Analysis
Check license compatibility:
* Can you combine these licenses?
* What are the obligations?
* Are there conflicts?
## Attribution Generation
Generate required attribution:
1. Select your project
2. Click **Generate Attribution**
3. Output includes:
* All components used
* License text for each
* Copyright notices
* Source code URLs
Export as:
* NOTICE file
* HTML page
* PDF document
* Markdown
## Compliance Dashboard
Monitor license compliance:
* Policies passed/failed
* Violations by severity
* Trend over time
* Projects at risk
## Gold Package Licenses
All Gold packages have:
* Clear license declaration
* Permissive or well-understood licenses
* No conflicting dependencies
* Complete attribution information
# User Guide (/docs/osm/user-guide)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Open Source Manager User Guide
This guide covers everything you need to know to effectively use Open Source Manager for open source security intelligence and package management.
## Getting Started
### Accessing OSM
1. Log in to Safeguard
2. Navigate to **Open Source Manager** from the main menu
3. You'll see the OSM dashboard
### Dashboard Overview
The OSM dashboard displays:
| Section | Description |
| ------------------- | --------------------------------------- |
| **Search Bar** | Search for open source packages |
| **Gold Directory** | Pre-verified secure packages |
| **Recent Searches** | Your search history |
| **Watchlist** | Packages you're monitoring |
| **Alerts** | New vulnerabilities in watched packages |
## Searching Packages
### Basic Search
1. Enter package name in search bar
2. Optionally specify version
3. Press Enter or click Search
### Search Syntax
```
# Simple search
lodash
# With version
lodash@4.17.21
# With ecosystem
npm:lodash
pypi:requests
maven:org.apache.commons:commons-lang3
```
### Supported Ecosystems
| Ecosystem | Prefix | Example |
| --------- | ------------ | ----------------------------- |
| npm | `npm:` | `npm:express` |
| PyPI | `pypi:` | `pypi:django` |
| Maven | `maven:` | `maven:log4j:log4j` |
| Go | `go:` | `go:github.com/gin-gonic/gin` |
| RubyGems | `gem:` | `gem:rails` |
| NuGet | `nuget:` | `nuget:Newtonsoft.Json` |
| Cargo | `cargo:` | `cargo:serde` |
| Packagist | `packagist:` | `packagist:laravel/framework` |
### Search Results
Results show:
* Package name and version
* Attestation score (LCAL)
* Vulnerability count
* License
* Maintenance status
* Last updated
## Package Details
### Overview Tab
| Field | Description |
| --------------------- | ----------------------- |
| **Package Name** | Official package name |
| **Version** | Current version |
| **Attestation Score** | LCAL 0-4 rating |
| **Risk Score** | Overall risk assessment |
| **Vulnerabilities** | Known CVE count |
| **License** | Package license |
| **Repository** | Source repository link |
### Vulnerabilities Tab
View all known vulnerabilities:
* CVE identifier
* Severity (CVSS score)
* EPSS score
* Fix available indicator
* Affected versions
* Remediation guidance
### Attestation Tab
Supply chain verification:
* Provenance verification status
* Build attestation
* Signature verification
* SLSA level
* Malicious package scan results
### Dependencies Tab
Package dependency tree:
* Direct dependencies
* Transitive dependencies
* Dependency vulnerabilities
* License analysis
### Versions Tab
All available versions:
* Version number
* Release date
* Vulnerabilities per version
* Recommended version indicator
## Gold Directory
### What is Gold Directory?
Gold Directory contains pre-verified packages that meet Safeguard's security standards:
* LCAL 3+ attestation
* No critical/high vulnerabilities
* Active maintenance
* License compliance verified
### Using Gold Directory
1. Navigate to **Gold Directory**
2. Browse by category or search
3. Filter by ecosystem
4. Click package for details
### Gold Package Benefits
| Benefit | Description |
| ---------------- | ----------------------------------- |
| **Pre-Verified** | Security checks already done |
| **Monitored** | Continuous vulnerability monitoring |
| **Recommended** | Safe for production use |
| **Fast Updates** | Quick alerts for issues |
### Adding to Project
Use Gold packages in your projects:
```bash
# npm: pin the Gold-verified version
npm install lodash@4.17.21
```
## Watchlist
### Adding to Watchlist
Monitor packages for security updates:
1. Open package details
2. Click **+ Add to Watchlist**
3. Configure notification preferences
### Watchlist Management
1. Go to **Watchlist** tab
2. View all watched packages
3. Edit notification settings
4. Remove packages as needed
### Notification Options
| Option | Description |
| ---------------------- | ----------------------------- |
| **New Vulnerability** | Alert on new CVE |
| **Critical Only** | Only critical vulnerabilities |
| **New Version** | Alert on new releases |
| **Maintenance Status** | Status changes |
## Risk Assessment
### Understanding Risk Scores
Risk scores (0-100) consider:
| Factor | Weight | Description |
| --------------- | ------ | ---------------------- |
| Vulnerabilities | 40% | CVE count and severity |
| Maintenance | 20% | Update frequency |
| Community | 15% | Stars, contributors |
| Age | 10% | Package maturity |
| License | 15% | License risk |
### Risk Categories
| Score | Category | Meaning |
| ------ | -------- | --------------------- |
| 0-20 | Low | Generally safe to use |
| 21-50 | Medium | Review before using |
| 51-80 | High | Caution advised |
| 81-100 | Critical | Avoid or replace |
## License Compliance
### License Analysis
OSM analyzes licenses for:
* License type identification
* Compatibility checking
* Obligation requirements
* Commercial use restrictions
### License Categories
| Category | Risk Level | Examples |
| --------------- | ---------- | -------------------- |
| Permissive | Low | MIT, Apache 2.0, BSD |
| Weak Copyleft | Medium | LGPL, MPL |
| Strong Copyleft | High | GPL, AGPL |
| Proprietary | Review | Commercial licenses |
### Checking Compatibility
1. Open package details
2. Go to **License** tab
3. View license obligations
4. Check compatibility with your license
## Comparing Packages
### Side-by-Side Comparison
Compare alternative packages:
1. Search for a package
2. Click **Compare**
3. Add packages to compare
4. View comparison table
### Comparison Metrics
* Security score
* Vulnerability count
* Maintenance health
* Download popularity
* Community size
* License type
## API Usage
### Search API
```bash
curl -X GET "https://api.safeguard.sh/v1/osm/packages?q=lodash" \
-H "Authorization: Bearer $API_KEY"
```
### Package Details
```bash
curl -X GET "https://api.safeguard.sh/v1/osm/packages/npm/lodash/4.17.21" \
-H "Authorization: Bearer $API_KEY"
```
### Vulnerabilities
```bash
curl -X GET "https://api.safeguard.sh/v1/osm/packages/npm/lodash/vulnerabilities" \
-H "Authorization: Bearer $API_KEY"
```
## Best Practices
### Package Selection
* Check attestation score first
* Review vulnerability history
* Verify active maintenance
* Consider alternatives
### Monitoring
* Watch critical dependencies
* Set up vulnerability alerts
* Review alerts promptly
* Update regularly
### Compliance
* Define allowed licenses
* Check before adding dependencies
* Document exceptions
* Review periodically
## Next Steps
* [Gold Directory](/docs/osm/gold-directory)
* [Attestation](/docs/osm/attestation)
* [License Compliance](/docs/osm/license-compliance)
# Audit Trails (/docs/portal/audit-trails)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Audit Trails
Portal maintains comprehensive audit trails for all activity, ensuring compliance and enabling security investigations.
## What's Logged
### SBOM Activity
* SBOM creation and import
* SBOM modifications
* SBOM deletion
* Version changes
* Metadata updates
### Access Activity
* SBOM views
* Downloads
* Sharing events
* Link creation and usage
* Permission changes
### Administrative Activity
* User management
* Settings changes
* Integration configurations
* Policy modifications
## Audit Log Fields
Each log entry includes:
| Field | Description |
| -------------- | ------------------------------ |
| **Timestamp** | When the action occurred (UTC) |
| **Actor** | Who performed the action |
| **Action** | What was done |
| **Resource** | What was affected |
| **Details** | Additional context |
| **IP Address** | Source IP |
| **User Agent** | Browser/client info |
| **Result** | Success or failure |
## Viewing Audit Logs
### Web Interface
1. Navigate to **Settings** → **Audit Logs**
2. Use filters to narrow results:
* Date range
* Actor
* Action type
* Resource
3. Click entries for full details
### API Access
```bash
curl "https://api.safeguard.sh/v1/audit-logs?from=2025-01-01&to=2025-01-31" \
-H "Authorization: Bearer $API_KEY"
```
## Exporting Logs
Export audit logs for compliance:
1. Set your filter criteria
2. Click **Export**
3. Choose format:
* CSV
* JSON
* PDF (formatted report)
4. Download or schedule delivery
## Log Retention
Default retention periods:
| Log Type | Retention |
| --------------- | ------------ |
| Access logs | 2 years |
| Administrative | 7 years |
| Security events | 7 years |
| All logs | Configurable |
Enterprise customers can configure custom retention.
## SIEM Integration
Send logs to your SIEM:
* Splunk
* Elastic/ELK
* Datadog
* Sumo Logic
* Custom webhook
Configure in **Settings** → **Integrations** → **SIEM**.
## Compliance Reporting
Generate compliance-ready audit reports:
* SOC2 evidence packages
* FedRAMP continuous monitoring
* ISO 27001 audit trails
* Custom compliance frameworks
# Compliance (/docs/portal/compliance)
# Compliance
Portal provides automated compliance verification for EO 14028, FedRAMP, and other regulatory requirements.
## EO 14028 Compliance
Executive Order 14028 requires software vendors selling to the US government to provide SBOMs meeting specific criteria.
### Automated Verification
Portal automatically validates SBOMs against EO 14028 requirements:
| Requirement | Description | Status |
| ------------------ | ------------------------------------- | ------ |
| **Minimum Fields** | All NTIA minimum fields present | ✅/❌ |
| **Component ID** | Unique identifiers for all components | ✅/❌ |
| **Supplier Info** | Vendor/supplier data included | ✅/❌ |
| **Version Info** | Specific version details | ✅/❌ |
| **Dependencies** | Relationships defined | ✅/❌ |
| **Hash Values** | Cryptographic verification | ✅/❌ |
### Compliance Score
Each SBOM receives a compliance score:
* **100%** - Fully compliant
* **80-99%** - Minor gaps
* **50-79%** - Significant gaps
* **Below 50%** - Major remediation needed
### Gap Analysis
View specific gaps and remediation steps:
1. Open the SBOM
2. Navigate to **Compliance** tab
3. View the gap analysis
4. Follow remediation guidance
## FedRAMP Compliance
For organizations requiring FedRAMP certification:
* FedRAMP HIGH control mapping
* IL5 (Impact Level 5) support
* Continuous monitoring integration
* Control inheritance documentation
## NTIA Minimum Elements
The NTIA defines minimum SBOM elements:
| Element | Description |
| --------------------------- | --------------------------------------- |
| **Supplier Name** | Name of entity that creates/distributes |
| **Component Name** | Name assigned to the component |
| **Version** | Version identifier |
| **Unique Identifier** | PURL, CPE, or other unique ID |
| **Dependency Relationship** | Upstream/downstream relationships |
| **Author** | Name of SBOM author |
| **Timestamp** | Date/time of SBOM generation |
## Compliance Reports
Generate audit-ready reports:
1. Select SBOMs for reporting
2. Choose report type:
* EO 14028 Compliance Report
* NTIA Minimum Elements Report
* Gap Analysis Report
* Full Audit Package
3. Export as PDF or Excel
4. Include supporting documentation
## Automated Remediation
Fix common compliance gaps automatically:
* Add missing supplier information
* Generate unique identifiers
* Complete dependency mapping
* Add required timestamps
# Find & Review SBOMs (/docs/portal/find-review-sboms)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Find & Review SBOMs
The Find & Review feature in Portal allows you to discover, search, and analyze SBOMs from your suppliers, partners, and the broader community.
## Overview
Find & Review helps you:
* Discover supplier SBOMs
* Search by product, component, or vulnerability
* Review SBOM quality and completeness
* Compare product versions
* Make informed procurement decisions
## Searching for SBOMs
### Basic Search
1. Navigate to **Portal** → **Find SBOMs**
2. Enter search terms in the search bar
3. Press Enter or click **Search**
### Search Fields
| Field | Description | Example |
| ---------------- | -------------------- | ----------------- |
| **Product Name** | Search by product | "Database Server" |
| **SKU** | Search by product ID | "PROD-2024-001" |
| **Supplier** | Search by vendor | "Acme Corp" |
| **Component** | Search by dependency | "log4j" |
| **Version** | Search by version | "2.0.0" |
### Advanced Search
Click **Advanced** for more options:
| Filter | Description |
| -------------- | ------------------------------------- |
| **Date Range** | SBOMs updated within period |
| **Format** | CycloneDX, SPDX |
| **Compliance** | EO 14028 compliant only |
| **Severity** | Exclude high-severity vulnerabilities |
### Search Syntax
Use operators for precise searches:
```
# Exact phrase
"apache tomcat"
# Component search
component:log4j
# Supplier search
supplier:"Acme Corp"
# Version range
version:>=2.0.0
# Exclude term
database -mysql
# Combine filters
supplier:"Acme" AND component:spring
```
## Search Results
### Results List
Search results display:
| Column | Description |
| -------------- | ------------------------ |
| **Product** | Product name and logo |
| **Supplier** | Vendor organization |
| **Version** | Latest version available |
| **Updated** | Last SBOM update date |
| **Compliance** | Compliance status |
| **Components** | Number of components |
### Sorting Options
Sort results by:
* Relevance (default)
* Product name
* Supplier name
* Update date
* Component count
### Filtering Results
Narrow results using filters:
* **Category** - Product category
* **Supplier** - Specific vendors
* **Access** - Public / My SBOMs / Shared with me
* **Compliance** - Compliance status
## Reviewing SBOMs
### SBOM Overview
Click a result to view details:
| Section | Contents |
| ------------------- | ------------------------------- |
| **Summary** | Product info, supplier, version |
| **Compliance** | EO 14028 status, NTIA elements |
| **Components** | Total count, breakdown by type |
| **Vulnerabilities** | Known vulnerabilities summary |
| **Licenses** | License distribution |
### Detailed Analysis
View in-depth SBOM analysis:
#### Components Tab
* Full component list
* Version information
* Package URLs (PURLs)
* Supplier data
#### Vulnerabilities Tab
* CVE list with severity
* CVSS scores
* Fix availability
* Exploitation status
#### Licenses Tab
* License types
* Compatibility analysis
* Attribution requirements
#### Quality Tab
* SBOM completeness score
* Missing fields
* Data quality issues
## Comparing SBOMs
### Version Comparison
Compare different versions of the same product:
1. Open product SBOM
2. Click **Compare Versions**
3. Select versions to compare
4. View differences
### Comparison View
| Comparison | Shows |
| ------------------------- | --------------------- |
| **Added Components** | New dependencies |
| **Removed Components** | Dropped dependencies |
| **Version Changes** | Updated components |
| **New Vulnerabilities** | Newly introduced CVEs |
| **Fixed Vulnerabilities** | Resolved CVEs |
### Product Comparison
Compare different products:
1. Select multiple products
2. Click **Compare Products**
3. View side-by-side analysis
## Requesting Access
### Request Private SBOMs
For SBOMs not publicly available:
1. Find the product
2. Click **Request Access**
3. Provide justification
4. Submit request
### Request Status
Track request status:
| Status | Meaning |
| ------------ | -------------------------- |
| **Pending** | Awaiting supplier response |
| **Approved** | Access granted |
| **Denied** | Request rejected |
| **Expired** | Access period ended |
## Adding to My SBOMs
### Save for Later
Add SBOMs to your collection:
1. Find SBOM
2. Click **Add to My SBOMs**
3. Select destination folder
4. Confirm
### Organizing Saved SBOMs
Create folders to organize:
1. Go to **My SBOMs**
2. Click **+ New Folder**
3. Name the folder
4. Drag SBOMs to organize
## Subscribing to Updates
### Enable Notifications
Subscribe to SBOM updates:
1. Open product SBOM
2. Click **Subscribe**
3. Choose notification preferences:
* New versions
* Vulnerability updates
* Compliance changes
### Managing Subscriptions
View and manage subscriptions:
1. Go to **Settings** → **Subscriptions**
2. View all subscriptions
3. Modify or cancel as needed
## Exporting SBOMs
### Download Options
Download SBOMs in various formats:
| Format | Description |
| ------------------ | ----------------------- |
| **Original** | As provided by supplier |
| **CycloneDX JSON** | Converted if needed |
| **SPDX JSON** | Converted if needed |
| **CSV** | Component list |
| **PDF Report** | Formatted report |
### Bulk Export
Export multiple SBOMs:
1. Select SBOMs
2. Click **Export Selected**
3. Choose format
4. Download archive
## Integration with TPRM
Link discovered SBOMs to vendor assessments:
1. Find vendor SBOM
2. Click **Link to TPRM**
3. Select or create vendor profile
4. Associate SBOM
See [Third Party Risk Manager](/docs/tprm) for more.
## API Access
```bash
# Search SBOMs
curl -X GET "https://api.safeguard.sh/v1/portal/search?q=apache" \
-H "Authorization: Bearer $API_KEY"
# Get SBOM details
curl -X GET https://api.safeguard.sh/v1/portal/sboms/{id} \
-H "Authorization: Bearer $API_KEY"
# Request access
curl -X POST https://api.safeguard.sh/v1/portal/sboms/{id}/request-access \
-H "Authorization: Bearer $API_KEY" \
-d '{"justification": "Vendor evaluation"}'
```
## Best Practices
### Searching
* Use specific terms for precise results
* Combine filters for targeted searches
* Save common searches
* Subscribe to important suppliers
### Reviewing
* Check compliance status first
* Review vulnerability summary
* Verify component completeness
* Compare with previous versions
### Organization
* Create logical folder structure
* Tag important SBOMs
* Review subscriptions regularly
* Archive outdated SBOMs
## Next Steps
* [My Products](/docs/portal/my-products)
* [SBOM Repository](/docs/portal/sbom-repository)
* [Third Party Risk Manager](/docs/tprm)
# Portal (/docs/portal)
# Portal
Scattered SBOMs mean scattered security. Portal centralizes SBOM management with secure third-party sharing, EO 14028 compliance verification, and complete audit trails.
**One platform. Total control. Zero compliance gaps.**
## What Portal is, and what it is not
Portal is **one product**: the place you publish, share and redistribute SBOMs,
plus the Trust Center that fronts them. Publishing creates an immutable copy;
sharing distributes that copy as-is. Everything on this page belongs to that
one product.
Portal is **not** the free tier. Two different things are called "free" and
they are easy to confuse:
| | What it is | How it meters |
| --------------------- | ---------------------------------------------------------------- | --------------------- |
| **Portal free entry** | The $0 rung of Portal. 1 product published, public link sharing. | Per product published |
| **The Free plan** | The $0 rung of the main platform. Scanning, 1+ scan a month. | Per developer |
A customer can be on the platform Free plan and still have no Portal
entitlement, and a customer can buy Portal standalone without being on the
Free plan at all. If you are scoping or pricing, say which one you mean.
## Key Features
### Centralized Repository
* Single source of truth for all SBOMs
* Organized by products, versions, and teams
* Full version history
* Searchable across your entire portfolio
### Secure Sharing
* Share SBOMs with customers and partners
* Granular access controls
* Time-limited sharing links
* Download tracking
### EO 14028 Compliance
* Automated compliance verification
* Required field validation
* Compliance scoring
* Audit-ready reports
### Complete Audit Trails
* Every action logged
* Who accessed what, when
* Change history
* Exportable for auditors
## What's Included
## Getting Started
1. Import existing SBOMs or connect to Enterprise ESCM
2. Organize by products and versions
3. Configure sharing settings
4. Verify compliance status
5. Share with stakeholders
## Export Formats
Portal supports 30+ export formats:
| Category | Formats |
| ------------------ | -------------------------------------------- |
| **SBOM Standards** | SPDX (JSON, XML, RDF), CycloneDX (JSON, XML) |
| **Spreadsheets** | CSV, Excel (XLSX), TSV |
| **Documents** | PDF, HTML, Markdown |
| **Data** | JSON, YAML, XML |
| **Custom** | Template-based exports |
## Integration
Portal integrates with:
* Enterprise ESCM (automatic SBOM sync)
* Third Party Risk Manager (vendor SBOMs)
* Open Source Manager (Gold packages)
* CI/CD pipelines (automated publishing)
# Manage Your Repository (/docs/portal/manage-repository)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# Manage Your Repository
The repository management features in Portal help you organize, maintain, and govern your SBOM collection effectively.
## Overview
Repository management enables you to:
* Organize SBOMs into folders and categories
* Set retention policies
* Manage storage and quotas
* Configure access controls
* Maintain SBOM quality
## Repository Structure
### Hierarchy
```
Repository
├── Products/
│ ├── Product A/
│ │ ├── v1.0.0 (SBOM)
│ │ ├── v1.1.0 (SBOM)
│ │ └── v2.0.0 (SBOM)
│ └── Product B/
├── Third-Party/
│ ├── Vendor A/
│ └── Vendor B/
├── Internal/
└── Archive/
```
### Folders
Create folders to organize SBOMs:
1. Navigate to **Portal** → **Repository**
2. Click **+ New Folder**
3. Enter folder name
4. Set folder properties
5. Click **Create**
### Folder Properties
| Property | Description |
| --------------- | --------------------------- |
| **Name** | Folder display name |
| **Description** | Purpose of folder |
| **Parent** | Parent folder (for nesting) |
| **Access** | Who can access |
| **Retention** | Auto-archive policy |
## Managing SBOMs
### Uploading SBOMs
Upload new SBOMs to your repository:
1. Navigate to target folder
2. Click **Upload**
3. Drag files or click **Browse**
4. Enter SBOM metadata
5. Click **Upload**
### SBOM Metadata
| Field | Description | Required |
| --------------- | ------------------- | -------- |
| **Name** | Display name | Yes |
| **Version** | Version identifier | Yes |
| **Product** | Associated product | No |
| **Description** | SBOM description | No |
| **Tags** | Classification tags | No |
### Moving SBOMs
Move SBOMs between folders:
1. Select SBOM(s)
2. Click **Move**
3. Select destination folder
4. Confirm move
### Copying SBOMs
Create copies:
1. Select SBOM(s)
2. Click **Copy**
3. Select destination
4. Optionally rename
5. Confirm copy
### Deleting SBOMs
Remove SBOMs:
1. Select SBOM(s)
2. Click **Delete**
3. Confirm deletion
**Note:** Deleted SBOMs are moved to Trash and can be restored within 30 days.
## Tagging System
### Creating Tags
Set up tags for classification:
1. Go to **Settings** → **Tags**
2. Click **+ New Tag**
3. Enter tag name and color
4. Save
### Applying Tags
Add tags to SBOMs:
1. Select SBOM
2. Click **Tags**
3. Select applicable tags
4. Save
### Tag-Based Views
Filter repository by tags:
1. Click **Filter**
2. Select tag(s)
3. View filtered results
## Retention Policies
### Policy Types
| Policy | Description |
| ----------------- | ---------------------------- |
| **Keep All** | No automatic deletion |
| **Keep Latest N** | Keep N most recent versions |
| **Time-Based** | Delete after X days |
| **Archive After** | Move to archive after X days |
### Setting Retention
Configure retention at folder level:
1. Open folder settings
2. Go to **Retention** tab
3. Select policy type
4. Configure parameters
5. Save
### Retention Exceptions
Exclude specific SBOMs from retention:
1. Open SBOM
2. Click **Settings**
3. Enable **Exclude from retention**
## Storage Management
### View Storage Usage
Monitor storage consumption:
1. Go to **Settings** → **Storage**
2. View usage summary:
* Total storage used
* Usage by folder
* Largest SBOMs
* Growth trends
### Storage Quotas
| Plan | Storage Limit |
| -------------- | ------------- |
| **Free** | 1 GB |
| **Pro** | 50 GB |
| **Enterprise** | Unlimited |
### Reducing Storage
Free up storage:
* Delete unused SBOMs
* Archive old versions
* Enable retention policies
* Remove duplicate SBOMs
## Bulk Operations
### Bulk Upload
Upload multiple SBOMs:
1. Click **Bulk Upload**
2. Select files (ZIP archive supported)
3. Map to products/folders
4. Review and confirm
5. Monitor progress
### Bulk Download
Download multiple SBOMs:
1. Select SBOMs
2. Click **Download**
3. Choose format
4. Download archive
### Bulk Edit
Edit multiple SBOMs:
1. Select SBOMs
2. Click **Bulk Edit**
3. Modify common fields
4. Apply changes
## Access Control
### Folder Permissions
Set access at folder level:
| Permission | Capabilities |
| ---------- | ------------------- |
| **Owner** | Full control |
| **Editor** | Add, modify, delete |
| **Viewer** | View and download |
| **None** | No access |
### Inheritance
Child folders inherit parent permissions unless overridden.
### Sharing Folders
Share folders with team members:
1. Open folder settings
2. Go to **Sharing** tab
3. Add users/teams
4. Set permission level
5. Save
## Search and Filter
### Quick Search
Search within repository:
* Type in search box
* Search by name, tag, metadata
* Results update in real-time
### Advanced Filters
| Filter | Options |
| -------------- | ------------------ |
| **Folder** | Specific folder(s) |
| **Date** | Upload date range |
| **Tags** | Selected tags |
| **Format** | CycloneDX, SPDX |
| **Compliance** | Compliance status |
### Saved Searches
Save common searches:
1. Apply filters
2. Click **Save Search**
3. Name the search
4. Access from **Saved Searches**
## Audit Trail
### Repository Activity
View repository activity log:
1. Go to **Repository** → **Activity**
2. View recent actions:
* Uploads
* Downloads
* Modifications
* Deletions
### Export Audit Log
Export for compliance:
1. Click **Export**
2. Select date range
3. Choose format
4. Download log
## API Access
```bash
# List repository contents
curl -X GET https://api.safeguard.sh/v1/portal/repository \
-H "Authorization: Bearer $API_KEY"
# Create folder
curl -X POST https://api.safeguard.sh/v1/portal/repository/folders \
-H "Authorization: Bearer $API_KEY" \
-d '{"name": "Products", "parent_id": null}'
# Upload SBOM
curl -X POST https://api.safeguard.sh/v1/portal/repository/sboms \
-H "Authorization: Bearer $API_KEY" \
-F "file=@sbom.json" \
-F "name=My Product" \
-F "version=1.0.0"
# Delete SBOM
curl -X DELETE https://api.safeguard.sh/v1/portal/repository/sboms/{id} \
-H "Authorization: Bearer $API_KEY"
```
## Best Practices
### Organization
* Create logical folder structure
* Use consistent naming conventions
* Apply tags consistently
* Document folder purposes
### Maintenance
* Review storage regularly
* Apply appropriate retention
* Archive old versions
* Clean up duplicates
### Security
* Set appropriate permissions
* Review access regularly
* Audit sensitive operations
* Use least privilege
## Next Steps
* [SBOM Repository](/docs/portal/sbom-repository)
* [Settings](/docs/portal/settings)
* [User Roles](/docs/portal/user-roles)
# My Products (/docs/portal/my-products)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# My Products
The My Products section in Portal allows you to organize and manage your software products and their associated SBOMs for sharing with customers and partners.
## Overview
My Products helps you:
* Create a product catalog
* Associate SBOMs with products
* Manage product versions
* Track product lifecycle
* Enable SBOM sharing
## Product Catalog
### What is a Product?
A Product represents a shippable software item that you provide to customers:
* Commercial software applications
* Open source projects
* Internal tools shared externally
* APIs and services
* Hardware firmware
### Product vs Project
| Concept | Description | Use Case |
| ----------- | ---------------------------- | ---------------------- |
| **Project** | Internal scanning unit | Development & security |
| **Product** | External-facing catalog item | Customer sharing |
Projects generate SBOMs; Products organize them for distribution.
## Creating a Product
### Step 1: Navigate to My Products
1. Go to **Portal** → **My Products**
2. Click **+ New Product**
### Step 2: Enter Product Details
| Field | Description | Required |
| ---------------- | ------------------- | -------- |
| **Product Name** | Display name | Yes |
| **SKU** | Unique identifier | Yes |
| **Description** | Product description | No |
| **Category** | Product category | No |
| **Website** | Product website URL | No |
| **Logo** | Product logo image | No |
### Step 3: Configure Settings
| Setting | Description |
| ---------------------- | ---------------------------------- |
| **Visibility** | Public catalog or private |
| **Auto-publish SBOMs** | Automatically publish new versions |
| **Require Approval** | Approval workflow for publishing |
### Step 4: Save Product
Click **Create Product** to add to your catalog.
## Managing Products
### Product List
View all products in your catalog:
| Column | Description |
| ------------------ | ------------------- |
| **Name** | Product name |
| **SKU** | Product identifier |
| **Versions** | Number of versions |
| **Latest Version** | Most recent version |
| **Status** | Active/Deprecated |
### Product Actions
| Action | Description |
| --------------- | ---------------------- |
| **Edit** | Modify product details |
| **Add Version** | Add new version |
| **View SBOMs** | See associated SBOMs |
| **Share** | Configure sharing |
| **Deprecate** | Mark as deprecated |
| **Delete** | Remove product |
## Product Versions
### Adding a Version
1. Open product
2. Click **+ Add Version**
3. Enter version details:
| Field | Description |
| ------------------ | ------------------------------ |
| **Version Number** | Semantic version (e.g., 2.1.0) |
| **Release Date** | When version was released |
| **Release Notes** | Changes in this version |
| **Status** | Current, Deprecated, EOL |
4. Associate SBOM (see below)
5. Click **Save Version**
### Version Lifecycle
| Status | Meaning |
| --------------- | ------------------------------ |
| **Pre-release** | Not yet released |
| **Current** | Active supported version |
| **Deprecated** | Still supported but superseded |
| **End of Life** | No longer supported |
## Associating SBOMs
### Link Existing SBOM
Associate an SBOM from ESSCM:
1. Open product version
2. Click **Associate SBOM**
3. Select from available projects
4. Choose specific version
5. Click **Associate**
### Upload New SBOM
Upload an SBOM directly:
1. Open product version
2. Click **Upload SBOM**
3. Select SBOM file (CycloneDX or SPDX)
4. Click **Upload**
### SBOM Requirements
For published products, SBOMs should include:
* All NTIA minimum elements
* Accurate component data
* Current vulnerability status
* Valid format and structure
## Publishing Products
### Publishing Workflow
1. **Draft** - Product created but not visible
2. **Review** - Pending approval (if enabled)
3. **Published** - Visible to authorized parties
4. **Archived** - Removed from active catalog
### Publishing a Version
1. Ensure SBOM is associated
2. Complete all required fields
3. Click **Publish**
4. Confirm publication
### Unpublishing
To remove a published version:
1. Open version
2. Click **Unpublish**
3. Provide reason
4. Confirm
## Product Sharing
### Share with Customers
Configure who can access your products:
1. Open product
2. Go to **Sharing** tab
3. Add recipients by:
* Email address
* Organization
* Public link (if allowed)
### Access Levels
| Level | Capabilities |
| ------------- | ---------------------------- |
| **View** | See product and SBOM details |
| **Download** | Download SBOM files |
| **Subscribe** | Receive update notifications |
See [Sharing](/docs/portal/sharing) for detailed sharing options.
## Product Analytics
### View Analytics
Track product engagement:
| Metric | Description |
| --------------- | ----------------------- |
| **Views** | Number of product views |
| **Downloads** | SBOM download count |
| **Subscribers** | Active subscribers |
| **Shares** | Times shared |
### Analytics Dashboard
1. Open product
2. Go to **Analytics** tab
3. View metrics and trends
## Bulk Operations
### Import Products
Import multiple products:
1. Click **Import**
2. Download CSV template
3. Fill in product data
4. Upload CSV file
5. Review and confirm
### Export Products
Export product catalog:
1. Click **Export**
2. Select format (CSV, JSON)
3. Choose fields to include
4. Download file
## API Access
```bash
# List products
curl -X GET https://api.safeguard.sh/v1/portal/products \
-H "Authorization: Bearer $API_KEY"
# Create product
curl -X POST https://api.safeguard.sh/v1/portal/products \
-H "Authorization: Bearer $API_KEY" \
-d '{"name": "My Product", "sku": "PROD-001"}'
# Add version
curl -X POST https://api.safeguard.sh/v1/portal/products/{id}/versions \
-H "Authorization: Bearer $API_KEY" \
-d '{"version": "2.0.0", "sbom_id": "sbom-uuid"}'
```
## Best Practices
### Product Organization
* Use consistent SKU naming
* Maintain accurate descriptions
* Keep versions up to date
* Archive old products
### SBOM Quality
* Ensure SBOMs pass validation
* Include all dependencies
* Update with each release
* Verify accuracy
### Sharing
* Review sharing settings regularly
* Use appropriate access levels
* Track who has access
* Revoke access when needed
## Next Steps
* [My SBOMs](/docs/portal/sbom-repository)
* [Find & Review SBOMs](/docs/portal/find-review-sboms)
* [Sharing](/docs/portal/sharing)
# SBOM Repository (/docs/portal/sbom-repository)
The `/v1` REST endpoints on this page are not yet available — every path under
`https://api.safeguard.sh/v1/` returns 404 today. They describe the intended
shape only. See [API Reference](/docs/api-reference#rest-api) for what is
supported now.
# SBOM Repository
The SBOM Repository provides centralized storage, organization, and management for all your Software Bills of Materials.
## Organization Structure
### Products
Group SBOMs by software product:
1. Navigate to **Products**
2. Click **Create Product**
3. Enter product details (name, SKU, description)
4. Associate SBOMs with the product
### Versions
Track SBOM versions:
* Automatic versioning from source (git tags)
* Manual version assignment
* Version comparison and diff
* Release lifecycle tracking
### Tags
Categorize with custom tags:
* Environment (production, staging, development)
* Team ownership
* Compliance requirements
* Custom categories
## Importing SBOMs
### From Enterprise ESCM
SBOMs generated in Enterprise ESCM can sync automatically:
1. Go to **Settings** → **Integrations**
2. Enable **Enterprise ESCM Sync**
3. Select projects to sync
4. Configure sync frequency
### Manual Upload
Upload existing SBOMs:
1. Click **Import SBOM**
2. Select format (SPDX, CycloneDX, etc.)
3. Upload file or paste content
4. Assign to product and version
5. Click **Import**
### API Import
```bash
curl -X POST "https://api.safeguard.sh/v1/portal/sboms" \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d @sbom.json
```
## SBOM Details
Each SBOM includes:
| Field | Description |
| -------------- | ---------------------- |
| **Product** | Associated product |
| **Version** | Version identifier |
| **Format** | Original format |
| **Components** | Total component count |
| **Created** | Import/generation date |
| **Source** | Where it came from |
| **Compliance** | EO 14028 status |
## Search & Filter
Find SBOMs quickly:
* Full-text search across metadata
* Filter by product, version, date
* Filter by compliance status
* Filter by component contents
## Version Comparison
Compare two SBOM versions:
1. Select two versions of the same product
2. Click **Compare**
3. View:
* Added components
* Removed components
* Version changes
* New vulnerabilities
* Resolved vulnerabilities
# Portal Settings (/docs/portal/settings)
# Portal Settings
Configure Portal-specific settings including preferences, notifications, branding, and integration options.
## Accessing Settings
1. Navigate to **Portal**
2. Click **Settings** (gear icon)
3. Select the settings category
## General Settings
### Organization Profile
Configure your organization's Portal profile:
| Setting | Description |
| --------------------- | ------------------------------------------ |
| **Organization Name** | Display name in Portal |
| **Logo** | Organization logo (displayed to customers) |
| **Website** | Company website URL |
| **Support Email** | Customer support contact |
| **Description** | Brief company description |
### Default Settings
| Setting | Description |
| ------------------------- | ------------------------------- |
| **Default SBOM Format** | CycloneDX or SPDX |
| **Default Export Format** | JSON, XML, or PDF |
| **Auto-Enrich SBOMs** | Enable automatic enrichment |
| **Timezone** | Default timezone for timestamps |
## Sharing Settings
### Default Sharing Permissions
| Setting | Options |
| ------------------------ | -------------------------------- |
| **Default Access Level** | View Only, Download, Full Access |
| **Require Approval** | Yes/No for sharing requests |
| **Expiration Policy** | Never, 30/60/90 days, Custom |
| **Watermarking** | Enable/disable SBOM watermarks |
### Sharing Restrictions
Control who can share:
* By role (Admin, Manager, User)
* By product category
* By customer type
* Require manager approval
### Public Sharing
| Setting | Description |
| -------------------------- | ---------------------------- |
| **Allow Public Links** | Enable public SBOM access |
| **Public Link Expiration** | Default expiration time |
| **Require Registration** | Require account for download |
| **Track Downloads** | Log public downloads |
## Notification Settings
### Email Notifications
| Notification | Trigger |
| ----------------------- | -------------------------------- |
| **New Share Request** | Customer requests SBOM |
| **Share Accepted** | Customer accepts share |
| **SBOM Updated** | Linked SBOM is updated |
| **Vulnerability Alert** | New vulnerability in shared SBOM |
| **Expiration Warning** | Share nearing expiration |
### Notification Preferences
Configure per notification type:
* Email delivery (immediate, daily digest, weekly)
* In-app notification
* Webhook delivery
### Webhook Configuration
Send notifications to external systems:
1. Go to **Settings** → **Webhooks**
2. Click **+ Add Webhook**
3. Configure:
| Field | Description |
| ---------- | ----------------- |
| **URL** | Webhook endpoint |
| **Events** | Events to trigger |
| **Secret** | Signing secret |
| **Active** | Enable/disable |
## Branding Settings
### Customer Portal Branding
Customize the customer-facing portal:
| Element | Customization |
| ----------------- | ---------------- |
| **Logo** | Header logo |
| **Favicon** | Browser tab icon |
| **Primary Color** | Brand color |
| **Custom CSS** | Advanced styling |
### Email Branding
Customize notification emails:
| Element | Customization |
| ------------ | ------------------- |
| **Logo** | Email header logo |
| **Footer** | Custom footer text |
| **Reply-To** | Reply email address |
### Custom Domain
Use your own domain for Portal:
1. Go to **Settings** → **Custom Domain**
2. Enter your domain (e.g., sbom.yourcompany.com)
3. Configure DNS records
4. Verify domain ownership
5. Enable custom domain
## Integration Settings
### ESSCM Integration
Link Portal with Enterprise ESSCM:
| Setting | Description |
| ---------------------- | ---------------------------- |
| **Auto-Sync Projects** | Import SBOMs automatically |
| **Sync Frequency** | Real-time, hourly, daily |
| **Project Filter** | Which projects to sync |
| **Version Mapping** | How versions map to products |
### Third Party Risk Manager (TPRM)
Connect Portal with TPRM:
| Setting | Description |
| ------------------ | -------------------------------- |
| **Link Vendors** | Associate vendors with suppliers |
| **Share Requests** | Route requests through TPRM |
| **Risk Data** | Include risk scores in shares |
### External Integrations
| Integration | Purpose |
| ------------------- | --------------------- |
| **ServiceNow** | Ticket creation |
| **Slack** | Notifications |
| **Microsoft Teams** | Notifications |
| **Email (SMTP)** | Custom email delivery |
## Security Settings
### Access Control
| Setting | Description |
| ------------------- | --------------------------- |
| **Session Timeout** | Auto-logout duration |
| **IP Allowlist** | Restrict access by IP |
| **Download Limits** | Rate limiting for downloads |
### Audit Settings
| Setting | Description |
| -------------------- | ----------------------- |
| **Retention Period** | How long to keep logs |
| **Log Level** | Detail level of logging |
| **Export Enabled** | Allow audit log export |
### Data Protection
| Setting | Description |
| -------------------- | -------------------------- |
| **Encryption** | At-rest encryption options |
| **Data Residency** | Region restrictions |
| **Backup Frequency** | Backup schedule |
## Compliance Settings
### EO 14028 Defaults
| Setting | Description |
| ---------------------- | -------------------------- |
| **Auto-Validate** | Check SBOMs on upload |
| **Require Compliance** | Block non-compliant shares |
| **Compliance Report** | Include in shares |
### NTIA Minimum Elements
| Setting | Description |
| -------------------- | ---------------------- |
| **Enforce Minimums** | Require all elements |
| **Warn on Missing** | Alert for missing data |
| **Auto-Enrich** | Fill in missing data |
## API Settings
### API Access
| Setting | Description |
| --------------- | ------------------------ |
| **API Enabled** | Enable Portal API access |
| **Rate Limits** | Requests per minute/hour |
| **Allowed IPs** | IP restrictions for API |
### API Keys
Manage Portal-specific API keys:
1. Go to **Settings** → **API Keys**
2. View existing keys
3. Create new keys with scoped permissions
4. Rotate or revoke keys
## Import/Export Settings
### Default Formats
| Type | Options |
| ----------------- | ---------------------------- |
| **SBOM Import** | CycloneDX, SPDX, Syft, Trivy |
| **SBOM Export** | CycloneDX, SPDX, CSV, PDF |
| **Report Export** | PDF, HTML, Excel |
### Bulk Operations
| Setting | Description |
| ------------------- | ------------------------ |
| **Max Upload Size** | Maximum file size |
| **Batch Size** | Items per bulk operation |
| **Async Threshold** | When to process async |
## Saving Settings
* Click **Save** after making changes
* Some settings require confirmation
* Changes take effect immediately unless noted
## Reset to Defaults
1. Go to settings section
2. Click **Reset to Defaults**
3. Confirm reset
4. Previous settings are logged
## Next Steps
* [User Roles](/docs/portal/user-roles)
* [Sharing SBOMs](/docs/portal/sharing)
* [Compliance](/docs/portal/compliance)
# Sharing (/docs/portal/sharing)
# Sharing
Share SBOMs securely with customers, partners, auditors, and other stakeholders with granular access controls and complete tracking.
## Sharing Methods
### Direct Sharing
Share with specific users:
1. Select the SBOM to share
2. Click **Share**
3. Enter recipient email addresses
4. Set permission level
5. Add optional message
6. Click **Send**
Recipients receive an email invitation to access the SBOM.
### Shareable Links
Create links for broader distribution:
1. Select the SBOM
2. Click **Create Link**
3. Configure options:
* Expiration date
* Download limit
* Password protection
* Format restrictions
4. Click **Generate**
5. Copy and distribute the link
### Customer Portal
Set up a branded portal for customers:
1. Go to **Settings** → **Customer Portal**
2. Configure branding and domain
3. Assign SBOMs to publish
4. Invite customers to register
## Permission Levels
| Level | Capabilities |
| ------------ | ---------------------------- |
| **View** | View SBOM online only |
| **Download** | View and download |
| **Full** | View, download, and re-share |
## Access Controls
### Organization-Level
* Require authentication for all shares
* Restrict sharing to approved domains
* Set default expiration periods
* Enable/disable link sharing
### SBOM-Level
* Override organization defaults
* Set specific expiration
* Require NDA acceptance
* Enable download notifications
## Tracking & Analytics
Monitor all sharing activity:
* Who accessed which SBOMs
* Download history
* Link usage statistics
* Geographic access data
## Revoking Access
Immediately revoke access:
1. Navigate to the SBOM's sharing settings
2. Find the user or link
3. Click **Revoke**
4. Access is terminated immediately
## Bulk Sharing
Share multiple SBOMs at once:
1. Select SBOMs in the repository
2. Click **Share Selected**
3. Configure recipients and permissions
4. All selected SBOMs are shared together
# User Roles (/docs/portal/user-roles)
# Portal User Roles
Portal uses role-based access control to manage what users can do within the SBOM management platform.
## Role Overview
Portal has four primary roles:
| Role | Description |
| --------------- | ----------------------------------- |
| **Admin** | Full Portal administration |
| **Manager** | Manage products, SBOMs, and sharing |
| **Contributor** | Create and edit content |
| **Viewer** | Read-only access |
## Role Permissions
### Admin
Full access to all Portal features:
| Permission | Access |
| ---------------- | ------ |
| Manage Settings | ✅ |
| Manage Users | ✅ |
| Manage Products | ✅ |
| Manage SBOMs | ✅ |
| Share Externally | ✅ |
| View Analytics | ✅ |
| API Access | ✅ |
| Audit Logs | ✅ |
### Manager
Manage content and sharing:
| Permission | Access |
| ---------------- | --------- |
| Manage Settings | Limited |
| Manage Users | ❌ |
| Manage Products | ✅ |
| Manage SBOMs | ✅ |
| Share Externally | ✅ |
| View Analytics | ✅ |
| API Access | ✅ |
| Audit Logs | View Only |
### Contributor
Create and edit content:
| Permission | Access |
| ---------------- | --------------- |
| Manage Settings | ❌ |
| Manage Users | ❌ |
| Manage Products | Create/Edit Own |
| Manage SBOMs | Create/Edit Own |
| Share Externally | With Approval |
| View Analytics | Limited |
| API Access | Limited |
| Audit Logs | ❌ |
### Viewer
Read-only access:
| Permission | Access |
| ---------------- | --------- |
| Manage Settings | ❌ |
| Manage Users | ❌ |
| Manage Products | View Only |
| Manage SBOMs | View Only |
| Share Externally | ❌ |
| View Analytics | ❌ |
| API Access | Read Only |
| Audit Logs | ❌ |
## Detailed Permission Matrix
### Product Permissions
| Action | Admin | Manager | Contributor | Viewer |
| ---------------- | ----- | ------- | ----------- | ------ |
| Create Product | ✅ | ✅ | ✅ | ❌ |
| Edit Any Product | ✅ | ✅ | ❌ | ❌ |
| Edit Own Product | ✅ | ✅ | ✅ | ❌ |
| Delete Product | ✅ | ✅ | Own Only | ❌ |
| View Products | ✅ | ✅ | ✅ | ✅ |
| Manage Versions | ✅ | ✅ | Own Only | ❌ |
### SBOM Permissions
| Action | Admin | Manager | Contributor | Viewer |
| ----------- | ----- | ------- | ----------- | ------ |
| Upload SBOM | ✅ | ✅ | ✅ | ❌ |
| Edit SBOM | ✅ | ✅ | Own Only | ❌ |
| Delete SBOM | ✅ | ✅ | Own Only | ❌ |
| View SBOM | ✅ | ✅ | ✅ | ✅ |
| Export SBOM | ✅ | ✅ | ✅ | ✅ |
| Enrich SBOM | ✅ | ✅ | ✅ | ❌ |
### Sharing Permissions
| Action | Admin | Manager | Contributor | Viewer |
| ---------------- | ----- | ------- | ----------- | ------ |
| Share Externally | ✅ | ✅ | Approval | ❌ |
| Share Internally | ✅ | ✅ | ✅ | ❌ |
| Revoke Share | ✅ | ✅ | Own Only | ❌ |
| View Shares | ✅ | ✅ | Own Only | ❌ |
| Approve Requests | ✅ | ✅ | ❌ | ❌ |
### Administration
| Action | Admin | Manager | Contributor | Viewer |
| ---------------------- | ----- | -------- | ----------- | ------ |
| Manage Users | ✅ | ❌ | ❌ | ❌ |
| Manage Settings | ✅ | Limited | ❌ | ❌ |
| View Audit Logs | ✅ | ✅ | ❌ | ❌ |
| Manage API Keys | ✅ | Own Only | Own Only | ❌ |
| Configure Integrations | ✅ | ✅ | ❌ | ❌ |
## Assigning Roles
### Invite with Role
When inviting users:
1. Go to **Settings** → **Users**
2. Click **+ Invite User**
3. Enter email address
4. Select role
5. Click **Send Invite**
### Change Role
Modify existing user's role:
1. Go to **Settings** → **Users**
2. Find the user
3. Click on their role
4. Select new role
5. Confirm change
## Custom Roles
### Creating Custom Roles
For granular control, create custom roles:
1. Go to **Settings** → **Roles**
2. Click **+ New Role**
3. Name the role
4. Select permissions
5. Save role
### Custom Role Permissions
Select from available permissions:
**Products**
* `products.create`
* `products.edit`
* `products.delete`
* `products.view`
**SBOMs**
* `sboms.upload`
* `sboms.edit`
* `sboms.delete`
* `sboms.view`
* `sboms.export`
**Sharing**
* `sharing.external`
* `sharing.internal`
* `sharing.approve`
* `sharing.revoke`
**Administration**
* `admin.users`
* `admin.settings`
* `admin.audit`
* `admin.integrations`
## External User Roles
### Customer Roles
External customers have different roles:
| Role | Description |
| ------------------ | ---------------------------------- |
| **Customer Admin** | Manage their organization's access |
| **Customer User** | Access shared content |
### Customer Permissions
| Action | Customer Admin | Customer User |
| ------------------ | -------------- | ------------- |
| View Shared SBOMs | ✅ | ✅ |
| Download SBOMs | ✅ | Per Share |
| Request SBOMs | ✅ | ✅ |
| Manage Their Users | ✅ | ❌ |
## Role Best Practices
### Assignment Guidelines
| Scenario | Recommended Role |
| ------------------ | ----------------- |
| Security team lead | Admin |
| Product owners | Manager |
| Developers | Contributor |
| Auditors | Viewer |
| Compliance team | Manager or Viewer |
### Principle of Least Privilege
* Start with lowest needed role
* Elevate only when necessary
* Review roles periodically
* Revoke when no longer needed
### Role Reviews
Regular role audits:
1. Go to **Settings** → **Users**
2. Review user list
3. Check last activity dates
4. Verify roles are appropriate
5. Remove inactive users
## API Access by Role
### API Scopes
| Role | API Scopes |
| ----------- | ------------------ |
| Admin | All scopes |
| Manager | read, write, share |
| Contributor | read, write (own) |
| Viewer | read |
### Generating API Keys
1. Go to **Profile** → **API Keys**
2. Click **+ New Key**
3. Key inherits your role permissions
4. Additional scope restrictions optional
## Troubleshooting
### "Access Denied" Errors
* Verify user has correct role
* Check permission matrix
* Confirm resource ownership
* Review custom role settings
### Role Not Applying
* User may need to log out/in
* Clear browser cache
* Check for conflicting permissions
* Verify role assignment saved
## Next Steps
* [Portal Settings](/docs/portal/settings)
* [Organization Management](/docs/esscm/organization-management)
* [Sharing SBOMs](/docs/portal/sharing)
# SSO Authentication (/docs/sso-authentication)
# SSO Authentication
Safeguard supports five identity provider (IdP) types for tenant sign-in: **SAML 2.0**, **OpenID Connect (OIDC)**, and OAuth "social" login via **Google**, **Microsoft**, and **GitHub**. This page walks through configuring each, provider by provider.
## Which approach should I use?
| Approach | Best when | Supports |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **SAML 2.0** | You need IdP-side group/attribute-based control, or your IdP doesn't offer a simple OAuth app | Okta, Microsoft Entra ID, Google Workspace, OneLogin, Ping Identity, Duo Security, JumpCloud, Auth0, Keycloak, Authentik, AD FS, Shibboleth, SailPoint IdentityNow, CyberArk Identity, IBM Security Verify |
| **OAuth "social" login** | Fastest to set up; you don't need SAML-specific attribute mapping | Google, Microsoft, GitHub |
| **OpenID Connect (OIDC)** | You want OIDC specifically instead of SAML from a provider that supports both, or any other OIDC 1.0-compliant provider | Auth0, Keycloak, self-hosted or other OIDC IdPs |
## How sign-in works
Once a provider is configured, users can sign in two ways — both land them in Safeguard:
* **SP-initiated (recommended)** — the user starts at `https://app.safeguard.sh`, enters their email, and is sent to the IdP to authenticate. This is the primary, always-available path and works for every provider type (SAML, OIDC, social).
* **IdP-initiated** — the user launches Safeguard from the IdP itself: an app-launcher tile/dashboard, or a "Test SAML login" button. For SAML providers, Safeguard detects the unsolicited response arriving at its broker endpoint and transparently restarts it as an SP-initiated login, so — since the user is already authenticated at the IdP — it completes without a second prompt. (OIDC and social logins are inherently SP-initiated.)
Either way, on first login Safeguard applies your tenant's [provisioning policy](/docs/sso-authentication/provisioning-policy) to decide whether to create the account.
## Where to configure SSO
1. Sign in as a tenant **Admin** or **Owner**.
2. Go to **Settings → Authentication**.
3. Scroll to the **Single Sign-On** section.
From here you can:
* **Add Provider** — opens the *Add Identity Provider* dialog covered in the sections below.
* **Test** — verifies Safeguard can complete a round-trip with the provider.
* **Delete** — removes a provider (existing sessions created via that provider are not revoked automatically; users must sign in again on their next session).
The right-hand **Policy** panel controls what happens on first SSO login and whether password login stays available — see [Provisioning policy](/docs/sso-authentication/provisioning-policy).
## In this section
* [URLs & Endpoints](/docs/sso-authentication/urls-and-endpoints) — the callback, ACS, and metadata URLs your IdP needs.
* [SAML 2.0](/docs/sso-authentication/saml) — generic steps plus fifteen provider-specific guides.
* [OpenID Connect (OIDC)](/docs/sso-authentication/oidc) — connect any OIDC 1.0-compliant provider.
* [Social Login](/docs/sso-authentication/social) — Google, Microsoft, and GitHub OAuth buttons.
* [Provisioning Policy](/docs/sso-authentication/provisioning-policy) — what happens on first SSO login.
* [Testing & Troubleshooting](/docs/sso-authentication/troubleshooting) — verify a provider and debug common errors.
# OpenID Connect (OIDC) (/docs/sso-authentication/oidc)
# OpenID Connect (OIDC)
Use this for any OIDC 1.0-compliant provider that isn't covered by the dedicated Google/Microsoft/GitHub [social](/docs/sso-authentication/social) options (for example, a self-hosted Keycloak, Auth0, or PingFederate instance).
1. In your IdP, register a new confidential OIDC client/application.
2. Set the **Redirect URI** to the Callback URL (`https://api.safeguard.sh/auth/api/v1/sso/callback`).
3. Collect the **Authorization endpoint**, **Token endpoint**, and **UserInfo endpoint** URLs (most providers publish these on a `/.well-known/openid-configuration` discovery document), plus the **Client ID** and **Client Secret**.
4. In Safeguard, click **Add Provider → OpenID Connect** and fill in:
| Field | Value |
| --------------------- | ----------------------------------------------------------------------------------- |
| **Alias** | URL-safe id, e.g. `keycloak`, `auth0` |
| **Display Name** | Shown on the login screen |
| **Authorization URL** | From step 3 |
| **Token URL** | From step 3 |
| **User Info URL** | From step 3 |
| **Client ID** | From step 3 |
| **Client Secret** | From step 3 |
| **Default Scopes** | Defaults to `openid profile email` — leave as-is unless your provider requires more |
5. Click **Save**, then **Test**.
## Example values
Illustrative values for a self-hosted Keycloak realm named `acme`. The Client ID/Secret are obvious dummies — use the real ones from your IdP.
**In Safeguard — Add Provider → OpenID Connect:**
| Field | Example value |
| ----------------- | ---------------------------------------------------------------------- |
| Alias | `keycloak` |
| Display Name | `Sign in with Keycloak` |
| Authorization URL | `https://idp.example.com/realms/acme/protocol/openid-connect/auth` |
| Token URL | `https://idp.example.com/realms/acme/protocol/openid-connect/token` |
| User Info URL | `https://idp.example.com/realms/acme/protocol/openid-connect/userinfo` |
| Client ID | `safeguard-oidc-client` |
| Client Secret | `sk_live_xxxxxxxxxxxxxxxx` |
| Default Scopes | `openid profile email` |
**In your IdP — register this Redirect URI on the client:**
`https://api.safeguard.sh/auth/api/v1/sso/callback`
# Provisioning Policy (/docs/sso-authentication/provisioning-policy)
# Provisioning Policy
The **Policy** panel next to your provider list controls what happens when someone signs in via SSO for the first time:
| Mode | Behavior |
| ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- |
| **JIT — auto-link existing accounts** | A new user is created on first SSO login; if the email matches an existing password account, the two are automatically linked. |
| **JIT — reject conflicts** (default) | A new user is created on first SSO login, but sign-in is rejected if the email already has a password account, until an admin manually links them. |
| **Invite only** | No auto-provisioning — the user must already have been invited by an admin before they can sign in via SSO. |
**Allow password login** toggles whether users can still sign in with a password at all. Turn this off once SSO is fully rolled out to require SSO for every login.
# Testing & Troubleshooting (/docs/sso-authentication/troubleshooting)
# Testing & Troubleshooting
* Use the **Test** button next to a provider to verify Safeguard can reach it and complete a basic handshake, before rolling it out to your team.
* **The ACS/Callback/Metadata URLs shown after saving a provider point at `localhost`** — this is a server-side misconfiguration, not something fixable from the UI. Contact Safeguard support.
* **Redirected back with `?error=IDP_ERROR`** — the IdP itself rejected or errored on the login attempt; check the `message` query parameter for the IdP's error description.
* **Redirected back with `?error=STATE_INVALID`** — the login attempt took too long, was replayed, or the browser lost its session state; have the user retry from the beginning.
## Related
* [RBAC, Teams & Organizations](/docs/rbac-teams) — roles, MFA, API keys, and how SSO fits into the broader identity/access model.
* [Web Application](/docs/web-app) — general web app login flow.
# URLs & Endpoints (/docs/sso-authentication/urls-and-endpoints)
# URLs & Endpoints
The URLs your IdP needs depend on whether you're configuring an **OIDC/social** provider or a **SAML** provider. Safeguard generates the exact values and shows them in the Add-Provider dialog **after you click Save** — copy them directly from there rather than typing them by hand.
## OIDC and social providers
For **OIDC** and **social** (Google/Microsoft/GitHub) providers, register a single **Redirect URI / Callback URL** on the provider's side:
| URL | Purpose | Pattern |
| ------------------------------- | ------------------------------------------------------------- | --------------------------------------------------- |
| **Redirect URI / Callback URL** | Where the OAuth/OIDC provider sends the user back after login | `https://api.safeguard.sh/auth/api/v1/sso/callback` |
This is the same value you register as the "Redirect URI" / "Authorized redirect URI" on the provider's side.
## SAML providers
The SAML brokered flow now goes through Safeguard's internal Keycloak broker, so a SAML IdP needs **different** values from OIDC/social — and they are **per-provider** and **per-tenant**. The external IdP must be configured with an **ACS URL** and an **SP Entity ID** that Safeguard generates and displays in the Add-Provider dialog **after you click Save**:
| URL | Purpose | Pattern |
| ---------------- | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------- |
| **ACS URL** | Where the SAML IdP sends the assertion after login | `https://api.safeguard.sh/auth/idp/realms//broker//endpoint` |
| **SP Entity ID** | The service-provider entity ID / audience the IdP asserts to | `https://api.safeguard.sh/auth/idp/realms/` |
| **Metadata URL** | SP metadata document some IdPs can import instead of manual field entry | `https://api.safeguard.sh/auth/api/v1/sso/metadata/{tenantId}/{alias}` |
**Copy the exact ACS URL and SP Entity ID from the dialog** — do not hand-type them. They are specific to your tenant and to this provider's alias, so the `` and `` segments are different for every provider you add.
> If these URLs ever show `http://localhost:...` instead of `https://api.safeguard.sh/...`, do not paste them into your IdP — that means the auth service's public URL isn't configured correctly server-side. Contact Safeguard support rather than working around it.
# Third Party Risk Manager (/docs/tprm)
# Third Party Risk Manager (TPRM)
95% of breaches originate from third-party software. TPRM transforms vendor risk from blind spot to strategic advantage. Request, validate, and monitor supplier SBOMs with integrated remediation workflows.
## Key Features
### Vendor Management
* Centralized vendor directory
* Contact management
* Contract and SLA tracking
* Risk categorization
### SBOM Requests
* Automated SBOM requests
* Customizable request templates
* Follow-up workflows
* Response tracking
### Risk Assessment
* Automated SBOM analysis
* Vulnerability mapping
* Risk scoring
* Compliance verification
### Continuous Monitoring
* Ongoing vendor monitoring
* Alert on new vulnerabilities
* Periodic re-assessment
* Trend tracking
## What's Included
## Getting Started
1. Add vendors to your directory
2. Categorize by risk tier
3. Request SBOMs from high-risk vendors
4. Review and validate submissions
5. Enable continuous monitoring
## Risk Tiers
Categorize vendors by criticality:
| Tier | Description | SBOM Requirement |
| ------------ | ------------------------ | --------------------------- |
| **Critical** | Core business operations | Required, quarterly updates |
| **High** | Significant data access | Required, annual updates |
| **Medium** | Limited system access | Recommended |
| **Low** | Minimal risk | Optional |
## Integration
TPRM integrates with:
* Portal (store received SBOMs)
* Enterprise ESCM (analyze SBOMs)
* Procurement systems
* GRC platforms
# Monitoring (/docs/tprm/monitoring)
# Monitoring
Enable continuous monitoring of your vendors' security posture with automated alerts and periodic re-assessment.
## Continuous Monitoring
### What's Monitored
* New vulnerabilities affecting vendor SBOMs
* Vulnerability severity changes
* Exploit availability updates
* CISA KEV additions
* Component health changes
### Alert Configuration
Configure alerts in **Settings** → **Monitoring**:
| Alert Type | Trigger |
| ----------------- | --------------------------- |
| **Critical Vuln** | New critical CVE discovered |
| **Exploited** | CVE added to CISA KEV |
| **Risk Change** | Score drops below threshold |
| **SBOM Expiry** | SBOM older than threshold |
## Scheduled Re-assessment
### Automatic Re-scans
Configure periodic SBOM re-analysis:
* Daily (for critical vendors)
* Weekly
* Monthly
* Quarterly
### Re-assessment Triggers
Trigger re-assessment on:
* New vulnerability disclosures
* Major version updates
* Contract renewals
* Security incidents
## Vendor Dashboard
Monitor all vendors at a glance:
* Aggregate risk metrics
* Vendors requiring attention
* Recent score changes
* Upcoming SBOM expirations
## Trend Analysis
Track vendor risk over time:
* Risk score trends
* Vulnerability count trends
* Remediation velocity
* Compliance improvements
## Reporting
### Scheduled Reports
Automatic reports delivered:
* Weekly summary
* Monthly vendor review
* Quarterly risk assessment
* Annual vendor audit
### Ad-hoc Reports
Generate reports on demand:
1. Select date range and vendors
2. Choose report type
3. Export as PDF or Excel
## Integration Alerts
Send alerts to:
* Email
* Slack
* Microsoft Teams
* PagerDuty
* Webhook (custom)
# Risk Assessment (/docs/tprm/risk-assessment)
# Risk Assessment
Automatically assess vendor risk based on SBOM analysis, vulnerability data, and compliance status.
## Risk Score
Each vendor receives a risk score (0-100):
| Score | Risk Level | Description |
| ------ | ---------- | ------------------------- |
| 0-25 | Critical | Immediate action required |
| 26-50 | High | Significant concerns |
| 51-75 | Medium | Moderate risk |
| 76-100 | Low | Acceptable risk |
## Risk Factors
### Vulnerability Risk
Based on SBOM analysis:
* Critical vulnerability count
* High vulnerability count
* EPSS scores (exploit probability)
* Known exploited vulnerabilities
### Compliance Risk
Based on SBOM quality:
* EO 14028 compliance percentage
* Missing required fields
* Outdated SBOM (age)
* Format validity
### Component Risk
Based on dependency health:
* Abandoned packages
* License compliance
* Transitive dependency depth
* Known malicious packages
### Operational Risk
Based on vendor factors:
* Response time to requests
* Update frequency
* Security incident history
* Contract compliance
## Assessment Report
Generate detailed risk reports:
1. Select vendor(s)
2. Click **Generate Report**
3. Report includes:
* Executive summary
* Risk score breakdown
* Vulnerability details
* Compliance gaps
* Recommendations
## Comparative Analysis
Compare vendors side-by-side:
* Risk scores
* Vulnerability counts
* Compliance status
* Trend over time
## Risk Acceptance
Document accepted risks:
1. Review the risk finding
2. Click **Accept Risk**
3. Provide business justification
4. Set review date
5. Obtain required approvals
## Remediation Tracking
Track vendor remediation efforts:
* Requested fixes
* Vendor commitments
* Progress updates
* Verification status
# SBOM Requests (/docs/tprm/sbom-requests)
# SBOM Requests
Streamline the process of requesting, collecting, and validating SBOMs from your third-party software vendors.
## Creating Requests
### Single Request
1. Navigate to the vendor
2. Click **Request SBOM**
3. Select the product(s)
4. Choose request template
5. Customize message (optional)
6. Set deadline
7. Click **Send**
### Bulk Requests
Request SBOMs from multiple vendors:
1. Go to **Vendors**
2. Select vendors to contact
3. Click **Bulk Request**
4. Configure request settings
5. Review and send
## Request Templates
### Standard Template
Default request including:
* SBOM format requirements (SPDX, CycloneDX)
* Required fields (EO 14028 compliance)
* Submission instructions
* Deadline information
### Custom Templates
Create templates for specific needs:
1. Go to **Settings** → **Request Templates**
2. Click **Create Template**
3. Customize content
4. Save for reuse
## Request Tracking
Monitor request status:
| Status | Description |
| --------------- | ---------------------- |
| **Sent** | Request delivered |
| **Viewed** | Recipient opened email |
| **In Progress** | Vendor acknowledged |
| **Submitted** | SBOM received |
| **Validated** | SBOM verified |
| **Rejected** | Submission rejected |
## Automated Follow-ups
Configure automatic reminders:
* First reminder: 7 days before deadline
* Second reminder: At deadline
* Escalation: 7 days after deadline
## Submission Portal
Vendors can submit via:
* Email attachment
* Secure upload portal
* API submission
* Direct integration
## Validation
When an SBOM is received:
1. Format validation (valid SPDX/CycloneDX)
2. Completeness check (required fields)
3. Compliance verification (EO 14028)
4. Automatic vulnerability scan
5. Notification to requestor
## Rejection Workflow
If an SBOM doesn't meet requirements:
1. Review validation failures
2. Click **Request Revision**
3. Specify needed corrections
4. Vendor receives update request
# Vendor Management (/docs/tprm/vendor-management)
# Vendor Management
Maintain a centralized directory of all third-party software vendors with contact information, contracts, and risk categorization.
## Vendor Directory
### Adding Vendors
1. Navigate to **Vendors**
2. Click **Add Vendor**
3. Enter vendor information:
* Company name
* Primary contact
* Contact email
* Website
* Products used
4. Set risk tier
5. Click **Save**
### Vendor Information
Track comprehensive vendor details:
| Field | Description |
| ------------------- | --------------------------- |
| **Company Name** | Vendor organization name |
| **Products** | Software products you use |
| **Primary Contact** | Main point of contact |
| **Contract Status** | Active, pending, expired |
| **Risk Tier** | Critical, High, Medium, Low |
| **SBOM Status** | Received, requested, none |
| **Last Assessment** | Most recent risk review |
### Bulk Import
Import vendors from spreadsheet:
1. Download the template CSV
2. Fill in vendor information
3. Upload the completed file
4. Review and confirm import
## Risk Tiering
### Automatic Categorization
TPRM can suggest risk tiers based on:
* Data access level
* System criticality
* User count
* Compliance requirements
### Manual Override
Adjust risk tiers manually:
1. Select the vendor
2. Click **Edit Risk Tier**
3. Choose new tier
4. Document justification
5. Save changes
## Vendor Relationships
Track relationships between vendors:
* Parent companies
* Subsidiaries
* Resellers
* Implementation partners
## Contract Management
Link contracts to vendors:
* Contract documents
* Start and end dates
* SLA terms
* Security requirements
* SBOM obligations
## Vendor Portal
Invite vendors to self-service:
* Update their own information
* Submit SBOMs directly
* Respond to questionnaires
* View their risk status
# Trust Center access requests (/docs/trust-center/access-requests)
# Trust Center access requests
Restricted documents on your [Trust Center](/docs/trust-center), such as an audit report or a penetration test, are shared only with people you approve. Visitors request access on your page, accept your NDA and confirm their email address. Your team then approves or denies the request, or an auto-approval rule decides it. An approved viewer signs in with an emailed link and downloads only what they were given.
Access management is switched on per workspace. When it is on, **Compliance › Trust Center** has these sections: **Page**, **Access requests**, **Viewers**, **Activity**, **Documents**, **NDA**, **Settings** and, where switched on, **Security contacts**.
## Set it up
1. Publish your Trust Center ([Trust Center setup](/docs/trust-center)).
2. On **Documents**, add at least one document with **Visibility** set to **Restricted**.
3. On **NDA**, choose **Create new version**, write the agreement and **Publish** it. Requesters accept the current version before their request reaches you.
4. On **Settings**, turn on **Access portal**. It can be turned on only when the checklist under **Before you turn it on** is complete: **Trust Center published**, **NDA published**, **At least one restricted document**, and **Sign-in links configured on the server**. If that last item is not ticked, contact Safeguard support.
The **Portal address** under **Settings** is where approved viewers sign in; **Open the portal** shows it.
## What the visitor does
1. On your Trust Center, the visitor chooses **Request access** and fills in their first and last name, **Work email**, **Company**, their relationship to you (existing customer, prospective customer, partner, auditor or other) and, optionally, a reason.
2. Under **Access**, they ask for **Full access** (every restricted document) or **Limited access** (only the documents they choose).
3. They accept the NDA: they read it, tick the box and type their full name exactly as entered above. Where the customer setting is on, a visitor who says they are an existing customer can choose **Request access as a customer** and skip the NDA.
4. They get an email and choose **Confirm my email**. Only then does the request reach your team. Requests whose email address is never confirmed are deleted automatically after 7 days.
5. When the request is approved, they receive a sign-in link. The link works once; after signing in they see the documents they can download and until when. An approved viewer can ask for a new link at any time with **Email me a sign-in link**.
Disposable email addresses are refused when the request is sent. If **Refuse free email addresses** is on in **Settings**, so are addresses from free mail providers.
## Decide a request
Open **Access requests**. A request shows its requester, NDA acceptance, whether the email was verified, its flags and when it was sent. Flags help you decide quickly, for example **Free email**, **Always review**, **Allowlisted**, **Existing customer**, **Previously denied**, **Already a viewer**, **Access was revoked**, **Renewal** and **No NDA on file**.
**Approve** opens the approval:
* **Access**: **Full access** (every restricted document, including ones added later) or **Limited access** (only the documents you choose).
* **Access ends**: after a number of days, or **On a date** at least one day from now and at most two years away.
* **Internal note (optional)**: only your team sees it.
The requester gets an email with a sign-in link, and access ends on the date shown.
**Deny** takes an optional **Reason**, sent to the requester only if you choose **Email the requester**. To decide many at once, select them and use **Approve selected** or **Deny selected**. An approval in bulk gives each requester what they asked for, for your default access length.
Only a compliance reviewer can decide a request (see [who can approve](/docs/compliance-requests/approvals#who-can-approve)).
## Auto-approval
Under **Settings › Auto-approval**, rules can approve a request without a person. A rule runs only after the requester has verified their email and, when you require one, accepted the NDA. In order:
1. A domain listed under **Always review these domains** always waits for a person, whatever the rules say.
2. **Allowlisted domains** are approved.
3. **Existing customer domains** are approved.
4. **Every verified request** approves everyone who confirms their email and accepts the NDA.
5. **Any business email** approves any address that is not from a free mail provider.
6. Anything else waits for a person.
A domain matches its subdomains too. **Access given by a rule** sets whether an auto-approved viewer gets what they requested or full access, and **Default access length (days)** (1 to 730) sets how long it lasts.
Where switched on for your workspace, you can also list exact **Customer email addresses**, give matched customers full access (**Customers get full access**), and let customers covered by their agreement skip the NDA (**Customers covered by their agreement skip the NDA**). A visitor who claims to be a customer but does not match waits for a person.
## Manage viewers
**Viewers** lists everyone who can sign in to read your restricted documents, and everyone who could. Filter by **Active**, **Expiring in 14 days**, **Expired**, **Revoked** or **All**. For each viewer you can:
* **Change end date** or **Change access**;
* **Send sign-in link**;
* **Revoke**: the viewer is signed out at once and can no longer open restricted documents;
* **Restore** revoked access until a date you choose;
* open **Activity** to see what they viewed and downloaded.
**Remind viewers before access ends (days)** (0 to 60, where 0 turns it off) emails viewers before their access expires.
## Notifications
Under **Settings › Notifications**:
* **Assignees**: each is told about every request, and the first one owns its review task.
* **Also notify**: more addresses to tell about every request.
* **Email requesters when denied**: whether a denial is emailed by default.
## The audit trail
Every step is recorded.
* **The request** (open it from **Access requests**) shows the requester, what they asked for, when the email was verified, the decision, and its history. The NDA acceptance records the version, the name the requester typed, when they accepted, their IP address and browser, and the agreement's SHA-256, so you can prove what was accepted.
* **Activity** reports requests, approval rate, median time to decision, active viewers and downloads over the last 30 days, 90 days or 12 months, with the most-read documents and most active companies. Its **Access log** records every action, from **Request sent**, **NDA accepted** and **Email verified** to **Approved**, **Approved by a rule**, **Denied**, document downloads and settings changes. Export it with **Export CSV**.
* **NDA** lists every version (**Draft**, **Current** or **Retired**) with its text SHA-256 and a PDF copy, and who accepted each version. Publishing a new version applies to new requests; existing viewers keep the acceptance they gave.
## Related
* [Trust Center setup](/docs/trust-center)
* [Requests and approvals](/docs/compliance-requests)
# Trust Center setup (/docs/trust-center)
# Trust Center setup
A Trust Center is a public page where customers and prospects check your security and compliance before they buy: the frameworks you meet, the controls you monitor, your policies and subprocessors, your audit outcome, and the documents you share. It is published at `https://.trust.safeguard.sh`, where `` is the public slug you choose.
You manage it on **Compliance › Trust Center**. If you do not see that tab, the Trust Center is not switched on for your workspace; ask your Safeguard administrator.
## 1. Create the page
On **Compliance › Trust Center**, choose one of two editors:
* **Edit Trust Center** opens your real public page with **Click any text to edit it**: change text in place, then save.
* **Advanced settings** opens the same content as a form, with everything the page has: logos, the coverage grid, contact details and which policies are listed.
The page settings are:
| Setting | What it does |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| **Public slug** | The address of the page: `https://.trust.safeguard.sh`. Required. |
| **Organization name** | Shown at the top of the page. Required. |
| **Headline** and **Description** | A short line and two or three sentences under your name: what your company does and what the page reports. |
| **Masthead links** | Links shown beside your contact addresses, such as your privacy policy or status page. Each must start with `http://` or `https://`. |
| **Brand color (hex)** and **Logo URL** | Your colour and logo. |
| **Security contact email** and **Privacy contact email** | Shown in the page's contact section, for vulnerability reports and for data subject requests. |
## 2. Publish it
In **Advanced settings**, turn on **Publish Trust Center** and save. When it is off, your public page returns 404. Publishing is always an explicit action: nothing goes live on its own, and new content such as a highlight starts as a draft.
Use **View public page** to open the live page. Changes you save appear on it; a framework's live readiness, below, updates within five minutes.
## 3. Choose what the page shows
Each section appears on the public page only when it has something in it.
* **Frameworks.** Pick the frameworks to publish. Each shows one status: **Compliant**, **In progress**, **Not assessed** or **Signed** (see [framework statuses](#framework-statuses)).
* **Published controls.** Pick the control areas to show. Each is read live from your continuous monitoring, so a control that starts failing shows as failing without you republishing. Only areas from frameworks you publish are listed, and an area appears once a compliance scan has evaluated it.
* **Published policies** and **Sub-processors.** On your main Trust Center page these come from your policy and vendor registers whenever those have entries.
* **Coverage by offering.** A grid of what each of your products covers. Until you set it up, the section does not appear.
* **Data collected.** What personal data you hold, and what you do not. Saying no is a stronger answer than leaving a category out.
* **FAQ.** The questions reviewers ask before they email you, shown in your order.
* **Updates.** Dated posts, such as a new report or a framework achieved. The newest appears first.
* **Audit outcome.** The auditor's opinion from a completed audit (see [audit outcome](#audit-outcome)).
Where they are switched on for your workspace, the page can also carry:
* **Quick summary**: up to 12 short highlights at the top of the page, such as annual audits, penetration tests or a bug bounty, each with an optional icon, detail and https link. State only what is true today.
* **FAQ categories**, such as Access Management, Encryption or Vendor Management.
* **Incidents and security advisories**: an update can be an **Announcement**, an **Incident** or a **Security advisory**. An incident carries a status (**Investigating**, **Identified**, **Monitoring**, **Resolved** or **Not affected**) and a dated history shown under the post.
* **AI governance**: the AI in your product, in your own words (the models, who makes them, where they run and how you govern them), published on the page's AI Governance tab.
## Framework statuses
| Status | Where it comes from |
| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Compliant** | Live readiness with every control in scope passing, a framework backed by a current audit report or certificate, or, for frameworks that allow it, your own self-assessment with its attestation date. |
| **In progress** | Live readiness with controls still failing, or a declared status. |
| **Not assessed** | Nothing backs a status yet. |
| **Signed** | A pledge you signed, such as the Secure by Design Pledge. It is never shown as Compliant. |
A framework that needs an independent auditor or certification body cannot be declared compliant on a self-assessment: show its certification instead.
**Publish live readiness.** When your page shows a framework as **Not assessed**, you can publish its live readiness instead: the readiness score of your own controls (not an audit), shown as **Compliant** only when every control in scope passes. Choose **Publish live readiness** on that framework. The page updates within five minutes, and **Stop publishing live readiness** takes it back off.
**Monitoring line.** Once your continuous tests have completed a check, the page says **Continuously monitored, last checked** and when. Showing how many tests pass is opt-in; ask Safeguard support to turn it on.
## Audit outcome
When an auditor records an issued opinion in the audit workspace, it appears under **Audit outcome** on **Compliance › Trust Center**. Publishing it shows the opinion type, the framework, the period and the auditor firm on your page. The signed report is listed as available on request and is released only through an approved [access request](/docs/trust-center/access-requests).
Only a compliance reviewer or administrator can publish or take down an audit outcome. The page takes it down by itself when the auditor corrects the opinion or a certificate expires.
## Documents
With access management on, the **Documents** section of the Trust Center lists what your page offers. Choose **Add document** and set:
* a **Category**: **Compliance report**, **Penetration test**, **Questionnaire**, **Policy**, **Privacy**, **Financial**, **Security** or **Other**;
* its **Visibility**: anyone can download a **Public** document, and only an approved viewer a **Restricted** one;
* whether it appears **On the public page**.
Each file shows its size and SHA-256. Audit reports come from your audits; here they can only be shown on or hidden from the public page. A restricted document listed without a file shows to viewers as not yet available.
To share restricted documents, set up [access requests](/docs/trust-center/access-requests).
## Subscribers and updates
Visitors can **Subscribe to updates** on your page with their email address and are emailed when you publish a change, such as a new report, a policy update or a security incident. Where confirmed subscriptions are switched on, visitors choose their topics (**Updates and announcements**, **Incidents and security advisories**) and confirm by email before anything is sent.
Where security contacts are switched on, the **Security contacts** section lists the people your customers named to receive security notifications, such as a CISO or an incident response list. Your team can add contacts too. **Notify about an update** sends a published update to every security contact of the Trust Center by email; an email cannot be unsent.
## Related
* [Trust Center access requests](/docs/trust-center/access-requests)
* [Requests and approvals](/docs/compliance-requests)
* [Compliance](/docs/compliance)
# What's New — July 2026 (/docs/whats-new/2026-07)
# What's New — July 2026
A summary of the July 2026 release wave. All items are generally available to existing customers unless noted; MCP tiers, custom-domain Trust Center pages, and the browser extensions roll out per plan.
## Agentic Search (Griffin)
* **Live activity view.** Every search turn streams what the model is doing in real time — thinking, tool calls, web pages read, sandboxed code runs, and spawned sub-agents — with a status line that updates as work happens. See [Griffin AI](/docs/griffin-ai) and [Search Skills](/docs/search-skills).
* **Reliable web research.** Web search runs through a multi-provider cascade (Tavily → Serper → keyless fallbacks), so general questions return real, cited results. Set `TAVILY_API_KEY` or `SERPER_API_KEY` for production reliability.
* **Model tiers.** Choose a tier per turn — **Lino** (fast, basic queries), **Eagle**, and the flagship **Griffin** — each with the right tool budget. See [AI Models](/docs/ai-models).
* **Research reports as artifacts.** Deep-research answers open as a report in a side panel, with inline sources.
## Trust Center (Portal)
The public Trust Center is now entity-backed and owner-governed. See [Portal](/docs/portal).
* **Default-private publish.** A Trust Center page 404s publicly until an owner explicitly publishes it. The public resolver filters fields server-side by visibility tier — internal data can never leak.
* **Artifact sharing.** Downloadable SBOM, VEX, and AI-BOM (CycloneDX) artifacts generated from your scans.
* **NDA-gated documents.** Request → owner-approve → time-boxed, signed download, with every grant, view, and download written to an append-only access audit.
* **Questionnaire auto-answer.** Import SIG / CAIQ / spreadsheet questionnaires and get grounded draft answers from your approved trust content, each with a confidence level and cited sources for human review.
## Platforms & access
A new **Platforms** tab in Integrations lists every way to use Safeguard, across all four products:
* Web app, [CLI](/docs/cli), and IDE extensions (VS Code, JetBrains) — see [Browser Extension](/docs/browser-extension) and [Desktop App](/docs/desktop-app).
* **MCP server** available across all four products, with capability depth controlled per plan — see [MCP](/docs/mcp).
* Cloud marketplace deployments (AWS, Azure, GCP).
## Browser extensions
* **Safeguard side panel** — brings Griffin search alongside any browser tab (no host permissions, no data collection). Now published — [install it from the Chrome Web Store](https://chromewebstore.google.com/detail/safeguard/dpadlgjdcjgplnnfjbglokhncalkgoae), or see [Browser Extension](/docs/browser-extension).
* **Gold Open Source** — a lightweight launcher for [Safeguard Gold](https://gold.safeguard.sh), the public open-source CVE and package intelligence site.
## Fixes
* **Project/product comparison** via the bulk-query rail is fixed — the compare drawer and any dashboard comparison widget now populate correctly across all surfaces.
# CISA KEV Correlation (/docs/frameworks/internal/cisa-kev)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Components checked against CISA Known Exploited Vulnerabilities catalog.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | KEV |
| Region | Internal |
| Country or scope | Internal |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers KEV
* **Scan requirements:** 1, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for KEV.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for KEV and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these requirement against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------- | --------------------------------------------------------------------------------- | ---------- |
| `KEV-1` No Actively Exploited Vulnerabilities | No components matched entries in the CISA Known Exploited Vulnerabilities catalog | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | ------------------------------------- |
| `KEV-01` | KEV Catalog Correlation |
| `KEV-02` | Remediation Due-Date Tracking |
| `KEV-03` | Patch SLA Compliance |
| `KEV-04` | KEV Exception Process |
| `KEV-05` | KEV Feed Freshness |
| `KEV-06` | KEV Scope Coverage: All Ecosystems |
| `KEV-07` | Vulnerability Disclosure Notification |
| `KEV-08` | Post-Patch Verification |
## Policy templates
Written for KEV:
* CISA KEV Response SLA Policy
* KEV Exception and Risk Acceptance Policy
* KEV Feed Management and Data Freshness Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KEV.
# Component Health (/docs/frameworks/internal/component-health)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
SBOM component quality: PURL coverage, hash integrity, supplier attribution, license completeness.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Health |
| Region | Internal |
| Country or scope | Internal |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Health
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for Health.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for Health and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CH-NTIA-ID` Unique Component Identifiers | Components should carry a package URL so they can be uniquely referenced and correlated across tools and databases (NTIA Minimum Elements - unique identifiers; PURL spec) | Scan |
| `CH-NTIA-COMP` Name and Version Completeness | Every component entry should state both its name and its version, the two baseline NTIA data fields for describing a component (NTIA Minimum Elements - component name, version of the component) | Scan |
| `CH-NTIA-SUP` Supplier Attribution | Each component should name its supplier, the party that creates, defines and identifies the component (NTIA Minimum Elements - supplier name) | Scan |
| `CH-CDX-HASH` Integrity Hashes | Components should include cryptographic hashes of their artefacts so consumers can verify integrity, per the hashes field of the CycloneDX component model and SPDX package checksums (CycloneDX spec - component.hashes; SPDX - PackageChecksum) | Scan |
| `CH-SPDX-LIC` Licence Completeness | Components should declare licence information so downstream legal obligations can be evaluated, per SPDX licence expression fields and the CycloneDX licenses element (SPDX spec - PackageLicenseDeclared; CycloneDX - component.licenses) | Scan |
| `CH-NTIA-DEP` Dependency Relationships | The SBOM should characterise the relationships between components, not merely list them, so transitive exposure can be analysed (NTIA Minimum Elements - dependency relationship) | Scan |
| `CH-NTIA-AUTH` SBOM Author and Timestamp | The SBOM itself must record who created it and when, the NTIA author-of-SBOM-data and timestamp elements (NTIA Minimum Elements - author of SBOM data, timestamp) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | ------------------------------------ |
| `CH-01` | PURL Coverage |
| `CH-02` | Cryptographic Hash Integrity |
| `CH-03` | Supplier Attribution |
| `CH-04` | License Completeness |
| `CH-05` | Version Pinning |
| `CH-06` | Namespace Presence |
| `CH-07` | Dependency Relationship Completeness |
| `CH-08` | Component Author / Maintainer Field |
## Policy templates
Written for Health:
* SBOM Quality and Component Identity Policy
* Component Dependency Relationship Completeness Policy
* SBOM Generation Tooling Governance Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Health.
# Crypto Algorithm Audit (/docs/frameworks/internal/crypto-algo-audit)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Identifies deprecated/weak cryptographic algorithms (MD5, SHA-1, DES, RC4, Blowfish).
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Crypto Audit |
| Region | Internal |
| Country or scope | Internal |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Crypto Audit
* **Scan requirements:** 4, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for Crypto Audit.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for Crypto Audit and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 4 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | --------------------------------------------------------------- | ---------- |
| `CRYPTO-AUDIT-1` Cryptographic Library Identification | Identify all cryptographic libraries in the supply chain | Scan |
| `CRYPTO-AUDIT-2` Weak Algorithm Detection | Detect weak hash algorithms in component hashes | Scan |
| `CRYPTO-AUDIT-3` Strong Algorithm Verification | Verify use of strong cryptographic algorithms | Scan |
| `CRYPTO-AUDIT-4` Crypto Library Versioning | Cryptographic libraries require version info for CVE assessment | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | ---------------------------------------------- |
| `CRYPTO-01` | Deprecated Algorithm Detection: MD5 |
| `CRYPTO-02` | Deprecated Algorithm Detection: SHA-1 |
| `CRYPTO-03` | Deprecated Algorithm Detection: DES / 3DES |
| `CRYPTO-04` | Deprecated Algorithm Detection: RC4 / Blowfish |
| `CRYPTO-05` | Key Length Minima Enforcement |
| `CRYPTO-06` | Algorithm Transition Plan |
| `CRYPTO-07` | Post-Quantum Readiness Assessment |
| `CRYPTO-08` | Random Number Generator Quality |
## Policy templates
Written for Crypto Audit:
* Cryptographic Algorithm Lifecycle Policy
* Post-Quantum Cryptography Readiness Policy
* Cryptographic Implementation and Code Review Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Crypto Audit.
# Dependency Age (/docs/frameworks/internal/dependency-age)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Flags components older than 2 years (stale) or 4 years (very old).
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Age |
| Region | Internal |
| Country or scope | Internal |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Age
* **Scan requirements:** 1, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for Age.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for Age and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these requirement against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------- | ----------------------------------------------- | ---------- |
| `AGE-1` Dependency Freshness | All components should have recent release dates | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | ---------------------------------- |
| `AGE-01` | Stale Component Threshold: 2 Years |
| `AGE-02` | Critical Age Threshold: 4 Years |
| `AGE-03` | Abandoned Project Detection |
| `AGE-04` | End-of-Life (EOL) Tracking |
| `AGE-05` | Major Version Lag |
| `AGE-06` | Release Cadence Monitoring |
| `AGE-07` | Dependency Age Reporting |
## Policy templates
Written for Age:
* Dependency Lifecycle and Stale Component Remediation Policy
* Dependency Age Governance and Upgrade Planning Policy
* End-of-Life Software Tracking and Decommissioning Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Age.
# Duplicate Detection (/docs/frameworks/internal/duplicate-components)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Identifies components at multiple versions: unresolved dependency conflicts or stale transitive deps.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Duplicates |
| Region | Internal |
| Country or scope | Internal |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Duplicates
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 6 controls from Safeguard's control catalog for Duplicates.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for Duplicates and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `DUP-ID-PURL` Version-Qualified Identifiers | Duplicate detection requires each component instance to carry a PURL, whose coordinates make same-name/different-version occurrences mechanically distinguishable (Package URL specification; CycloneDX component identity) | Scan |
| `DUP-VER-PRES` Versions Present for Comparison | A component without a version cannot be checked for duplication against its siblings, so version fields must be populated (NTIA Minimum Elements - version of the component) | Scan |
| `DUP-VER-SPEC` Exact Versions Only | Ranged or floating versions (latest, \*, >=) mask duplicate resolution and defeat conflict analysis; every declared version must be a single resolved value (CycloneDX/SPDX version field semantics) | Scan |
| `DUP-DEP-GRAPH` Dependency Paths Documented | Distinguishing a legitimate multi-version situation from a stale transitive dependency requires the dependency relationships that pull each instance in (NTIA Minimum Elements - dependency relationship) | Scan |
| `DUP-COMPLETE` Name+Version Completeness | Duplicate analysis keys on the (name, version) pair, so components must carry both fields to participate in the check (NTIA Minimum Elements - component name and version) | Scan |
| `DUP-HASH-DIST` Hashes Distinguish Rebuilds | Integrity hashes distinguish genuinely different artefacts from re-listed identical ones, sharpening duplicate classification (CycloneDX component.hashes; SPDX PackageChecksum) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | -------------------------------------------------- |
| `DUP-01` | Multi-Version Duplicate Detection |
| `DUP-02` | Transitive Conflict Resolution Policy |
| `DUP-03` | Deduplication Policy Enforcement |
| `DUP-04` | Bundle / Vendor Copy Detection |
| `DUP-05` | Duplicate Vulnerability Deduplication in Reporting |
| `DUP-06` | Duplicate Count Trend Monitoring |
## Policy templates
Written for Duplicates:
* Duplicate Component Detection and Deduplication Policy
* Duplicate Vulnerability Reporting and Trend Monitoring Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Duplicates.
# Internal (/docs/frameworks/internal)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Safeguard's own software supply-chain policies, scored like any framework. Each framework's page lists what a scan checks, its controls, its policy templates and its automated tests. How coverage works: [Compliance frameworks](/docs/frameworks).
| Framework | Country or scope | Sector | Scan requirements | Catalog controls |
| ---------------------------------------------------------------------- | ---------------- | ------------ | ----------------- | ---------------- |
| [CISA KEV Correlation](/docs/frameworks/internal/cisa-kev) | Internal | Supply Chain | 1 | 8 |
| [Component Health](/docs/frameworks/internal/component-health) | Internal | Supply Chain | 7 | 8 |
| [Crypto Algorithm Audit](/docs/frameworks/internal/crypto-algo-audit) | Internal | General | 4 | 8 |
| [Dependency Age](/docs/frameworks/internal/dependency-age) | Internal | Supply Chain | 1 | 7 |
| [Duplicate Detection](/docs/frameworks/internal/duplicate-components) | Internal | Supply Chain | 6 | 6 |
| [License Obligations](/docs/frameworks/internal/license-obligations) | Internal | Open Source | 6 | 7 |
| [Provenance Chain](/docs/frameworks/internal/provenance-chain) | Internal | Supply Chain | 6 | 7 |
| [Supply Chain Risk Score](/docs/frameworks/internal/supply-chain-risk) | Internal | Supply Chain | 6 | 8 |
| [Transitive Depth](/docs/frameworks/internal/transitive-depth) | Internal | Supply Chain | 4 | 7 |
| [Typosquatting Detection](/docs/frameworks/internal/typosquatting) | Internal | Supply Chain | 6 | 7 |
| [VEX Readiness](/docs/frameworks/internal/vex-readiness) | Internal | Supply Chain | 7 | 7 |
# License Obligations (/docs/frameworks/internal/license-obligations)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
License obligation manifest: attribution, source disclosure, copyleft, patent grants.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Obligations |
| Region | Internal |
| Country or scope | Internal |
| Sector | Open Source |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Obligations
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for Obligations.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for Obligations and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LIC-OBL-COVERAGE` License Identification | The license of each software component must be identified before its obligations can be honored (ISO/IEC 5230:2020 §3, license compliance artifacts) | Scan |
| `LIC-OBL-INV` Complete OSS Inventory | A bill of materials of all open-source components is a prerequisite for any obligation analysis (ISO/IEC 5230:2020 §3, bill of materials requirement) | Scan |
| `LIC-OBL-ATTR` Attribution Data Completeness | Attribution notices must name the component and its version, so entries need both fields populated (attribution conditions in common OSS licenses, e.g. Apache-2.0 §4, per SPDX license texts) | Scan |
| `LIC-OBL-ORIGIN` Copyright Holder Attribution | Honoring attribution and copyleft duties requires knowing the originator/supplier of each component (attribution and notice-preservation conditions in OSS licenses, per SPDX license data) | Scan |
| `LIC-OBL-SRCVER` Exact Versions for Source Disclosure | Copyleft source-disclosure duties attach to the exact distributed version, so vague versions or ranges make compliance unverifiable (source provision conditions, e.g. GPL-2.0 §3, per SPDX license texts) | Scan |
| `LIC-OBL-FMT` Machine-Readable License Manifest | License obligations should be tracked in a standardized machine-readable format supporting SPDX license expressions (ISO/IEC 5962:2021 SPDX license expression syntax) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | ---------------------------------------- |
| `LIC-01` | Attribution Requirement Fulfilment |
| `LIC-02` | Source Disclosure Compliance |
| `LIC-03` | Copyleft Boundary Enforcement |
| `LIC-04` | Patent Grant Verification |
| `LIC-05` | License Compatibility Matrix |
| `LIC-06` | Commercial License Tracking |
| `LIC-07` | Unknown and NOASSERTION License Handling |
## Policy templates
Written for Obligations:
* License Obligation Compliance Policy
* Commercial License Tracking and Compliance Policy
* License Compatibility and Distribution Clearance Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Obligations.
# Provenance Chain (/docs/frameworks/internal/provenance-chain)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Supply chain provenance completeness: creator documentation, integrity hashes, dependency graph.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Provenance |
| Region | Internal |
| Country or scope | Internal |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Provenance
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for Provenance.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for Provenance and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `PROV-AUTHOR` SBOM Author Recorded | The name of the entity or tool that created the SBOM must be recorded, anchoring the start of the provenance chain (NTIA Minimum Elements: 'Author of SBOM Data'; SPDX creationInfo / CycloneDX metadata.tools) | Scan |
| `PROV-TIME` Document Identity and Timestamp | The SBOM must carry a unique document identifier and creation timestamp so a specific document instance can be referenced and superseded (NTIA Minimum Elements: 'Timestamp'; SPDX documentNamespace / CycloneDX serialNumber) | Scan |
| `PROV-SUPPLIER` Component Supplier Names | Each component must name its supplier: the entity that creates, defines, and identifies it, extending provenance beyond the document to its contents (NTIA Minimum Elements, 'Supplier Name') | Scan |
| `PROV-HASH` Verifiable Artifact Integrity | Components should carry cryptographic hashes so that the artifacts described can be tied back to the exact bits that were shipped (NTIA Minimum Elements: 'Other Unique Identifiers'; SPDX checksums / CycloneDX hashes) | Scan |
| `PROV-GRAPH` Dependency Relationships | The SBOM must document how components relate to each other so the chain from top-level product to transitive dependency is traceable (NTIA Minimum Elements: 'Dependency Relationship') | Scan |
| `PROV-ID` Resolvable Component Identity | Provenance claims are only verifiable when components carry standard identifiers (PURL or CPE) that resolve to their upstream sources (NTIA Minimum Elements: 'Other Unique Identifiers') | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | -------------------------------- |
| `PROV-01` | Creator Documentation |
| `PROV-02` | Integrity Hash Chain |
| `PROV-03` | Dependency Graph Completeness |
| `PROV-04` | Build Attestation (SLSA) |
| `PROV-05` | Source Repository Linkage |
| `PROV-06` | SBOM Signing and Non-Repudiation |
| `PROV-07` | Provenance Retention |
## Policy templates
Written for Provenance:
* Software Provenance and Build Attestation Policy
* Provenance Data Retention and Repository Linkage Policy
* Dependency Graph Integrity and SBOM Completeness Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Provenance.
# Supply Chain Risk Score (/docs/frameworks/internal/supply-chain-risk)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Composite score: PURL, hash, supplier, license, version coverage.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SC Risk |
| Region | Internal |
| Country or scope | Internal |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SC Risk
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for SC Risk.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for SC Risk and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SCR-PURL` PURL Coverage | Components should carry Package URLs so they can be unambiguously resolved across ecosystems and tooling (NTIA Minimum Elements: 'Other Unique Identifiers'; PURL specification) | Scan |
| `SCR-HASH` Hash Coverage | Components should carry cryptographic hashes enabling integrity verification of shipped artifacts (CISA SBOM guidance; SPDX checksums / CycloneDX hashes) | Scan |
| `SCR-SUPPLIER` Supplier Coverage | Each component should name its supplier, the baseline datum for assessing supplier concentration and trust (NTIA Minimum Elements: 'Supplier Name') | Scan |
| `SCR-LICENSE` License Coverage | Components should carry license information to expose legal supply chain risk alongside security risk (SPDX license fields; CycloneDX licenses) | Scan |
| `SCR-VERSION` Version Coverage | Each component should record its version, without which no vulnerability or update posture can be computed (NTIA Minimum Elements: 'Version of the Component') | Scan |
| `SCR-GRAPH` Dependency Graph Present | Dependency relationships should be documented so transitive exposure can be traced from any affected component (NTIA Minimum Elements: 'Dependency Relationship') | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | ------------------------------------------------- |
| `SCR-01` | Composite Risk Score Inputs |
| `SCR-02` | Supplier Tiering |
| `SCR-03` | Single-Source Risk Detection |
| `SCR-04` | Geographic Risk Flagging |
| `SCR-05` | Supplier Contact & SLA Capture |
| `SCR-06` | Open-Source Abandoned Project Detection |
| `SCR-07` | Software Bill of Materials Sharing with Customers |
| `SCR-08` | Registry Integrity Verification |
## Policy templates
Written for SC Risk:
* Third-Party Software Supplier Risk Management Policy
* Open-Source Component Intake and Registry Integrity Policy
* SBOM Customer Sharing and Transparency Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SC Risk.
# Transitive Depth (/docs/frameworks/internal/transitive-depth)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Flags components with transitive dependencies exceeding 8 levels: expanded attack surface.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Trans. Depth |
| Region | Internal |
| Country or scope | Internal |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Trans. Depth
* **Scan requirements:** 4, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for Trans. Depth.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for Trans. Depth and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 4 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | --------------------------------------------------------- | ---------- |
| `TRANS-1` Dependency Relationship Completeness | All components should have dependency relationships | Scan |
| `TRANS-2` Transitive Dependency Count | High transitive counts increase attack surface | Scan |
| `TRANS-3` Circular Dependency Detection | Circular dependencies indicate architectural issues | Scan |
| `TRANS-4` PURL Coverage for Resolution | Components need PURL for transitive dependency resolution | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | ------------------------------------------- |
| `TD-01` | Maximum Transitive Depth Threshold |
| `TD-02` | Surface-Area Metric Tracking |
| `TD-03` | Flattening Strategy Documentation |
| `TD-04` | Dependency Graph Health Score |
| `TD-05` | Critical-Path Transitive Vulnerability Risk |
| `TD-06` | Ghost Dependency Detection |
| `TD-07` | Lock-File Consistency |
## Policy templates
Written for Trans. Depth:
* Transitive Dependency Risk Management Policy
* Critical-Path Reachability and Ghost Dependency Policy
* Dependency Graph Health Reporting and Accountability Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Trans. Depth.
# Typosquatting Detection (/docs/frameworks/internal/typosquatting)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Detects known typosquatted package names: potential supply chain confusion attacks.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Typosquatting |
| Region | Internal |
| Country or scope | Internal |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Typosquatting
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for Typosquatting.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for Typosquatting and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TYPO-PURL` Exact Ecosystem Identity | Detecting look-alike package names requires each component to carry a Package URL fixing its ecosystem, namespace, and exact name (PURL specification; OpenSSF package name-confusion guidance) | Scan |
| `TYPO-COMPLETE` Name and Version Present | Name-similarity analysis against known-good registries requires every component record to contain both a name and a version (CISA open source software security guidance on dependency hygiene) | Scan |
| `TYPO-PIN` Pinned Versions | Dependency-confusion attacks exploit floating version ranges that let a higher-versioned malicious package win resolution; versions must be exact, not ranges or 'latest' (OpenSSF / industry dependency-confusion guidance, e.g. namespace substitution attacks) | Scan |
| `TYPO-HASH` Artifact Hash Comparison | Confirming a suspect package is the legitimate upstream artifact requires integrity hashes to compare against registry-published digests (OpenSSF supply chain integrity guidance) | Scan |
| `TYPO-SUP` Supplier Attribution | Typosquatted packages typically have suppliers that differ from the legitimate project's maintainer; supplier data per component enables this comparison (OpenSSF package provenance guidance) | Scan |
| `TYPO-GRAPH` Introduction Path Traceability | When a suspicious package is found, the dependency graph is needed to trace which direct dependency introduced it (CISA SBOM guidance: dependency relationships) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | -------------------------------------------- |
| `TS-01` | Package-Name Edit Distance Check |
| `TS-02` | Known Typosquat Catalog Correlation |
| `TS-03` | Install-Block Policy for Unreviewed Packages |
| `TS-04` | Scope and Namespace Squatting Detection |
| `TS-05` | Homoglyph and Unicode Attack Detection |
| `TS-06` | New Package Age Verification |
| `TS-07` | Allowlist Governance and Review Cadence |
## Policy templates
Written for Typosquatting:
* Typosquatting and Malicious Package Detection Policy
* Package Allowlist Governance and Install-Block Policy
* Dependency Confusion and Internal Registry Security Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Typosquatting.
# VEX Readiness (/docs/frameworks/internal/vex-readiness)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
SBOM readiness for Vulnerability Exploitability eXchange: PURL coverage, version, hash, namespace.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | VEX |
| Region | Internal |
| Country or scope | Internal |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers VEX
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for VEX.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for VEX and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `VEX-PURL` Machine-Resolvable Product Identifiers | VEX statements must identify affected products with identifiers that tooling can resolve, requiring PURLs on SBOM components (CISA Minimum Requirements for VEX: product identification) | Scan |
| `VEX-IDENT` Fallback Identifiability | Components lacking a PURL must at least carry another standard identifier (e.g. CPE) so vulnerability status can still be asserted against them (CISA Minimum Requirements for VEX: product identification) | Scan |
| `VEX-VER` Version-Level Status Granularity | Exploitability status differs by version, so VEX-ready SBOM components must each record an exact version (CISA Minimum Requirements for VEX: product version identification) | Scan |
| `VEX-DOCID` Linkable Document Identity | VEX documents reference the SBOM they qualify, so the SBOM must have a unique document identifier and timestamp to be linkable and supersedable (CISA Minimum Requirements for VEX: document metadata; CycloneDX/CSAF linking) | Scan |
| `VEX-FMT` Machine-Readable SBOM Base | VEX exchange is machine-to-machine, so the underlying SBOM must be in a machine-readable standard format (CISA Minimum Requirements for VEX: machine readability) | Scan |
| `VEX-HASH` Artifact Binding via Hashes | Binding a not-affected assertion to the exact shipped artifact is strongest when components carry hashes distinguishing rebuilds and patched variants (VEX use-case guidance; CycloneDX hashes) | Scan |
| `VEX-GRAPH` Transitive Status Propagation | Determining whether a vulnerable subcomponent affects the top-level product requires the SBOM's dependency relationships (VEX status justification, e.g. component\_not\_present / not in execute path) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | -------------------------------------- |
| `VEX-01` | PURL Coverage for VEX Correlation |
| `VEX-02` | Hash Presence for Impact Assessment |
| `VEX-03` | Version Specificity for VEX Matching |
| `VEX-04` | Namespace for Ecosystem Identification |
| `VEX-05` | VEX Document Ingestion Pipeline |
| `VEX-06` | Internal VEX Authoring Capability |
| `VEX-07` | VEX Statement Expiry and Re-Evaluation |
## Policy templates
Written for VEX:
* VEX Readiness and SBOM Quality Prerequisites Policy
* VEX Document Lifecycle and Authoring Policy
* VEX-Based Vulnerability Suppression Governance Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to VEX.
# CIS Controls v8 (/docs/frameworks/international/cis-controls)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Authorized software inventory, asset management, vulnerability management, secure coding.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CIS |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CIS
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 18 controls from Safeguard's control catalog for CIS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for CIS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `CIS-CTL-2.1` Software Asset Inventory | Establish and maintain a detailed inventory of all licensed software installed on enterprise assets (CIS Controls v8, Safeguard 2.1) | Scan |
| `CIS-CTL-2.1V` Inventory Records Version | The software inventory must document attributes including the version of each item so that authorised software can be distinguished from outdated software (CIS Controls v8, Safeguard 2.1 attributes) | Scan |
| `CIS-CTL-16.4` Third-Party Component Inventory | Establish and manage an inventory of third-party software components used in development, including supplier/source attribution for each component (CIS Controls v8, Safeguard 16.4) | Scan |
| `CIS-CTL-7.1` Vulnerability Management Correlation | A continuous vulnerability management process requires components to carry standard identifiers (PURL/CPE) so scan results and advisories can be matched to the inventory (CIS Controls v8, Control 7) | Scan |
| `CIS-CTL-2.2` Supported and Pinned Software | Ensure only currently supported software is authorised, which requires exact rather than vague version declarations to judge support status (CIS Controls v8, Safeguard 2.2) | Scan |
| `CIS-CTL-16.11` Trusted Component Integrity | Leverage vetted modules from trusted sources; verifying that a component is the vetted artefact requires published integrity hashes (CIS Controls v8, Safeguard 16.11) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | --------------------------------------------------------------- |
| `CIS-1.1` | Establish and Maintain an Enterprise Asset Inventory |
| `CIS-2.1` | Establish and Maintain a Software Asset Inventory |
| `CIS-3.1` | Establish and Maintain a Data Management Process |
| `CIS-4.1` | Establish and Maintain a Secure Configuration Process |
| `CIS-5.1` | Establish and Maintain an Inventory of Accounts |
| `CIS-6.1` | Establish an Access Granting Process |
| `CIS-7.1` | Establish and Maintain a Vulnerability Management Process |
| `CIS-8.1` | Establish and Maintain an Audit Log Management Process |
| `CIS-9.1` | Ensure Use of Only Fully Supported Browsers and Email Clients |
| `CIS-10.1` | Deploy and Maintain Anti-Malware Software |
| `CIS-11.1` | Establish and Maintain a Data Recovery Practice |
| `CIS-12.1` | Ensure Network Infrastructure is Up-to-Date |
| `CIS-13.1` | Centralize Security Event Alerting |
| `CIS-14.1` | Establish and Maintain a Security Awareness Program |
| `CIS-15.1` | Establish and Maintain a Service Provider Inventory |
| `CIS-16.1` | Establish and Maintain a Secure Application Development Process |
| `CIS-17.1` | Establish and Maintain a Documented Incident Response Process |
| `CIS-18.1` | Establish and Maintain a Penetration Testing Program |
## Policy templates
Written for CIS:
* Asset Management and Vulnerability Management Policy (CIS v8)
* Access Control and Audit Logging Policy (CIS v8)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CIS.
# Common Criteria (CC) (/docs/frameworks/international/common-criteria)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
ISO/IEC 15408, security evaluation assurance: configuration management, integrity testing.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CC/EAL |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CC/EAL
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 13 controls from Safeguard's control catalog for CC/EAL.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for CC/EAL and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CC-ALC-CMS` Configuration Management Scope | The configuration list must include the product itself and the parts that comprise it, so every software component of the target of evaluation must be enumerated (ISO/IEC 15408 / CC Part 3, ALC\_CMS) | Scan |
| `CC-ALC-CMC` Unique Product Reference | The target of evaluation and its configuration items must be labelled with unique references so the evaluated version is unambiguous (ISO/IEC 15408 / CC Part 3, ALC\_CMC) | Scan |
| `CC-ALC-CMCID` Configuration Item Identification Method | Configuration items must be identified by a defined method that guarantees uniqueness, satisfied by standard identifiers such as PURL or CPE per component (ISO/IEC 15408 / CC Part 3, ALC\_CMC identification requirements) | Scan |
| `CC-ALC-DEL` Delivery Integrity | Delivery procedures must maintain the integrity of the product between production and installation, evidenced by cryptographic hashes over delivered components (ISO/IEC 15408 / CC Part 3, ALC\_DEL) | Scan |
| `CC-ADV-DOC` Evaluation Evidence Identity | Evaluation evidence documents must be identifiable and versioned so evaluators can tie evidence to the evaluated configuration, met by SBOM document identity and timestamp (ISO/IEC 15408, evaluation evidence requirements) | Scan |
| `CC-AVA-VAN` Vulnerability Analysis Precision | Vulnerability analysis of the evaluated product requires exact, non-vague component versions so public vulnerability information can be applied to the precise configuration (ISO/IEC 15408 / CC Part 3, AVA\_VAN) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | -------------------------------------------------------- |
| `ALC_CMC.1` | Configuration Management Capability Labelling |
| `ALC_CMC.4` | Production Support, Acceptance Procedures and Automation |
| `ALC_CMS.4` | Problem Tracking Configuration Management Scope |
| `ALC_DEL.1` | Delivery Procedures |
| `ALC_DVS.2` | Sufficiency of Security Measures for Development |
| `ALC_LCD.1` | Developer Defined Life-Cycle Model |
| `ALC_TAT.1` | Well-Defined Development Tools |
| `ATE_COV.2` | Analysis of Coverage |
| `ATE_DPT.2` | Testing Security Enforcing Modules |
| `ATE_FUN.1` | Functional Testing |
| `ATE_IND.2` | Independent Testing: Sample |
| `ASE_TSS.1` | TOE Summary Specification |
| `ADV_ARC.1` | Security Architecture Description |
## Policy templates
Written for CC/EAL:
* TOE Development Lifecycle and Configuration Management Policy
* TOE Security Testing Policy
* TOE Delivery and Operational Guidance Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CC/EAL.
# CSA Cloud Controls Matrix (/docs/frameworks/international/csa-ccm)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Supply chain management, software integrity, component inventory, license management.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CSA CCM |
| Region | International |
| Country or scope | International |
| Sector | Cloud |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CSA CCM
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for CSA CCM.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for CSA CCM and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CSA-CCM-STA-INV` Supply Chain Inventory | Providers must develop and maintain an inventory of their supply chain relationships and the software components delivered through them (CCM v4, STA domain - supply chain inventory control) | Scan |
| `CSA-CCM-STA-SUP` Supply Chain Partner Attribution | Supply-chain risk management requires identifying the upstream provider of each software component so obligations can be flowed down and risk assessed per supplier (CCM v4, STA domain - supply chain risk management) | Scan |
| `CSA-CCM-AIS-INT` Application Component Integrity | Application and interface security requires assurance that deployed software has not been tampered with, evidenced by integrity hashes on components (CCM v4, AIS domain - application security / integrity verification) | Scan |
| `CSA-CCM-TVM-VER` Vulnerability Remediation Visibility | Threat and vulnerability management requires knowing the version of each deployed component so vulnerabilities can be matched and remediation tracked (CCM v4, TVM domain) | Scan |
| `CSA-CCM-GRC-LIC` Licence Compliance | Governance and compliance obligations extend to intellectual-property terms of third-party software, requiring licence information on components (CCM v4, GRC/STA domains - licence management) | Scan |
| `CSA-CCM-A&A-DOC` Auditable Assurance Documentation | Audit and assurance controls require that evidence artefacts be identifiable and dated, met by SBOMs carrying document identity and creation timestamps (CCM v4, A\&A domain) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ----------------------------------------------------------- |
| `CCM-AIS-01` | Apply Secure SDLC Across Cloud-Native Applications |
| `CCM-CEK-01` | Manage Cloud Encryption Keys with Hardware Security Modules |
| `CCM-DCS-01` | Control Physical Access to Cloud Data Centers |
| `CCM-HRS-01` | Conduct Security Background Checks for Cloud Personnel |
| `CCM-IPY-01` | Manage Cloud Service Interoperability and Portability |
| `CCM-STA-01` | Assess and Monitor Cloud Supply Chain Risk |
| `CCM-UEM-01` | Manage Endpoint Security for Cloud Access |
## Policy templates
Written for CSA CCM:
* Cloud Controls Matrix Compliance Policy (CSA CCM v4)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CSA CCM.
# CSA STAR (/docs/frameworks/international/csa-star)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Cloud threat/vulnerability management, supply chain management, asset inventory, encryption.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | International |
| Country or scope | International |
| Sector | Cloud |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CSA STAR
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for CSA STAR.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for CSA STAR and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `STAR-DCS-INV` Asset Cataloguing | STAR assessment against the CCM requires a maintained catalogue of assets, including the software components composing cloud services (CSA STAR / CCM v4, DCS domain - asset inventory) | Scan |
| `STAR-TVM-ID` Threat and Vulnerability Correlation | Threat and vulnerability management processes must be able to map advisories to deployed software, requiring standard identifiers (PURL/CPE) on components (CSA STAR / CCM v4, TVM domain) | Scan |
| `STAR-TVM-VER` Patch Level Visibility | Vulnerability remediation and patch management require the exact version of each component to be recorded (CSA STAR / CCM v4, TVM domain - vulnerability remediation) | Scan |
| `STAR-STA-SUP` Supply Chain Transparency | STA controls require transparency over the provider's supply chain, including attribution of software components to their upstream suppliers (CSA STAR / CCM v4, STA domain) | Scan |
| `STAR-CEK-INT` Cryptographic Integrity Evidence | Cryptography and key-management controls extend to using cryptographic means to protect and verify data and software integrity, evidenced by component hashes (CSA STAR / CCM v4, CEK domain) | Scan |
| `STAR-REG-DOC` Registry Evidence Provenance | STAR registry submissions are dated assurance artefacts; supporting SBOMs must record their creator and creation time to be usable as evidence (CSA STAR program - assessment evidence requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ------------------------------------------------------ |
| `CSA-IAM-01` | Establish Identity and Access Management Policy |
| `CSA-IAM-02` | Implement Centralized Identity Provider |
| `CSA-DSP-01` | Classify and Protect Data Stored in Cloud |
| `CSA-TVM-01` | Implement Cloud Vulnerability and Threat Management |
| `CSA-IVS-01` | Segregate Cloud Network Environments |
| `CSA-LOG-01` | Enable and Centralize Cloud Audit Logging |
| `CSA-CCC-01` | Manage Cloud Change Control and Configuration |
| `CSA-BCR-01` | Define Cloud Business Continuity and Disaster Recovery |
| `CSA-GRC-01` | Maintain Cloud Governance Risk and Compliance Program |
| `CSA-SEF-01` | Define Cloud Security Incident Response |
## Policy templates
Written for CSA STAR:
* Cloud Shared Responsibility Policy (CSA STAR)
* Cloud Security Incident Response Policy (CSA STAR)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CSA STAR.
# CycloneDX VEX (/docs/frameworks/international/cyclonedx-vex)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Vulnerability Exploitability eXchange: PURL, hash integrity, version specificity, supplier attribution.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CDX VEX |
| Region | International |
| Country or scope | International |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CDX VEX
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 6 controls from Safeguard's control catalog for CDX VEX.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for CDX VEX and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `VEX-CDX-PURL` Correlatable Component Identifiers | VEX statements reference affected components by identifier, so components must carry PURLs for statements to be matched deterministically (CISA Minimum Requirements for VEX - product identifiers; CycloneDX analysis referencing) | Scan |
| `VEX-CDX-VER` Version-Scoped Statements | Exploitability status is asserted per product version, so nearly every component must declare its version for VEX status to apply (CISA Minimum Requirements for VEX - product version; CycloneDX component.version) | Scan |
| `VEX-CDX-SPEC` Unambiguous Version Values | Vague versions (ranges, latest, wildcards) make a VEX statement's scope undecidable, so component versions must be exact (CycloneDX spec - component version semantics) | Scan |
| `VEX-CDX-HASH` Artefact-Level Assurance | Hashes bind a VEX assertion to the exact artefact analysed, preventing status being applied to a tampered or different build (CycloneDX spec - component.hashes) | Scan |
| `VEX-CDX-FMT` Machine-Readable BOM | VEX is designed to be processed automatically alongside the SBOM, which must therefore be in a standard machine-readable format such as CycloneDX or SPDX (CISA Minimum Requirements for VEX - machine readability) | Scan |
| `VEX-CDX-DOC` Statement Metadata | A VEX document must identify itself and carry timestamps so consumers can order and supersede statements; the paired SBOM needs the same document identity and creation time (CISA Minimum Requirements for VEX - VEX metadata) | Scan |
| `VEX-CDX-AUTH` Statement Author | VEX requires an identified author for each statement, so the document creator (tool/organisation) must be recorded (CISA Minimum Requirements for VEX - VEX author) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | -------------------------------------------------------- |
| `VEX-1` | Publish VEX Statements for All Disclosed Vulnerabilities |
| `VEX-2` | Justify Not-Affected VEX Status with Evidence |
| `VEX-3` | Track Affected Vulnerabilities Through Remediation |
| `VEX-4` | Automate VEX Generation in CI/CD |
| `VEX-5` | Version and Sign VEX Documents |
| `VEX-6` | Distribute VEX to Software Consumers |
## Policy templates
Written for CDX VEX:
* Vulnerability Exploitability Exchange (VEX) Management Policy
* Customer Security Advisory and VEX Notification Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CDX VEX.
# DO-326A (/docs/frameworks/international/do-326a)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Aviation Cybersecurity: airworthiness, avionics supplier verification, software integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | International |
| Country or scope | International |
| Sector | Aerospace |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers DO-326A
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for DO-326A.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for DO-326A and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `DO326A-SCOPE` Security Scope Asset Identification | The airworthiness security process begins by identifying the assets within the security scope, requiring a complete enumeration of the software components in the certified system (DO-326A, security scope definition / asset identification) | Scan |
| `DO326A-CONFIG` Certified Configuration Traceability | Security assurance applies to a specific certified configuration, so every software component must record its exact version (DO-326A, security development and configuration identification) | Scan |
| `DO326A-SPEC` No Ambiguous Configurations | Airworthiness security assessment cannot be performed against floating or ranged versions; declared versions must be exact (DO-326A, configuration control expectations) | Scan |
| `DO326A-INT` Software Integrity Protection | Protection of aircraft systems against intentional unauthorised electronic interaction includes verifying that loaded software is authentic and unmodified, evidenced by integrity hashes (DO-326A, security measures against tampering; cf. field-loadable software integrity practice) | Scan |
| `DO326A-SUPP` Supplier Security Verification | Security risk assessment must cover software obtained from suppliers, requiring attribution of each component to its supplier for flow-down of security obligations (DO-326A, supply chain considerations in the security process) | Scan |
| `DO326A-EVID` Certification Evidence Identity | Airworthiness security evidence submitted for certification must be identifiable and dated so authorities can tie it to the approved design (DO-326A, security assurance documentation) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ---------------------------------------------------------------------- |
| `DO326A-4.1` | Conduct Airworthiness Security Risk Assessment |
| `DO326A-4.2` | Define Security Architecture for Avionics Systems |
| `DO326A-4.3` | Implement Security Controls Meeting IDAL Requirements |
| `DO326A-5.1` | Perform Security Verification Against Architecture |
| `DO326A-5.2` | Produce and Maintain the Airworthiness Security Plan |
| `DO326A-6.1` | Manage Ongoing Airworthiness Security Threats Post-Certification |
| `DO326A-6.2` | Coordinate Security Vulnerability Disclosure with Aviation Authorities |
| `DO326A-3.1` | Apply Security Process Assurance Commensurate with DAL |
## Policy templates
Written for DO-326A:
* Airworthiness Cybersecurity Plan (DO-326A)
* Avionics Cybersecurity Vulnerability Disclosure Policy (DO-326A)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DO-326A.
# GxP (GMP/GLP/GCP) (/docs/frameworks/international/gxp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Good Practice guidelines for regulated life-sciences - traceability, validation, change control, data integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | GxP |
| Region | International |
| Country or scope | International |
| Sector | Healthcare |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers GxP
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for GxP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for GxP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GXP-A11-4` Computerised System Validation and Inventory | Computerised systems used in GMP activities must be validated across their lifecycle, and an up-to-date listing of relevant systems and their GMP functionality must be available; an enumerated software component inventory is the direct fulfilment of that listing duty (EU GMP Annex 11, clause 4) | Scan |
| `GXP-A11-3` Supplier and Service Provider Qualification | When third parties supply, install, configure or maintain computerised systems, formal agreements and supplier assessment are required; each third-party software component should therefore be attributable to a named supplier (EU GMP Annex 11, clause 3) | Scan |
| `GXP-A11-9` Audit Trail Anchoring | Systems should record GMP-relevant changes and deletions in secure, time-stamped audit trails; the system's own documentation must carry document identity and creation timestamps to anchor that traceability (EU GMP Annex 11, clause 9) | Scan |
| `GXP-A11-10` Change and Configuration Management | Changes to computerised systems must follow a defined change- and configuration-management procedure; indeterminate component versions (latest, wildcards, ranges) defeat controlled configuration management (EU GMP Annex 11, clause 10) | Scan |
| `GXP-A11-12` Security of Computerised Systems | Physical and logical controls must restrict system access to authorised persons and protect data from damage; cryptographic integrity evidence for deployed software components demonstrates protection against unauthorised alteration (EU GMP Annex 11, clause 12) | Scan |
| `GXP-ALCOA` ALCOA+ Attributability | GxP data integrity requires records to be attributable, legible, contemporaneous, original and accurate; for system records this means the creating tool or organisation must itself be recorded (FDA Data Integrity and Compliance with Drug CGMP guidance, ALCOA principles) | Scan |
| `GXP-CFR-211-68` Automated Equipment Software Control | Automatic and electronic equipment used in drug manufacture must be routinely calibrated and checked per a written program, with input/output verification and controlled backup; that control regime presumes the exact versions of the operating software are recorded (21 CFR § 211.68) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | ------------------------------------- |
| `GXP-DI-01` | ALCOA+ Data Integrity Principles |
| `GXP-DI-02` | Data Integrity Risk Assessment |
| `GXP-VAL-01` | User Requirements Specification (URS) |
| `GXP-VAL-02` | Installation Qualification (IQ) |
| `GXP-VAL-03` | Operational Qualification (OQ) |
| `GXP-VAL-04` | Performance Qualification (PQ) |
| `GXP-CC-01` | Change Control System |
| `GXP-CAPA-01` | Deviation & CAPA Management |
| `GXP-TR-01` | GxP Training Requirements |
| `GXP-SOP-01` | Standard Operating Procedures |
| `GXP-AUD-01` | GxP Audit Trail Requirements |
| `GXP-CS-01` | Computer System Validation (CSV) |
## Policy templates
Written for GxP:
* Validation Master Plan (VMP)
* Data Integrity Policy: GxP (ALCOA+)
* Change Control & CAPA Procedure: GxP
* GxP Training Requirements Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GxP.
# IEC 62443-4-2 (/docs/frameworks/international/iec-62443-4-2)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Component Security Requirements: software integrity, non-repudiation, component provenance.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | 62443-4-2 |
| Region | International |
| Country or scope | International |
| Sector | Energy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers 62443-4-2
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 15 controls from Safeguard's control catalog for 62443-4-2.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for 62443-4-2 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IEC62443-4-2-CR7.8` Component Inventory Reporting | Components must support being reported as part of the control system component inventory (IEC 62443-4-2 CR 7.8) | Scan |
| `IEC62443-4-2-CR3.4` Software and Information Integrity | The component must support verification of the integrity of its software and information, requiring integrity hashes for constituent software (IEC 62443-4-2 CR 3.4) | Scan |
| `IEC62443-4-2-CR3.4-AUTH` Software Authenticity and Provenance | Integrity verification should extend to authenticity of the software source, requiring a named supplier for each component (IEC 62443-4-2 CR 3.4 enhancement on authenticity) | Scan |
| `IEC62443-4-2-CR2.12` Non-Repudiation of Origin | Non-repudiation requirements imply that the origin and creator of the component's software bill of materials must be recorded and attributable (IEC 62443-4-2 CR 2.12) | Scan |
| `IEC62443-4-2-VER` Component Version Disclosure | Inventory reporting is only useful for defect and patch management when each constituent component carries its version (IEC 62443-4-2 CR 7.8 inventory content) | Scan |
| `IEC62443-4-2-UID` Unambiguous Component Identification | Component security requirements presuppose that each software constituent can be unambiguously identified, e.g. via a package URL (IEC 62443-4-2 component identification requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ------------------------------------------------------ |
| `CR 1.1` | Component Human User Identification and Authentication |
| `CR 1.5` | Authenticator Management |
| `CR 1.8` | Public Key Infrastructure Certificates |
| `CR 1.14` | Strength of Authentication |
| `CR 2.1` | Authorization Enforcement at Component Level |
| `CR 2.8` | Auditable Events at Component Level |
| `CR 2.12` | Non-Repudiation at Component Level |
| `CR 3.1` | Communication Integrity at Component Level |
| `CR 3.4` | Software and Information Integrity |
| `CR 3.8` | Session Integrity |
| `CR 3.14` | Integrity of Boot Process |
| `CR 4.1` | Information Confidentiality at Component Level |
| `CR 7.2` | Resource Availability |
| `CR 7.6` | Network and Security Configuration at Component Level |
| `CR 7.8` | Control System Component Inventory Reporting |
## Policy templates
Written for 62443-4-2:
* IACS Component Security Requirements Policy
* IACS Component Secure Configuration and Hardening Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to 62443-4-2.
# IEC 62304 (/docs/frameworks/international/iec62304)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Medical Device Software Lifecycle: SOUP tracking, configuration management, integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | International |
| Country or scope | International |
| Sector | Healthcare |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers IEC 62304
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for IEC 62304.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for IEC 62304 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IEC62304-8.1.1` Configuration Item Identification | The manufacturer must establish a scheme identifying all configuration items that make up the software system, i.e. a complete component inventory (IEC 62304 §8.1.1) | Scan |
| `IEC62304-8.1.2-ID` SOUP Identification | Each SOUP item must be documented with its title and a unique version or other designator, so every third-party component needs both a name and version (IEC 62304 §8.1.2) | Scan |
| `IEC62304-8.1.2-MFR` SOUP Manufacturer Attribution | The manufacturer of each SOUP item must be recorded as part of its configuration identification (IEC 62304 §8.1.2) | Scan |
| `IEC62304-7.1.3` Published SOUP Anomaly Evaluation | Published anomaly lists for SOUP items must be evaluated, which requires components to be identifiable against public vulnerability and anomaly sources (IEC 62304 §7.1.3) | Scan |
| `IEC62304-8.1.3` System Configuration Documentation | The set of configuration items and their versions comprising the software system must be documented (IEC 62304 §8.1.3) | Scan |
| `IEC62304-6.1` Maintenance Monitoring of SOUP | The maintenance process must monitor SOUP for upgrades and fixes, which is only actionable when component versions are specific rather than vague ranges (IEC 62304 §6.1) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ------------------------------------------------------------ |
| `IEC62304-5.1` | Define Medical Device Software Development Planning |
| `IEC62304-5.2` | Document Software Requirements for Safety Classification |
| `IEC62304-5.3` | Produce Software Architecture for Class B/C Systems |
| `IEC62304-5.5` | Implement and Document Unit Testing for Safety Software |
| `IEC62304-5.8` | Perform and Document Software Integration and System Testing |
| `IEC62304-8.1.2` | Manage SOUP (Software of Unknown Provenance) |
| `IEC62304-9.1` | Establish a Software Problem Resolution Process |
| `IEC62304-7.1` | Conduct Software Risk Management per ISO 14971 |
| `IEC62304-5.6` | Perform Integration Testing Across Software Items |
## Policy templates
Written for IEC 62304:
* Medical Device Software Lifecycle Policy (IEC 62304)
* SOUP (Software of Unknown Provenance) Management Policy (IEC 62304)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to IEC 62304.
# IEC 62443 (/docs/frameworks/international/iec62443)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Industrial Automation & Control Systems security: component inventory, supplier verification, integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | International |
| Country or scope | International |
| Sector | Energy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers IEC 62443
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 19 controls from Safeguard's control catalog for IEC 62443.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for IEC 62443 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `IEC62443-SR7.8` Control System Component Inventory | The control system must support reporting a current inventory of all its components (IEC 62443-3-3 SR 7.8) | Scan |
| `IEC62443-SR3.4` Software and Information Integrity | The system must protect and allow verification of the integrity of software, which requires integrity hashes for deployed components (IEC 62443-3-3 SR 3.4) | Scan |
| `IEC62443-4-1-SM9` Security of Externally Provided Components | Security requirements must be applied to externally provided components, which presupposes knowing the supplier of each third-party component (IEC 62443-4-1 practice SM-9) | Scan |
| `IEC62443-4-1-SM10` Third-Party Component Identification | Custom and third-party components used in the product must be identified and assessed, requiring unambiguous component identifiers (IEC 62443-4-1 practice SM-10) | Scan |
| `IEC62443-4-1-DM` Security Defect Management | Security-related issues in the product and its components must be received, tracked and remediated, which requires knowing the exact version of each component (IEC 62443-4-1 practice 6, Defect Management) | Scan |
| `IEC62443-4-1-DOC` Development Documentation | Secure development requires documented, traceable artifacts describing the product composition, satisfied by an SBOM with document identity and creation metadata (IEC 62443-4-1 documentation requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ------------------------------------------------------------- |
| `SR 1.1` | Human User Identification and Authentication |
| `SR 1.2` | Software Process and Device Identification and Authentication |
| `SR 1.7` | Strength of Password-Based Authentication |
| `SR 1.13` | Access via Untrusted Networks |
| `SR 2.1` | Authorisation Enforcement |
| `SR 2.4` | Mobile Code |
| `SR 2.8` | Auditable Events |
| `SR 2.12` | Non-Repudiation |
| `SR 3.1` | Communication Integrity |
| `SR 3.3` | Security Functionality Verification |
| `SR 3.9` | Protection of Audit Information |
| `SR 4.1` | Information Confidentiality |
| `SR 5.1` | Network Segmentation |
| `SR 5.4` | Application Partitioning |
| `SR 6.1` | Audit Log Accessibility |
| `SR 6.2` | Continuous Monitoring |
| `SR 7.1` | Denial of Service Protection |
| `SR 7.6` | Network and Security Configuration Settings |
| `SR 7.8` | Control System Component Inventory |
## Policy templates
Written for IEC 62443:
* IACS Zone and Conduit Security Policy
* IACS Patch Management and Vulnerability Policy
* IACS Access Control and Authentication Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to IEC 62443.
# in-toto (/docs/frameworks/international/in-toto)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Provenance Framework: supply chain layout, artifact identity (PURL/CPE), artifact hashes.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | International |
| Country or scope | International |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers in-toto
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 6 controls from Safeguard's control catalog for in-toto.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for in-toto and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `INTOTO-LAYOUT` Supply Chain Layout | The supply chain must be described as an explicit layout of steps and the artifacts flowing between them, i.e. documented dependency relationships (in-toto Specification v1.0, layout definition) | Scan |
| `INTOTO-HASH` Artifact Hash Recording | Link metadata must record cryptographic hashes of every material and product so artifacts can be verified end to end (in-toto Specification v1.0, link metadata) | Scan |
| `INTOTO-ARTIFACT-ID` Unambiguous Artifact Identity | Artifact rules match artifacts by unambiguous identity, so each component must be identifiable via PURL or CPE (in-toto Specification v1.0, artifact rules) | Scan |
| `INTOTO-FUNCTIONARY` Functionary Provenance | Every step is performed by an identified, key-holding functionary, so the tool or party that produced the metadata must be recorded (in-toto Specification v1.0, functionary keys) | Scan |
| `INTOTO-STEP-OWNER` Step Ownership Attribution | The party responsible for producing each artifact in the chain must be attributable, mapping to named suppliers for components (in-toto Specification v1.0, step authorization) | Scan |
| `INTOTO-FORMAT` Machine-Verifiable Metadata | Supply chain metadata must be machine-readable and verifiable, satisfied by a standard SBOM format such as SPDX or CycloneDX (in-toto Specification v1.0, metadata format) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------- | ---------------------------------------------------- |
| `INTOTO-LAYOUT-1` | Define and Sign an in-toto Supply Chain Layout |
| `INTOTO-LAYOUT-2` | Authorize Functionaries for Each Supply Chain Step |
| `INTOTO-STEP-1` | Generate Signed Link Metadata for Every Build Step |
| `INTOTO-ARTIFACT-1` | Verify Artifact Integrity Across Pipeline Stages |
| `INTOTO-VERIFY-1` | Perform Full Supply Chain Verification at Deployment |
| `INTOTO-KEY-1` | Protect in-toto Signing Keys in Secure Storage |
## Policy templates
Written for in-toto:
* in-toto Supply Chain Security Policy
* in-toto Key and Layout Management Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to in-toto.
# International (/docs/frameworks/international)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
International standards and frameworks that apply in any country. Each framework's page lists what a scan checks, its controls, its policy templates and its automated tests. How coverage works: [Compliance frameworks](/docs/frameworks).
| Framework | Country or scope | Sector | Scan requirements | Catalog controls |
| ------------------------------------------------------------------------- | ---------------- | -------------------- | ----------------- | ---------------- |
| [CIS Controls v8](/docs/frameworks/international/cis-controls) | International | General | 6 | 18 |
| [Common Criteria (CC)](/docs/frameworks/international/common-criteria) | International | General | 6 | 13 |
| [CSA Cloud Controls Matrix](/docs/frameworks/international/csa-ccm) | International | Cloud | 6 | 7 |
| [CSA STAR](/docs/frameworks/international/csa-star) | International | Cloud | 6 | 10 |
| [CycloneDX VEX](/docs/frameworks/international/cyclonedx-vex) | International | Supply Chain | 7 | 6 |
| [DO-326A](/docs/frameworks/international/do-326a) | International | Aerospace | 6 | 8 |
| [GxP (GMP/GLP/GCP)](/docs/frameworks/international/gxp) | International | Healthcare | 7 | 12 |
| [IEC 62304](/docs/frameworks/international/iec62304) | International | Healthcare | 6 | 10 |
| [IEC 62443](/docs/frameworks/international/iec62443) | International | Energy | 6 | 19 |
| [IEC 62443-4-2](/docs/frameworks/international/iec-62443-4-2) | International | Energy | 6 | 15 |
| [in-toto](/docs/frameworks/international/in-toto) | International | Supply Chain | 6 | 6 |
| [ISO 22301](/docs/frameworks/international/iso-22301) | International | General | 6 | 15 |
| [ISO 28000](/docs/frameworks/international/iso28000) | International | Supply Chain | 6 | 12 |
| [ISO 31000](/docs/frameworks/international/iso31000) | International | General | 6 | 11 |
| [ISO/IEC 20000](/docs/frameworks/international/iso-20000) | International | General | 5 | 12 |
| [ISO/IEC 21434](/docs/frameworks/international/iso21434) | International | Automotive | 6 | 14 |
| [ISO/IEC 27001](/docs/frameworks/international/iso27001) | International | General | 6 | 22 |
| [ISO/IEC 27002:2022](/docs/frameworks/international/iso27002) | International | General | 7 | 23 |
| [ISO/IEC 27005](/docs/frameworks/international/iso27005) | International | General | 6 | 8 |
| [ISO/IEC 27017](/docs/frameworks/international/iso27017) | International | Cloud | 6 | 12 |
| [ISO/IEC 27018](/docs/frameworks/international/iso27018) | International | Cloud | 5 | 12 |
| [ISO/IEC 27032](/docs/frameworks/international/iso27032) | International | General | 6 | 10 |
| [ISO/IEC 27035](/docs/frameworks/international/iso27035) | International | General | 6 | 10 |
| [ISO/IEC 27701](/docs/frameworks/international/iso27701) | International | Privacy | 6 | 9 |
| [ISO/IEC 29147](/docs/frameworks/international/iso29147) | International | General | 6 | 7 |
| [ISO/IEC 42001](/docs/frameworks/international/iso-42001) | International | AI | 6 | 14 |
| [ISO/IEC 5962 (SPDX)](/docs/frameworks/international/iso5962) | International | General | 7 | 12 |
| [MITRE ATT\&CK](/docs/frameworks/international/mitre-attack) | International | General | 6 | 10 |
| [O-TTPS / ISO 20243](/docs/frameworks/international/o-ttps) | International | Supply Chain | 6 | 6 |
| [OpenChain ISO 5230](/docs/frameworks/international/openchain-iso5230) | International | Open Source | 6 | 7 |
| [OpenSSF Scorecard](/docs/frameworks/international/openssf-scorecard) | International | Open Source | 6 | 14 |
| [OWASP ASVS](/docs/frameworks/international/owasp-asvs) | International | Application Security | 4 | 12 |
| [OWASP CycloneDX BOM](/docs/frameworks/international/owasp-cyclonedx-bom) | International | Application Security | 7 | 10 |
| [OWASP MASVS](/docs/frameworks/international/owasp-masvs) | International | Application Security | 5 | 10 |
| [OWASP SCVS](/docs/frameworks/international/owasp-scvs) | International | Application Security | 7 | 15 |
| [OWASP Top 10](/docs/frameworks/international/owasp-top10) | International | Application Security | 6 | 30 |
| [PCI DSS 4.0 (Full)](/docs/frameworks/international/pci-dss-4) | International | Finance | 7 | 14 |
| [PCI DSS v4.0](/docs/frameworks/international/pci-dss) | International | Finance | 6 | 19 |
| [SLSA Supply Chain](/docs/frameworks/international/slsa) | International | Supply Chain | 6 | 11 |
| [SWIFT CSCF](/docs/frameworks/international/swift-cscf) | International | Finance | 6 | 19 |
| [UNECE WP.29](/docs/frameworks/international/unece-wp29) | International | Automotive | 7 | 13 |
# ISO/IEC 20000 (/docs/frameworks/international/iso-20000)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
IT Service Management: configuration item inventory, supplier management, change management.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 20000 |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 20000
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for ISO 20000.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ISO 20000 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO20000-CM-INV` Configuration Item Records | Configuration information for services must be recorded, meaning the software components (CIs) that make up a service are inventoried (ISO/IEC 20000-1:2018, configuration management requirements) | Scan |
| `ISO20000-CM-VER` CI Version Information | Configuration item records must be accurate enough to support service management decisions, which requires the version of each software CI (ISO/IEC 20000-1:2018, configuration management requirements) | Scan |
| `ISO20000-8.3.4` Supplier Management | External suppliers contributing to services must be identified and managed under documented agreements, presupposing known suppliers for the components used (ISO/IEC 20000-1:2018 §8.3.4, Supplier management) | Scan |
| `ISO20000-8.5.1` Change Management Precision | Changes must be assessed for impact before deployment, which is only feasible when component versions are specific rather than vague ranges (ISO/IEC 20000-1:2018 §8.5.1, Change management) | Scan |
| `ISO20000-INFOSEC` Information Security of Services | Information security controls must protect services, supported by the ability to verify the integrity of deployed software components (ISO/IEC 20000-1:2018, information security management requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ------------------------------------- |
| `ISO20000-4.1` | SMS Context and Scope |
| `ISO20000-5.1` | Leadership Commitment to SMS |
| `ISO20000-6.3` | Service Portfolio Planning |
| `ISO20000-8.2.2` | Change Management |
| `ISO20000-8.2.3` | Configuration Management |
| `ISO20000-8.3.1` | Incident Management |
| `ISO20000-8.6.1` | Service Level Management |
| `ISO20000-8.7` | Supplier Management |
| `ISO20000-8.8` | Asset Management |
| `ISO20000-8.5` | Capacity and Demand Management |
| `ISO20000-9.1` | Monitoring and Measurement of the SMS |
| `ISO20000-10.1` | Continual Improvement of SMS |
## Policy templates
Written for ISO 20000:
* Service Management System (SMS) Policy
* Change and Configuration Management Policy
* Supplier Management Policy for IT Services
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 20000.
# ISO 22301 (/docs/frameworks/international/iso-22301)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Business Continuity Management: software asset inventory for recovery, supplier dependencies.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 22301
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 15 controls from Safeguard's control catalog for ISO 22301.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for ISO 22301 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO22301-8.2.2-INV` BIA Resource Identification | The business impact analysis must identify the resources needed to support prioritized activities, including an inventory of the software components those activities depend on (ISO 22301:2019 §8.2.2, Business impact analysis) | Scan |
| `ISO22301-8.2.2-SUP` Supplier Dependency Mapping | Dependencies on partners and suppliers must be identified in the BIA, which maps to knowing the supplier of each software component (ISO 22301:2019 §8.2.2, dependencies including suppliers) | Scan |
| `ISO22301-8.2.2-DEP` Dependency Chain Documentation | Understanding how a disruption propagates requires documented dependency relationships between components (ISO 22301:2019 §8.2.2, dependency analysis) | Scan |
| `ISO22301-8.3-VER` Recovery-Grade Version Records | Continuity strategies and solutions must enable restoring activities within recovery objectives, which requires knowing the exact versions of software to rebuild (ISO 22301:2019 §8.3, Business continuity strategies and solutions) | Scan |
| `ISO22301-8.2.3` Risk Assessment of Disruption | The risk assessment must identify risks of disruption to prioritized activities, which for software risk requires components identifiable against known-vulnerability sources (ISO 22301:2019 §8.2.3, Risk assessment) | Scan |
| `ISO22301-8.4-DOC` Documented Continuity Information | Plans and procedures must be maintained as documented, dated information, satisfied by an SBOM with document identity and creation timestamp (ISO 22301:2019 §8.4, Business continuity plans and procedures) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ---------------------------------------------------------- |
| `ISO22301-4.1` | Understanding the Organisation and Its Context |
| `ISO22301-4.2` | Understanding Needs and Expectations of Interested Parties |
| `ISO22301-5.1` | Leadership and Commitment |
| `ISO22301-6.1` | Actions to Address Risks and Opportunities |
| `ISO22301-6.2` | Business Continuity Objectives and Planning |
| `ISO22301-7.1` | Resources for the BCMS |
| `ISO22301-8.2` | Business Impact Analysis |
| `ISO22301-8.3` | Risk Assessment for Business Continuity |
| `ISO22301-8.4` | Business Continuity Strategies and Solutions |
| `ISO22301-8.5` | Business Continuity Plans |
| `ISO22301-8.6` | Exercise and Testing Programme |
| `ISO22301-9.1` | Monitoring, Measurement, Analysis and Evaluation |
| `ISO22301-9.2` | Internal Audit of the BCMS |
| `ISO22301-10.1` | Nonconformity and Corrective Action |
| `ISO22301-10.2` | Continual Improvement of the BCMS |
## Policy templates
Written for ISO 22301:
* Business Continuity Management System (BCMS) Policy
* Business Continuity Plan Template
* Business Impact Analysis Policy and Procedure
* BCMS Exercise and Testing Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 22301.
# ISO/IEC 42001 (/docs/frameworks/international/iso-42001)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
AI Management System: AI lifecycle documentation, supply chain controls for AI systems.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 42001 |
| Region | International |
| Country or scope | International |
| Sector | AI |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 42001
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for ISO 42001.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for ISO 42001 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO42001-A4-RES` AI Resource Documentation | Resources used by AI systems, including tooling and software components, must be identified and documented (ISO/IEC 42001:2023 Annex A, resources for AI systems) | Scan |
| `ISO42001-A10-SUP` Supplier and Third-Party Management | Responsibilities with suppliers and third parties contributing to the AI system must be allocated and their services controlled, presupposing known suppliers for components (ISO/IEC 42001:2023 Annex A, third-party and customer relationships) | Scan |
| `ISO42001-A6-LIFECYCLE` AI Lifecycle Documentation | AI system lifecycle stages must produce identifiable, dated documentation, satisfied by an SBOM with document identity and timestamp (ISO/IEC 42001:2023 Annex A, AI system life cycle) | Scan |
| `ISO42001-REPRO-VER` Version Records for Reproducibility | Traceability and reproducibility of AI system behavior require recorded versions of the frameworks and libraries used (ISO/IEC 42001:2023 Annex A, AI system documentation and traceability) | Scan |
| `ISO42001-PROV` Component Provenance | The provenance of AI system elements must be recorded to support accountability for AI outcomes, including who produced the composition documentation (ISO/IEC 42001:2023 Annex A, provenance and accountability provisions) | Scan |
| `ISO42001-INTEGRITY` AI Supply Chain Integrity | Controls over the AI supply chain include verifying that acquired components are unmodified, supported by integrity hashes (ISO/IEC 42001:2023 Annex A, AI supply chain controls) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------------- | ------------------------------------------- |
| `ISO42001-4.1` | AI Context and Organisational Understanding |
| `ISO42001-5.2` | AI Policy |
| `ISO42001-6.1` | AI Risk Assessment |
| `ISO42001-6.2` | AI Objectives and Planning |
| `ISO42001-8.2` | AI System Impact Assessment |
| `ISO42001-8.4` | AI Lifecycle Management |
| `ISO42001-A.2.2` | AI Data Governance |
| `ISO42001-A.3.2` | AI Model Documentation |
| `ISO42001-A.5.2` | Responsible Use of AI |
| `ISO42001-A.6.2` | AI Supply Chain Controls |
| `ISO42001-A.7.2` | AI System Performance Monitoring |
| `ISO42001-A.8.2` | Transparency and Explainability |
| `ISO42001-A.9.2` | AI Incident Management |
| `ISO42001-A.10.2` | AI Human Oversight |
## Policy templates
Written for ISO 42001:
* AI Management System (AIMS) Policy
* AI Risk Assessment and Impact Assessment Policy
* AI Lifecycle Management Policy
* AI Supply Chain and Third-Party AI Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 42001.
# ISO/IEC 21434 (/docs/frameworks/international/iso21434)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Road Vehicle Cybersecurity Engineering: automotive component inventory, CVE tracking.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 21434 |
| Region | International |
| Country or scope | International |
| Sector | Automotive |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 21434
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for ISO 21434.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ISO 21434 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO21434-CL8.3` Cybersecurity Monitoring Basis | Continual monitoring of cybersecurity information for the item and its components requires an inventory of the software components in scope (ISO/SAE 21434 Clause 8, cybersecurity monitoring) | Scan |
| `ISO21434-CL8.5` Vulnerability Analysis | Identified weaknesses must be analyzed for vulnerabilities, which requires components to be identifiable against CVE/advisory sources via PURL or CPE (ISO/SAE 21434 Clause 8, vulnerability analysis) | Scan |
| `ISO21434-CL8.6` Vulnerability Management | Vulnerabilities must be managed and remediated across the vehicle lifecycle, which requires knowing the exact version of each software component (ISO/SAE 21434 Clause 8, vulnerability management) | Scan |
| `ISO21434-CL7` Distributed Cybersecurity Activities | Cybersecurity responsibilities with suppliers must be defined and supplier capability evaluated, presupposing that the supplier of each component is known (ISO/SAE 21434 Clause 7, distributed cybersecurity activities) | Scan |
| `ISO21434-CL10` Integration and Verification Integrity | Product development requires verifying the integrity of integrated software, supported by integrity hashes for components (ISO/SAE 21434 Clause 10, product development) | Scan |
| `ISO21434-CL6` Work Product Documentation | Cybersecurity activities must produce identifiable, managed work products, satisfied by an SBOM with document identity and creation timestamp (ISO/SAE 21434 Clause 6, project-dependent cybersecurity management) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | ---------------------------------------------------------------- |
| `RQ-08-01` | Cybersecurity Monitoring |
| `RQ-08-06` | Cybersecurity Incident Response |
| `RQ-09-02` | Item Definition |
| `RQ-09-04` | Cybersecurity Goals |
| `RQ-10-01` | Cybersecurity Specifications |
| `RQ-10-04` | Cybersecurity Validation |
| `RQ-11-01` | Cybersecurity Incident Response and Updates |
| `RQ-11-04` | End of Cybersecurity Support |
| `RQ-13-01` | Threat Analysis and Risk Assessment (TARA): Asset Identification |
| `RQ-13-05` | TARA: Attack Path Analysis |
| `RQ-13-08` | TARA: Risk Treatment Decision |
| `RQ-15-01` | Continual Cybersecurity Activity Management |
| `RQ-06-01` | Cybersecurity Supply Chain Risk Management |
| `RQ-06-04` | Component Vulnerability Management |
## Policy templates
Written for ISO 21434:
* Threat Analysis and Risk Assessment (TARA) Policy
* Automotive Cybersecurity Supply Chain Policy
* Automotive Cybersecurity Validation and Continual Improvement Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 21434.
# ISO/IEC 27001 (/docs/frameworks/international/iso27001)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Information security management: inventory, vulnerability management, supplier security controls.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 27001 |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 27001
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 22 controls from Safeguard's control catalog for ISO 27001.
* **Automated tests:** 850 map to its controls, and 360 connectors provide automated evidence for them. See [ISO/IEC 27001 and connectors](/docs/framework-connectors/iso27001).
* **Policy templates:** 27: 6 written for ISO 27001 and 21 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO27001-A5.9` Inventory of Assets | An inventory of information and other associated assets, including software, must be developed and maintained (ISO/IEC 27001:2022 Annex A 5.9) | Scan |
| `ISO27001-A8.8` Management of Technical Vulnerabilities | Information about technical vulnerabilities of systems in use must be obtained and evaluated, which requires components to be identifiable against vulnerability databases (ISO/IEC 27001:2022 Annex A 8.8) | Scan |
| `ISO27001-A5.21` ICT Supply Chain Security | Information security risks in the ICT products and services supply chain must be managed, which presupposes knowing the supplier of each software component (ISO/IEC 27001:2022 Annex A 5.21) | Scan |
| `ISO27001-A8.9` Configuration Management | Configurations of software must be established, documented and monitored, requiring version information for the software in use (ISO/IEC 27001:2022 Annex A 8.9) | Scan |
| `ISO27001-A8.19` Control of Operational Software | Installation of software on operational systems must be securely managed, supported by the ability to verify component integrity via hashes (ISO/IEC 27001:2022 Annex A 8.19) | Scan |
| `ISO27001-A5.32` Intellectual Property Rights | Procedures must ensure compliance with intellectual property rights and use of proprietary software, requiring license information for components (ISO/IEC 27001:2022 Annex A 5.32) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | ----------------------------------------------------------- |
| `A.5.1` | Policies for Information Security |
| `A.5.7` | Threat Intelligence |
| `A.5.9` | Inventory of Information and Other Associated Assets |
| `A.5.10` | Acceptable Use of Information and Other Associated Assets |
| `A.5.15` | Access Control |
| `A.5.19` | Information Security in Supplier Relationships |
| `A.5.23` | Information Security for Use of Cloud Services |
| `A.5.30` | ICT Readiness for Business Continuity |
| `A.5.34` | Privacy and Protection of Personal Identifiable Information |
| `A.6.1` | Screening |
| `A.6.3` | Information Security Awareness, Education and Training |
| `A.7.10` | Storage Media |
| `A.8.1` | User Endpoint Devices |
| `A.8.2` | Privileged Access Rights |
| `A.8.5` | Secure Authentication |
| `A.8.7` | Protection Against Malware |
| `A.8.8` | Management of Technical Vulnerabilities |
| `A.8.9` | Configuration Management |
| `A.8.16` | Monitoring Activities |
| `A.8.23` | Web Filtering |
| `A.8.28` | Secure Coding |
| `A.8.32` | Change Management |
## Policy templates
Written for ISO 27001:
* Statement of Applicability (SoA)
* Information Security Management System (ISMS) Policy
* Technical Vulnerability Management Policy
* Supplier Information Security Policy
* Access Control Policy
* Secure Development Lifecycle Policy
And 21 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 27001.
# ISO/IEC 27002:2022 (/docs/frameworks/international/iso27002)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Code of practice for info-sec controls - 4 themes (Org/People/Physical/Tech), 93 controls.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 27002 |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 27002
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 23 controls from Safeguard's control catalog for ISO 27002.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 4 written for ISO 27002 and 19 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO27002-5.9` Inventory of Information and Associated Assets | An inventory of information and other associated assets, including software, must be developed and maintained with identified owners, which for applications means a non-empty component inventory (ISO/IEC 27002:2022 control 5.9) | Scan |
| `ISO27002-5.19` Information Security in Supplier Relationships | Processes must manage the information security risks associated with the use of supplier products and services, which requires knowing the supplier of each software component in use (ISO/IEC 27002:2022 control 5.19) | Scan |
| `ISO27002-5.21` Managing Security in the ICT Supply Chain | Risks associated with the ICT products and services supply chain must be managed, including visibility into how acquired components depend on further upstream components (ISO/IEC 27002:2022 control 5.21) | Scan |
| `ISO27002-8.8` Management of Technical Vulnerabilities | Information about technical vulnerabilities of systems in use must be obtained and exposure evaluated, which requires version-level knowledge of every deployed component to match against advisories (ISO/IEC 27002:2022 control 8.8) | Scan |
| `ISO27002-8.9` Configuration Management | Configurations, including of software, must be established, documented and monitored, which excludes vague or floating version specifications that make the deployed configuration ambiguous (ISO/IEC 27002:2022 control 8.9) | Scan |
| `ISO27002-8.24` Use of Cryptography for Integrity | Rules for the effective use of cryptography, including for protecting the authenticity and integrity of information, support verifying software artifacts via cryptographic hashes (ISO/IEC 27002:2022 control 8.24) | Scan |
| `ISO27002-5.37` Documented Operating Procedures | Operating procedures for information processing facilities must be documented and available, supported by identifiable, timestamped machine-readable records of what software those facilities run (ISO/IEC 27002:2022 control 5.37) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | ----------------------------------------------------------------- |
| `A.5.1` | Policies for Information Security |
| `A.5.7` | Threat Intelligence |
| `A.5.9` | Inventory of Information and Other Associated Assets |
| `A.5.10` | Acceptable Use of Information and Other Associated Assets |
| `A.5.15` | Access Control |
| `A.5.19` | Information Security in Supplier Relationships |
| `A.5.23` | Information Security for Use of Cloud Services |
| `A.5.30` | ICT Readiness for Business Continuity |
| `A.5.34` | Privacy and Protection of Personal Identifiable Information (PII) |
| `A.6.1` | Screening |
| `A.6.3` | Information Security Awareness, Education and Training |
| `A.7.4` | Physical Security Monitoring |
| `A.7.10` | Storage Media |
| `A.8.1` | User Endpoint Devices |
| `A.8.2` | Privileged Access Rights |
| `A.8.5` | Secure Authentication |
| `A.8.7` | Protection Against Malware |
| `A.8.8` | Management of Technical Vulnerabilities |
| `A.8.9` | Configuration Management |
| `A.8.16` | Monitoring Activities |
| `A.8.23` | Web Filtering |
| `A.8.28` | Secure Coding |
| `A.8.32` | Change Management |
## Policy templates
Written for ISO 27002:
* Information Security Policy
* Acceptable Use Policy
* Supplier and Third-Party Security Policy
* Secure Software Development Policy
And 19 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 27002.
# ISO/IEC 27005 (/docs/frameworks/international/iso27005)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Information security risk management - risk identification, analysis, evaluation, treatment.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 27005 |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 27005
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for ISO 27005.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ISO 27005 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO27005-RISK-ID` Risk and Asset Identification | Risk identification requires determining the assets within scope that could be affected by information security risks; for software systems this means an enumerated inventory of the components in use (ISO/IEC 27005:2022, risk identification guidance, Cl. 7) | Scan |
| `ISO27005-RISK-AN` Risk Analysis Inputs | Analysing the likelihood and consequences of identified risks requires knowing exactly which versions of software assets are deployed so threats and known vulnerabilities can be matched to them (ISO/IEC 27005:2022, risk analysis guidance) | Scan |
| `ISO27005-ASSET-ID` Unambiguous Asset Identification | Effective risk assessment depends on assets being unambiguously identifiable so that risks, owners, and treatments can be tied to specific assets rather than vague descriptions (ISO/IEC 27005:2022, asset identification guidance) | Scan |
| `ISO27005-SUPPLY` Supply Chain Risk Sources | The risk context must account for risk sources arising from external parties and suppliers; assessing supplier-originated risk requires knowing the supplier of each component in the system (ISO/IEC 27005:2022, context establishment and risk source guidance) | Scan |
| `ISO27005-DOC` Documented Risk Assessment Records | Risk assessment and treatment results must be documented and retained so they can be communicated, reviewed, and audited, which requires formally identified, timestamped machine-readable records of the assessed systems (ISO/IEC 27005:2022, documentation and communication guidance) | Scan |
| `ISO27005-MON` Monitoring and Review Provenance | Risks and the factors underlying them must be monitored and reviewed over time; comparing successive assessments requires knowing which tool or organization produced each system record and when (ISO/IEC 27005:2022, monitoring and review guidance) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ----------------------------------- |
| `27005-CL6` | Context Establishment |
| `27005-CL7-ID` | Risk Identification |
| `27005-CL7-AN` | Risk Analysis |
| `27005-CL7-EV` | Risk Evaluation and Prioritisation |
| `27005-CL8` | Risk Treatment |
| `27005-CL9` | Risk Acceptance |
| `27005-CL10` | Risk Communication and Consultation |
| `27005-CL11` | Monitoring and Review |
## Policy templates
Written for ISO 27005:
* Information Security Risk Management Policy
* Risk Treatment and Acceptance Procedure
* Risk Communication and Monitoring Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 27005.
# ISO/IEC 27017 (/docs/frameworks/international/iso27017)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Cloud Security Controls: component inventory, supplier attribution, integrity verification.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 27017 |
| Region | International |
| Country or scope | International |
| Sector | Cloud |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 27017
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for ISO 27017.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for ISO 27017 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO27017-8.1.1` Inventory of Cloud Assets | Assets associated with cloud services, including software components, must be identified and inventoried (ISO/IEC 27017 §8.1.1, Inventory of assets) | Scan |
| `ISO27017-12.6.1` Technical Vulnerability Management | Technical vulnerabilities in cloud service software must be identified and addressed in a timely manner, requiring identifiable components (ISO/IEC 27017 §12.6.1, Management of technical vulnerabilities) | Scan |
| `ISO27017-15.1.3` ICT Supply Chain Attribution | Agreements with suppliers must address risks propagated through the ICT services supply chain, presupposing known suppliers for the components in use (ISO/IEC 27017 §15.1.3, ICT supply chain) | Scan |
| `ISO27017-12.5.1` Integrity of Installed Software | Installation of software on operational cloud systems must be controlled, supported by integrity hashes for verification (ISO/IEC 27017 §12.5.1, Installation of software on operational systems) | Scan |
| `ISO27017-12.1.2` Change Management Version Tracking | Changes to systems must be controlled, which requires knowing the version of each software component deployed (ISO/IEC 27017 §12.1.2, Change management) | Scan |
| `ISO27017-18.1.2` Intellectual Property in Cloud Services | Compliance with intellectual property rights for software used in cloud services must be ensured, requiring license information (ISO/IEC 27017 §18.1.2, Intellectual property rights) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ------------------------------------------------------------------ |
| `CLD.6.3.1` | Shared Roles and Responsibilities in Cloud Environments |
| `CLD.8.1.5` | Removal of Cloud Service Customer Assets |
| `CLD.9.5.1` | Segregation in Virtual Computing Environments |
| `CLD.9.5.2` | Virtual Machine Hardening |
| `CLD.12.1.5` | Administrator Operational Security |
| `CLD.12.4.5` | Monitoring of Cloud Services |
| `CLD.13.1.4` | Alignment of Security Management for Virtual and Physical Networks |
| `A.5.23` | Information Security for Use of Cloud Services |
| `A.8.9` | Cloud Configuration Management |
| `A.5.19` | Cloud Supply Chain Security |
| `A.8.8` | Vulnerability Management in Cloud Environments |
| `A.8.28` | Secure Development in Cloud Environments |
## Policy templates
Written for ISO 27017:
* Cloud Service Agreement Security Policy
* Cloud Configuration and Hardening Policy
* Cloud Security Monitoring Policy
* Cloud Supply Chain Security Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 27017.
# ISO/IEC 27018 (/docs/frameworks/international/iso27018)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Privacy in Cloud: sub-processor disclosure, cryptographic controls, component accountability.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 27018 |
| Region | International |
| Country or scope | International |
| Sector | Cloud |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 27018
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for ISO 27018.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ISO 27018 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO27018-SUBPROC` Sub-Processor Disclosure | The cloud PII processor must disclose the use of sub-contractors involved in processing, mapping to named suppliers for the software components in the service (ISO/IEC 27018 Annex A control on disclosure of sub-contracted PII processing) | Scan |
| `ISO27018-8.1.1` Asset Inventory for PII Systems | Assets used to process PII, including software components, must be identified and inventoried per the underlying 27002 controls (ISO/IEC 27018 applying §8.1.1, Inventory of assets) | Scan |
| `ISO27018-CRYPTO` Cryptographic and Integrity Controls | Cryptographic controls protecting PII imply the ability to verify the integrity of the processing software via component hashes (ISO/IEC 27018 applying §10, Cryptography) | Scan |
| `ISO27018-12.6.1` Vulnerability Management for PII Systems | Technical vulnerabilities in systems processing PII must be managed, which requires current version information for deployed components (ISO/IEC 27018 applying §12.6.1, Management of technical vulnerabilities) | Scan |
| `ISO27018-ACCT` Accountability Records | The processor must be able to demonstrate accountability for its processing environment, supported by dated, identifiable documentation of the software composition (ISO/IEC 27018 accountability provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | ------------------------------------------------- |
| `A.1.1` | Consent and Choice for PII Processing |
| `A.2.1` | Purpose Limitation for PII |
| `A.3.1` | Obligation of Sub-Processors |
| `A.5.1` | Cryptographic Controls for PII |
| `A.7.1` | PII Retention and Disposal |
| `A.10.1` | PII Disclosure to Third Parties |
| `A.4.1` | Restriction of Processing |
| `A.9.1` | Access to PII by Cloud Service Provider Personnel |
| `A.11.1` | Records of PII Disclosure to Third Parties |
| `A.12.1` | PII Breach Notification |
| `A.14.1` | Availability of PII Processing Records |
| `A.6.1` | Data Minimisation |
## Policy templates
Written for ISO 27018:
* PII Processing and Privacy Policy for Cloud Services
* PII Principal Rights and Transparency Policy
* Access Control for PII Processing Environments
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 27018.
# ISO/IEC 27032 (/docs/frameworks/international/iso27032)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Cybersecurity guidelines - cyberspace stakeholder roles, controls, information sharing.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 27032 |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 27032
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for ISO 27032.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for ISO 27032 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO27032-ASSET` Cyberspace Asset Identification | Organisations must identify the assets they expose to and depend on in cyberspace, which for applications means an inventory of their software components (ISO/IEC 27032 asset identification guidance) | Scan |
| `ISO27032-CTRL` Technical Integrity Controls | Recommended technical controls include protecting systems against malicious code and unauthorised modification, evidenced by cryptographic integrity hashes on software artifacts (ISO/IEC 27032 technical controls guidance) | Scan |
| `ISO27032-STAKE` Provider and Stakeholder Coordination | Cybersecurity in cyberspace depends on coordination between consumers and providers of services and software, requiring documented knowledge of who supplies each component (ISO/IEC 27032 stakeholder roles guidance) | Scan |
| `ISO27032-SHARE` Information Sharing Framework | Effective inter-organisational information sharing requires structured, standardised data about systems, which for software estates means machine-readable SBOM formats (ISO/IEC 27032 information sharing and coordination framework) | Scan |
| `ISO27032-INC` Incident Coordination Readiness | Coordinated incident handling across stakeholders requires that affected components can be unambiguously identified and communicated (ISO/IEC 27032 incident handling coordination guidance) | Scan |
| `ISO27032-POC` Coordination Contact Points | Information sharing and coordination frameworks require established organisational points of contact, evidenced by contact details recorded alongside system documentation (ISO/IEC 27032 coordination and contact guidance) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | -------------------------------------------------- |
| `5.2` | Cyberspace Stakeholder Responsibilities: Consumers |
| `5.3` | Cyberspace Stakeholder Responsibilities: Providers |
| `10.1` | Asset Management in Cyberspace |
| `10.2` | Threat and Vulnerability Management |
| `11.1` | Application Security Controls |
| `12.1` | Server and Infrastructure Security |
| `13.1` | End-User Security Controls |
| `14.1` | Controls Against Social Engineering |
| `15.1` | Information Sharing and Coordination |
| `15.2` | Cybersecurity Incident Response Coordination |
## Policy templates
Written for ISO 27032:
* Cybersecurity Programme Charter
* Cyber Threat Intelligence Information Sharing Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 27032.
# ISO/IEC 27035 (/docs/frameworks/international/iso27035)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Information security incident management - principles, IR plan, coordination, lessons learned.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 27035 |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 27035
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for ISO 27035.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ISO 27035 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO27035-PLAN` Plan and Prepare Documentation | Incident management requires prepared, current documentation of the environment to be defended, evidenced by identifiable and timestamped records of deployed software (ISO/IEC 27035-2 plan-and-prepare phase) | Scan |
| `ISO27035-DETECT` Detection Baseline | Effective detection and reporting of incidents presumes knowing what software is running so anomalies and affected assets can be recognised, i.e. a maintained component inventory (ISO/IEC 27035-1 detection and reporting phase) | Scan |
| `ISO27035-ASSESS` Assessment and Decision Readiness | Assessing whether an event is an incident and deciding severity requires unambiguous identification of the components involved so they can be matched against threat intelligence (ISO/IEC 27035-1 assessment and decision phase) | Scan |
| `ISO27035-RESP` Response Scoping by Version | Responding to incidents, including containment and eradication, requires version-level knowledge of deployed software to scope which instances are affected (ISO/IEC 27035-1 response phase) | Scan |
| `ISO27035-CONTACT` Incident Reporting Contact Points | Incident management planning requires established points of contact for reporting and coordination, evidenced by contact details recorded with the software documentation (ISO/IEC 27035-2 incident management plan and contact provisions) | Scan |
| `ISO27035-SHARE` Structured Records for Coordination | Coordination and lessons-learned activities depend on structured, shareable records, which for software estates means standardised machine-readable formats (ISO/IEC 27035-1 lessons learned and information sharing principles) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | ------------------------------------ |
| `5.1` | Plan and Prepare |
| `5.2` | Detect and Report |
| `5.3` | Assess and Decide |
| `5.4` | Respond |
| `5.5` | Lessons Learnt |
| `6.1` | ISIRT Establishment and Structure |
| `6.2` | ISIRT Competence and Training |
| `7.1` | Incident Communication: Internal |
| `7.2` | Incident Communication: External |
| `7.3` | Evidence Collection and Preservation |
## Policy templates
Written for ISO 27035:
* Information Security Incident Response Plan
* ISIRT Charter: Information Security Incident Response Team
* Incident Communication Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 27035.
# ISO/IEC 27701 (/docs/frameworks/international/iso27701)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Privacy Information Management System extension to ISO 27001 - PII controllers and processors.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 27701 |
| Region | International |
| Country or scope | International |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 27701
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for ISO 27701.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for ISO 27701 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `ISO27701-6.5` Asset Management for PII Systems | The PIMS extends ISO 27002 asset management to PII processing: assets involved in processing PII, including software components, must be identified and inventoried (ISO/IEC 27701:2019, Cl. 6.5) | Scan |
| `ISO27701-6.9` Operations Security and Integrity | Operations security controls extended for PII processing require protecting systems against unauthorized modification and malware, which presupposes integrity verification of the deployed software components (ISO/IEC 27701:2019, Cl. 6.9) | Scan |
| `ISO27701-6.9-VULN` Technical Vulnerability Management | The extended operations-security guidance includes managing technical vulnerabilities of systems processing PII, which requires knowing the exact version of each component in order to match it against published vulnerabilities (ISO/IEC 27701:2019, Cl. 6.9 technical vulnerability management guidance) | Scan |
| `ISO27701-6.12` Supplier Relationships | Supplier relationship controls extended for privacy require addressing PII protection in agreements with suppliers, which depends on knowing the supplier of each component in the processing chain (ISO/IEC 27701:2019, Cl. 6.12) | Scan |
| `ISO27701-7.2.8` Records Related to Processing PII | PII controllers must determine and securely maintain the necessary records demonstrating processing of PII, which for technical systems means formally identified, timestamped machine-readable documentation (ISO/IEC 27701:2019, Cl. 7.2.8) | Scan |
| `ISO27701-6.15` Compliance Including Intellectual Property | The extended compliance controls cover identification of applicable legal requirements including intellectual property rights in the software used for PII processing, requiring license information for the components in use (ISO/IEC 27701:2019, Cl. 6.15) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------------- | -------------------------------------------------------- |
| `27701-5` | PIMS Requirements: Context and Leadership |
| `27701-6` | PIMS Planning: Privacy Risk Assessment |
| `27701-A.7.2.1` | Identify and Document PII Processing Purpose |
| `27701-A.7.2.2` | Identify Lawful Basis for PII Processing |
| `27701-A.7.3.1-10` | PII Principal Rights Fulfilment |
| `27701-A.7.4` | Privacy by Design and by Default |
| `27701-A.7.5` | International PII Transfers |
| `27701-B.8.2.1-B.8.5` | Processor Obligations (Annex B) |
| `27701-7-8` | PIMS Support: Competence, Awareness, Operational Control |
## Policy templates
Written for ISO 27701:
* Privacy Information Management System (PIMS) Manual
* PII Processor Obligations Policy (Annex B)
* Privacy by Design and Default Procedure
* PII Principal Rights Fulfilment Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 27701.
# ISO 28000 (/docs/frameworks/international/iso28000)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Security and resilience - Security management systems for the supply chain.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | International |
| Country or scope | International |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 28000
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for ISO 28000.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ISO 28000 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `ISO28000-4` Context and Supply Chain Scope | The organisation must determine the scope of the security management system including its supply chain context, which for software means the system under review is named and its contents enumerated (ISO 28000:2022 clause 4, context of the organization) | Scan |
| `ISO28000-6` Security Risk Assessment Planning | Planning requires assessing security risks and opportunities across the supply chain, which is only possible when components are unambiguously identifiable for threat matching (ISO 28000:2022 clause 6, planning and security risk assessment) | Scan |
| `ISO28000-7.5` Documented Information | The management system must maintain controlled documented information, which for software supply chains means identifiable, timestamped bills of materials (ISO 28000:2022 clause 7.5, documented information) | Scan |
| `ISO28000-8` Operational Security Controls | Operational planning and control must implement the security measures identified, including protecting goods and artifacts in the chain against tampering, evidenced by cryptographic hashes on software components (ISO 28000:2022 clause 8, operation) | Scan |
| `ISO28000-SUP` Upstream Supplier Visibility | Managing supply chain security requires knowing the parties upstream in the chain, which for software means a named supplier for each component (ISO 28000:2022 supply chain security management requirements) | Scan |
| `ISO28000-DEP` Chain Relationship Mapping | Security management across the supply chain presumes understanding how elements of the chain depend on one another, which for software means documented dependency relationships (ISO 28000:2022 supply chain context and interdependency considerations) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | ---------------------------------------------- |
| `4.1` | Understanding the Organisation and Its Context |
| `5.1` | Leadership and Commitment |
| `6.1` | Supply Chain Security Risk Assessment |
| `7.1` | Resources, Competence and Awareness |
| `7.4` | Communication |
| `7.5` | Documented Information |
| `8.1` | Operational Planning and Control |
| `8.2` | Supply Chain Security Plan |
| `8.5` | Emergency Preparedness and Response |
| `8.6` | Management of Change in Supply Chain Security |
| `9.1` | Performance Evaluation and Monitoring |
| `10.1` | Continual Improvement |
## Policy templates
Written for ISO 28000:
* Supply Chain Security Management System (SCSMS) Manual
* Supply Chain Security Risk Assessment Procedure
* Supply Chain Emergency Preparedness and Response Plan
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 28000.
# ISO/IEC 29147 (/docs/frameworks/international/iso29147)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Vulnerability Disclosure: PURL/CPE correlation, hash verification, coordinated disclosure.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 29147 |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 29147
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for ISO 29147.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for ISO 29147 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO29147-CONTACT` Vulnerability Report Contact Point | The vendor must publish a capability and point of contact for receiving vulnerability reports, so the SBOM creator must include reachable contact information (ISO/IEC 29147, receiving vulnerability reports) | Scan |
| `ISO29147-PRODID` Affected Product Identification | Advisories and coordination require unambiguous identification of affected products, satisfied by PURL or CPE identifiers on components (ISO/IEC 29147, advisory content on affected products) | Scan |
| `ISO29147-VERSIONS` Affected Version Enumeration | Vulnerability advisories must state which versions are affected, which requires version information for every component (ISO/IEC 29147, advisory content on affected versions) | Scan |
| `ISO29147-VERSPEC` Specific Version Designators | Correlating reports to affected releases is only possible with specific version designators, not wildcards or ranges (ISO/IEC 29147, product and version identification) | Scan |
| `ISO29147-UID` Identifier Correlation | Coordinated disclosure across parties depends on shared unique identifiers such as package URLs for the software in question (ISO/IEC 29147, coordination and identifiers) | Scan |
| `ISO29147-DOC` Traceable Disclosure Documentation | Disclosure processes require dated, identifiable documentation of the software composition to assess report applicability (ISO/IEC 29147, documentation of the disclosure process) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | -------------------------------------------------------- |
| `ISO29147-6.1` | Establish a Vulnerability Intake Process |
| `ISO29147-6.2` | Triage and Assess Reported Vulnerabilities |
| `ISO29147-6.3` | Communicate Remediation Plans to Reporters |
| `ISO29147-6.4` | Remediate Vulnerabilities Within Defined SLAs |
| `ISO29147-7.1` | Coordinate Public Vulnerability Disclosure |
| `ISO29147-7.2` | Publish Security Advisories for Resolved Vulnerabilities |
| `ISO29147-8.1` | Measure and Improve the Disclosure Process |
## Policy templates
Written for ISO 29147:
* Vulnerability Disclosure Policy (ISO/IEC 29147)
* Internal Vulnerability Handling Process (ISO/IEC 29147)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 29147.
# ISO 31000 (/docs/frameworks/international/iso31000)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Risk management - principles, framework, process for organisation-wide risk management.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 31000
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for ISO 31000.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ISO 31000 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO31000-6.3` Scope, Context and Criteria | The risk management process must define its scope and understand the internal context, which for a software system means the system is named and its contents enumerated (ISO 31000:2018 clause 6.3, scope, context and criteria) | Scan |
| `ISO31000-6.4.2` Risk Identification | Risks must be found, recognised and described, including sources of risk, which for software requires an inventory of the components where risk can arise (ISO 31000:2018 clause 6.4.2, risk identification) | Scan |
| `ISO31000-6.4.3` Risk Analysis on Best Available Information | Risk analysis must comprehend the nature and level of risk using the best available information, which for software components requires version data to assess exposure to known weaknesses (ISO 31000:2018 clause 6.4.3, risk analysis) | Scan |
| `ISO31000-6.6` Monitoring and Review | Risks and the risk process must be continually monitored and reviewed, which presumes components remain unambiguously identifiable so new threat information can be mapped to them (ISO 31000:2018 clause 6.6, monitoring and review) | Scan |
| `ISO31000-6.7` Recording and Reporting | The risk management process and its outcomes must be documented and reported through appropriate mechanisms, evidenced by identifiable, timestamped records of the assessed system (ISO 31000:2018 clause 6.7, recording and reporting) | Scan |
| `ISO31000-5.4` Framework Integration and Accountability | The risk management framework requires assigned accountability and integration into organisational processes, supported by provenance records showing who produced the system documentation and when (ISO 31000:2018 clause 5, framework/leadership and commitment) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | --------------------------------------- |
| `5.2` | Leadership and Commitment |
| `5.3` | Integration |
| `5.4` | Design of Risk Management Framework |
| `5.5` | Implementation |
| `5.6` | Evaluation of Risk Management Framework |
| `6.2` | Communication and Consultation |
| `6.3` | Scope, Context and Criteria |
| `6.4` | Risk Assessment |
| `6.5` | Risk Treatment |
| `6.6` | Monitoring and Review |
| `6.7` | Recording and Reporting |
## Policy templates
Written for ISO 31000:
* Risk Management Policy
* Risk Assessment and Treatment Procedure
* Risk Monitoring and Reporting SOP
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 31000.
# ISO/IEC 5962 (SPDX) (/docs/frameworks/international/iso5962)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
SPDX SBOM format standard: document creation, package data, license expressions, completeness.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISO 5962 |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISO 5962
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for ISO 5962.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ISO 5962 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ISO5962-FMT` Conformant Machine-Readable Format | The document must be produced in a standardized, machine-readable SBOM format (ISO/IEC 5962:2021 / SPDX 2.2.1 conformance) | Scan |
| `ISO5962-CL6-DOC` Document Creation Information | The SBOM must carry document identity fields including a unique namespace/identifier and the created timestamp (SPDX 2.2.1 Clause 6, Document creation information, incl. 6.5 and 6.9) | Scan |
| `ISO5962-CL6.8` Creator Field | The tool, person or organization that created the document must be recorded in the Creator field (SPDX 2.2.1 Clause 6.8) | Scan |
| `ISO5962-CL7-NAMEVER` Package Name and Version | Each package must have a name and should carry its version to be uniquely locatable (SPDX 2.2.1 Clauses 7.1 and 7.3) | Scan |
| `ISO5962-CL7-LIC` License Expressions | Packages should declare license information as SPDX license expressions (SPDX 2.2.1 Clauses 7.13 and 7.15, concluded and declared license) | Scan |
| `ISO5962-CL7.10` Package Checksums | Packages should provide cryptographic checksums enabling integrity verification of the described artifacts (SPDX 2.2.1 Clause 7.10, Package checksum) | Scan |
| `ISO5962-CL11` Relationships Between Elements | The document should express dependency and containment relationships between SPDX elements (SPDX 2.2.1 Clause 11, Relationships) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | ------------------------------------------- |
| `SPDX-2.1` | SPDX Document Creation Information |
| `SPDX-3.1` | Package Information Completeness |
| `SPDX-3.7` | Package URL and External References |
| `SPDX-4.1` | File Information and Checksums |
| `SPDX-5.1` | Snippet Information |
| `SPDX-6.1` | License Expressions |
| `SPDX-7.1` | Relationship Information |
| `SPDX-8.1` | Annotation Information |
| `SPDX-COMP` | SBOM Completeness and NTIA Minimum Elements |
| `SPDX-HASH` | Cryptographic Hash Verification |
| `SPDX-FORMAT` | Machine-Readable Format Compliance |
| `SPDX-LIC` | License Identification and Obligations |
## Policy templates
Written for ISO 5962:
* SBOM Creation and Management Policy (SPDX)
* Open Source License Compliance Policy
* SBOM Integrity and Authenticity Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISO 5962.
# MITRE ATT&CK (/docs/frameworks/international/mitre-attack)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Supply Chain: compromise prevention, dependency compromise, trust subversion.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ATT\&CK |
| Region | International |
| Country or scope | International |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ATT\&CK
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for ATT\&CK.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for ATT\&CK and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ATTACK-T1195.002` Software Supply Chain Integrity | Defending against compromise of software delivered through the supply chain requires verifying artifact integrity, i.e. hashes for the components consumed (MITRE ATT\&CK T1195.002, Compromise Software Supply Chain) | Scan |
| `ATTACK-T1195.001` Dependency and Tooling Visibility | Detecting compromise of development tools and dependencies requires documented dependency relationships across the build (MITRE ATT\&CK T1195.001, Compromise Software Dependencies and Development Tools) | Scan |
| `ATTACK-M1051` Update Software | The Update Software mitigation requires knowing the current version of every component to determine patch status (MITRE ATT\&CK mitigation M1051) | Scan |
| `ATTACK-M1016` Vulnerability Scanning Correlation | The Vulnerability Scanning mitigation depends on components being identifiable against vulnerability data via PURL or CPE (MITRE ATT\&CK mitigation M1016) | Scan |
| `ATTACK-T1195-TRUST` Supplier Trust Assessment | Assessing which upstream parties could subvert trust requires a named supplier for each component in the chain (MITRE ATT\&CK T1195, supply chain compromise vectors) | Scan |
| `ATTACK-INTEL-UID` Threat Intelligence Matching | Matching components against threat intelligence on compromised packages requires unique identifiers such as package URLs (MITRE ATT\&CK T1195 detection guidance) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | -------------------------------------------- |
| `T1195` | Detect and Prevent Supply Chain Compromise |
| `T1195.001` | Prevent Compromise of Software Dependencies |
| `T1195.002` | Prevent Compromise of Software Supply Chain |
| `T1195.003` | Mitigate Compromise of Hardware Supply Chain |
| `T1199` | Control Trusted Relationship Access |
| `T1078` | Detect and Prevent Valid Account Abuse |
| `T1190` | Harden Public-Facing Applications |
| `M1016` | Apply Vulnerability Scanning Mitigation |
| `M1051` | Update Software Mitigation |
| `M1045` | Enforce Code Signing Mitigation |
## Policy templates
Written for ATT\&CK:
* Supply Chain Threat Defense Policy (MITRE ATT\&CK)
* ATT\&CK-Aligned Threat Detection and Response Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ATT\&CK.
# O-TTPS / ISO 20243 (/docs/frameworks/international/o-ttps)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Open Trusted Technology Provider Standard: secure engineering, supply chain risk, license compliance.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | O-TTPS |
| Region | International |
| Country or scope | International |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers O-TTPS
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 6 controls from Safeguard's control catalog for O-TTPS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for O-TTPS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `OTTPS-SC-INV` Product Component Traceability | Providers must be able to trace the components incorporated into their products through the supply chain, starting with a complete inventory of included components (ISO/IEC 20243-1 supply chain security requirements) | Scan |
| `OTTPS-SC-CTM` Counterfeit Mitigation via Component Identity | To mitigate counterfeit components, each component must be precisely identified with a standard identifier so genuine parts can be distinguished from substitutes (ISO/IEC 20243-1 counterfeit mitigation requirements) | Scan |
| `OTTPS-SC-TAINT` Tainted Product Mitigation via Integrity | To mitigate maliciously tainted components, delivered software must be verifiable against cryptographic integrity data (ISO/IEC 20243-1 malware/taint mitigation requirements) | Scan |
| `OTTPS-SC-SUP` Supplier Management | Providers must apply supply chain security requirements to their suppliers, which presupposes that the supplier of each third-party component is known and recorded (ISO/IEC 20243-1 supplier management requirements) | Scan |
| `OTTPS-SE-LIC` Intellectual Property and License Compliance | Secure engineering practice includes managing the intellectual property rights of incorporated third-party and open source components, requiring license information per component (ISO/IEC 20243-1 secure engineering / IP management requirements) | Scan |
| `OTTPS-SE-CM` Configuration and Version Control | Well-defined development discipline requires configuration management of product components, meaning each component's version is tracked (ISO/IEC 20243-1 product development / engineering method requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ----------------------------------------------- |
| `OTTPS-PD-DES` | Apply Security in Product Design |
| `OTTPS-PD-CFM` | Implement Configuration and Change Management |
| `OTTPS-PD-SCEM` | Control Software Component and External Modules |
| `OTTPS-SC-RSM` | Assess and Manage Supply Chain Risk |
| `OTTPS-SC-DIST` | Secure Product Distribution and Delivery |
| `OTTPS-SC-PROC` | Vet and Monitor Critical Suppliers |
## Policy templates
Written for O-TTPS:
* Product Security and Supply Chain Risk Management Policy (O-TTPS)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to O-TTPS.
# OpenChain ISO 5230 (/docs/frameworks/international/openchain-iso5230)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
International standard for open source license compliance management programs.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | OpenChain |
| Region | International |
| Country or scope | International |
| Sector | Open Source |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers OpenChain
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for OpenChain.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for OpenChain and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `OC-3-3-BOM` Open Source Bill of Materials | The program must have a process to create and manage a bill of materials that includes each open source component in a supplied software release (ISO/IEC 5230:2020 §3.3, open source content review and approval) | Scan |
| `OC-3-3-LIC` License Identification | Identified licenses of open source components must be reviewed against the intended distribution use case, which requires license information to be recorded per component (ISO/IEC 5230:2020 §3.3) | Scan |
| `OC-3-2-ART` Compliance Artifact Preparation | The program must be able to prepare the compliance artifacts (notices, source offers) that identified licenses require, which presupposes each component is unambiguously identified (ISO/IEC 5230:2020 §3.2 / §3.4 compliance artifacts) | Scan |
| `OC-3-3-VER` Component Version Tracking | License obligations frequently differ between versions of the same component, so the bill of materials must record the version of each open source component (ISO/IEC 5230:2020 §3.3 BOM management) | Scan |
| `OC-3-1-DOC` Documented Program Evidence | The compliance program must produce documented evidence; a bill of materials with a document identifier and creation timestamp provides the auditable record for each release (ISO/IEC 5230:2020 §3.1 program foundation) | Scan |
| `OC-3-5-SUP` Upstream Component Origins | Understanding open source community engagement and obligations requires knowing where each component comes from, i.e. its supplier or originating project (ISO/IEC 5230:2020 program requirements on external contributions/obligations) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | ------------------------------------------------------- |
| `OC-3.1.1` | Establish a Written Open-Source Policy |
| `OC-3.1.2` | Define Roles and Responsibilities for OSS Compliance |
| `OC-3.2.1` | Demonstrate Competence of Program Participants |
| `OC-3.3.1` | Raise Awareness of Open-Source Obligations |
| `OC-3.4.1` | Maintain Documented Inbound and Outbound OSS Processes |
| `OC-3.5.1` | Verify Supplier Conformance to Open-Source Requirements |
| `OC-3.6.1` | Fulfill Distribution License Obligations |
## Policy templates
Written for OpenChain:
* Open-Source License Compliance Policy (OpenChain ISO 5230)
* Open-Source Software Contribution Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to OpenChain.
# OpenSSF Scorecard (/docs/frameworks/international/openssf-scorecard)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
License identification, version specification, dependency tooling, supply chain integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | OpenSSF |
| Region | International |
| Country or scope | International |
| Sector | Open Source |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers OpenSSF
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for OpenSSF.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for OpenSSF and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `OSSF-LICENSE` License Declared | Projects and their consumed components should have a published, identifiable license, mirrored here as license information recorded per component (OpenSSF Scorecard 'License' check) | Scan |
| `OSSF-PINNED` Pinned Dependencies | Dependencies should be pinned to exact versions rather than floating ranges or 'latest' tags to prevent silent substitution (OpenSSF Scorecard 'Pinned-Dependencies' check) | Scan |
| `OSSF-PIN-VER` Versions Declared | Pinning presupposes that every dependency has a declared version in the first place (OpenSSF Scorecard 'Pinned-Dependencies' check) | Scan |
| `OSSF-VULN` Known Vulnerability Matching | Projects are scored on unfixed known vulnerabilities via OSV lookup, which requires components to carry standard identifiers (PURL/CPE) to be matched at all (OpenSSF Scorecard 'Vulnerabilities' check) | Scan |
| `OSSF-SIGNED` Release Integrity Material | Signed releases and provenance let consumers verify artifacts; at SBOM level this requires integrity hashes recorded for components (OpenSSF Scorecard 'Signed-Releases' check) | Scan |
| `OSSF-DEPTOOL` Dependency Awareness | Using dependency-update tooling presupposes a documented dependency graph so transitive relationships are known (OpenSSF Scorecard 'Dependency-Update-Tool' check) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------------------- | --------------------------------------------------------------- |
| `SC-Binary-Artifacts` | Eliminate Binary Artifacts from Source Repository |
| `SC-Branch-Protection` | Enable Branch Protection on Default and Release Branches |
| `SC-CI-Tests` | Run Automated Tests on Every Pull Request |
| `SC-Code-Review` | Require Code Review for All Changes |
| `SC-Dangerous-Workflow` | Prohibit Dangerous CI/CD Workflow Patterns |
| `SC-Dependency-Update-Tool` | Automate Dependency Updates |
| `SC-Fuzzing` | Integrate Fuzz Testing into the Build Pipeline |
| `SC-License` | Include a Machine-Readable License in the Repository |
| `SC-Pinned-Dependencies` | Pin All CI/CD Action and Dependency Versions to Hashes |
| `SC-SAST` | Run Static Analysis Security Testing in CI |
| `SC-Security-Policy` | Publish a SECURITY.md with Vulnerability Reporting Instructions |
| `SC-Signed-Releases` | Cryptographically Sign All Release Artifacts |
| `SC-Token-Permissions` | Minimize GitHub Token Permissions in Workflows |
| `SC-Vulnerabilities` | Remediate Open Vulnerabilities in a Timely Manner |
## Policy templates
Written for OpenSSF:
* Repository Security Baseline Policy (OpenSSF Scorecard)
* Secure Dependency Management Policy (OpenSSF)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to OpenSSF.
# OWASP ASVS (/docs/frameworks/international/owasp-asvs)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Application Security Verification Standard V14: dependency inventory, version verification, integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ASVS |
| Region | International |
| Country or scope | International |
| Sector | Application Security |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ASVS
* **Scan requirements:** 4, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for ASVS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for ASVS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 4 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------- | -------------------------------------------------- | ---------- |
| `ASVS-V2` Authentication Components | ASVS V2 requires documented authentication | Scan |
| `ASVS-V3` Session Management | ASVS V3 requires secure session management | Scan |
| `ASVS-V4` Access Control Components | ASVS V4 requires access control documentation | Scan |
| `ASVS-V6` Cryptographic Algorithm Audit | ASVS V6 requires approved cryptographic algorithms | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ---------------------------------------------- |
| `ASVS-V1.1.2` | Document and Review Application Architecture |
| `ASVS-V2.1.1` | Enforce Minimum Password Length and Complexity |
| `ASVS-V2.2.1` | Require MFA for High-Value Accounts |
| `ASVS-V3.2.1` | Generate Secure Session Tokens |
| `ASVS-V4.1.1` | Enforce Server-Side Access Control |
| `ASVS-V5.1.1` | Validate All Input Against an Allowlist |
| `ASVS-V7.1.1` | Do Not Log Sensitive Data |
| `ASVS-V8.1.1` | Classify and Label Sensitive Data |
| `ASVS-V9.1.1` | Enforce TLS for All Communications |
| `ASVS-V10.2.1` | Scan for Malicious Code and Backdoors |
| `ASVS-V13.1.1` | Authenticate and Authorize All API Requests |
| `ASVS-V14.2.1` | Pin and Verify Dependency Versions |
## Policy templates
Written for ASVS:
* Application Security Verification Requirements Policy (ASVS L2)
* Data Protection and Cryptography Policy (ASVS V8/V2)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ASVS.
# OWASP CycloneDX BOM (/docs/frameworks/international/owasp-cyclonedx-bom)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
CycloneDX BOM Standard: format compliance, inventory completeness, PURL, hash, license data.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CDX BOM |
| Region | International |
| Country or scope | International |
| Sector | Application Security |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CDX BOM
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for CDX BOM.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for CDX BOM and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CDX-FORMAT` Machine-Readable BOM Format | The BOM must be expressed in a conformant machine-readable format such as CycloneDX or SPDX rather than free-form documentation (CycloneDX specification / ECMA-424, format conformance) | Scan |
| `CDX-META` BOM Metadata and Serial Number | A BOM should carry a unique serial number and creation timestamp in its metadata so document instances can be distinguished and versioned (CycloneDX 'serialNumber' and 'metadata.timestamp' fields) | Scan |
| `CDX-TOOLS` BOM Creator Recorded | The metadata should record the tools or organization that created the BOM, providing provenance for the document itself (CycloneDX 'metadata.tools' / 'metadata.authors' fields) | Scan |
| `CDX-PURL` Package URL Identity | Components should be identified with Package URLs so they can be located and cross-referenced across ecosystems (CycloneDX component 'purl' field) | Scan |
| `CDX-HASH` Component Hashes | Components should include cryptographic hashes enabling integrity verification of the described artifacts (CycloneDX component 'hashes' field) | Scan |
| `CDX-LIC` Component License Data | Components should declare their licenses using SPDX expressions or license objects (CycloneDX component 'licenses' field) | Scan |
| `CDX-DEPS` Dependency Relationships | The BOM should describe the dependency graph relating components to one another and to the root component (CycloneDX 'dependencies' element) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ---------------------------------------------- |
| `CDX-BOM-1` | Include Required BOM Metadata Fields |
| `CDX-BOM-2` | Declare Component Type and Scope |
| `CDX-BOM-3` | Include PURL and CPE for Components |
| `CDX-BOM-4` | Record Component Cryptographic Hashes |
| `CDX-BOM-5` | Declare Dependency Relationships |
| `CDX-BOM-6` | Include License Information for All Components |
| `CDX-BOM-7` | Document External Services in BOM |
| `CDX-BOM-8` | Attach Vulnerability Assertions via VEX |
| `CDX-BOM-9` | Capture Build Formulation in BOM |
| `CDX-BOM-10` | Sign and Verify BOM Documents |
## Policy templates
Written for CDX BOM:
* CycloneDX BOM Authoring and Validation Policy
* Build Formulation and Reproducibility Policy (CycloneDX)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CDX BOM.
# OWASP MASVS (/docs/frameworks/international/owasp-masvs)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Mobile Application Security Verification Standard: component inventory, third-party tracking.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | MASVS |
| Region | International |
| Country or scope | International |
| Sector | Application Security |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers MASVS
* **Scan requirements:** 5: 4 decided by a scan, 1 that needs evidence or an attestation.
* **Controls:** the scan requirements below, plus 6 controls from Safeguard's control catalog for MASVS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for MASVS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
* **Scan:** the scan decides whether the requirement is met.
* **Evidence:** a scan cannot see what the requirement asks for. It passes when a person attests it with evidence.
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MASVS-NOT-ASSESSED` OWASP MASVS was not assessed | The requirements below are inferred from SBOM component names, not from testing the application. They are a dependency inventory and must NOT be presented as MASVS conformance evidence. | Evidence |
| `MASVS-STORAGE-1` Secure Storage Components | MASVS requires secure data storage components | Scan |
| `MASVS-CRYPTO-1` Cryptography Verification | MASVS requires strong cryptography | Scan |
| `MASVS-AUTH-1` Authentication Components | MASVS requires secure authentication libraries | Scan |
| `MASVS-NETWORK-1` Network Security Components | MASVS requires secure network communication | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------------- | ----------------------------------------------------- |
| `MASVS-STORAGE-2` | Prevent Sensitive Data Exposure via Backup Mechanisms |
| `MASVS-PLATFORM-1` | Restrict WebView Capabilities |
| `MASVS-CODE-1` | Remove Debug Code and Logging from Release Builds |
| `MASVS-RESILIENCE-1` | Detect and Respond to Runtime Tampering |
| `MASVS-PRIVACY-1` | Minimize Personal Data Collection on Mobile |
| `MASVS-PRIVACY-2` | Provide User Controls for Personal Data |
## Policy templates
Written for MASVS:
* Mobile Application Security Policy (OWASP MASVS)
* Mobile Application Tamper Resistance and Resilience Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MASVS.
# OWASP SCVS (/docs/frameworks/international/owasp-scvs)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Software Component Verification Standard: inventory, identity, provenance, vulnerability disclosure.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | International |
| Country or scope | International |
| Sector | Application Security |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers OWASP SCVS
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 15 controls from Safeguard's control catalog for OWASP SCVS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for OWASP SCVS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SCVS-V1-INV` Complete Component Inventory | All direct and transitive components and their versions must be known and inventoried at all times (OWASP SCVS V1, Inventory control family) | Scan |
| `SCVS-V1-VER` Versions For All Components | The inventory must capture the version of every component so risk can be assessed per release (OWASP SCVS V1) | Scan |
| `SCVS-V2-FMT` Machine-Readable SBOM | SBOMs must be produced in a standardized, machine-readable format (e.g. CycloneDX or SPDX) with automation in the build pipeline (OWASP SCVS V2, SBOM control family) | Scan |
| `SCVS-V2-ID` Unique SBOM and Component Identity | SBOMs must have unique identifiers and timestamps, and components must be referenced by ecosystem-native identifiers such as PURL (OWASP SCVS V2) | Scan |
| `SCVS-V2-PURL` Standard Component Identifiers | Components in the SBOM must carry accurate, standard identifiers so they can be resolved and analyzed automatically (OWASP SCVS V2) | Scan |
| `SCVS-V5-VULN` Component Vulnerability Analysis | Components must be analyzed for known vulnerabilities, requiring identifiers that map to vulnerability databases (OWASP SCVS V5, Component Analysis control family) | Scan |
| `SCVS-V6-PROV` Pedigree and Provenance | The provenance of components: who supplied them and how the SBOM was produced, must be knowable and documented (OWASP SCVS V6, Pedigree and Provenance control family) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | ------------------------------------------------------------- |
| `SCVS-1.1` | Maintain a Complete Component Inventory |
| `SCVS-1.2` | Inventory Includes Transitive Dependencies |
| `SCVS-1.3` | Track Component Origins and Download Locations |
| `SCVS-1.4` | Identify and Remediate Unused Components |
| `SCVS-1.5` | Record Internal Components in Inventory |
| `SCVS-2.1` | Assign Package URLs (PURL) to Components |
| `SCVS-2.4` | Include CPE Identifiers Where Available |
| `SCVS-2.8` | Record Cryptographic Hashes for Components |
| `SCVS-3.1` | Continuously Monitor Components for Known Vulnerabilities |
| `SCVS-3.2` | Subscribe to Vulnerability Advisories for Critical Components |
| `SCVS-4.1` | Verify Component Authenticity via Signatures |
| `SCVS-4.3` | Document Component Acquisition Process |
| `SCVS-5.1` | Record Component Modification History (Pedigree) |
| `SCVS-6.1` | Identify and Track Open-Source License Obligations |
| `SCVS-6.2` | Automate License Compliance Scanning |
## Policy templates
Written for OWASP SCVS:
* SBOM Management Policy (OWASP SCVS)
* Open-Source Component Governance Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to OWASP SCVS.
# OWASP Top 10 (/docs/frameworks/international/owasp-top10)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Supply chain and component risk categories: outdated components, integrity, broken access control.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | OWASP |
| Region | International |
| Country or scope | International |
| Sector | Application Security |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers OWASP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 30 controls from Safeguard's control catalog for OWASP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for OWASP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `OWASP-A06-INV` Know Your Components | Avoiding vulnerable and outdated components starts with an inventory of all client-side and server-side components in use (OWASP Top 10 2021, A06) | Scan |
| `OWASP-A06-VER` Component Versions Known | You are likely vulnerable if you do not know the versions of all components and nested dependencies you use (OWASP Top 10 2021, A06) | Scan |
| `OWASP-A06-SCAN` Continuous Vulnerability Matching | Components must be continuously checked against sources like CVE and NVD, which requires standard identifiers (PURL/CPE) on each component (OWASP Top 10 2021, A06 prevention guidance) | Scan |
| `OWASP-A06-DEPS` Nested Dependency Visibility | A06 explicitly covers direct and nested dependencies, so the dependency relationships among components must be documented (OWASP Top 10 2021, A06) | Scan |
| `OWASP-A08-INT` Software Integrity Verification | Software and data integrity failures arise when code from untrusted sources is consumed without integrity verification; components should carry hashes enabling digital verification (OWASP Top 10 2021, A08) | Scan |
| `OWASP-A08-SRC` Trusted Component Sources | Consuming libraries only from trusted sources and repositories requires knowing the supplier of each component (OWASP Top 10 2021, A08 prevention guidance) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ---------------------------------------------------- |
| `A01:2021-1` | Enforce Least-Privilege Access Control |
| `A01:2021-2` | Prevent Insecure Direct Object References |
| `A01:2021-3` | Enforce CORS Policy and Path Traversal Protections |
| `A02:2021-1` | Prohibit Weak or Deprecated Cryptographic Algorithms |
| `A02:2021-2` | Encrypt Data at Rest and in Transit |
| `A02:2021-3` | Manage Cryptographic Key Lifecycle |
| `A03:2021-1` | Prevent SQL and NoSQL Injection |
| `A03:2021-2` | Prevent OS Command and LDAP Injection |
| `A03:2021-3` | Prevent Cross-Site Scripting (XSS) |
| `A04:2021-1` | Conduct Threat Modeling During Design |
| `A04:2021-2` | Enforce Security Design Patterns |
| `A04:2021-3` | Implement Rate Limiting and Anti-Automation |
| `A05:2021-1` | Harden Default Security Configurations |
| `A05:2021-2` | Set Secure HTTP Security Headers |
| `A05:2021-3` | Manage Cloud Storage and Service Permissions |
| `A06:2021-1` | Maintain a Software Bill of Materials (SBOM) |
| `A06:2021-2` | Scan Dependencies for Known Vulnerabilities |
| `A06:2021-3` | Define Patch and Upgrade SLAs |
| `A07:2021-1` | Enforce Multi-Factor Authentication |
| `A07:2021-2` | Implement Secure Session Management |
| `A07:2021-3` | Prevent Credential Enumeration and Stuffing |
| `A08:2021-1` | Verify Software Integrity via Digital Signatures |
| `A08:2021-2` | Protect CI/CD Pipeline Integrity |
| `A08:2021-3` | Validate Deserialization of Untrusted Data |
| `A09:2021-1` | Log Security-Relevant Events with Sufficient Detail |
| `A09:2021-2` | Centralize and Protect Log Storage |
| `A09:2021-3` | Define and Test Alerting Thresholds |
| `A10:2021-1` | Validate and Sanitize Server-Side Request Targets |
| `A10:2021-2` | Enforce Network Segmentation for Outbound Traffic |
| `A10:2021-3` | Disable Unnecessary URL Schemes in HTTP Clients |
## Policy templates
Written for OWASP:
* Application Security Policy (OWASP Top 10)
* Secure Software Development Lifecycle Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to OWASP.
# PCI DSS 4.0 (Full) (/docs/frameworks/international/pci-dss-4)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
SBOM maintenance (6.3.2), third-party component tracking (6.3.3), vulnerability management.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | PCI 4.0 |
| Region | International |
| Country or scope | International |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers PCI 4.0
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for PCI 4.0.
* **Automated tests:** none map to it directly. Evidence from the frameworks the crosswalk relates it to counts toward its controls where a reviewed or approved equivalent row links them ([the crosswalk](/docs/framework-connectors#through-the-crosswalk)).
* **Policy templates:** 25: 3 written for PCI 4.0 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `PCI4-6-3-2` Maintained Component Inventory (SBOM) | Bespoke and custom software must have a maintained inventory of incorporated third-party components: effectively an SBOM, kept current across releases (PCI DSS v4.0 Req. 6.3.2) | Scan |
| `PCI4-6-3-2-FMT` Automatable Inventory Format | To support continuous vulnerability management at scale, the component inventory should be produced in a standardized machine-readable SBOM format (PCI DSS v4.0 Req. 6.3.2 good-practice guidance) | Scan |
| `PCI4-6-4-3` Payment Script Integrity | Scripts loaded and executed on payment pages must be managed with integrity assurance and an inventory with written justification; at SBOM level this maps to integrity hashes on components (PCI DSS v4.0 Req. 6.4.3) | Scan |
| `PCI4-6-3-1` Continuous Vulnerability Identification | New vulnerabilities affecting the software and its third-party components must be identified from industry sources, requiring resolvable identifiers per component (PCI DSS v4.0 Req. 6.3.1) | Scan |
| `PCI4-6-5-1` Change-Controlled Versions | Changes to system components must follow documented change control, requiring precise, unambiguous version identification of components rather than floating references (PCI DSS v4.0 Req. 6.5.1) | Scan |
| `PCI4-12-8-1` Third-Party Component Tracking | Relationships with third-party providers of software incorporated into the cardholder data environment must be tracked, requiring the supplier of each component to be recorded (PCI DSS v4.0 Req. 12.8.1) | Scan |
| `PCI4-6-3-3` Patch Applicability Data | Critical patches must be installed within one month of release, which requires current version data on all components to establish applicability (PCI DSS v4.0 Req. 6.3.3) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | --------------------------------------------------------------- |
| `6.3.2` | SBOM for All Software in CDE |
| `6.3.3` | Third-Party Software Component Patch Management |
| `12.3.4` | Hardware and Software Technologies Review |
| `8.6` | System and Application Accounts Management |
| `4.2.1` | Strong Cryptography for PAN in Transit |
| `10.7` | Failures of Critical Security Controls Detected and Reported |
| `11.6.1` | Change and Tamper Detection for Payment Pages |
| `3.7.1` | Cryptographic Key Management Policy |
| `5.4` | Phishing-Resistant Authentication |
| `2.3.2` | Wireless Environment Security |
| `1.5.1` | Security Controls on Any Devices Connecting to Internet and CDE |
| `12.9` | Third-Party Service Provider (TPSP) Security Obligations |
| `7.3.2` | All User Access Controlled by Access Control System |
| `12.6` | Security Awareness Education |
## Policy templates
Written for PCI 4.0:
* PCI DSS 4.0 Customised Approach Implementation Policy
* E-Commerce Payment Page Security Policy
* Targeted Risk Analysis Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PCI 4.0.
# PCI DSS v4.0 (/docs/frameworks/international/pci-dss)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Payment card industry software security: component inventory, vulnerability identification, integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | PCI DSS |
| Region | International |
| Country or scope | International |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers PCI DSS
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 19 controls from Safeguard's control catalog for PCI DSS.
* **Automated tests:** 658 map to its controls, and 343 connectors provide automated evidence for them. See [PCI DSS and connectors](/docs/framework-connectors/pci-dss).
* **Policy templates:** 26: 4 written for PCI DSS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `PCI-6-3-2` Software Component Inventory | An inventory of bespoke and custom software, including third-party components incorporated into it, must be maintained to support vulnerability and patch management (PCI DSS v4.0 Req. 6.3.2) | Scan |
| `PCI-6-3-1` Vulnerability Identification | Security vulnerabilities in software must be identified using industry-recognized sources and ranked by risk, which requires components to carry identifiers resolvable against those sources (PCI DSS v4.0 Req. 6.3.1) | Scan |
| `PCI-6-3-3` Patch Currency | Applicable security patches must be identified and installed within defined timeframes, which requires the exact version of every component to determine patch applicability (PCI DSS v4.0 Req. 6.3.3) | Scan |
| `PCI-6-2-4` Software Integrity Protections | Software engineering practice must prevent and detect tampering of software, supported by integrity hashes for the components composing payment software (PCI DSS v4.0 Req. 6.2.4 secure software engineering techniques) | Scan |
| `PCI-12-8-1` Third-Party Provider Accountability | A list of third-party service providers and software suppliers with which account data or its processing environment is shared must be maintained, requiring supplier identity per component (PCI DSS v4.0 Req. 12.8.1, applied to software supply chain) | Scan |
| `PCI-6-3-2-DOC` Inventory Completeness | The 6.3.2 inventory is only usable for vulnerability management when each listed component records both its name and version (PCI DSS v4.0 Req. 6.3.2 guidance) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | -------------------------------------------------------------- |
| `1.1` | Network Security Controls: Processes and Mechanisms |
| `1.3` | Restrict Inbound and Outbound Traffic to CDE |
| `2.2` | System Components Configuration Standards |
| `3.3` | Sensitive Authentication Data Not Retained After Authorisation |
| `3.5` | Primary Account Number (PAN) Security |
| `4.2` | PAN Secured During Transmission |
| `5.2` | Malware Protection Mechanisms |
| `6.2` | Bespoke and Custom Software Security |
| `6.3.2` | Software Bill of Materials (SBOM) Maintenance |
| `6.3.3` | Software Component Vulnerability Tracking |
| `7.2` | Access Control System Implementation |
| `8.3` | User Authentication for Strong Authentication |
| `10.2` | Audit Log Implementation |
| `10.5` | Audit Log Retention and Protection |
| `11.3` | External and Internal Vulnerability Scans |
| `11.4` | External and Internal Penetration Testing |
| `12.3` | Risk Assessment and Targeted Risk Analysis |
| `12.10` | Incident Response Plan |
| `12.6` | Security Awareness Education |
## Policy templates
Written for PCI DSS:
* Cardholder Data Environment (CDE) Scoping Policy
* Software Bill of Materials (SBOM) Policy for PCI DSS
* Payment Security Incident Response Plan
* CDE Access Control and Privileged Access Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PCI DSS.
# SLSA Supply Chain (/docs/frameworks/international/slsa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Supply-chain Levels for Software Artifacts: provenance, integrity, supply chain security (L1-L4).
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SLSA |
| Region | International |
| Country or scope | International |
| Sector | Supply Chain |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SLSA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for SLSA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for SLSA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SLSA-L1-PROV` Provenance Exists | Build Level 1 requires that provenance is generated describing how the artifact was built, including the identity of the builder or tooling (SLSA v1.0 Build L1: provenance exists) | Scan |
| `SLSA-PROV-FMT` Machine-Readable Attestation | SLSA provenance and related supply chain documents must be machine-readable so verification can be automated; SBOM equivalents are SPDX or CycloneDX documents (SLSA v1.0 provenance format requirements) | Scan |
| `SLSA-DIGEST` Artifact Digests | Provenance must identify output artifacts by cryptographic digest, so components in the accompanying inventory must carry integrity hashes (SLSA v1.0 provenance schema: subject digests) | Scan |
| `SLSA-DEPS` Resolved Dependencies Recorded | Higher-fidelity provenance records the dependencies resolved during the build, which maps to a documented dependency graph in the SBOM (SLSA v1.0 provenance: resolvedDependencies) | Scan |
| `SLSA-ID` Unambiguous Artifact Identity | Verifying an artifact against provenance requires an unambiguous identity for each component, i.e. a standard identifier such as a PURL (SLSA v1.0 verification model) | Scan |
| `SLSA-PIN` Pinned, Specific Versions | Tamper-resistant builds require inputs pinned to specific immutable versions rather than floating references like 'latest' (SLSA v1.0 build integrity principles) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | --------------------------------------------------------- |
| `SLSA-SRC-L1` | Store All Source Code in Version Control |
| `SLSA-SRC-L2` | Maintain Verified Commit History |
| `SLSA-SRC-L3` | Require Two-Person Review for Protected Branch Changes |
| `SLSA-BUILD-L1` | Use Scripted, Automated Build Process |
| `SLSA-BUILD-L2` | Run Builds in Isolated Environments |
| `SLSA-BUILD-L3` | Enforce Hermetic and Parameterless Builds |
| `SLSA-PROV-L1` | Generate Build Provenance for Every Artifact |
| `SLSA-PROV-L2` | Authenticate Provenance via Service-Generated Attestation |
| `SLSA-PROV-L3` | Ensure Provenance is Non-Falsifiable |
| `SLSA-COMMON-1` | Apply Security Practices to Build Infrastructure |
| `SLSA-COMMON-2` | Restrict Access to Build Secrets and Signing Keys |
## Policy templates
Written for SLSA:
* SLSA Build Provenance Policy
* CI/CD Pipeline Security and Integrity Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SLSA.
# SWIFT CSCF (/docs/frameworks/international/swift-cscf)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Customer Security Controls Framework: component inventory, integrity hashes, supplier verification.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SWIFT |
| Region | International |
| Country or scope | International |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SWIFT
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 19 controls from Safeguard's control catalog for SWIFT.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for SWIFT and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SWIFT-INV` SWIFT Environment Component Knowledge | Protecting and scoping the SWIFT secure zone requires knowing all software components deployed within it, i.e. a maintained component inventory (SWIFT CSCF Control 1.1, SWIFT Environment Protection: scope identification) | Scan |
| `SWIFT-2-2` Security Updates | Mandatory security updates must be applied promptly to SWIFT-related components, which requires current version data to establish update applicability (SWIFT CSCF Control 2.2, Security Updates) | Scan |
| `SWIFT-6-2` Software Integrity | The integrity of SWIFT-related software must be verified against known-good references, requiring integrity hashes for deployed components (SWIFT CSCF Control 6.2, Software Integrity) | Scan |
| `SWIFT-2-7` Vulnerability Scanning | Regular vulnerability scanning of the SWIFT environment requires components identifiable against vulnerability databases (SWIFT CSCF Control 2.7, Vulnerability Scanning) | Scan |
| `SWIFT-SUP` Supplier / Provider Verification | Reliance on vendors and outsourced providers for SWIFT infrastructure requires knowing the supplier of each software component so provider assurance can be obtained (SWIFT CSCF outsourcing/provider assurance provisions) | Scan |
| `SWIFT-ATTEST` Attestation Evidence | Annual attestation via the KYC Security Attestation process requires dated, identifiable evidence of the environment's software composition (SWIFT Customer Security Programme attestation requirement) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | ---------------------------------------------- |
| `1.1` | SWIFT Environment Protection: Secure Zone |
| `1.2` | Operating System Privileged Account Control |
| `1.3` | Virtualisation Platform Security |
| `1.4` | Restriction of Internet Access |
| `2.1` | Internal Data Flow Security |
| `2.2` | Security Updates |
| `2.3` | System Hardening |
| `2.5` | External Transmission Data Protection |
| `2.6` | Operator Session Confidentiality and Integrity |
| `2.9` | Transaction Business Controls |
| `2.11` | RMA Business Controls |
| `4.1` | Password Policy |
| `5.1` | Logical Access Controls |
| `5.2` | Token Management |
| `5.4` | Physical and Logical Password Storage |
| `6.1` | Malware Protection |
| `6.5` | Intrusion Detection |
| `7.1` | Cyber Incident Response Planning |
| `7.4` | Penetration Testing |
## Policy templates
Written for SWIFT:
* SWIFT Local Operating Environment Security Policy
* SWIFT Transaction Security and Anomaly Detection Policy
* SWIFT Environment Software Integrity and Patch Management Policy
* SWIFT Cybersecurity Incident Response Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SWIFT.
# UNECE WP.29 (/docs/frameworks/international/unece-wp29)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
UN vehicle cybersecurity: software update management, risk assessment, ECU integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | WP.29 |
| Region | International |
| Country or scope | International |
| Sector | Automotive |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers WP.29
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 13 controls from Safeguard's control catalog for WP.29.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for WP.29 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `WP29-R156-SWID` Software Identification (RXSWIN) | Manufacturers must be able to identify the software relevant to type approval on each vehicle type, including component versions underlying the declared RXSWIN (UN R156 software identification requirements) | Scan |
| `WP29-R156-INV` Software Composition Knowledge | A Software Update Management System must know what software is installed and updatable on vehicle systems, which requires a component inventory per software build (UN R156 SUMS requirements) | Scan |
| `WP29-R156-INT` Update Integrity | Software updates must be protected so their integrity can be verified before installation on ECUs, requiring integrity hashes for delivered software components (UN R156 update integrity/authenticity requirements) | Scan |
| `WP29-R155-RISK` CSMS Risk Assessment of Components | The CSMS must identify and assess cybersecurity risks across the vehicle lifecycle, including risks from third-party and open source software, requiring identifiable components for threat matching (UN R155 §7.2.2 CSMS process requirements) | Scan |
| `WP29-R155-SUPPLY` Supply Chain Risk Management | Manufacturers must manage cybersecurity risks arising from their supply chain, including contracted suppliers, which requires supplier attribution for software components (UN R155 CSMS supplier-related requirements) | Scan |
| `WP29-R155-MON` Post-Production Vulnerability Monitoring | Manufacturers must monitor for new threats and vulnerabilities affecting vehicles in the field and respond, requiring versioned components to determine affected fleets (UN R155 §7.2.2 monitoring and response obligations) | Scan |
| `WP29-DOC` Type-Approval Documentation | Type approval requires documentation demonstrating CSMS/SUMS operation to the approval authority; dated, identifiable software composition records support this evidence (UN R155/R156 documentation requirements for approval authorities) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | -------------------------------------------------- |
| `4.3.1` | Cyber Security Management System (CSMS) |
| `4.3.2` | CSMS Risk-Based Approach |
| `4.3.3` | Organisational Roles and Responsibilities for CSMS |
| `4.3.4` | Supply Chain Management for Cybersecurity |
| `4.3.5` | Post-Production Cybersecurity Monitoring |
| `4.3.6` | Cybersecurity Incident Response |
| `4.3.7` | CSMS Audit and Improvement |
| `5.1.1` | Vehicle Type Cybersecurity Risk Assessment |
| `5.1.2` | Vehicle Type Cybersecurity Testing |
| `5.3.1` | Software Update Management System |
| `5.4.1` | Cryptographic Module Controls |
| `5.4.2` | External Connectivity Protection |
| `5.4.3` | Vehicle Data Integrity and Protection |
## Policy templates
Written for WP.29:
* Vehicle Cyber Security Management System (CSMS) Policy
* Vehicle Software Supply Chain Security Policy
* Vehicle Cybersecurity Incident Response and SUMS Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to WP.29.
# Anguilla Data Protection Act 2020 (/docs/frameworks/americas/anguilla-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AI DPA 2020 |
| Region | Americas |
| Country or scope | Anguilla |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AI DPA 2020
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AI-ETA-31` Data Protection in Electronic Transactions | Personal data handled in electronic transactions must be protected against unlawful use and alteration, including verifiable integrity of the software components involved (Electronic Transactions Act, R.S.A. c. E38, s. 31) | Scan |
| `AI-ETA-32` Pseudonymous Identification | The Act's recognition of pseudonyms in electronic dealings presumes systems can nonetheless precisely identify the components that process identity data (Electronic Transactions Act, R.S.A. c. E38, s. 32) | Scan |
| `AI-CONST-PRIV` Processing System Inventory | Constitutional privacy protection presumes entities can account for the systems and software through which personal information is processed (Constitution of Anguilla, fundamental rights provisions) | Scan |
| `AI-ETA-VER` Maintained Transaction Software | Reliable and secure electronic transactions require the underlying software to be version-tracked so weaknesses can be assessed and remedied (Electronic Transactions Act, R.S.A. c. E38, electronic-transactions integrity framework) | Scan |
| `AI-DOC` Documented Data-Handling Systems | Data-protection duties in electronic commerce presume identifiable, timestamped documentation of the systems handling personal data (Electronic Transactions Act, R.S.A. c. E38, Part 8) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AI DPA 2020.
# Antigua and Barbuda Data Protection Act 2013 (/docs/frameworks/americas/antigua-barbuda-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AG DPA |
| Region | Americas |
| Country or scope | Antigua and Barbuda |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AG DPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AG-DPA-SEC` Security Principle | Data users must take practical steps to protect personal data from loss, misuse, modification, or unauthorized access, including integrity protection of processing systems (DPA 2013, security principle) | Scan |
| `AG-DPA-INTG` Data Integrity Principle | Personal data must be accurate, complete, not misleading, and kept up to date, requiring version tracking of the software maintaining it (DPA 2013, data-integrity principle) | Scan |
| `AG-DPA-PROC` Processing by Data Processors | Where processing is carried out by a processor on the data user's behalf, the user must ensure equivalent safeguards, so processing-component suppliers must be identified (DPA 2013, data-processor provision) | Scan |
| `AG-DPA-INV` Accountability for Processing Systems | Compliance with the principles for all processing under the data user's control presupposes an inventory of the systems and components involved (DPA 2013, data-user obligations) | Scan |
| `AG-DPA-DOC` Notice and Documentation | The general notice duty implies documented, identifiable records of the processing environment (DPA 2013, notice-and-choice principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AG DPA.
# Argentina PDPL (Law 25.326) (/docs/frameworks/americas/argentina-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Argentina Personal Data Protection Law - registration, data subject rights, cross-border transfers.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | AR PDPL |
| Region | Americas |
| Country or scope | Argentina |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers AR PDPL
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for AR PDPL.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for AR PDPL and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AR-PDPL-9` Data Security | Controllers must adopt technical and organizational measures guaranteeing the security and integrity of personal data, and may not record data in databases that do not meet technical integrity and security conditions; integrity hashes across the software inventory evidence this (Law 25.326 Art. 9) | Scan |
| `AR-PDPL-4` Data Quality | Data must be accurate, adequate and up to date for its purpose; the same quality discipline applied to the processing environment requires every component to carry a complete name and version (Law 25.326 Art. 4) | Scan |
| `AR-PDPL-21` Database Registration | Data files and databases must be registered with the supervisory registry, including identification of the file and its characteristics; a uniquely identified, timestamped SBOM supports this registration duty (Law 25.326 Art. 21) | Scan |
| `AR-PDPL-25` Third-Party Processing Services | When processing is outsourced to a service provider, duties and responsibilities must be contractually fixed, which presupposes knowing which suppliers stand behind the software used in processing (Law 25.326 Art. 25) | Scan |
| `AR-PDPL-12` International Transfer Readiness | Transfers to countries without adequate protection are restricted; determining what data flows where requires that the components performing processing be precisely identifiable (Law 25.326 Art. 12) | Scan |
| `AR-PDPL-10` Duty of Confidentiality | Persons involved in processing are bound by professional secrecy; accountability for who built and handles the processing tooling requires recorded creator provenance (Law 25.326 Art. 10) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ------------------------------------------ |
| `PDPL-Art4` | Calidad de los Datos (Art. 4) |
| `PDPL-Art5` | Consentimiento (Art. 5) |
| `PDPL-Art9` | Seguridad de los Datos (Art. 9) |
| `PDPL-Art11` | Transferencia Internacional (Art. 11) |
| `PDPL-Art13` | Derecho de Acceso (Art. 13) |
| `PDPL-Art14` | Derecho de Rectificación (Art. 14) |
| `PDPL-Art21` | Registro de Bases de Datos (Art. 21) |
| `PDPL-DS-01` | Datos Sensibles: Prohibición y Excepciones |
| `PDPL-EN-01` | Confidencialidad del Responsable |
| `PDPL-CE-01` | Cesión de Datos entre Responsables |
## Policy templates
Written for AR PDPL:
* Política de Transferencia Internacional de Datos Personales: LATAM
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AR PDPL.
# Aruba Personal Data Protection Ordinance (/docs/frameworks/americas/aruba-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AW PDP Ord |
| Region | Americas |
| Country or scope | Aruba |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AW PDP Ord
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AW-LVP-8` Security of Personal Data Registrations | The controller must implement appropriate technical and organizational measures to secure personal data against loss and against unauthorized access, change or transmission, including integrity verification of the software involved (Landsverordening persoonsregistratie, art. 8) | Scan |
| `AW-LVP-PURP` Purpose-Bound Registration | Personal data may only be collected and processed for specific legitimate purposes consistent with the registration, presupposing fully described data-handling components (Landsverordening persoonsregistratie, purpose-limitation provisions) | Scan |
| `AW-LVP-3P` Third-Party Disclosure Control | Disclosure to third parties is permitted only when necessary for the original purpose, required by law or explicitly consented to, requiring supplier visibility for third-party components handling registered data (Landsverordening persoonsregistratie, third-party disclosure provisions) | Scan |
| `AW-LVP-REG` Registration System Inventory | Holders of personal-data registrations must be able to account for the systems and software constituting each registration (Landsverordening persoonsregistratie, registration and holder obligations) | Scan |
| `AW-LVP-DOC` Documented Registrations | Transparency toward data subjects about recorded data presumes identifiable, timestamped documentation of the processing systems (Landsverordening persoonsregistratie, transparency and access provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AW PDP Ord.
# Bahamas Data Protection Act 2003 (/docs/frameworks/americas/bahamas-dppa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BS DPA |
| Region | Americas |
| Country or scope | Bahamas |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BS DPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BS-DPA-SEC` Appropriate Security Measures | Data controllers must take appropriate security measures against unauthorized access to, alteration, or destruction of personal data held in their systems (DP(PPI)A 2003, controller security duty) | Scan |
| `BS-DPA-ACC` Accuracy and Currency of Data | Personal data must be accurate and, where necessary, kept up to date, requiring version tracking of the software maintaining records (DP(PPI)A 2003, accuracy duty) | Scan |
| `BS-DPA-INV` Knowledge of Held Data and Systems | A controller must know what personal data it keeps and for what purpose, presupposing an inventory of the processing software (DP(PPI)A 2003, controller duties) | Scan |
| `BS-DPA-PROC` Data Processor Safeguards | Processing carried out by data processors on a controller's behalf must be governed by equivalent safeguards, so processing-component suppliers must be identifiable (DP(PPI)A 2003, data-processor provisions) | Scan |
| `BS-DPA-DOC` Documented Processing Environment | Accountability to the Data Protection Commissioner requires a documented, identifiable record of the processing environment (DP(PPI)A 2003, Commissioner oversight) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BS DPA.
# Barbados Data Protection Act 2019 (/docs/frameworks/americas/barbados-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BB DPA |
| Region | Americas |
| Country or scope | Barbados |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BB DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BB-DPA-SEC` Security of Processing | Controllers and processors must implement appropriate technical and organizational measures to secure processing, including integrity of processing systems (DPA 2019, GDPR Art. 32-style security-of-processing obligation) | Scan |
| `BB-DPA-ROPA` Records of Processing Activities | Controllers must maintain records of processing activities, which presupposes an inventory of the software components involved in processing (DPA 2019, records-of-processing duty) | Scan |
| `BB-DPA-PROC` Processor Obligations | Processing on behalf of a controller requires binding contracts and sufficient guarantees, so third-party component suppliers must be identified (DPA 2019, processor-contract obligation) | Scan |
| `BB-DPA-BREACH` Breach Notification Readiness | Personal data breaches must be notified to the Commissioner, which requires the ability to identify exactly which components were affected (DPA 2019, breach-notification duty) | Scan |
| `BB-DPA-ACC` Accuracy Principle | Personal data must be accurate and kept up to date, requiring precise version tracking of the software maintaining it (DPA 2019, accuracy principle) | Scan |
| `BB-DPA-DOC` Accountability Documentation | The controller must be able to demonstrate compliance, met by an identifiable, timestamped machine-readable record of the processing environment (DPA 2019, accountability principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BB DPA.
# Belize Data Protection Act 2021 (/docs/frameworks/americas/belize-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BZ DPA 2021 |
| Region | Americas |
| Country or scope | Belize |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BZ DPA 2021
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BZ-DPA-SEC` Security of Processing | Controllers and processors must implement appropriate technical and organizational measures to protect personal data and the integrity of processing systems (DPA 2021, GDPR Art. 32-style security obligation) | Scan |
| `BZ-DPA-ROPA` Records of Processing | Controllers must be able to account for their processing activities, presupposing an inventory of the software components involved (DPA 2021, accountability/records duty) | Scan |
| `BZ-DPA-PROC` Processor Contracts and Guarantees | Processing on a controller's behalf requires binding contracts and sufficient guarantees, so third-party component suppliers must be identified (DPA 2021, processor obligations) | Scan |
| `BZ-DPA-BREACH` Breach Notification Readiness | Personal data breaches must be notified to the Commissioner, requiring the ability to pinpoint which components were affected (DPA 2021, breach-notification duty) | Scan |
| `BZ-DPA-ACC` Accuracy Principle | Personal data must be accurate and kept up to date, requiring precise version tracking of the software maintaining it (DPA 2021, accuracy principle) | Scan |
| `BZ-DPA-DOC` Demonstrable Compliance Documentation | The accountability principle requires demonstrable compliance via identifiable, timestamped documentation of the processing environment (DPA 2021, accountability principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BZ DPA 2021.
# Bermuda Personal Information Protection Act 2016 (/docs/frameworks/americas/bermuda-pipa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BM PIPA |
| Region | Americas |
| Country or scope | Bermuda |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BM PIPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BM-PIPA-13` Security Safeguards | Organisations must protect personal information with safeguards proportional to its sensitivity and the likely harm, including integrity protection of the systems holding it (PIPA 2016 s.13) | Scan |
| `BM-PIPA-14` Breach of Security Notification Readiness | Breaches of security likely to cause harm must be notified to the Privacy Commissioner and affected individuals, which requires identifying exactly which system components were affected (PIPA 2016 s.14) | Scan |
| `BM-PIPA-RESP` Organisational Responsibility | An organisation is responsible for the personal information in its custody and must designate a privacy officer, presupposing an inventory of the systems that use it (PIPA 2016, responsibility/privacy-officer provisions) | Scan |
| `BM-PIPA-TP` Third-Party and Overseas Processing | Using third parties or overseas transfers to process personal information requires comparable protection, so processing-component suppliers must be identified (PIPA 2016, third-party/overseas transfer provisions) | Scan |
| `BM-PIPA-INTG` Integrity of Personal Information | Personal information must be accurate and kept up to date as far as necessary for its purpose, requiring version tracking of the software maintaining it (PIPA 2016, integrity/accuracy provision) | Scan |
| `BM-PIPA-DOC` Privacy Notice and Documentation | Organisations must maintain clear, accessible documentation of their information practices, met by an identifiable, timestamped record of the processing environment (PIPA 2016, privacy-notice duty) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BM PIPA.
# Bolivia Supreme Decree 1793 (/docs/frameworks/americas/bolivia-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BO SD 1793 |
| Region | Americas |
| Country or scope | Bolivia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BO SD 1793
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BO-SD1793-SEC` Security of Digital Processing | Entities processing personal data in digital environments must apply technical measures preserving the confidentiality and integrity of the data and the systems processing it (SD 1793/2013, data-security provisions for digital services) | Scan |
| `BO-SD1793-INV` Inventory of Processing Systems | Responsibility for lawful digital processing presupposes knowing which software systems and components handle personal data (SD 1793/2013, responsibilities of digital-service providers) | Scan |
| `BO-SD1793-VER` Currency and Accuracy of Systems | The data-quality/truthfulness principle for digital processing requires tracking the exact versions of the software maintaining personal data (SD 1793/2013, data-processing principles) | Scan |
| `BO-SD1793-DOC` Verifiable Digital Documentation | The decree's digital-document and certification regime expects processing records to be identifiable, timestamped, and machine-verifiable (SD 1793/2013, digital-document provisions) | Scan |
| `BO-SD1793-SUP` Third-Party Service Accountability | Digital-service providers remain accountable for processing carried out through third parties, so component suppliers must be identified (SD 1793/2013, provider-responsibility provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BO SD 1793.
# Brazil LGPD (/docs/frameworks/americas/brazil-lgpd)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Lei Geral de Protecao de Dados: technical safeguards, processing activity records, supplier tracking.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | LGPD |
| Region | Americas |
| Country or scope | Brazil |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers LGPD
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for LGPD.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for LGPD and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BR-LGPD-46` Technical Security Measures | Processing agents must adopt technical and administrative measures able to protect personal data from unauthorised access and from accidental or unlawful destruction or alteration, which includes integrity verification of software components (LGPD Art. 46) | Scan |
| `BR-LGPD-37` Records of Processing Operations | Controllers and processors must keep records of the personal data processing operations they carry out, which presupposes an inventory of the software performing that processing (LGPD Art. 37) | Scan |
| `BR-LGPD-39` Processor Chain Accountability | Processors must carry out processing according to the controller's instructions, and the controller must verify compliance, requiring identification of the suppliers behind processing components (LGPD Arts. 39-42) | Scan |
| `BR-LGPD-48` Security Incident Notification Readiness | Controllers must notify the ANPD and data subjects of security incidents that may cause relevant risk or damage, which requires the ability to determine quickly which components and versions were affected (LGPD Art. 48) | Scan |
| `BR-LGPD-50` Governance and Good Practice Documentation | Good-practice and governance programmes must be demonstrable through documented, up-to-date records, met by SBOMs bearing a document identity and creation timestamp (LGPD Art. 50) | Scan |
| `BR-LGPD-6X` Accountability Principle - Provenance | The accountability principle requires agents to demonstrate the effective measures taken to comply, including who produced the compliance documentation itself (LGPD Art. 6(X)) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | ---------------------------------------------------------------------- |
| `LGPD-A6` | Process Personal Data According to Good Faith Principles |
| `LGPD-A7` | Establish a Lawful Basis for Processing Personal Data |
| `LGPD-A9` | Provide Clear Notice of Processing Activities |
| `LGPD-A11` | Obtain Explicit Consent for Sensitive Data Processing |
| `LGPD-A17` | Fulfil Data Subject Ownership Rights |
| `LGPD-A18` | Respond to Data Subject Rights Requests Within 15 Days |
| `LGPD-A37` | Maintain Records of Processing Activities |
| `LGPD-A38` | Conduct Data Protection Impact Assessments |
| `LGPD-A46` | Implement Proportionate Technical and Administrative Security Measures |
| `LGPD-A48` | Notify ANPD and Data Subjects of Security Incidents |
| `LGPD-A50` | Establish a Privacy Governance Programme |
| `LGPD-DPO` | Appoint a Data Protection Officer |
## Policy templates
Written for LGPD:
* Lawful Basis and Consent Management Policy (LGPD)
* Data Subject Rights Policy (LGPD)
* Security Incident Notification and DPIA Policy (LGPD)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LGPD.
# British Virgin Islands Data Protection Act 2021 (/docs/frameworks/americas/bvi-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | VG DPA 2021 |
| Region | Americas |
| Country or scope | British Virgin Islands |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers VG DPA 2021
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `VG-DPA-SEC` Security Measures | Data controllers must take practical steps to protect personal data from loss, misuse, modification or unauthorized access, including the ability to verify integrity of the processing software (Data Protection Act 2021, security principle) | Scan |
| `VG-DPA-PROC` Processor Guarantees | Where a processor processes data on a controller's behalf, the controller must obtain sufficient guarantees that reasonable technical and organizational measures are in place, requiring supplier visibility for third-party components (Data Protection Act 2021, processor provisions) | Scan |
| `VG-DPA-INT` Data Integrity | Personal data must be accurate, complete, not misleading and kept up to date, which requires knowing the exact version of every component that processes it (Data Protection Act 2021, data integrity principle) | Scan |
| `VG-DPA-PRIN` Protection Principles Compliance | Processing must comply with the Act's data-protection principles, presupposing fully described processing components with both name and version (Data Protection Act 2021, data protection principles) | Scan |
| `VG-DPA-ACC` Accountable Processing Inventory | Public and private bodies subject to the Act must be able to account for the systems and software through which they process personal data (Data Protection Act 2021, controller obligations) | Scan |
| `VG-DPA-TRA` Transparent, Documented Processing | Notice and transparency duties toward data subjects presume identifiable, timestamped documentation of processing systems (Data Protection Act 2021, notice and choice principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to VG DPA 2021.
# Canada CPPA (/docs/frameworks/americas/canada-cppa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Consumer Privacy Protection Act (Bill C-27) - replaces PIPEDA, data mobility, AIDA AI provisions.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CPPA |
| Region | Americas |
| Country or scope | Canada |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CPPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for CPPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for CPPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CA-CPPA-57` Security Safeguards | Organisations must protect personal information through physical, organisational and technological safeguards proportionate to its sensitivity, which for processing software includes verifiable integrity of components (CPPA s. 57, Bill C-27) | Scan |
| `CA-CPPA-58` Breach of Security Safeguards Reporting | Breaches of security safeguards creating a real risk of significant harm must be reported to the Privacy Commissioner and affected individuals, requiring the ability to identify exactly which components were compromised (CPPA s. 58, Bill C-27) | Scan |
| `CA-CPPA-9` Privacy Management Program | Organisations must implement and document a privacy management program covering the protection of personal information, supported by identifiable, timestamped documentation of processing systems (CPPA s. 9, Bill C-27) | Scan |
| `CA-CPPA-11` Service Provider Protection Equivalence | When transferring personal information to a service provider, the organisation must ensure substantially equivalent protection, which extends to knowing who supplies the software components in the processing chain (CPPA s. 11, Bill C-27) | Scan |
| `CA-CPPA-OPEN` Openness and Transparency | Organisations must make information about their policies and practices readily available in plain language, a transparency posture served by machine-readable, standardised documentation of processing systems (CPPA openness and transparency provisions, Bill C-27) | Scan |
| `CA-CPPA-KNOW` Accountability for Information Under Control | An organisation is accountable for personal information under its control, which presumes maintained knowledge of the systems and components that store and process it (CPPA accountability provisions, Bill C-27) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ------------------------------------------ |
| `CPPA-6` | Transparency & Privacy Notice |
| `CPPA-12` | Valid Consent |
| `CPPA-22` | Collection, Use & Disclosure Limitation |
| `CPPA-40` | Privacy Management Programme |
| `CPPA-50` | Individual Rights Fulfilment |
| `CPPA-66` | Breach of Security Safeguards |
| `CPPA-84` | AIDA: AI System Accountability |
| `CPPA-85` | AIDA: AI Risk Mitigation Measures |
| `CPPA-86` | AIDA: Anomalous Impact Monitoring |
| `CPPA-87` | AIDA: Publication of AI System Information |
## Policy templates
Written for CPPA:
* Canada CPPA Privacy Management Programme
* Canada AIDA AI Impact Assessment Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CPPA.
# Canada PIPEDA (/docs/frameworks/americas/canada-pipeda)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Safeguards, accountability, supplier verification for personal data processing software.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | PIPEDA |
| Region | Americas |
| Country or scope | Canada |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers PIPEDA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for PIPEDA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for PIPEDA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CA-PIPEDA-4.7` Safeguards Principle | Personal information must be protected by security safeguards appropriate to its sensitivity, including technological measures that preserve the integrity of processing software (PIPEDA Schedule 1, Principle 4.7) | Scan |
| `CA-PIPEDA-4.1` Accountability for Processing Systems | An organisation is responsible for personal information under its control, which requires it to know and document the software systems that hold or process that information (PIPEDA Schedule 1, Principle 4.1) | Scan |
| `CA-PIPEDA-4.1.3` Third-Party Transfer Accountability | Information transferred to third parties for processing must receive a comparable level of protection, requiring the organisation to identify the suppliers behind its processing components (PIPEDA Schedule 1, Principle 4.1.3) | Scan |
| `CA-PIPEDA-4.8` Openness of Practices | Organisations must make information about their policies and practices for managing personal information readily available, supported by identifiable, timestamped system documentation (PIPEDA Schedule 1, Principle 4.8) | Scan |
| `CA-PIPEDA-10.1` Breach of Security Safeguards Readiness | Organisations must report breaches of security safeguards that create a real risk of significant harm, which requires the ability to identify affected software components and versions promptly (PIPEDA s. 10.1, Division 1.1) | Scan |
| `CA-PIPEDA-IDENT` Identifiable Processing Components | Ongoing safeguard review and breach assessment require processing components to be unambiguously identifiable against vulnerability information (PIPEDA Schedule 1, Principle 4.7.3, care of information) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | -------------------------------------------------------- |
| `PIPEDA-P1` | Establish Accountability for Personal Information |
| `PIPEDA-P2` | Identify Purposes Before or at Collection |
| `PIPEDA-P3` | Obtain Meaningful Consent for Collection and Use |
| `PIPEDA-P4` | Limit Collection to Identified Purposes |
| `PIPEDA-P5` | Limit Use, Disclosure, and Retention |
| `PIPEDA-P6` | Maintain Accuracy of Personal Information |
| `PIPEDA-P7` | Protect Personal Information with Appropriate Safeguards |
| `PIPEDA-P8` | Be Open About Privacy Practices and Policies |
| `PIPEDA-P9` | Give Individuals Access to Their Personal Information |
| `PIPEDA-P10` | Provide a Process to Challenge Compliance |
| `PIPEDA-BREACH` | Report Significant Breaches of Security Safeguards |
## Policy templates
Written for PIPEDA:
* Privacy Programme and Accountability Policy (PIPEDA)
* Consent, Collection Limits, and Individual Access Policy (PIPEDA)
* Security Safeguards and Breach Reporting Policy (PIPEDA)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PIPEDA.
# Cayman Islands Data Protection Act 2017 (/docs/frameworks/americas/cayman-islands-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | KY DPA |
| Region | Americas |
| Country or scope | Cayman Islands |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers KY DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `KY-DPA-P7` Seventh Principle: Security | Appropriate technical and organisational measures must be taken against unauthorised or unlawful processing and against accidental loss, destruction, or damage, including integrity of processing systems (DPA (2021 Revision) Sch. 1, seventh data protection principle) | Scan |
| `KY-DPA-P4` Fourth Principle: Accuracy | Personal data must be accurate and, where necessary, kept up to date, which requires precise version tracking of the software maintaining records (DPA (2021 Revision) Sch. 1, fourth data protection principle) | Scan |
| `KY-DPA-PROC` Processor Contracts | Processing by a data processor must be under a written contract requiring equivalent security measures, so the suppliers of processing components must be identified (DPA (2021 Revision), processor provisions under the seventh principle) | Scan |
| `KY-DPA-BREACH` Breach Notification Readiness | Personal data breaches must be notified to the Ombudsman and affected data subjects, which requires identifying exactly which components were affected (DPA (2021 Revision), personal-data-breach notification duty) | Scan |
| `KY-DPA-INV` Accountability for Processing | Controllers are responsible for compliance with the principles for all processing under their control, presupposing an inventory of processing components (DPA (2021 Revision), controller responsibility) | Scan |
| `KY-DPA-DOC` Fair and Transparent Processing Documentation | The first principle's fair-processing requirements imply documented, identifiable records of how and where data is processed (DPA (2021 Revision) Sch. 1, first data protection principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KY DPA.
# CCPA / CPRA (/docs/frameworks/americas/ccpa-cpra)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
California privacy: data processing software inventory, vendor documentation, license transparency.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CCPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CCPA
* **Scan requirements:** 4, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for CCPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for CCPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 4 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | -------------------------------------------------------------------------------- | ---------- |
| `CCPA-1798.100` Data Processor Documentation | CCPA requires documentation of service providers processing personal information | Scan |
| `CCPA-1798.150` Privacy-Relevant Component Identification | Components handling personal information must be identified for CCPA compliance | Scan |
| `CPRA-1798.100(d)` Third-Party Component Transparency | CPRA requires transparency about third-party components and data sharing | Scan |
| `CPRA-1798.185` SBOM Creator Accountability | CPRA requires documented accountability for personal information handling | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | ------------------------------------------------------------------- |
| `1798.100` | Honor Consumer Right to Know |
| `1798.105` | Honor Consumer Right to Delete |
| `1798.106` | Honor Consumer Right to Correct Inaccurate Information |
| `1798.110` | Disclose Categories of Personal Information Collected |
| `1798.115` | Disclose Third-Party Data Sharing |
| `1798.120` | Honor Consumer Right to Opt-Out of Sale or Sharing |
| `1798.121` | Honor Consumer Right to Limit Use of Sensitive Personal Information |
| `1798.125` | Ensure Non-Discrimination for Exercising Rights |
| `1798.130` | Implement Designated Methods for Consumer Requests |
| `1798.135` | Maintain Privacy Policy and Notice at Collection |
| `1798.140` | Classify and Track Sensitive Personal Information |
| `1798.150` | Implement Reasonable Security for Personal Information |
| `1798.185(a)` | Establish Privacy Risk Assessment Program |
| `1798.100(d)` | Manage Contractor and Service Provider Data Use |
## Policy templates
Written for CCPA:
* CCPA/CPRA Privacy Notice and Policy
* CCPA/CPRA Consumer Rights Request Handling Policy
* CCPA/CPRA Reasonable Security and Data Protection Policy
* CCPA/CPRA Service Provider and Contractor Data Agreements Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CCPA.
# Chile Law 19.628 (/docs/frameworks/americas/chile-19628)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Chilean Personal Data Protection Law - data quality, consent, sensitive data, data subject rights.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CL 19628 |
| Region | Americas |
| Country or scope | Chile |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CL 19628
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for CL 19628.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for CL 19628 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CL-19628-11` Due Diligence in Data Custody | The party responsible for a data registry must take care of it with due diligence and answers for damages; demonstrable integrity controls over the processing software evidence that diligence (Law 19.628 Art. 11) | Scan |
| `CL-19628-06` Currency and Elimination of Stale Data | Data must be modified, blocked or eliminated when it is inaccurate, outdated or lacks legal basis for storage; knowing component versions is a precondition for identifying stale processing elements (Law 19.628 Art. 6-style currency obligation) | Scan |
| `CL-19628-09` Purpose-Bound Use | Personal data may only be used for the purposes for which it was collected, which presupposes documented, identifiable records of the systems performing each processing purpose (Law 19.628 Art. 9-style purpose limitation) | Scan |
| `CL-19628-REG` Registry of Data Banks | Databases maintained by public bodies must be recorded in a public registry identifying the database and its characteristics; an enumerated, named component inventory supports the same discipline (Law 19.628, public data-bank registry provision) | Scan |
| `CL-19628-MAND` Processing Under Mandate | Processing carried out on behalf of the controller under mandate must be governed by the controller's instructions, requiring visibility into which third-party suppliers provide the processing software (Law 19.628, processing-by-mandate provision) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | ---------------------------------------------- |
| `CL-Art4` | Consentimiento del Titular (Art. 4) |
| `CL-Art7` | Calidad de los Datos (Art. 7) |
| `CL-Art9` | Seguridad de los Datos (Art. 9) |
| `CL-Art10` | Derecho de Acceso y Rectificación (Art. 10-11) |
| `CL-Art21` | Datos Sensibles (Art. 21) |
| `CL-TR-01` | Transferencia Internacional de Datos |
| `CL-RET-01` | Plazos de Conservación y Eliminación |
| `CL-OP-01` | Oposición al Tratamiento |
| `CL-ENC-01` | Cifrado y Seudonimización |
| `CL-BR-01` | Notificación de Incidentes de Seguridad |
## Policy templates
Written for CL 19628:
* Procedimiento de Calidad, Retención y Eliminación de Datos Personales
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CL 19628.
# CMMC 2.0 (/docs/frameworks/americas/cmmc)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
US DoD supply chain security requirements for defense contractors.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CMMC |
| Region | Americas |
| Country or scope | United States |
| Sector | Defense |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CMMC
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 13 controls from Safeguard's control catalog for CMMC.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for CMMC and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CMMC-CM.2.061` Software Inventory Baseline | Establish and maintain baseline configurations including software inventory (CMMC CM.2.061) | Scan |
| `CMMC-CM.2.062` Security Configuration | Establish and maintain security configuration settings (CMMC CM.2.062) | Scan |
| `CMMC-SI.1.210` Vulnerability Identification | Identify, report, and correct system flaws: components must be identifiable for vulnerability scanning (CMMC SI.1.210) | Scan |
| `CMMC-SR.2.111` Supply Chain Risk Management | Manage supply chain risk associated with development of systems (CMMC SR.2.111) | Scan |
| `CMMC-AU.2.041` Audit Record Review | Review and update logged events: SBOM must have audit trail via timestamps (CMMC AU.2.041) | Scan |
| `CMMC-IA.1.076` Identifier Management | Manage system and user identifiers: components need unique identifiers (CMMC IA.1.076) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ---------------------------------------------------------------------------- |
| `AC.L1-3.1.1` | Limit system access to authorized users (CMMC L1) |
| `AC.L1-3.1.2` | Limit access to authorized transaction types |
| `AC.L2-3.1.3` | Control CUI flow based on approved authorizations |
| `IA.L1-3.5.1` | Identify information system users and devices |
| `IA.L2-3.5.3` | Use MFA for access to CUI systems |
| `SC.L2-3.13.8` | Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI |
| `CM.L2-3.4.1` | Establish baseline configurations for CUI systems |
| `IR.L2-3.6.1` | Establish incident handling capability for CUI systems |
| `IR.L2-3.6.2` | Track, document, and report CUI incidents |
| `MA.L2-3.7.5` | Require MFA for remote maintenance of CUI systems |
| `RM.L2-3.11.1` | Periodically assess risk to CUI |
| `PS.L2-3.9.2` | Protect CUI during and after personnel actions |
| `AT.L2-3.2.1` | Provide security awareness training for CUI handling |
## Policy templates
Written for CMMC:
* CMMC Level 1 Basic Cyber Hygiene Policy
* CMMC Level 2 CUI Protection Policy
* CMMC Third-Party Assessment Preparation Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CMMC.
# Colombia Law 1581 (/docs/frameworks/americas/colombia-1581)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Colombian Personal Data Protection Law - principles, data subject rights, registration, data processing.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CO 1581 |
| Region | Americas |
| Country or scope | Colombia |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CO 1581
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for CO 1581.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for CO 1581 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CO-1581-4G` Security Principle | Information must be handled with the technical measures necessary to prevent adulteration, loss, or unauthorized access; integrity hashes over the software inventory demonstrate protection against adulteration (Law 1581/2012 Art. 4(g)) | Scan |
| `CO-1581-4D` Veracity or Quality Principle | Information subject to processing must be truthful, complete, exact and up to date; applying the same bar to the processing environment means components must carry both a name and a version (Law 1581/2012 Art. 4(d)) | Scan |
| `CO-1581-17` Controller Duties | Controllers must keep the information under the security conditions necessary to prevent its adulteration or loss and maintain records supporting processing; an enumerated component inventory of processing systems supports these duties (Law 1581/2012 Art. 17) | Scan |
| `CO-1581-18` Processor Duties | Processors handling data on behalf of controllers carry their own security and confidentiality duties, requiring the controller to know which suppliers stand behind the software in the processing chain (Law 1581/2012 Art. 18) | Scan |
| `CO-1581-25` National Registry of Databases | Databases subject to the law must be registered in the National Registry of Databases (RNBD) with identifying information; a uniquely identified, timestamped SBOM document supports registration-grade recordkeeping (Law 1581/2012 Art. 25) | Scan |
| `CO-1581-4E` Transparency Principle | Data subjects are entitled to obtain information about the processing concerning them at any time; interchangeable machine-readable records of the processing environment make such transparency operational (Law 1581/2012 Art. 4(e)) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | --------------------------------------------- |
| `CO-Art4` | Principios del Tratamiento (Art. 4) |
| `CO-Art8` | Derechos de los Titulares (Art. 8) |
| `CO-Art9` | Autorización del Titular (Art. 9) |
| `CO-Art17` | Deberes del Responsable (Art. 17) |
| `CO-Art25` | Registro Nacional de Bases de Datos (Art. 25) |
| `CO-Art26` | Transferencia Internacional (Art. 26) |
| `CO-SEC-01` | Medidas de Seguridad de la Información |
| `CO-POL-01` | Política de Tratamiento de Datos |
| `CO-ENC-01` | Cifrado en Tránsito y Reposo |
| `CO-DS-01` | Datos Sensibles: Restricciones |
| `CO-BR-01` | Reporte de Incidentes de Seguridad |
## Policy templates
Written for CO 1581:
* Procedimiento de Notificación de Incidentes de Seguridad: LATAM
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CO 1581.
# Colorado CPA (/docs/frameworks/americas/colorado-cpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Colorado Privacy Act - opt-out rights, universal opt-out, sensitive data consent, DPIA.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CO CPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CO CPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for CO CPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for CO CPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CO-CPA-1308-CARE` Duty of Care: Data Security | Controllers owe a duty of care to take reasonable measures to secure personal data during storage and use, appropriate to the volume, scope and nature of the data; integrity verification of the processing software evidences that duty (Colo. Rev. Stat. § 6-1-1308(5)) | Scan |
| `CO-CPA-1308-MIN` Purpose Specification and Minimisation | Collection must be specified, express and limited to what is reasonably necessary; demonstrating compliance presumes an accounting of the systems and software components through which personal data flows (Colo. Rev. Stat. § 6-1-1308) | Scan |
| `CO-CPA-1305` Processor Obligations | Processors must adhere to controller instructions under a binding contract, assist with security and breach duties, and flow obligations down to sub-processors; this vendor chain must be identifiable component-by-component (Colo. Rev. Stat. § 6-1-1305) | Scan |
| `CO-CPA-1309` Data Protection Assessments | Processing that presents a heightened risk of harm (targeted advertising, sale, profiling, sensitive data) requires documented data protection assessments, which depend on knowing the exact versions of the software performing that processing (Colo. Rev. Stat. § 6-1-1309) | Scan |
| `CO-CPA-1306` Opt-Out and Rights Infrastructure | Consumers hold rights of access, correction, deletion, portability and opt-out, including via a universal opt-out mechanism the controller must honor; executing these rights across systems requires unambiguous identification of the components involved (Colo. Rev. Stat. §§ 6-1-1306, 6-1-1313) | Scan |
| `CO-CPA-1308-TRANS` Duty of Transparency | Controllers owe a duty of transparency via a reasonably accessible, clear and meaningful privacy notice; supporting system documentation should carry its own identity and creation timestamp so disclosures are auditable (Colo. Rev. Stat. § 6-1-1308(1)) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | -------------------------------------------------------------- |
| `6-1-1306` | Consumer Rights: Access, Correction, Deletion & Portability |
| `6-1-1306(1)(d)` | Universal Opt-Out Signal (GPC) Recognition |
| `6-1-1308` | Data Protection Assessment |
| `6-1-1303(22)` | Sensitive Data Consent & Opt-In |
| `6-1-1309` | Processor Data Processing Agreements |
| `6-1-1305` | Privacy Notice & Transparency |
| `6-1-1306(2)` | Consumer Appeal Mechanism |
| `6-1-1304` | Controller Duties: Minimization, Security & Non-Discrimination |
| `6-1-1310` | Children's Data Restrictions |
## Policy templates
Written for CO CPA:
* Colorado CPA State Privacy Notice
* Colorado CPA Sensitive Data Consent Policy
* Colorado CPA Data Protection Assessment Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CO CPA.
# Connecticut CTDPA (/docs/frameworks/americas/connecticut-ctdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Connecticut Data Privacy Act - controller duties, consumer rights, sensitive data limits.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CT CTDPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CT CTDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for CT CTDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for CT CTDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CT-CTDPA-6-SEC` Data Security Safeguards | Controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices proportionate to the data processed; integrity-verifiable software is a baseline technical practice (CTDPA, P.A. 22-15 § 6 controller duties) | Scan |
| `CT-CTDPA-6-MIN` Minimisation and Purpose Limitation Accountability | Personal data collection must be limited to what is adequate, relevant and reasonably necessary; a named processing platform with an enumerated component inventory is the evidentiary basis for that limitation (CTDPA, P.A. 22-15 § 6 controller duties) | Scan |
| `CT-CTDPA-7` Processor Contract Obligations | Processors are bound by contract to follow controller instructions, ensure personnel confidentiality, and impose the same duties on subcontractors; the third-party software chain must therefore be attributable to named suppliers (CTDPA, P.A. 22-15 § 7) | Scan |
| `CT-CTDPA-8` Data Protection Assessment Readiness | Data protection assessments are required for heightened-risk processing such as targeted advertising, sale, profiling and sensitive data; risk cannot be assessed unless the versions of the processing software are recorded (CTDPA, P.A. 22-15 § 8) | Scan |
| `CT-CTDPA-4` Consumer Rights Fulfilment | Consumers may access, correct, delete and port their data and opt out of targeted advertising, sale and profiling; fulfilling requests across systems requires those systems' components to be unambiguously identifiable (CTDPA, P.A. 22-15 § 4) | Scan |
| `CT-CTDPA-NOTICE` Privacy Notice Documentation | Controllers must provide a reasonably accessible, clear and meaningful privacy notice covering categories processed and shared; underlying documentation should be identified and timestamped so the notice remains verifiably current (CTDPA privacy-notice provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------ | ----------------------------------------------------------- |
| `PA-22-15-Sec4` | Consumer Rights: Access, Correction, Deletion & Portability |
| `PA-22-15-Sec4(5)` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `PA-22-15-Sec4(6)` | Universal Opt-Out Mechanism Recognition (from Jan 2025) |
| `PA-22-15-Sec5` | Sensitive Data Consent |
| `PA-22-15-Sec8` | Data Protection Assessment |
| `PA-22-15-Sec9` | Processor Contracts |
| `PA-22-15-Sec6` | Privacy Notice Requirements |
| `PA-22-15-Sec4(4)` | Consumer Appeals Process |
| `PA-22-15-Sec7` | Non-Discrimination for Exercising Rights |
## Policy templates
Written for CT CTDPA:
* Connecticut CTDPA State Privacy Notice
* Connecticut CTDPA Consumer Rights Request Handling Procedure
* Connecticut CTDPA Data Protection Assessment Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CT CTDPA.
# COPPA (/docs/frameworks/americas/coppa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Children Online Privacy Protection Act - verifiable parental consent, notice, data minimization (under-13).
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers COPPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for COPPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for COPPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `COPPA-312.8` Confidentiality, Security, and Integrity | Operators must establish and maintain reasonable procedures to protect the confidentiality, security, and integrity of personal information collected from children, implying integrity verification of the software handling that information (16 CFR 312.8) | Scan |
| `COPPA-312.8-SP` Capable Service Providers and Third Parties | Operators may release children's personal information only to service providers and third parties capable of maintaining its confidentiality, security, and integrity, and must obtain assurances they will do so: requiring knowledge of the supplier behind each component and service (16 CFR 312.8) | Scan |
| `COPPA-312.4` Notice of Information Practices | Operators must provide clear and complete notice of what information is collected from children, how it is used, and their disclosure practices, which is supported by formally identified, timestamped documentation of the collecting systems (16 CFR 312.4) | Scan |
| `COPPA-312.10` Retention Limits and Deletion Readiness | Children's personal information may be retained only as long as reasonably necessary and must then be securely deleted; honoring this requires knowing which systems and software components hold the data, i.e. an enumerated inventory (16 CFR 312.10) | Scan |
| `COPPA-312.8-VULN` Reasonable Security Procedures Against Known Flaws | Maintaining reasonable security procedures for children's data includes keeping collection systems free of known exploitable flaws, which requires the exact version of each deployed component to be recorded and checkable (16 CFR 312.8 reasonable-procedures standard) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | ----------------------------------------- |
| `312.3` | Privacy Notice |
| `312.4` | Direct Notice to Parents |
| `312.5` | Verifiable Parental Consent |
| `312.6` | Parental Rights |
| `312.7` | Prohibition on Conditioning Participation |
| `312.8` | Confidentiality, Security, and Integrity |
| `312.9` | Retention and Deletion |
| `312.10` | Safe Harbor Programs |
| `312.12` | Operator Accountability |
## Policy templates
Written for COPPA:
* COPPA Parental Consent Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to COPPA.
# Costa Rica Law No. 8968 on Personal Data (/docs/frameworks/americas/costa-rica-law8968)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CR L8968 |
| Region | Americas |
| Country or scope | Costa Rica |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CR L8968
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CR-8968-10` Security of Data | The party responsible for a database must adopt technical and organizational measures appropriate to the processing risk to guarantee the security of personal data and prevent its alteration, loss or unauthorized access, presuming integrity controls over the processing software (Law No. 8968, Art. 10) | Scan |
| `CR-8968-11` Duty of Confidentiality Across Parties | Everyone who intervenes in the processing of personal data is bound by professional or functional secrecy, requiring the third parties and suppliers involved in processing systems to be identified (Law No. 8968, Art. 11) | Scan |
| `CR-8968-6` Quality of Information | Personal data must be current, truthful, exact and complete; applied to the processing stack this requires every component to carry both a name and a version (Law No. 8968, Art. 6) | Scan |
| `CR-8968-PROT` Documented Action Protocols | Database managers must follow documented action protocols governing how data is handled, which requires dated, identifiable documentation of the processing systems, such as an SBOM with document ID and timestamp (Law No. 8968, Art. 12 action-protocol obligation) | Scan |
| `CR-8968-REG` Database Registration with PRODHAB | Databases must be registered with PRODHAB, including a description of the processing, its security measures and recipients, which presupposes an enumerated inventory of the systems and components involved (Law No. 8968, registration regime) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CR L8968.
# Cuba Law 149/2022 on Personal Data Protection (/docs/frameworks/americas/cuba-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CU Law 149 |
| Region | Americas |
| Country or scope | Cuba |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CU Law 149
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CU-L149-SEC` Security of Personal Data Processing | Those responsible for processing must apply technical and organizational measures that guarantee the security, confidentiality, and integrity of personal data and its processing systems (Law 149/2022, security-of-processing obligation) | Scan |
| `CU-L149-INV` Accountability for Processing Systems | Responsibility for lawful processing presupposes knowing which software systems and components process personal data (Law 149/2022, controller-responsibility principle) | Scan |
| `CU-L149-QUAL` Data Quality and Updating | Personal data must be exact and kept up to date so subjects can exercise rectification rights, requiring version tracking of the maintaining software (Law 149/2022, data-quality principle and rectification right) | Scan |
| `CU-L149-TP` Third-Party Processing Safeguards | Communication of data to, or processing by, third parties requires legal grounds and equivalent safeguards, so component suppliers must be identified (Law 149/2022, third-party processing/communication provisions) | Scan |
| `CU-L149-DOC` Documented Processing Environment | The duties of information and lawful processing imply an identifiable, timestamped record of the processing environment (Law 149/2022, duty of information) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CU Law 149.
# Curacao Personal Data Protection Ordinance (/docs/frameworks/americas/curacao-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CW PDP Ord |
| Region | Americas |
| Country or scope | Curacao |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CW PDP Ord
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CW-LBP-13` Security of Processing | The responsible party must implement appropriate technical and organizational measures securing personal data against loss and any form of unlawful processing, taking account of the state of the art and processing risk (Landsverordening bescherming persoonsgegevens, art. 13) | Scan |
| `CW-LBP-MIN` Prevention of Unnecessary Processing | Security measures must be aimed partly at preventing unnecessary gathering and further processing of personal data, which excludes vaguely specified components whose behavior cannot be pinned down (Landsverordening bescherming persoonsgegevens, art. 13) | Scan |
| `CW-LBP-PROC` Processor Guarantees | Processing carried out on the responsible party's behalf must be governed by agreements guaranteeing equivalent security, requiring supplier visibility for third-party components (Landsverordening bescherming persoonsgegevens, processor provisions) | Scan |
| `CW-LBP-QUAL` Data Quality | Personal data must be accurate, adequate and processed for explicit legitimate purposes, presupposing fully described processing components with name and version (Landsverordening bescherming persoonsgegevens, data-quality provisions) | Scan |
| `CW-LBP-REC` Accountable Processing Inventory | Responsible parties must be able to account for the processing operations they conduct, including a named, populated inventory of the software involved (Landsverordening bescherming persoonsgegevens, responsible-party accountability provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CW PDP Ord.
# Delaware PDPA (/docs/frameworks/americas/delaware-pdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Delaware Personal Data Privacy Act - controller obligations, consumer rights, sensitive data.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | DE PDPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers DE PDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for DE PDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for DE PDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `DE-PDPA-SEC` Data Security Practices | Controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices appropriate to the volume and nature of the personal data; integrity-verifiable processing software evidences that duty (6 Del. C. ch. 12D, controller-duties provision) | Scan |
| `DE-PDPA-MIN` Minimisation Accountability | Collection of personal data must be limited to what is adequate, relevant and reasonably necessary for the disclosed purposes, which presumes an inventory of the software components through which that data flows (6 Del. C. ch. 12D, controller-duties provision) | Scan |
| `DE-PDPA-PROC` Processor Obligations | Processors must adhere to controller instructions under binding contracts, assist with security and assessments, and bind subcontractors equivalently; third-party components should carry named suppliers to demonstrate this oversight (6 Del. C. ch. 12D, processor provisions) | Scan |
| `DE-PDPA-DPIA` Data Protection Assessment Readiness | Data protection assessments are required for heightened-risk processing such as targeted advertising, sale, risky profiling and sensitive data; recorded software versions are the basis for credible risk assessment (6 Del. C. ch. 12D, data protection assessment provisions) | Scan |
| `DE-PDPA-RIGHTS` Consumer Rights Fulfilment | Consumers may access, correct, delete and port personal data, obtain a list of third-party recipient categories, and opt out including via universal opt-out signals; the processing components must be unambiguously identifiable to execute these rights (6 Del. C. ch. 12D, consumer-rights provisions) | Scan |
| `DE-PDPA-NOTICE` Privacy Notice Documentation | Controllers must provide a reasonably accessible, clear and meaningful privacy notice covering processing purposes and sharing; supporting documentation should be identified and timestamped so disclosures remain auditable (6 Del. C. ch. 12D, transparency provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ----------------------------------------------------------- |
| `DE-6-12D-102C` | Consumer Rights: Access, Correction, Deletion & Portability |
| `DE-6-12D-102D` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `DE-6-12D-103` | Sensitive Data Consent |
| `DE-6-12D-107` | Data Protection Assessment |
| `DE-6-12D-108` | Processor Agreements |
| `DE-6-12D-101` | Privacy Notice |
| `DE-6-12D-104` | Children's Data Protections |
| `DE-6-12D-105` | Universal Opt-Out Signal Recognition |
| `DE-6-12D-106` | Consumer Appeals |
## Policy templates
Written for DE PDPA:
* Delaware PDPA State Privacy Notice
* Delaware PDPA Consumer Rights Request Handling Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DE PDPA.
# DFARS 252.204-7012 (/docs/frameworks/americas/dfars-7012)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Defense acquisition: SBOM delivery, component provenance, prohibited vendor detection.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | DFARS |
| Region | Americas |
| Country or scope | United States |
| Sector | Defense |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers DFARS
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for DFARS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for DFARS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `DFARS-7012-B2` NIST 800-171 Baseline Inventory | Adequate security requires implementing NIST SP 800-171, whose configuration-management family mandates baseline configurations and inventories of organisational systems including installed software (DFARS 252.204-7012(b)(2); NIST SP 800-171 3.4.1) | Scan |
| `DFARS-7012-FLAW` Flaw Remediation Visibility | Identifying, reporting and correcting system flaws in a timely manner requires knowing the exact versions of the software in use (DFARS 252.204-7012; NIST SP 800-171 3.14.1) | Scan |
| `DFARS-7012-C` 72-Hour Incident Scoping | Rapid cyber incident reporting to DoD requires the contractor to determine quickly which covered systems and software components were affected, so components must be unambiguously identifiable (DFARS 252.204-7012(c) rapid reporting) | Scan |
| `DFARS-7012-M` Subcontractor Flowdown Provenance | The clause must be flowed down to subcontractors, which presumes the contractor knows which suppliers stand behind the software in delivered systems (DFARS 252.204-7012(m); see also Section 889 supplier prohibitions) | Scan |
| `DFARS-7012-MEDIA` Forensic Integrity of Software | Contractors must preserve and protect images of affected systems for DoD damage assessment, supported by cryptographic hashes that prove component integrity (DFARS 252.204-7012(e) media preservation) | Scan |
| `DFARS-7012-DOC` Deliverable Software Documentation | Software composition evidence delivered under defense contracts must be attributable and dated to support assessment and audit (DFARS 252.204-7012 assessment/audit context; NIST SP 800-171 documentation requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | -------------------------------------------------------------- |
| `DFARS-7012-b1` | Provide adequate security on all covered contractor systems |
| `DFARS-7012-b2` | Report cyber incidents within 72 hours to DoD |
| `DFARS-7012-b3` | Submit malware identified in cyber incidents to DoD |
| `DFARS-7012-c` | Rapidly report cyber incidents to contracting officer |
| `DFARS-7012-d` | Preserve and protect images of compromised systems |
| `DFARS-7012-f` | Flow DFARS requirements to sub-contractors handling CDI |
| `DFARS-7012-g` | Implement NIST SP 800-171 and maintain SSP with SPRS score |
| `DFARS-7012-h` | Cloud services for CDI must use FedRAMP Moderate or equivalent |
## Policy templates
Written for DFARS:
* DFARS 252.204-7012 Adequate Security Policy
* SPRS Self-Assessment and Score Maintenance Policy
* CDI Media Protection and Sanitization Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DFARS.
# Dominica National ICT / Privacy Framework (/docs/frameworks/americas/dominica-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | DM ICT/Priv |
| Region | Americas |
| Country or scope | Dominica |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers DM ICT/Priv
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `DM-ICT-INTG` Integrity of Electronic Records | The electronic-transactions regime depends on the verifiable integrity of electronic records, implying integrity data for the software components producing and storing them (Electronic Transactions Act 2013, integrity-of-record provisions) | Scan |
| `DM-ICT-SEC` Protection Against Unauthorized Data Access | Computer-misuse provisions penalizing unauthorized access to and modification of data presuppose that operators can detect tampering with their systems (Dominican ICT framework, computer-misuse offences) | Scan |
| `DM-FW-INV` Knowledge of Processing Systems | Responsible handling of personal information under the national framework requires knowing which software systems and components process it (Dominican ICT/privacy framework, general duty of care) | Scan |
| `DM-FW-ID` Identifiability for Incident Response | Investigating incidents affecting personal information requires that system components carry standard identifiers (Dominican ICT/privacy framework, incident-response readiness) | Scan |
| `DM-FW-DOC` Verifiable Documentation of Systems | The electronic-records regime expects system documentation to be identifiable and timestamped so records can be attributed and verified (Electronic Transactions Act 2013, record-attribution provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DM ICT/Priv.
# Dominican Republic Law No. 172-13 on Personal Data (/docs/frameworks/americas/dominican-republic-law172)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | DO L172-13 |
| Region | Americas |
| Country or scope | Dominican Republic |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers DO L172-13
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `DO-L172-SEC` Security of Data | The data controller must take technical and organizational measures to guarantee the security of personal data and prevent alteration, loss, or unauthorized access to the systems processing it (Law No. 172-13, data-security obligation) | Scan |
| `DO-L172-QUAL` Data Quality | Data must be certain, adequate, and kept current, which requires operators to track precise versions of the software components maintaining records (Law No. 172-13, data-quality principle) | Scan |
| `DO-L172-PROC` Processing Services by Third Parties | When processing is outsourced, the provider acts only under contract and equivalent safeguards, so third-party software suppliers must be identified (Law No. 172-13, third-party processing provision) | Scan |
| `DO-L172-REG` Database Accountability | Databases and the systems operating them must be identifiable and accounted for to the supervisory framework, presupposing a software inventory (Law No. 172-13, database registration/accountability) | Scan |
| `DO-L172-DOC` Documented Processing Environment | Duties of information and lawful processing require a documented, timestamped record of the processing environment (Law No. 172-13, duty of information) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DO L172-13.
# Ecuador Organic Law on Personal Data Protection (/docs/frameworks/americas/ecuador-lopdp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | EC LOPDP |
| Region | Americas |
| Country or scope | Ecuador |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers EC LOPDP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `EC-LOPDP-37` Personal Data Security Measures | Controllers and processors must implement technical, organisational and legal measures ensuring integrity, confidentiality and availability of personal data, evidenced by integrity hashes on processing-system components (LOPDP 2021, Art. 37 data-security obligations) | Scan |
| `EC-LOPDP-BRN` Security Breach Notification Readiness | Security breaches affecting personal data must be notified to the Superintendence and affected data subjects within short statutory deadlines, which requires components to be immediately identifiable (LOPDP 2021, breach-notification provisions, Arts. 43-46 range) | Scan |
| `EC-LOPDP-REC` Accountability and Processing Records | The accountability (responsabilidad proactiva) principle requires controllers to document and demonstrate their processing, which presupposes an inventory of the software systems involved (LOPDP 2021, accountability principle and record duties) | Scan |
| `EC-LOPDP-PROC` Processor (Encargado) Oversight | Processing by an encargado must occur under a binding contract with sufficient guarantees, so third-party software components must carry named suppliers (LOPDP 2021, controller-processor provisions) | Scan |
| `EC-LOPDP-VER` Known Software Versions | Risk-based security and breach-impact analysis require exact versions of software components to be recorded (LOPDP 2021, risk-analysis and security-measure duties) | Scan |
| `EC-LOPDP-DOC` Demonstrable Documentation | Demonstrating compliance to the Superintendence requires software records to be identifiable, timestamped documents with a recorded creator (LOPDP 2021, compliance-demonstration duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to EC LOPDP.
# El Salvador Cybersecurity and Information Security Law 2024 (/docs/frameworks/americas/el-salvador-cyber)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SV Cyber |
| Region | Americas |
| Country or scope | El Salvador |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SV Cyber
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SV-CYBER-INV` Software Asset Inventory | Information-security governance requires entities to maintain an inventory of their technology assets, including the software components they run (Cybersecurity Law 2024, asset-management/governance obligations) | Scan |
| `SV-CYBER-SYS` System Identification | Each information system in scope must be identified by name with its constituent components enumerated (Cybersecurity Law 2024, asset-management obligations) | Scan |
| `SV-CYBER-INT` Integrity Controls | Entities must implement controls that preserve the integrity of information and of the software that processes it, verifiable through cryptographic integrity data (Cybersecurity Law 2024, information-security measures) | Scan |
| `SV-CYBER-VULN` Vulnerability Management Readiness | Risk-management and incident-response duties require knowing the exact version of every deployed component so vulnerabilities can be matched and remediated (Cybersecurity Law 2024, risk-management/incident-response obligations) | Scan |
| `SV-CYBER-ID` Component Identifiability for Incident Response | Incident reporting to the ACE requires components to carry standard identifiers so affected software can be pinpointed rapidly (Cybersecurity Law 2024, incident-notification duty) | Scan |
| `SV-CYBER-SUP` Supply-Chain Verification | Security risk management extends to third-party and supplier risk, so the supplier of each software component must be recorded (Cybersecurity Law 2024, third-party/supply-chain risk provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SV Cyber.
# El Salvador Personal Data Protection Law 2024 (/docs/frameworks/americas/el-salvador-lpdp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SV LPDP |
| Region | Americas |
| Country or scope | El Salvador |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SV LPDP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `SV-LPDP-SEC` Security Measures for Processing | Controllers and processors must adopt technical, administrative, and organizational measures ensuring the security and integrity of personal data and of the systems that process it (LPDP 2024, security-measures obligation) | Scan |
| `SV-LPDP-INV` Accountability for Processing Systems | The accountability principle requires controllers to know and be able to demonstrate what systems and components process personal data (LPDP 2024, accountability principle) | Scan |
| `SV-LPDP-PROC` Processor and Third-Party Obligations | Processing by third parties requires contractual guarantees, so the suppliers of processing components must be identified (LPDP 2024, data-processor obligations) | Scan |
| `SV-LPDP-BREACH` Breach Notification Readiness | Security incidents affecting personal data must be reported, which requires being able to identify precisely which components were involved (LPDP 2024, incident/breach notification duty) | Scan |
| `SV-LPDP-QUAL` Data Quality | Personal data must be exact and kept up to date, requiring precise version tracking of the software maintaining it (LPDP 2024, data-quality principle) | Scan |
| `SV-LPDP-DOC` Demonstrable Compliance Documentation | Compliance must be demonstrable to the supervisory authority via identifiable, timestamped documentation of the processing environment (LPDP 2024, accountability/documentation duty) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SV LPDP.
# Falkland Islands Data Protection Ordinance (/docs/frameworks/americas/falkland-islands-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | FK DP Ord |
| Region | Americas |
| Country or scope | Falkland Islands |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers FK DP Ord
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `FK-CONST-PRIV` Processing System Inventory | Constitutional privacy protection presumes entities can account for the systems and software processing personal information (Falkland Islands Constitution Order 2008, fundamental rights provisions) | Scan |
| `FK-POL-SEC` Security of Processing | UK-GDPR-aligned practice applied by the Falkland Islands Government requires technical and organisational measures protecting personal data, including software integrity verification (FIG Data Protection Policy, UK GDPR Art. 32-style security standard) | Scan |
| `FK-POL-REC` Records of Processing | Aligned practice requires maintaining records of processing activities, including a named, populated inventory of processing software (FIG Data Protection Policy, UK GDPR Art. 30-style record duty) | Scan |
| `FK-POL-PROC` Third-Party Processor Accountability | Engaging processors under GDPR-aligned practice requires sufficient guarantees and supplier visibility for third-party components handling personal data (FIG Data Protection Policy, UK GDPR Art. 28-style processor standard) | Scan |
| `FK-POL-ID` Breach Impact Readiness | Breach-response practice aligned with UK GDPR requires the ability to identify precisely which components an incident affected (FIG Data Protection Policy, UK GDPR Art. 33-style breach readiness) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FK DP Ord.
# FCRA / FACTA (/docs/frameworks/americas/fcra)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Fair Credit Reporting Act - accuracy, disposal rule, red flags, identity theft prevention.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | FCRA |
| Region | Americas |
| Country or scope | United States |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers FCRA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for FCRA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for FCRA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FCRA-1681EB` Maximum Possible Accuracy | Consumer reporting agencies must follow reasonable procedures to assure maximum possible accuracy of consumer report information; applied to the systems producing those reports, every software component record must itself be complete with name and version (15 U.S.C. 1681e(b)) | Scan |
| `FCRA-1681EA` Permissible Purpose Controls | Agencies must maintain reasonable procedures to furnish consumer reports only for permissible purposes and to verify prospective users, which requires knowing the identity and supplier of the systems and parties in the data flow (15 U.S.C. 1681e(a)) | Scan |
| `FACTA-682` Disposal Rule Readiness | Any person maintaining consumer report information must take reasonable measures to properly dispose of it; disposing of data reliably requires knowing which systems and software components hold it, i.e. an enumerated inventory (FACTA Disposal Rule, 16 CFR Part 682) | Scan |
| `FACTA-681.1` Red Flags Identity Theft Prevention | Financial institutions and creditors with covered accounts must run a written identity theft prevention program that detects and responds to red flags, which requires the account-handling systems and their components to be individually identifiable (Red Flags Rule, 16 CFR 681.1) | Scan |
| `FACTA-681.1-DOC` Written, Board-Approved Program | The identity theft prevention program must be written, approved, and periodically updated to reflect changing risks, which is supported by formally identified, timestamped documentation of the systems in scope (16 CFR 681.1(d)-(e)) | Scan |
| `FCRA-INTEG` Integrity of Report-Producing Systems | Accuracy and integrity duties for furnishers and agencies presuppose that the software producing and transmitting consumer report data has not been tampered with, implying integrity verification of deployed components (FCRA accuracy and integrity obligations, incl. 15 U.S.C. 1681s-2 furnisher duties) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ------------------------------------------- |
| `1681b` | Permissible Purpose Controls |
| `1681c` | Prohibited Information Controls |
| `1681e` | Procedures for Accuracy |
| `1681i` | Consumer Dispute Resolution |
| `1681m` | Adverse Action Notices |
| `1681m-redflags` | Red Flags Identity Theft Prevention Program |
| `1681w` | Disposal of Consumer Information |
| `FACTA-216` | Summary of Consumer Rights |
| `1681s2b` | Furnisher Accuracy & Investigation Duties |
## Policy templates
Written for FCRA:
* FCRA Red Flags Identity Theft Prevention Program
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FCRA.
# FDA 21 CFR Part 11 (/docs/frameworks/americas/fda-21cfr-part11)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
FDA Electronic Records and Electronic Signatures - audit trail, validation, access control, integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | 21 CFR 11 |
| Region | Americas |
| Country or scope | United States |
| Sector | Healthcare |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers 21 CFR 11
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for 21 CFR 11.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for 21 CFR 11 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FDA-P11-10A` System Validation Baseline | Systems must be validated to ensure accuracy, reliability and consistent intended performance; validation is only meaningful against a fully enumerated system where every software component is named and versioned (21 CFR § 11.10(a)) | Scan |
| `FDA-P11-10B` Accurate Machine-Readable Copies | Systems must be able to generate accurate and complete copies of records in both human-readable and electronic form suitable for FDA inspection; standardised machine-readable system documentation (SPDX/CycloneDX) satisfies the electronic-copy expectation for the software record (21 CFR § 11.10(b)) | Scan |
| `FDA-P11-10C` Record Protection and Integrity | Records must be protected so they remain accurate and readily retrievable throughout the retention period; cryptographic integrity evidence (hashes) for the software handling those records demonstrates protection against undetected alteration (21 CFR § 11.10(c)) | Scan |
| `FDA-P11-10E` Audit Trail Foundations | Secure, computer-generated, time-stamped audit trails must independently record operator entries and actions; the system documentation itself must carry document identity and creation timestamps to anchor that audit chain (21 CFR § 11.10(e)) | Scan |
| `FDA-P11-10K` Documentation and Change Control | There must be controls over systems documentation, including revision and change-control procedures that maintain an audit trail of modifications; vague or floating component versions (latest, wildcards, ranges) are incompatible with controlled change management (21 CFR § 11.10(k)) | Scan |
| `FDA-P11-50` Signature and Authorship Manifestation | Signed electronic records must show the printed name of the signer and the date, time and meaning of the signing; analogously, the system record must identify who or what tool created it (21 CFR § 11.50) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | -------------------------------- |
| `11.10(a)` | System Validation |
| `11.10(b)` | Record Legibility & Retention |
| `11.10(c)` | Record Protection & Archival |
| `11.10(d)` | System Access Limitation |
| `11.10(e)` | Secure Audit Trails |
| `11.10(f)` | Operational System Checks |
| `11.10(g)` | Authority Checks |
| `11.10(k)` | Personnel Training Controls |
| `11.30` | Open Systems Additional Controls |
| `11.50` | Signature Manifestations |
| `11.70` | Signature/Record Linking |
| `11.100` | Electronic Signature Uniqueness |
| `11.200` | Electronic Signature Components |
| `11.300` | ID Code & Password Controls |
## Policy templates
Written for 21 CFR 11:
* Computer System Validation (CSV) Policy: 21 CFR Part 11
* Electronic Signature Controls Procedure: 21 CFR Part 11
* Audit Trail Review Procedure: 21 CFR Part 11
* Open Systems Security Policy: 21 CFR Part 11
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to 21 CFR 11.
# FDA Medical Device (/docs/frameworks/americas/fda-med-device)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Premarket Cybersecurity Guidance: SBOM submission, component inventory, patch management.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | FDA MDS |
| Region | Americas |
| Country or scope | United States |
| Sector | Healthcare |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers FDA MDS
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for FDA MDS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for FDA MDS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FDA-524B-SBOM` SBOM Submission | Sponsors of cyber devices must provide an SBOM covering commercial, open-source and off-the-shelf software components, in a machine-readable format per FDA guidance (FD\&C Act s. 524B(b)(3); FDA 2023 Premarket Cybersecurity Guidance) | Scan |
| `FDA-524B-INV` Complete Component Inventory | The device SBOM must enumerate the software components contained in the device so the total product lifecycle risk can be assessed (FD\&C Act s. 524B(b)(3)) | Scan |
| `FDA-524B-VER` Component Versions for Patch Management | FDA's guidance expects SBOM entries to include the version of each component so vulnerabilities can be monitored and patched across the device's lifecycle (FDA 2023 Premarket Cybersecurity Guidance - SBOM data elements) | Scan |
| `FDA-524B-SUP` Component Manufacturer Attribution | SBOM entries should identify the manufacturer/supplier of each component, including the level of support, so off-the-shelf software risk can be evaluated (FDA 2023 Premarket Cybersecurity Guidance - SBOM data elements) | Scan |
| `FDA-524B-VULN` Postmarket Vulnerability Monitoring | Manufacturers must monitor, identify and address postmarket vulnerabilities in a reasonable time, requiring components identifiable against vulnerability databases (FD\&C Act s. 524B(b)(1)) | Scan |
| `FDA-524B-INT` Device Software Integrity | Premarket cybersecurity controls include ensuring the integrity and authenticity of device software and updates, supported by cryptographic hashes over components (FDA 2023 Premarket Cybersecurity Guidance - integrity controls) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ----------------------------------------------------------- |
| `V.A.1` | Establish a Software Bill of Materials (SBOM) |
| `V.A.2` | Implement Threat Modeling for Device Software |
| `V.A.3` | Apply Security Controls by Design |
| `V.A.4` | Conduct Cybersecurity Testing |
| `V.B.1` | Establish a Coordinated Vulnerability Disclosure Policy |
| `V.B.2` | Monitor for Cybersecurity Vulnerabilities Post-Market |
| `V.B.3` | Remediate and Patch Vulnerabilities Timely |
| `VI.A.1` | Submit Cybersecurity Documentation in Premarket Submissions |
| `VI.B.1` | Implement Secure Software Update Mechanism |
| `VI.B.2` | Protect Credentials and Authentication |
| `VI.C.1` | Protect Data in Transit and at Rest |
| `VI.D.1` | Maintain Device Audit Logs |
| `VII.A.1` | Adopt a Cybersecurity Framework |
| `VII.B.1` | Provide Customer Cybersecurity Guidance |
## Policy templates
Written for FDA MDS:
* FDA Premarket Cybersecurity Documentation Policy
* FDA Post-Market Cybersecurity Vulnerability Management Policy
* FDA Secure Product Development Lifecycle Policy
* FDA Medical Device Access Control and Authentication Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FDA MDS.
# FedRAMP (/docs/frameworks/americas/fedramp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Federal cloud security and component inventory requirements.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Americas |
| Country or scope | United States |
| Sector | Cloud |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers FedRAMP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for FedRAMP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for FedRAMP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FR-CM-8` System Component Inventory | Authorized cloud services must develop and maintain an accurate, current inventory of system components, including the software within the authorization boundary (FedRAMP baselines; NIST SP 800-53 CM-8) | Scan |
| `FR-CM-8V` Inventory Granularity | The component inventory must include information necessary for accountability, such as software version numbers, to be usable for assessment and incident response (NIST SP 800-53 CM-8 inventory content) | Scan |
| `FR-SI-7` Software Integrity Verification | Providers must employ integrity verification tools to detect unauthorized changes to software, which depends on known-good cryptographic hashes for components (NIST SP 800-53 SI-7) | Scan |
| `FR-RA-5` Vulnerability Scanning Correlation | Monthly vulnerability scanning obligations require components to carry standard identifiers so scan findings map to inventory entries (FedRAMP continuous monitoring; NIST SP 800-53 RA-5) | Scan |
| `FR-SR-4` Supply Chain Provenance | Rev 5 baselines require documenting the provenance of systems and components, attributing software to its developers and suppliers (NIST SP 800-53 SR-4) | Scan |
| `FR-CA-DOC` Authorization Package Evidence | Assessment and authorization artifacts must be identifiable, dated documents maintained across the authorization lifecycle (FedRAMP authorization package requirements; NIST SP 800-53 CA family) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | ------------------------------------------------------------ |
| `FRMP-AC-2` | Cloud account management controls |
| `FRMP-CA-3` | Authorize system interconnections |
| `FRMP-CM-6` | Apply FedRAMP-approved configuration baselines |
| `FRMP-IR-6` | Report incidents to US-CERT and agencies within FedRAMP SLAs |
| `FRMP-RA-5` | Perform FedRAMP-required vulnerability scanning |
| `FRMP-SA-9` | Manage third-party cloud service dependencies |
| `FRMP-SC-28` | Encrypt federal data at rest in cloud storage |
| `FRMP-AU-6` | Review and analyze audit logs for FedRAMP |
| `FRMP-PL-8` | Maintain FedRAMP System Security Plan |
| `FRMP-3PAO` | Engage a FedRAMP-accredited 3PAO for assessments |
| `FRMP-CONMON` | Implement FedRAMP continuous monitoring program |
## Policy templates
Written for FedRAMP:
* FedRAMP Authorization Boundary and System Description Policy
* FedRAMP Incident Reporting and Breach Notification Policy
* FedRAMP Continuous Monitoring Program Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FedRAMP.
# FERPA (/docs/frameworks/americas/ferpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Family Educational Rights and Privacy Act - student records access, consent, directory info handling.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Americas |
| Country or scope | United States |
| Sector | Education |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers FERPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for FERPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for FERPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FERPA-99.31-SO` Direct Control of Outsourced Providers | Education records may be shared without consent with contractors and vendors acting as school officials only if the institution maintains direct control over their use of the records, which requires knowing which suppliers stand behind each system component handling records (34 CFR 99.31(a)(1)(i)(B)) | Scan |
| `FERPA-99.31-RM` Reasonable Methods to Limit Access | Institutions must use reasonable methods to ensure school officials access only records in which they have a legitimate educational interest, which requires the systems and components holding records to be individually identifiable (34 CFR 99.31(a)(1)(ii)) | Scan |
| `FERPA-99.32` Recordkeeping of Disclosures | Institutions must maintain a record of each request for and disclosure of education records, which presupposes formally identified, timestamped documentation of the systems through which records flow (34 CFR 99.32) | Scan |
| `FERPA-1232G-B` Consent-Gated Disclosure Transparency | Federal funding is conditioned on institutions not releasing education records without written consent outside the statutory exceptions; demonstrating this discipline is supported by standard machine-readable descriptions of the record-handling systems (20 U.S.C. 1232g(b)) | Scan |
| `FERPA-SYS-INV` Knowledge of Record-Holding Systems | Meeting access, correction, and disclosure-limitation duties presupposes the institution knows which systems and software components hold education records at all, i.e. an enumerated component inventory (FERPA access and disclosure duties, 20 U.S.C. 1232g / 34 CFR Part 99) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | --------------------------------------- |
| `99.7` | Annual Notice of Rights |
| `99.10` | Access to Education Records |
| `99.20` | Record Amendment Procedure |
| `99.30` | Written Consent for Disclosure |
| `99.31` | Permissible Disclosures Without Consent |
| `99.32` | Disclosure Recordkeeping |
| `99.33` | Third-Party Redisclosure Prohibition |
| `99.34` | Directory Information Policy |
## Policy templates
Written for FERPA:
* FERPA Education Records Access Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FERPA.
# FFIEC CAT (/docs/frameworks/americas/ffiec-cat)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Financial institution cyber risk management, threat intelligence, cybersecurity controls.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | FFIEC |
| Region | Americas |
| Country or scope | United States |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers FFIEC
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for FFIEC.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for FFIEC and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FFIEC-CAT-D1-INV` IT Asset Inventory Baseline | Baseline maturity in cyber risk management requires an inventory of the institution's technology assets, including the software components of business-critical systems (FFIEC CAT Domain 1 - Governance, asset inventory declarative statements) | Scan |
| `FFIEC-CAT-D4-DEP` External Dependency Identification | External dependency management requires identifying third parties and the software connections they provide, attributing components to their external suppliers (FFIEC CAT Domain 4 - External Dependency Management) | Scan |
| `FFIEC-CAT-D3-PATCH` Patch Management Visibility | Cybersecurity controls include a patch management program, which requires current version information for the software in the environment (FFIEC CAT Domain 3 - Preventative Controls, patch management) | Scan |
| `FFIEC-CAT-D2-TI` Threat Intelligence Correlation | Using threat intelligence effectively requires mapping advisories to the institution's own software, so components need standard identifiers (FFIEC CAT Domain 2 - Threat Intelligence and Collaboration) | Scan |
| `FFIEC-CAT-D3-INT` System Integrity Controls | Preventative controls extend to detecting unauthorized changes to software, supported by integrity hashes for deployed components (FFIEC CAT Domain 3 - Cybersecurity Controls) | Scan |
| `FFIEC-CAT-D1-DOC` Assessment Evidence Records | Maturity assessment relies on documented, dated evidence that examiners can verify, so composition documentation must be identifiable and timestamped (FFIEC CAT - assessment process documentation) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ---------------------------------------------------- |
| `D1.G.IT.B.1` | Establish IT Asset Inventory |
| `D1.G.IT.B.2` | Classify Data by Sensitivity |
| `D1.RM.Ra.B.1` | Conduct Enterprise Cyber Risk Assessment |
| `D2.MA.Ma.B.1` | Establish Threat Intelligence Program |
| `D3.PC.Am.B.1` | Implement Network Access Controls |
| `D3.PC.Im.B.1` | Manage Patch and Vulnerability Remediation |
| `D3.CC.Se.B.1` | Encrypt Customer Data in Transit and at Rest |
| `D4.C.Co.B.1` | Implement Cybersecurity Monitoring |
| `D4.C.De.B.1` | Detect Anomalous Transactions |
| `D5.IR.Pl.B.1` | Maintain Incident Response Plan |
| `D5.IR.Re.B.1` | Escalate and Report Cyber Incidents |
| `D1.TC.Te.B.1` | Provide Cybersecurity Awareness Training |
| `D3.PC.Se.B.1` | Manage Third-Party and Supply Chain Risk |
| `D5.BR.Pl.B.1` | Establish Cyber Resilience and Recovery Capabilities |
## Policy templates
Written for FFIEC:
* FFIEC CAT Cybersecurity Risk Management Policy
* FFIEC CAT Cybersecurity Controls Policy
* FFIEC CAT Cyber Incident Response and Notification Policy
* FFIEC CAT Third-Party and Supply Chain Risk Management Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FFIEC.
# FIPS 140-3 (/docs/frameworks/americas/fips-140-3)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Cryptographic modules: crypto component inventory, version pinning, PURL/CPE, hash integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | FIPS |
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers FIPS
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for FIPS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for FIPS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FIPS140-SPEC-INV` Module Component Specification | The cryptographic module specification must define the module's boundary and enumerate all hardware, software and firmware components within it (FIPS 140-3 / ISO/IEC 19790, cryptographic module specification requirements) | Scan |
| `FIPS140-VER` Versioned Module Components | Validation applies to specific versions of the module's software and firmware, so every component must carry an exact version matching the validation certificate (FIPS 140-3 / ISO/IEC 19790, versioning of validated modules) | Scan |
| `FIPS140-VERSPEC` No Floating Crypto Versions | A module cannot remain within its validated configuration if component versions are expressed as ranges or 'latest'; versions must be pinned exactly (FIPS 140-3 validation scope; CMVP guidance on module versioning) | Scan |
| `FIPS140-INTEG` Software Integrity Test Evidence | Modules must perform pre-operational integrity verification of software and firmware using approved techniques, which presupposes published cryptographic digests for the components (FIPS 140-3 / ISO/IEC 19790, pre-operational software/firmware integrity test) | Scan |
| `FIPS140-ID` Unambiguous Component Identification | Life-cycle assurance requires configuration items to be uniquely identified throughout development and delivery, satisfied by standard identifiers such as PURL or CPE (FIPS 140-3 / ISO/IEC 19790, life-cycle assurance - configuration management) | Scan |
| `FIPS140-CM-DOC` Configuration Management Records | Configuration management documentation for the module must be maintained and traceable, requiring identifiable and dated composition records (FIPS 140-3 / ISO/IEC 19790, life-cycle assurance documentation) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------------- | ------------------------------------------------------------------ |
| `FIPS140-3-L1-01` | Use FIPS 140-3 validated cryptographic modules |
| `FIPS140-3-L2-01` | Implement physical security for Level 2 modules |
| `FIPS140-3-KM-01` | Manage cryptographic keys using approved key management procedures |
| `FIPS140-3-AS-01` | Use only approved cryptographic algorithms |
| `FIPS140-3-SE-01` | Protect sensitive security parameters within modules |
| `FIPS140-3-ST-01` | Perform self-tests on cryptographic modules |
| `FIPS140-3-OP-01` | Operate modules in approved operational modes only |
| `FIPS140-3-AU-01` | Audit use of cryptographic modules |
## Policy templates
Written for FIPS:
* FIPS 140-3 Cryptographic Module Selection and Use Policy
* Cryptographic Key Management Policy (FIPS 140-3)
* FIPS-Compliant TLS and Protocol Configuration Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FIPS.
# FISMA (/docs/frameworks/americas/fisma)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Federal Information Security Modernization Act: software inventory, vulnerability, supply chain risk.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers FISMA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for FISMA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for FISMA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FISMA-3505-INV` System and Software Inventory | Agencies must maintain an inventory of major information systems, operationalized through NIST controls requiring component-level software inventories (44 U.S.C. 3505(c); NIST SP 800-53 CM-8) | Scan |
| `FISMA-3554-PROT` Information Integrity Protections | Agencies must provide protections commensurate with risk against unauthorized modification of information and systems, supported by integrity hashes for deployed software (44 U.S.C. 3554(a)(1)(A); NIST SP 800-53 SI-7) | Scan |
| `FISMA-SI-2` Flaw Remediation | Security programs must include processes for planning and remediating deficiencies, requiring current version data for the software in agency systems (44 U.S.C. 3554(b); NIST SP 800-53 SI-2) | Scan |
| `FISMA-RA-5-ID` Scan-to-Inventory Correlation | Periodic testing and vulnerability assessment require components identifiable via standard identifiers so findings map to owned assets (44 U.S.C. 3554(a)(2)(D); NIST SP 800-53 RA-5) | Scan |
| `FISMA-SR-SUP` Supply Chain Risk Visibility | Federal systems must manage supply-chain risk, including knowing the sources of acquired software, per the SR control family adopted in Rev 5 baselines (NIST SP 800-53 SR-3/SR-4 under FISMA implementation) | Scan |
| `FISMA-EO14028` Machine-Readable Composition Evidence | Federal software supply-chain policy following EO 14028 and OMB M-22-18 anticipates SBOMs in standard machine-readable formats (SPDX/CycloneDX) as attestation artifacts (EO 14028 s.4; OMB M-22-18) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ----------------------------------------------- |
| `FISMA-RA-01` | Conduct and document a system risk assessment |
| `FISMA-CA-01` | Obtain Authorization to Operate (ATO) |
| `FISMA-CA-02` | Perform security control assessments |
| `FISMA-PL-02` | Develop and maintain a System Security Plan |
| `FISMA-IR-01` | Establish incident reporting to US-CERT |
| `FISMA-CM-01` | Maintain a continuous monitoring program |
| `FISMA-AT-01` | Provide annual security awareness training |
| `FISMA-SC-01` | Implement FIPS-validated cryptography |
| `FISMA-POA-01` | Manage Plans of Action and Milestones (POA\&M) |
| `FISMA-SA-01` | Apply NIST SP 800-53 security control baselines |
| `FISMA-ID-01` | Categorize information systems per FIPS 199 |
## Policy templates
Written for FISMA:
* System Authorization (ATO) Policy
* Plan of Action and Milestones Management Policy
* Annual FISMA Reporting and Review Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FISMA.
# Florida Digital Bill of Rights (/docs/frameworks/americas/florida-dbr)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Florida Digital Bill of Rights - large-controller obligations, consumer rights, sensitive data, opt-out.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | FL DBR |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers FL DBR
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for FL DBR.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for FL DBR and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FL-DBR-SEC` Data Security Practices | Covered controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices appropriate to the personal data processed; for billion-dollar-scale platforms the expected integrity bar is high (Fla. Stat. §§ 501.701-501.722, controller-duties provisions) | Scan |
| `FL-DBR-MIN` Collection Limitation Accountability | Collection must be limited to what is adequate, relevant and reasonably necessary for disclosed purposes; a named processing platform with enumerated software components is the evidentiary basis at platform scale (Fla. Stat. §§ 501.701-501.722, controller-duties provisions) | Scan |
| `FL-DBR-PROC` Processor Obligations | Processors act under binding contracts with controller instructions and equivalent duties flowed to subcontractors; naming the supplier of each third-party component demonstrates that oversight (Fla. Stat. §§ 501.701-501.722, processor provisions) | Scan |
| `FL-DBR-DPIA` Data Protection Assessment Readiness | Data protection assessments are required for heightened-risk processing including targeted advertising, sale, profiling and sensitive data; recorded versions of the processing software underpin credible assessment (Fla. Stat. §§ 501.701-501.722, data protection assessment provisions) | Scan |
| `FL-DBR-RIGHTS` Consumer Rights Fulfilment | Consumers may confirm processing, access, correct, delete and port personal data, and opt out of targeted advertising, sale, profiling and, distinctively, the collection of data through voice- and facial-recognition features; executing these requires unambiguous identification of the components involved (Fla. Stat. §§ 501.701-501.722, consumer-rights provisions) | Scan |
| `FL-DBR-TRANS` Platform Transparency Documentation | Beyond the standard privacy notice, the act imposes transparency duties on large platforms, including search engines describing their ranking parameters; identified, timestamped system documentation is the foundation for such disclosures (Fla. Stat. §§ 501.701-501.722, transparency provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ------------------------------------------------- |
| `FL-501.701` | Consumer Rights: Access, Deletion & Portability |
| `FL-501.702` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `FL-501.703` | Sensitive Data: Opt-In Consent |
| `FL-501.704` | Data Protection Assessment |
| `FL-501.705` | Processor Agreements |
| `FL-501.706` | Privacy Notice & Opt-Out Link |
| `FL-501.707` | Children's Data: Under 18 Sale Prohibition |
| `FL-501.708` | Security & Breach Response |
## Policy templates
Written for FL DBR:
* Florida DBR State Privacy Notice
* Florida DBR Consumer Rights Request Handling Procedure
* Florida DBR Sensitive Data Consent Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FL DBR.
# FTC Safeguards Rule (/docs/frameworks/americas/ftc-safeguards)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Financial institutions: software inventory, third-party risk, license compliance, change management.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | FTC |
| Region | Americas |
| Country or scope | United States |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers FTC
* **Scan requirements:** 4, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for FTC.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for FTC and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 4 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | ---------- |
| `FTC-SG-314.4(c)` Encryption Component Identification | FTC Safeguards requires encryption of customer financial data: identify encryption components | Scan |
| `FTC-SG-314.4(f)` Third-Party Service Provider Documentation | FTC Safeguards requires oversight of service providers with access to customer information | Scan |
| `FTC-SG-314.4(b)` Access Control Components | FTC Safeguards requires access controls to customer information | Scan |
| `FTC-SG-314.4(h)` Component Integrity Hashes | Safeguards rule requires strong hash algorithms for data integrity verification | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | --------------------------------------------- |
| `314.4(a)` | Designate a Qualified Individual |
| `314.4(b)` | Conduct a Risk Assessment |
| `314.4(c)` | Design and Implement Safeguards |
| `314.4(d)` | Oversee Third-Party Service Providers |
| `314.4(e)` | Evaluate and Adjust the Security Program |
| `314.4(f)` | Implement an Incident Response Plan |
| `314.4(g)` | Report Regularly to the Board |
| `314.4(h)` | Implement Specific Technical Safeguards |
| `314.5` | Maintain Written Information Security Program |
| `314.6` | Provide Notice of Security Breach |
| `314.4(c)(1)` | Implement Access Controls |
| `314.4(c)(6)` | Train and Test Security Personnel |
## Policy templates
Written for FTC:
* FTC Safeguards Rule Information Security Program
* FTC Safeguards Rule Technical Safeguards Policy
* FTC Safeguards Rule Incident Response and Breach Notification Policy
* FTC Safeguards Rule Service Provider Oversight Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FTC.
# GLBA (/docs/frameworks/americas/glba)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Gramm-Leach-Bliley Act - financial privacy rule, safeguards rule, pretexting protection.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Americas |
| Country or scope | United States |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers GLBA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for GLBA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for GLBA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `GLBA-6801B` Statutory Safeguards Mandate | Financial institutions must establish safeguards to insure the security and confidentiality of customer records and protect against anticipated threats and unauthorized access, an obligation documented through a formally identified written security program (15 U.S.C. 6801(b)) | Scan |
| `GLBA-314.4C2` Inventory of Data and Systems | The information security program must identify and manage the data, personnel, devices, systems, and facilities that enable the institution to achieve its business purposes, requiring an enumerated inventory of software components in those systems (16 CFR 314.4(c)(2)) | Scan |
| `GLBA-314.4B` Written Risk Assessment | Institutions must base their safeguards on a written risk assessment identifying reasonably foreseeable risks to customer information; assessing software risk requires each component to be individually identifiable (16 CFR 314.4(b)) | Scan |
| `GLBA-314.4C3` Encryption and Integrity Controls | Customer information must be encrypted in transit over external networks and at rest, a protection posture that presupposes cryptographic integrity verification across the software stack handling that information (16 CFR 314.4(c)(3)) | Scan |
| `GLBA-314.4C4` Secure Development Practices | Institutions must adopt secure development practices for in-house applications and procedures for assessing externally developed applications that handle customer information, which requires precise, non-vague version declarations for the software in use (16 CFR 314.4(c)(4)) | Scan |
| `GLBA-314.4F` Service Provider Oversight | Institutions must take reasonable steps to select service providers capable of maintaining appropriate safeguards, require those safeguards by contract, and periodically assess them: requiring knowledge of the supplier behind each component and service (16 CFR 314.4(f)) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | -------------------------------------------------- |
| `313.4` | Privacy Notice: Initial |
| `313.6` | Privacy Notice: Annual |
| `314.4a` | Information Security Program: Qualified Individual |
| `314.4b` | Risk Assessment |
| `314.4c` | Safeguards: Access Controls |
| `314.4d` | Monitoring & Testing |
| `314.4e` | Service Provider Oversight |
| `314.4f` | Encryption of Customer Information |
| `314.4g` | Incident Response Plan |
| `314.4h` | Annual Board Reporting |
| `314.4i` | Multi-Factor Authentication |
## Policy templates
Written for GLBA:
* GLBA Customer Privacy Notice
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GLBA.
# Greenland Data Protection Act (/docs/frameworks/americas/greenland-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GL DP Act |
| Region | Americas |
| Country or scope | Greenland |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GL DP Act
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GL-DPA-41` Security of Processing | Controllers must implement technical and organisational security measures protecting data against accidental or unlawful destruction, loss, alteration and unauthorised access, including integrity verification of processing software (Act No. 429 of 31 May 2000, § 41) | Scan |
| `GL-DPA-42` Data Processor Agreements | Processing carried out by a data processor must rest on a written agreement guaranteeing the § 41 security measures, requiring supplier visibility for third-party components (Act No. 429 of 31 May 2000, § 42) | Scan |
| `GL-DPA-5` Data Quality and Purpose Limitation | Data must be processed in accordance with good processing practice, kept accurate and up to date, and collected for explicit purposes, presupposing fully described processing components (Act No. 429 of 31 May 2000, § 5) | Scan |
| `GL-DPA-INV` Accountable Processing Operations | Supervision by the Data Protection Authority presumes controllers can account for the systems and software carrying out processing operations (Act No. 429 of 31 May 2000, supervision provisions as applied to Greenland) | Scan |
| `GL-DPA-VER` Maintained Processing Systems | Adequate security under the Act requires processing software to be version-tracked so weaknesses can be assessed and remedied (Act No. 429 of 31 May 2000, § 41 security obligation) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GL DP Act.
# Grenada National ICT / Privacy Framework (/docs/frameworks/americas/grenada-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GD ICT/Priv |
| Region | Americas |
| Country or scope | Grenada |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GD ICT/Priv
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GD-ICT-INTG` Integrity of Electronic Records | The electronic-transactions regime relies on the integrity of electronic records being verifiable, implying integrity data for the software components producing them (Electronic Transactions Act 2008, integrity-of-record provisions) | Scan |
| `GD-ECA-SEC` Protection Against Unauthorized Data Interference | The criminalization of unauthorized access to and interference with computer data presupposes operators can detect tampering in their systems (Electronic Crimes Act 2013, unauthorized-access/data-interference offences) | Scan |
| `GD-FW-INV` Knowledge of Processing Systems | Responsible handling of personal information under the national framework requires knowing which software systems and components process it (Grenadian ICT/privacy framework, general duty of care) | Scan |
| `GD-FW-ID` Identifiability for Incident Response | Investigating electronic-crime incidents requires that system components carry standard identifiers so affected software can be pinpointed (Electronic Crimes Act 2013, incident/investigation context) | Scan |
| `GD-FW-DOC` Verifiable Documentation of Systems | The electronic-records regime expects system documentation to be identifiable and timestamped so records can be attributed and verified (Electronic Transactions Act 2008, record-attribution provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GD ICT/Priv.
# Guatemala Ley de Acceso a la Informacion Publica (/docs/frameworks/americas/guatemala-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GT LAIP |
| Region | Americas |
| Country or scope | Guatemala |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GT LAIP
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GT-LAIP-SEC` Protection of Personal Data Held in Systems | Subjects holding personal data must protect it against alteration, loss, and unauthorized access, implying integrity controls over the systems storing it (Decree 57-2008, personal-data protection duties) | Scan |
| `GT-LAIP-INV` Knowledge of Information Systems | Obligated subjects must know and document the information systems in which personal data resides, presupposing a component inventory (Decree 57-2008, information-systems documentation duties) | Scan |
| `GT-LAIP-HD` Habeas Data Correction Readiness | The right of data subjects to access and correct their personal data requires accurate, current record-keeping systems with tracked versions (Decree 57-2008, habeas data provisions) | Scan |
| `GT-LAIP-TRANS` Transparency of Processing Environment | The law's transparency mandate implies identifiable, timestamped documentation of the systems that handle personal information (Decree 57-2008, transparency obligations) | Scan |
| `GT-LAIP-TP` Third-Party Handling Accountability | Personal data may not be circulated or commercialized without consent, so any third-party components handling it must have identified suppliers (Decree 57-2008, restrictions on transfer of personal data) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GT LAIP.
# Guyana Data Protection Act 2023 (/docs/frameworks/americas/guyana-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GY DPA 2023 |
| Region | Americas |
| Country or scope | Guyana |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GY DPA 2023
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `GY-DPA-SEC` Security of Processing | Controllers and processors must implement appropriate technical and organizational measures to ensure the security and integrity of personal data processing systems (DPA 2023, security-of-processing obligation) | Scan |
| `GY-DPA-ROPA` Records of Processing Activities | Controllers must maintain records of their processing activities, presupposing an inventory of the software components involved (DPA 2023, records-of-processing duty) | Scan |
| `GY-DPA-PROC` Processor Obligations | Processing on behalf of a controller requires binding contracts with sufficient guarantees, so third-party component suppliers must be identified (DPA 2023, processor obligations) | Scan |
| `GY-DPA-BREACH` Breach Notification Readiness | Personal data breaches must be notified to the supervisory authority, requiring the ability to identify exactly which components were affected (DPA 2023, breach-notification duty) | Scan |
| `GY-DPA-ACC` Accuracy Principle | Personal data must be accurate and kept up to date, requiring precise version tracking of the software maintaining it (DPA 2023, accuracy principle) | Scan |
| `GY-DPA-DOC` Accountability Documentation | Controllers must be able to demonstrate compliance through identifiable, timestamped documentation of the processing environment (DPA 2023, accountability principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GY DPA 2023.
# Haiti National Privacy Framework (/docs/frameworks/americas/haiti-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | HT Privacy |
| Region | Americas |
| Country or scope | Haiti |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers HT Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `HT-CONST-49` Confidentiality and Integrity of Communications Systems | The constitutional inviolability of correspondence and communications implies integrity safeguards for the systems that carry and store personal communications (Constitution of 1987 Art. 49) | Scan |
| `HT-FW-INV` Knowledge of Processing Systems | General duties of care over personal information require organizations to know which software systems and components handle it (Haitian privacy framework, general duty of care) | Scan |
| `HT-FW-ID` Identifiability of Processing Components | Responding to privacy complaints or incidents requires that the components processing personal information be identifiable by standard identifiers (Haitian privacy framework, incident-response readiness) | Scan |
| `HT-FW-DOC` Documented Processing Environment | Demonstrating responsible handling of personal information requires an identifiable, timestamped record of the processing environment (Haitian privacy framework, accountability practice) | Scan |
| `HT-FW-VER` Maintained and Current Systems | The general duty of care implies keeping processing software identified by version so defects affecting personal information can be assessed (Haitian privacy framework, duty of care) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to HT Privacy.
# HIPAA / HITECH (/docs/frameworks/americas/hipaa-hitech)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
ePHI software inventory, business associate documentation, integrity controls, audit controls.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | HITECH |
| Region | Americas |
| Country or scope | United States |
| Sector | Healthcare |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers HITECH
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for HITECH.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for HITECH and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `HITECH-13401-BA` Business Associate Direct Liability | HITECH applies the Security Rule's safeguards directly to business associates, making it necessary to identify every vendor supplying software in the ePHI chain (HITECH Act s. 13401; 45 CFR 164.308(b)) | Scan |
| `HITECH-164-400` Breach Notification Readiness | Breaches of unsecured PHI must be discovered, assessed and notified within 60 days, requiring rapid identification of affected software components and their versions (45 CFR 164.400-414, Breach Notification Rule) | Scan |
| `HITECH-164-312B` Audit Controls | Systems containing ePHI must implement mechanisms to record and examine activity, which requires an inventory of the software components subject to audit (45 CFR 164.312(b)) | Scan |
| `HITECH-164-312C` ePHI Integrity Mechanisms | Electronic mechanisms must corroborate that ePHI has not been altered or destroyed in an unauthorized manner, supported by integrity hashes over the processing software (45 CFR 164.312(c)) | Scan |
| `HITECH-RISKID` Vulnerability Identification for ePHI Systems | Ongoing risk analysis and management for ePHI systems requires components identifiable against vulnerability databases via standard identifiers (45 CFR 164.308(a)(1)(ii); HHS Security Risk Assessment guidance) | Scan |
| `HITECH-164-316` Retained Compliance Documentation | Required documentation must be retained for six years from creation or last effective date and be available to those implementing the safeguards, requiring identifiable, timestamped records (45 CFR 164.316(b)) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | --------------------------------------------------- |
| `164.308(a)(1)` | Conduct Enhanced Risk Analysis for ePHI |
| `13402(a)` | Notify Individuals of Breaches |
| `13402(e)(1)` | Notify Secretary of Breaches Affecting 500 or More |
| `13402(f)` | Notify Media for Large Breaches |
| `13405(b)` | Provide Electronic Accounting of Disclosures |
| `13405(c)` | Restrict Disclosures to Health Plans |
| `13410(d)` | Apply Enhanced Penalties for Willful Neglect |
| `164.308(b)(1)` | Extend Security Requirements to Business Associates |
| `164.312(a)(1)` | Implement Meaningful Use Security Controls |
| `164.312(b)` | Maintain Comprehensive Audit Trails for EHR |
| `164.312(e)(2)` | Encrypt ePHI at Rest and in Transit |
| `13401(a)` | Apply Security Rule to Business Associates Directly |
| `164.308(a)(6)` | Implement Security Incident Response and Reporting |
| `164.316(b)(1)` | Document Policies with Retention Schedules |
## Policy templates
Written for HITECH:
* HITECH Enhanced Breach Notification Policy
* HITECH Electronic Health Record Security Policy
* HITECH Business Associate Direct Compliance Policy
* HITECH Security Awareness and Training Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to HITECH.
# HIPAA Security Rule (/docs/frameworks/americas/hipaa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Safeguards for electronic protected health information: integrity controls, audit procedures.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | HIPAA |
| Region | Americas |
| Country or scope | United States |
| Sector | Healthcare |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers HIPAA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 18 controls from Safeguard's control catalog for HIPAA.
* **Automated tests:** 675 map to its controls, and 359 connectors provide automated evidence for them. See [HIPAA Security Rule and connectors](/docs/framework-connectors/hipaa).
* **Policy templates:** 28: 6 written for HIPAA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `HIPAA-164-306` General Safeguard Duty | Covered entities must protect against reasonably anticipated threats to the security and integrity of ePHI, which for software systems includes knowing what software touches ePHI (45 CFR 164.306(a)) | Scan |
| `HIPAA-164-308RA` Risk Analysis Foundations | An accurate and thorough risk analysis of systems handling ePHI requires identifiable software components that can be matched against known vulnerabilities (45 CFR 164.308(a)(1)(ii)(A)) | Scan |
| `HIPAA-164-312C` Integrity Controls | Entities must implement mechanisms to corroborate that ePHI has not been improperly altered or destroyed, extending to integrity verification of the software processing it (45 CFR 164.312(c)(1)) | Scan |
| `HIPAA-164-308BA` Business Associate Assurance | ePHI may only be handled by business associates providing satisfactory assurances, requiring identification of the suppliers behind the software in the ePHI processing chain (45 CFR 164.308(b)) | Scan |
| `HIPAA-164-308SEC` Security Update Awareness | The security management and protection-from-malicious-software processes require knowing component versions so patches and updates can be applied (45 CFR 164.308(a)(1) and (a)(5)(ii)(B)) | Scan |
| `HIPAA-164-316` Documentation Requirements | Policies, procedures and required records must be documented, retained for six years, and kept current, requiring identifiable and dated documentation artifacts (45 CFR 164.316) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ----------------------------------------- |
| `164.308(a)(1)` | Conduct a Security Risk Analysis |
| `164.308(a)(2)` | Assign Security Responsibility |
| `164.308(a)(3)` | Implement Workforce Access Controls |
| `164.308(a)(4)` | Manage Information Access |
| `164.308(a)(5)` | Provide Security Awareness and Training |
| `164.308(a)(6)` | Implement Security Incident Procedures |
| `164.308(a)(7)` | Establish Contingency Plan |
| `164.308(a)(8)` | Perform Periodic Security Evaluations |
| `164.308(b)(1)` | Manage Business Associate Contracts |
| `164.310(a)(1)` | Implement Facility Access Controls |
| `164.310(d)(1)` | Control Device and Media Disposal |
| `164.312(a)(1)` | Implement Technical Access Controls |
| `164.312(b)` | Implement Audit Controls |
| `164.312(c)(1)` | Ensure Integrity of ePHI |
| `164.312(d)` | Implement Person or Entity Authentication |
| `164.312(e)(1)` | Implement Transmission Security |
| `164.314(a)` | Establish Business Associate Agreements |
| `164.316(b)(1)` | Maintain Documentation |
## Policy templates
Written for HIPAA:
* HIPAA Information Security Policy
* HIPAA Access Control and Authentication Policy
* HIPAA Audit Controls and Logging Policy
* HIPAA Breach Notification Policy
* HIPAA Business Associate Management Policy
* HIPAA Encryption and Transmission Security Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to HIPAA.
# HITRUST CSF (/docs/frameworks/americas/hitrust-csf)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Health Information Trust Alliance: asset management, vendor management, software integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | HITRUST |
| Region | Americas |
| Country or scope | United States |
| Sector | Healthcare |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers HITRUST
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 17 controls from Safeguard's control catalog for HITRUST.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 27: 5 written for HITRUST and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `HITRUST-07A` Inventory of Assets | All assets, including software components, must be identified and an inventory drawn up and maintained (HITRUST CSF control 07.a Inventory of Assets) | Scan |
| `HITRUST-10H` Control of Operational Software | Installation and versions of operational software must be controlled so the organization knows exactly which software releases are running (HITRUST CSF control 10.h Control of Operational Software) | Scan |
| `HITRUST-10M` Technical Vulnerability Management | Technical vulnerabilities must be identified in a timely fashion, which requires components to be identifiable against vulnerability databases (HITRUST CSF control 10.m Control of Technical Vulnerabilities) | Scan |
| `HITRUST-09J` Integrity Against Malicious Code | Detection and prevention controls against malicious code require the ability to verify the integrity of deployed software components (HITRUST CSF control 09.j Controls Against Malicious Code) | Scan |
| `HITRUST-05I` Third-Party and Vendor Risk | Risks from external parties supplying software must be identified, which requires knowing the supplier of each component (HITRUST CSF control 05.i Identification of Risks Related to External Parties) | Scan |
| `HITRUST-06-IPR` Intellectual Property Compliance | Use of software must comply with legal and contractual restrictions on intellectual property, requiring license information for components (HITRUST CSF category 06 Compliance, IPR control) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | --------------------------------------------- |
| `01.a` | Access Control Policy |
| `01.b` | User Registration and De-Registration |
| `01.c` | Privilege Management |
| `01.d` | User Password Management |
| `02.a` | Information Classification |
| `03.a` | Risk Management Program |
| `04.a` | Security Policy Document |
| `05.a` | Management Commitment to Information Security |
| `06.a` | Identification of Applicable Legislation |
| `07.a` | Asset Inventory |
| `09.aa` | Audit Logging |
| `09.ab` | Monitoring System Use |
| `09.i` | Electronic Commerce Security |
| `10.a` | Security Requirements of Information Systems |
| `11.a` | Reporting Information Security Events |
| `12.a` | Business Continuity Management |
| `13.a` | Third-Party Service Agreements |
## Policy templates
Written for HITRUST:
* HITRUST Information Security Management Policy
* HITRUST Access Control and Privilege Management Policy
* HITRUST Asset Management Policy
* HITRUST Third-Party and Vendor Security Policy
* HITRUST Security Incident Management Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to HITRUST.
# Honduras Ley de Transparencia (Habeas Data) (/docs/frameworks/americas/honduras-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | HN Transp |
| Region | Americas |
| Country or scope | Honduras |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers HN Transp
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `HN-TRANSP-SEC` Safeguarding Confidential Personal Data | Personal data classified as confidential must be safeguarded against unauthorized access and alteration, implying integrity controls over the systems holding it (Decree 170-2006, confidential-data provisions) | Scan |
| `HN-TRANSP-INV` Documented Information Systems | Obligated institutions must organize and document their information holdings, presupposing an inventory of the software systems involved (Decree 170-2006, information-management duties) | Scan |
| `HN-HD-182` Habeas Data Correction Readiness | The constitutional habeas data action to access, rectify, or delete personal records requires accurate systems with tracked software versions (Constitution of Honduras Art. 182, habeas data) | Scan |
| `HN-TRANSP-DOC` Transparency Documentation | The transparency mandate implies identifiable, timestamped documentation of the processing environment holding personal information (Decree 170-2006, transparency obligations) | Scan |
| `HN-TRANSP-TP` Third-Party Handling Controls | Confidential personal data may only be shared under legal grounds, so third-party components handling it must have identified suppliers (Decree 170-2006, limits on disclosure of confidential data) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to HN Transp.
# Illinois BIPA (/docs/frameworks/americas/il-bipa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Illinois Biometric Information Privacy Act - written consent, retention schedule, private right of action.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | BIPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers BIPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for BIPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for BIPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IL-BIPA-15E` Reasonable Standard of Care in Storage | Private entities must store, transmit, and protect biometric data using the reasonable standard of care within their industry, which implies verifiable integrity of the software systems storing and transmitting that data (740 ILCS 14/15(e)) | Scan |
| `IL-BIPA-15A` Retention Schedule and Destruction Policy | Entities in possession of biometric data must maintain a written, publicly available retention schedule and destruction guidelines, which requires formally identified, timestamped documentation of the systems holding the data (740 ILCS 14/15(a)) | Scan |
| `IL-BIPA-15B` Informed Written Consent Transparency | Collection of biometric data requires prior written notice and a written release from the subject; supporting such demonstrable transparency calls for standard machine-readable descriptions of the collecting systems (740 ILCS 14/15(b)) | Scan |
| `IL-BIPA-15D` Disclosure and Third-Party Restrictions | Biometric data may not be disclosed or disseminated without consent or another statutory basis; enforcing this restriction requires knowing which suppliers and third-party components can access or move the data (740 ILCS 14/15(d)) | Scan |
| `IL-BIPA-INV` Knowledge of Biometric Processing Systems | Complying with retention, destruction, and protection duties presupposes the entity knows which systems and software components hold or process biometric data at all, i.e. an enumerated component inventory (740 ILCS 14/15, possession-based duties) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------ | -------------------------------------------- |
| `BIPA-10` | Biometric Identifier Definitions |
| `BIPA-15a` | Written Retention & Destruction Policy |
| `BIPA-15b` | Informed Written Consent |
| `BIPA-15c` | Prohibition on Sale or Profit |
| `BIPA-15d` | Third-Party Disclosure Restrictions |
| `BIPA-15e` | Storage & Transmission Standards |
| `BIPA-20` | Private Right of Action Remediation Tracking |
| `BIPA-15a-DESTROY` | Biometric Data Destruction |
## Policy templates
Written for BIPA:
* BIPA Written Biometric Data Policy
* BIPA Informed Consent Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BIPA.
# Americas (/docs/frameworks/americas)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Laws, regulations and standards of North, Central and South America and the Caribbean. Each framework's page lists what a scan checks, its controls, its policy templates and its automated tests. How coverage works: [Compliance frameworks](/docs/frameworks).
| Framework | Country or scope | Sector | Scan requirements | Catalog controls |
| ---------------------------------------------------------------------------------------------------------- | -------------------------------- | ---------- | ----------------- | ---------------- |
| [Anguilla Data Protection Act 2020](/docs/frameworks/americas/anguilla-dpa) | Anguilla | Privacy | 5 | None |
| [Antigua and Barbuda Data Protection Act 2013](/docs/frameworks/americas/antigua-barbuda-dpa) | Antigua and Barbuda | Privacy | 5 | None |
| [Argentina PDPL (Law 25.326)](/docs/frameworks/americas/argentina-pdpl) | Argentina | Privacy | 6 | 10 |
| [Aruba Personal Data Protection Ordinance](/docs/frameworks/americas/aruba-dp) | Aruba | Privacy | 5 | None |
| [Bahamas Data Protection Act 2003](/docs/frameworks/americas/bahamas-dppa) | Bahamas | Privacy | 5 | None |
| [Barbados Data Protection Act 2019](/docs/frameworks/americas/barbados-dpa) | Barbados | Privacy | 6 | None |
| [Belize Data Protection Act 2021](/docs/frameworks/americas/belize-dpa) | Belize | Privacy | 6 | None |
| [Bermuda Personal Information Protection Act 2016](/docs/frameworks/americas/bermuda-pipa) | Bermuda | Privacy | 6 | None |
| [Bolivia Supreme Decree 1793](/docs/frameworks/americas/bolivia-dp) | Bolivia | Privacy | 5 | None |
| [Brazil LGPD](/docs/frameworks/americas/brazil-lgpd) | Brazil | Privacy | 6 | 12 |
| [British Virgin Islands Data Protection Act 2021](/docs/frameworks/americas/bvi-dpa) | British Virgin Islands | Privacy | 6 | None |
| [Canada CPPA](/docs/frameworks/americas/canada-cppa) | Canada | Privacy | 6 | 10 |
| [Canada PIPEDA](/docs/frameworks/americas/canada-pipeda) | Canada | Privacy | 6 | 11 |
| [Cayman Islands Data Protection Act 2017](/docs/frameworks/americas/cayman-islands-dpa) | Cayman Islands | Privacy | 6 | None |
| [CCPA / CPRA](/docs/frameworks/americas/ccpa-cpra) | United States | Privacy | 4 | 14 |
| [Chile Law 19.628](/docs/frameworks/americas/chile-19628) | Chile | Privacy | 5 | 10 |
| [CMMC 2.0](/docs/frameworks/americas/cmmc) | United States | Defense | 6 | 13 |
| [Colombia Law 1581](/docs/frameworks/americas/colombia-1581) | Colombia | Privacy | 6 | 11 |
| [Colorado CPA](/docs/frameworks/americas/colorado-cpa) | United States | Privacy | 6 | 9 |
| [Connecticut CTDPA](/docs/frameworks/americas/connecticut-ctdpa) | United States | Privacy | 6 | 9 |
| [COPPA](/docs/frameworks/americas/coppa) | United States | Privacy | 5 | 9 |
| [Costa Rica Law No. 8968 on Personal Data](/docs/frameworks/americas/costa-rica-law8968) | Costa Rica | Privacy | 5 | None |
| [Cuba Law 149/2022 on Personal Data Protection](/docs/frameworks/americas/cuba-dp) | Cuba | Privacy | 5 | None |
| [Curacao Personal Data Protection Ordinance](/docs/frameworks/americas/curacao-dp) | Curacao | Privacy | 5 | None |
| [Delaware PDPA](/docs/frameworks/americas/delaware-pdpa) | United States | Privacy | 6 | 9 |
| [DFARS 252.204-7012](/docs/frameworks/americas/dfars-7012) | United States | Defense | 6 | 8 |
| [Dominica National ICT / Privacy Framework](/docs/frameworks/americas/dominica-privacy) | Dominica | Privacy | 5 | None |
| [Dominican Republic Law No. 172-13 on Personal Data](/docs/frameworks/americas/dominican-republic-law172) | Dominican Republic | Privacy | 5 | None |
| [Ecuador Organic Law on Personal Data Protection](/docs/frameworks/americas/ecuador-lopdp) | Ecuador | Privacy | 6 | None |
| [El Salvador Cybersecurity and Information Security Law 2024](/docs/frameworks/americas/el-salvador-cyber) | El Salvador | Government | 6 | None |
| [El Salvador Personal Data Protection Law 2024](/docs/frameworks/americas/el-salvador-lpdp) | El Salvador | Privacy | 6 | None |
| [Falkland Islands Data Protection Ordinance](/docs/frameworks/americas/falkland-islands-dp) | Falkland Islands | Privacy | 5 | None |
| [FCRA / FACTA](/docs/frameworks/americas/fcra) | United States | Finance | 6 | 9 |
| [FDA 21 CFR Part 11](/docs/frameworks/americas/fda-21cfr-part11) | United States | Healthcare | 6 | 14 |
| [FDA Medical Device](/docs/frameworks/americas/fda-med-device) | United States | Healthcare | 6 | 14 |
| [FedRAMP](/docs/frameworks/americas/fedramp) | United States | Cloud | 6 | 11 |
| [FERPA](/docs/frameworks/americas/ferpa) | United States | Education | 5 | 8 |
| [FFIEC CAT](/docs/frameworks/americas/ffiec-cat) | United States | Finance | 6 | 14 |
| [FIPS 140-3](/docs/frameworks/americas/fips-140-3) | United States | Government | 6 | 8 |
| [FISMA](/docs/frameworks/americas/fisma) | United States | Government | 6 | 11 |
| [Florida Digital Bill of Rights](/docs/frameworks/americas/florida-dbr) | United States | Privacy | 6 | 8 |
| [FTC Safeguards Rule](/docs/frameworks/americas/ftc-safeguards) | United States | Finance | 4 | 12 |
| [GLBA](/docs/frameworks/americas/glba) | United States | Finance | 6 | 11 |
| [Greenland Data Protection Act](/docs/frameworks/americas/greenland-dp) | Greenland | Privacy | 5 | None |
| [Grenada National ICT / Privacy Framework](/docs/frameworks/americas/grenada-privacy) | Grenada | Privacy | 5 | None |
| [Guatemala Ley de Acceso a la Informacion Publica](/docs/frameworks/americas/guatemala-dp) | Guatemala | Privacy | 5 | None |
| [Guyana Data Protection Act 2023](/docs/frameworks/americas/guyana-dpa) | Guyana | Privacy | 6 | None |
| [Haiti National Privacy Framework](/docs/frameworks/americas/haiti-dp) | Haiti | Privacy | 5 | None |
| [HIPAA / HITECH](/docs/frameworks/americas/hipaa-hitech) | United States | Healthcare | 6 | 14 |
| [HIPAA Security Rule](/docs/frameworks/americas/hipaa) | United States | Healthcare | 6 | 18 |
| [HITRUST CSF](/docs/frameworks/americas/hitrust-csf) | United States | Healthcare | 6 | 17 |
| [Honduras Ley de Transparencia (Habeas Data)](/docs/frameworks/americas/honduras-dp) | Honduras | Privacy | 5 | None |
| [Illinois BIPA](/docs/frameworks/americas/il-bipa) | United States | Privacy | 5 | 8 |
| [Indiana CDPA](/docs/frameworks/americas/indiana-cdpa) | United States | Privacy | 6 | 8 |
| [Iowa CDPA](/docs/frameworks/americas/iowa-cdpa) | United States | Privacy | 5 | 7 |
| [Jamaica DPA](/docs/frameworks/americas/jamaica-dpa) | Jamaica | Privacy | 6 | 11 |
| [Maryland MODPA](/docs/frameworks/americas/maryland-modpa) | United States | Privacy | 7 | 8 |
| [Massachusetts 201 CMR 17.00](/docs/frameworks/americas/ma-201cmr17) | United States | Privacy | 6 | 10 |
| [Mexico LFPDPPP](/docs/frameworks/americas/mexico-lfpdppp) | Mexico | Privacy | 6 | 10 |
| [Minnesota CDPA](/docs/frameworks/americas/minnesota-cdpa) | United States | Privacy | 6 | 8 |
| [Montana CDPA](/docs/frameworks/americas/montana-cdpa) | United States | Privacy | 6 | 8 |
| [Montserrat National ICT / Privacy Framework](/docs/frameworks/americas/montserrat-dp) | Montserrat | Privacy | 5 | None |
| [NDAA Section 889](/docs/frameworks/americas/ndaa-section-889) | United States | Defense | 5 | 8 |
| [NERC CIP](/docs/frameworks/americas/nerc-cip) | United States | Energy | 6 | 12 |
| [New Hampshire DPA](/docs/frameworks/americas/new-hampshire-dpa) | United States | Privacy | 6 | 8 |
| [New Jersey CDPA](/docs/frameworks/americas/new-jersey-cdpa) | United States | Privacy | 6 | 8 |
| [Nicaragua Law No. 787 on Personal Data](/docs/frameworks/americas/nicaragua-law787) | Nicaragua | Privacy | 5 | None |
| [NIST AI RMF](/docs/frameworks/americas/nist-ai-rmf) | United States | AI | 4 | 13 |
| [NIST CSF 2.0](/docs/frameworks/americas/nist-csf) | United States | Government | 7 | 12 |
| [NIST CSF 2.0 (Full)](/docs/frameworks/americas/nist-csf-2) | United States | Government | 6 | 13 |
| [NIST Privacy Framework](/docs/frameworks/americas/nist-privacy-framework) | United States | Privacy | 6 | 12 |
| [NIST SP 800-161](/docs/frameworks/americas/nist-sp800-161) | United States | Government | 6 | 12 |
| [NIST SP 800-171](/docs/frameworks/americas/nist-sp800-171) | United States | Defense | 5 | 12 |
| [NIST SP 800-207](/docs/frameworks/americas/nist-sp800-207) | United States | Government | 4 | 11 |
| [NIST SP 800-218A](/docs/frameworks/americas/nist-sp800-218a) | United States | AI | 6 | 11 |
| [NIST SP 800-37 RMF](/docs/frameworks/americas/nist-sp800-37) | United States | Government | 6 | 13 |
| [NIST SP 800-53](/docs/frameworks/americas/nist-sp800-53) | United States | Government | 7 | 15 |
| [NIST SP 800-63](/docs/frameworks/americas/nist-sp800-63) | United States | Government | 6 | 12 |
| [NIST SP 800-66 r2](/docs/frameworks/americas/nist-sp800-66) | United States | Healthcare | 6 | 10 |
| [NIST SP 800-82](/docs/frameworks/americas/nist-sp800-82) | United States | Energy | 6 | 12 |
| [NIST SSDF](/docs/frameworks/americas/nist-ssdf) | United States | Government | 6 | 14 |
| [NY DFS 23 NYCRR 500](/docs/frameworks/americas/nyc-dfs-500) | United States | Finance | 7 | 15 |
| [NY SHIELD Act](/docs/frameworks/americas/ny-shield-act) | United States | Privacy | 5 | 11 |
| [Oregon OCPA](/docs/frameworks/americas/oregon-ocpa) | United States | Privacy | 6 | 8 |
| [Panama Law No. 81 of 2019 on Personal Data](/docs/frameworks/americas/panama-law81) | Panama | Privacy | 6 | None |
| [Paraguay Law No. 6534/2020 on Personal Data](/docs/frameworks/americas/paraguay-law6534) | Paraguay | Privacy | 5 | None |
| [Peru Law 29733](/docs/frameworks/americas/peru-29733) | Peru | Privacy | 5 | 10 |
| [Puerto Rico Act 111-2005 / US Frameworks](/docs/frameworks/americas/puerto-rico-dp) | Puerto Rico | Privacy | 5 | None |
| [Quebec Law 25](/docs/frameworks/americas/quebec-law25) | Canada | Privacy | 6 | 9 |
| [Saint Kitts and Nevis Data Protection Act 2018](/docs/frameworks/americas/saint-kitts-dpa) | Saint Kitts and Nevis | Privacy | 5 | None |
| [Saint Lucia Data Protection Act](/docs/frameworks/americas/saint-lucia-dpa) | Saint Lucia | Privacy | 5 | None |
| [Saint Vincent National ICT / Privacy Framework](/docs/frameworks/americas/saint-vincent-privacy) | Saint Vincent and the Grenadines | Privacy | 5 | None |
| [SOC2 Type 1](/docs/frameworks/americas/soc2) | United States | General | 61 | 61 |
| [SOC2 Type 2](/docs/frameworks/americas/soc2-type2) | United States | General | 61 | 61 |
| [SOX ITGC](/docs/frameworks/americas/sox-itgc) | United States | Finance | 6 | 14 |
| [StateRAMP](/docs/frameworks/americas/stateramp) | United States | Cloud | 6 | 9 |
| [Suriname National Privacy Framework](/docs/frameworks/americas/suriname-dp) | Suriname | Privacy | 5 | None |
| [Tennessee TIPA](/docs/frameworks/americas/tennessee-tipa) | United States | Privacy | 6 | 8 |
| [Texas TDPSA](/docs/frameworks/americas/texas-tdpsa) | United States | Privacy | 6 | 9 |
| [Trinidad and Tobago Data Protection Act 2011](/docs/frameworks/americas/trinidad-tobago-dpa) | Trinidad and Tobago | Privacy | 5 | None |
| [TSA Pipeline Security Directives](/docs/frameworks/americas/tsa-pipeline) | United States | Energy | 6 | 10 |
| [Turks and Caicos Data Protection Ordinance](/docs/frameworks/americas/turks-caicos-dp) | Turks and Caicos | Privacy | 5 | None |
| [Uruguay Law 18.331](/docs/frameworks/americas/uruguay-18331) | Uruguay | Privacy | 5 | 9 |
| [Utah UCPA](/docs/frameworks/americas/utah-ucpa) | United States | Privacy | 6 | 8 |
| [Venezuela Constitutional Habeas Data](/docs/frameworks/americas/venezuela-dp) | Venezuela | Privacy | 5 | None |
| [Virginia CDPA](/docs/frameworks/americas/virginia-cdpa) | United States | Privacy | 6 | 10 |
| [Washington My Health My Data Act](/docs/frameworks/americas/washington-mhmda) | United States | Healthcare | 6 | 11 |
# Indiana CDPA (/docs/frameworks/americas/indiana-cdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Indiana Consumer Data Protection Act - controller obligations, consumer rights.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | IN CDPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers IN CDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for IN CDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for IN CDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IN-CDPA-SEC` Data Security Practices | Controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices appropriate to the volume and nature of the personal data; integrity-verifiable processing software evidences this duty (Ind. Code art. 24-15, controller-duties provisions) | Scan |
| `IN-CDPA-MIN` Minimisation Accountability | Collection must be limited to what is adequate, relevant and reasonably necessary for the disclosed purposes, which presumes an inventory of the software components that process consumer data (Ind. Code art. 24-15, controller-duties provisions) | Scan |
| `IN-CDPA-PROC` Processor Obligations | Processors act only under binding contracts specifying instructions, data categories and flow-down duties to subcontractors; named suppliers on third-party components demonstrate the required oversight (Ind. Code art. 24-15, processor provisions) | Scan |
| `IN-CDPA-DPIA` Data Protection Assessment Readiness | Data protection assessments are required for targeted advertising, sale, risky profiling and sensitive-data processing; assessment credibility depends on recorded versions of the processing software (Ind. Code art. 24-15, data protection assessment provisions) | Scan |
| `IN-CDPA-RIGHTS` Consumer Rights Fulfilment | Consumers may confirm processing, access, correct, delete and port personal data (or a representative summary) and opt out of targeted advertising, sale and profiling; systems holding the data must be unambiguously identifiable (Ind. Code art. 24-15, consumer-rights provisions) | Scan |
| `IN-CDPA-NOTICE` Privacy Notice Documentation | Controllers must provide a reasonably accessible, clear and meaningful privacy notice; supporting system documentation should carry document identity and a creation timestamp so disclosures remain auditable (Ind. Code art. 24-15, transparency provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ----------------------------------------------------------- |
| `IC-24-15-3-1` | Consumer Rights: Access, Correction, Deletion & Portability |
| `IC-24-15-4-1` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `IC-24-15-5-1` | Sensitive Data: Opt-Out Model |
| `IC-24-15-6-1` | Data Protection Assessment |
| `IC-24-15-7-1` | Processor Agreements |
| `IC-24-15-2-1` | Privacy Notice |
| `IC-24-15-3-2` | Consumer Appeals |
| `IC-24-15-8-1` | Security & Data Minimization |
## Policy templates
Written for IN CDPA:
* Indiana CDPA State Privacy Notice
* Indiana CDPA Consumer Rights Request Handling Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to IN CDPA.
# Iowa CDPA (/docs/frameworks/americas/iowa-cdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Iowa Consumer Data Protection Act - controller obligations, consumer rights, sensitive data.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | IA CDPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers IA CDPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for IA CDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for IA CDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IA-CDPA-SEC` Reasonable Data Security | Controllers must adopt and implement reasonable administrative, technical and physical safeguards appropriate to the volume and nature of the personal data at issue; integrity evidence for the processing software supports that duty (Iowa Code ch. 715D, controller-duties provision) | Scan |
| `IA-CDPA-INV` Processing System Accountability | Calibrating safeguards to the amount and nature of the data processed presumes the controller can enumerate the software systems that store or process consumer data (Iowa Code ch. 715D, controller-duties provision) | Scan |
| `IA-CDPA-PROC` Processor Contract Duties | Processing on a controller's behalf must be governed by a contract addressing instructions, confidentiality and subcontractor flow-down; naming the supplier behind each third-party component demonstrates that chain (Iowa Code ch. 715D, processor provisions) | Scan |
| `IA-CDPA-RIGHTS` Consumer Rights Response Readiness | Consumers may confirm processing, access and delete personal data, obtain a portable copy, and opt out of sale; responding within the statutory 90-day window requires the systems holding the data to be unambiguously identifiable (Iowa Code ch. 715D, consumer-rights provisions) | Scan |
| `IA-CDPA-NOTICE` Privacy Notice and Sensitive-Data Disclosure | Controllers must provide a reasonably accessible, clear privacy notice, including the notice-and-opt-out disclosure required before processing sensitive data; supporting documentation should carry document identity and a creation timestamp (Iowa Code ch. 715D, transparency provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | ----------------------------------------------- |
| `IA-715D.2` | Consumer Rights: Access, Deletion & Portability |
| `IA-715D.3` | Opt-Out of Sale & Targeted Advertising |
| `IA-715D.4` | Sensitive Data: Opt-Out Model |
| `IA-715D.5` | Processor Agreements |
| `IA-715D.1` | Privacy Notice |
| `IA-715D.6` | Security Safeguards |
| `IA-715D.7` | Non-Discrimination |
## Policy templates
Written for IA CDPA:
* Iowa CDPA State Privacy Notice
* Iowa CDPA Consumer Rights Request Handling Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to IA CDPA.
# Jamaica DPA (/docs/frameworks/americas/jamaica-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Jamaica Data Protection Act (2020) - 8 standards, registration, data subject rights, breach notification.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | JM DPA |
| Region | Americas |
| Country or scope | Jamaica |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers JM DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for JM DPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for JM DPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `JM-DPA-STD7` Seventh Standard: Security Measures | Appropriate technical and organisational measures must protect personal data against unauthorised or unlawful processing and against accidental loss or damage, which for processing software includes verifiable artifact integrity (DPA 2020 seventh data protection standard) | Scan |
| `JM-DPA-REG` Registration of Data Controllers | Data controllers must register with the Information Commissioner with particulars describing their processing, requiring identifiable, dated documentation of the systems used (DPA 2020 controller registration provisions) | Scan |
| `JM-DPA-BREACH` Security Breach Notification Readiness | Security breaches affecting personal data must be notified to the Information Commissioner within seventy-two hours, requiring the ability to determine exactly which components were compromised (DPA 2020 breach notification obligation) | Scan |
| `JM-DPA-STD8` Eighth Standard: Transfers and Third Parties | Personal data must not be transferred without adequate protection, and processing through third parties requires equivalent safeguards, extending to visibility over who supplies processing software components (DPA 2020 eighth data protection standard and processor provisions) | Scan |
| `JM-DPA-QUAL` Adequacy and Accuracy Standards | The standards require data to be adequate, relevant, accurate and kept up to date; a processing environment evidences this discipline through a complete software inventory with names and versions (DPA 2020 data quality standards) | Scan |
| `JM-DPA-INV` Accountability for Processing Systems | Controllers must be able to demonstrate compliance with the standards, which presumes maintained knowledge of the systems and components performing processing (DPA 2020 accountability/duty-to-comply provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ----------------------------------- |
| `JM-STD1` | Lawfulness of Processing |
| `JM-STD2` | Purpose Limitation |
| `JM-STD3` | Adequacy & Data Minimisation |
| `JM-STD4` | Accuracy & Keeping Up To Date |
| `JM-STD5` | Retention Limitation |
| `JM-STD6` | Data Subject Rights |
| `JM-STD7` | Security of Personal Information |
| `JM-STD8` | International Transfer Standard |
| `JM-23` | Data Controller Registration |
| `JM-27` | Breach Notification Procedure |
| `JM-31` | Data Protection Officer Appointment |
## Policy templates
Written for JM DPA:
* Jamaica DPA Registration Pack
* Jamaica DPA Security & Breach Management Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to JM DPA.
# Massachusetts 201 CMR 17.00 (/docs/frameworks/americas/ma-201cmr17)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Massachusetts Standards for Protection of Personal Information - WISP, encryption, vendor mgmt.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | MA 201 CMR |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers MA 201 CMR
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for MA 201 CMR.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for MA 201 CMR and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MA-201-17.03` Written Information Security Program | Every covered entity must develop and maintain a comprehensive, documented written information security program appropriate to its size and the data held, supported by formally identified and timestamped technical documentation of its systems (201 CMR 17.03(1)) | Scan |
| `MA-201-17.03-VENDOR` Third-Party Service Provider Oversight | The WISP must include taking reasonable steps to select and retain service providers capable of maintaining appropriate security measures and requiring such measures by contract, which requires knowing the supplier of each component and service in use (201 CMR 17.03(2)(f)) | Scan |
| `MA-201-17.04-PATCH` Reasonably Up-to-Date System Software | Computer system security requirements include reasonably up-to-date firewall protection and operating system security patches; determining whether software is up to date requires knowing the version of every deployed component (201 CMR 17.04 patching/firewall element) | Scan |
| `MA-201-17.04-MALW` Current Protective Software Versions | The regulation requires reasonably up-to-date versions of system security agent software, set to receive current updates; this excludes vague or floating version declarations for security-relevant components (201 CMR 17.04 malware-protection element) | Scan |
| `MA-201-17.04-ENC` Encryption and Integrity of Records | Personal information transmitted across public networks or stored on portable devices must be encrypted, a protection level that presupposes cryptographic integrity controls across the software stack handling those records (201 CMR 17.04 encryption elements) | Scan |
| `MA-201-17.04-MON` System Monitoring Readiness | The WISP must include reasonable monitoring of systems for unauthorized use of or access to personal information, which requires the monitored systems and their components to be individually identifiable (201 CMR 17.04 monitoring element) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------------ | ------------------------------------------- |
| `17.03-WISP` | Written Information Security Program (WISP) |
| `17.03-RISK` | Risk Assessment & Identification |
| `17.03-VENDOR` | Vendor Management & Contracts |
| `17.03-TRAINING` | Employee Security Training |
| `17.04-NETWORK` | Secure Network Architecture |
| `17.04-ACCESS` | Access Control & Authentication |
| `17.04-ENCRYPT-TRANSIT` | Encryption of PI in Transit |
| `17.04-ENCRYPT-PORTABLE` | Encryption of PI on Portable Devices |
| `17.04-MONITOR` | Monitoring & Incident Detection |
| `17.04-DISPOSAL` | Secure Disposal of Records |
## Policy templates
Written for MA 201 CMR:
* Written Information Security Program (WISP)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MA 201 CMR.
# Maryland MODPA (/docs/frameworks/americas/maryland-modpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Maryland Online Data Privacy Act - strongest US state privacy regime, data minimisation, sale prohibition.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | MD MODPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers MD MODPA
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for MD MODPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for MD MODPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MD-MODPA-SEC` Data Security Practices | Controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices appropriate to the data processed; given MODPA's strictness, integrity verification across the processing stack is expected at a high bar (Maryland MODPA, controller-duties provision) | Scan |
| `MD-MODPA-STRICTMIN` Strict Data Minimisation Evidence | Collection is lawful only when reasonably necessary and proportionate to provide a specifically requested product or service: a stricter standard than any peer state law; demonstrating necessity requires a complete, precisely described inventory of every component that touches personal data (Maryland MODPA, data-minimisation provisions) | Scan |
| `MD-MODPA-INV` Processing System Inventory | The heightened minimisation and sensitive-data duties presume the controller can enumerate every software system through which consumer data flows (Maryland MODPA, controller-duties provisions) | Scan |
| `MD-MODPA-PROC` Processor and Vendor Oversight | Processors act under binding contracts with flow-down obligations to subcontractors, and the sensitive-data sale ban makes downstream vendor accountability critical; each third-party component should carry a named supplier (Maryland MODPA, processor provisions) | Scan |
| `MD-MODPA-FLOWS` Sensitive Data Flow Mapping | Because selling sensitive data is prohibited outright, controllers must be able to trace how data moves between systems and third parties; a documented dependency graph among processing components evidences that flow control (Maryland MODPA, sensitive-data sale prohibition) | Scan |
| `MD-MODPA-DPIA` Data Protection Assessment Readiness | Data protection assessments are required for heightened-risk processing, including an assessment for each algorithm used; credible per-algorithm assessment requires precise version records for the software involved (Maryland MODPA, data protection assessment provisions) | Scan |
| `MD-MODPA-RIGHTS` Consumer Rights Fulfilment | Consumers hold access, correction, deletion, portability and opt-out rights, with universal opt-out recognition; the strictness of the regime warrants a high bar for unambiguous identification of the components holding consumer data (Maryland MODPA, consumer-rights provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ----------------------------------------------------------- |
| `MD-CL-14-4604` | Consumer Rights: Access, Correction, Deletion & Portability |
| `MD-CL-14-4605` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `MD-CL-14-4606` | Sensitive Data: Opt-In Consent & Data Minimization |
| `MD-CL-14-4608` | Data Protection Assessment |
| `MD-CL-14-4609` | Processor Agreements |
| `MD-CL-14-4603` | Privacy Notice Transparency |
| `MD-CL-14-4607` | Children's Data: Heightened Protection |
| `MD-CL-14-4610` | Non-Discrimination & Security |
## Policy templates
Written for MD MODPA:
* Maryland MODPA State Privacy Notice
* Maryland MODPA Sensitive Data Consent & Minimization Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MD MODPA.
# Mexico LFPDPPP (/docs/frameworks/americas/mexico-lfpdppp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Federal Law on Protection of Personal Data Held by Private Parties - data subject rights, ARCO, security measures.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | LFPDPPP |
| Region | Americas |
| Country or scope | Mexico |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers LFPDPPP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for LFPDPPP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for LFPDPPP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MX-LFPDPPP-19` Security Measures | Controllers must establish and maintain administrative, technical and physical security measures protecting personal data against damage, loss or alteration; verifiable component integrity evidences such measures (LFPDPPP Art. 19) | Scan |
| `MX-LFPDPPP-20` Breach Assessment Readiness | Security breaches materially affecting data subjects must be reported to them; assessing a breach's scope requires knowing the exact versions of software handling the data (LFPDPPP Art. 20) | Scan |
| `MX-LFPDPPP-14` Accountability for Third-Party Processing | The controller remains responsible for compliance even when data is processed by third parties on its behalf, which requires knowing who supplies the software components in the processing chain (LFPDPPP Art. 14) | Scan |
| `MX-LFPDPPP-11` Data Quality Principle | Personal data must be kept accurate, complete and up to date for its purpose; the systems inventory itself must meet the same completeness bar, with components fully named and versioned (LFPDPPP Art. 11) | Scan |
| `MX-LFPDPPP-30` Personal Data Officer | Every controller must designate a person or department responsible for personal data, providing a reachable point of accountability for the systems described in the SBOM (LFPDPPP Art. 30) | Scan |
| `MX-LFPDPPP-36` Transfer Documentation | Domestic and international transfers must be documented and communicated via the privacy notice, presupposing identifiable, timestamped documentation of the processing environment (LFPDPPP Art. 36) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ----------------------------------------------------- |
| `LFPDPPP-Art6` | Consentimiento (Art. 6) |
| `LFPDPPP-Art13` | Derechos ARCO (Art. 13) |
| `LFPDPPP-Art16` | Aviso de Privacidad (Art. 16) |
| `LFPDPPP-Art19` | Medidas de Seguridad (Art. 19) |
| `LFPDPPP-Art34` | Transferencia de Datos (Art. 34) |
| `LFPDPPP-Reg57` | Responsabilidades de Seguridad: Reglamento Art. 57-59 |
| `LFPDPPP-Art36` | Datos Sensibles |
| `LFPDPPP-BR-01` | Notificación de Vulneraciones |
| `LFPDPPP-DP-01` | Privacidad desde el Diseño |
| `LFPDPPP-RET-01` | Conservación y Supresión de Datos |
## Policy templates
Written for LFPDPPP:
* Política de Seguridad de la Información: LFPDPPP
* Procedimiento para el Ejercicio de Derechos ARCO
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LFPDPPP.
# Minnesota CDPA (/docs/frameworks/americas/minnesota-cdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Minnesota Consumer Data Privacy Act - controller duties, consumer rights, sensitive data.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | MN CDPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers MN CDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for MN CDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for MN CDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `MN-CDPA-INVENTORY` Statutory Data Inventory | Minnesota uniquely obliges controllers to maintain a data inventory as part of their required data security program; an enumerated inventory of the software components processing consumer data is the direct analogue (Minn. Stat. ch. 325O, controller data-inventory duty) | Scan |
| `MN-CDPA-INVQUALITY` Inventory Completeness | A data inventory only serves its statutory purpose if entries are usable: each inventoried component should carry both a name and a version so the inventory supports security and rights obligations (Minn. Stat. ch. 325O, data-inventory and documentation duties) | Scan |
| `MN-CDPA-SEC` Data Security Practices | Controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices appropriate to the volume and nature of the personal data; integrity-verifiable processing software evidences that program (Minn. Stat. ch. 325O, controller-duties provision) | Scan |
| `MN-CDPA-PROC` Processor Obligations | Processors act under binding contracts with controller instructions and flow-down duties to subcontractors; named suppliers on third-party components demonstrate the required oversight (Minn. Stat. ch. 325O, processor provisions) | Scan |
| `MN-CDPA-DPIA` Privacy and Security Assessment Readiness | Data privacy and protection assessments are required for heightened-risk processing including profiling, targeted advertising, sale and sensitive data; recorded software versions underpin credible assessment (Minn. Stat. ch. 325O, assessment provisions) | Scan |
| `MN-CDPA-PROFILING` Profiling Contestability Readiness | Consumers may question the result of profiling used in furtherance of significant decisions and learn what actions they could have taken for a different outcome; explaining a system's decisions requires its constituent components to be unambiguously identified (Minn. Stat. ch. 325O, profiling-rights provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ----------------------------------------------------------- |
| `MN-325O.04` | Consumer Rights: Access, Correction, Deletion & Portability |
| `MN-325O.05` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `MN-325O.06` | Sensitive Data Consent |
| `MN-325O.08` | Data Protection Assessment |
| `MN-325O.09` | Processor Agreements |
| `MN-325O.03` | Privacy Notice Requirements |
| `MN-325O.07` | Universal Opt-Out Mechanism |
| `MN-325O.10` | Consumer Appeals & Non-Discrimination |
## Policy templates
Written for MN CDPA:
* Minnesota CDPA State Privacy Notice
* Minnesota CDPA Consumer Rights Request Handling Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MN CDPA.
# Montana CDPA (/docs/frameworks/americas/montana-cdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Montana Consumer Data Privacy Act - controller obligations, consumer rights.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | MT CDPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers MT CDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for MT CDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for MT CDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MT-CDPA-SEC` Data Security Practices | Controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices suited to the volume and nature of the personal data; verifiable software integrity supports this obligation (Montana CDPA, controller-duties provision) | Scan |
| `MT-CDPA-MIN` Collection Limitation Accountability | Personal data collection is limited to what is adequate, relevant and reasonably necessary for disclosed purposes; the controller should be able to enumerate the software components that process consumer data to demonstrate this (Montana CDPA, controller-duties provision) | Scan |
| `MT-CDPA-PROC` Processor Contract Obligations | Processors must follow controller instructions under binding contracts and flow equivalent duties to subcontractors; each third-party processing component should be attributable to a named supplier (Montana CDPA, processor provisions) | Scan |
| `MT-CDPA-DPIA` Data Protection Assessment Readiness | Data protection assessments are required for heightened-risk processing including targeted advertising, sale, risky profiling and sensitive data; credible assessment requires recorded versions of the processing software (Montana CDPA, data protection assessment provisions) | Scan |
| `MT-CDPA-RIGHTS` Consumer Rights Fulfilment | Consumers may access, correct, delete and port their personal data and opt out of targeted advertising, sale and profiling, including via universal opt-out signals; those requests require unambiguous identification of the systems holding the data (Montana CDPA, consumer-rights provisions) | Scan |
| `MT-CDPA-NOTICE` Privacy Notice Documentation | Controllers must provide a reasonably accessible, clear and meaningful privacy notice; the supporting system documentation should itself carry document identity and a creation timestamp so disclosures stay auditable (Montana CDPA, transparency provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ----------------------------------------------------------- |
| `MCA-30-14-1702` | Consumer Rights: Access, Correction, Deletion & Portability |
| `MCA-30-14-1703` | Opt-Out of Sale, Targeted Ads & Profiling |
| `MCA-30-14-1704` | Sensitive Data: Consent Requirement |
| `MCA-30-14-1705` | Data Protection Assessment |
| `MCA-30-14-1706` | Processor Agreements |
| `MCA-30-14-1701` | Privacy Notice Transparency |
| `MCA-30-14-1707` | Consumer Appeals Process |
| `MCA-30-14-1708` | Universal Opt-Out Signal Recognition |
## Policy templates
Written for MT CDPA:
* Montana CDPA State Privacy Notice
* Montana CDPA Consumer Rights Request Handling Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MT CDPA.
# Montserrat National ICT / Privacy Framework (/docs/frameworks/americas/montserrat-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MS Privacy |
| Region | Americas |
| Country or scope | Montserrat |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MS Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MS-CONST-PRIV` Processing System Inventory | Constitutional protection of privacy presumes entities can account for the systems and software processing personal information (Montserrat Constitution Order 2010, fundamental rights and freedoms) | Scan |
| `MS-OECS-SEC` Security of Processing | The regional model framework Montserrat is expected to adopt requires appropriate technical measures protecting personal data against loss and unlawful alteration, including software integrity verification (OECS model Data Protection Bill, security-of-processing obligation) | Scan |
| `MS-OECS-3P` Third-Party Processing Accountability | Controllers remain accountable for processing done on their behalf by third parties, requiring supplier visibility for third-party software components (OECS model Data Protection Bill, processor obligations) | Scan |
| `MS-ID-READY` Incident Impact Readiness | Assessing the privacy impact of a security incident requires the ability to identify precisely which components hold or process personal information (Montserrat privacy framework, incident-readiness expectation) | Scan |
| `MS-DOC` Documented Data-Handling Systems | Accountability for personal information handled by government and business presumes identifiable, timestamped documentation of the processing systems (Montserrat privacy framework, accountability expectation) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MS Privacy.
# NDAA Section 889 (/docs/frameworks/americas/ndaa-section-889)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Prohibits use of Huawei, ZTE, Hikvision, Dahua, Hytera equipment in federal contracts.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NDAA 889 |
| Region | Americas |
| Country or scope | United States |
| Sector | Defense |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NDAA 889
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for NDAA 889.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for NDAA 889 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NDAA889-SUPPLIER` Supplier Screening Coverage | Screening for covered entities requires knowing the supplier of essentially every component or equipment item in use (NDAA FY2019 §889(a)(1); FAR 52.204-25) | Scan |
| `NDAA889-INV` Complete Equipment and Software Inventory | The prohibition on using covered equipment or services can only be honored with a complete inventory of components and equipment in use (NDAA FY2019 §889(a)(1)(B)) | Scan |
| `NDAA889-IDENT` Component Identifiability | Determining whether an item is covered equipment requires unambiguous identification of components against the prohibited-entity lists (FAR 52.204-25 definitions of covered telecommunications equipment) | Scan |
| `NDAA889-COMPLETE` Reasonable Inquiry Data | The 'reasonable inquiry' backing the contractor representation needs entries with both name and version so items can be traced to their origin (FAR 52.204-24 representation after reasonable inquiry) | Scan |
| `NDAA889-PROV` Documented Provenance | Representations must be supportable by documented provenance of who compiled the equipment and software inventory (NDAA FY2019 §889(a)(1)(B) use prohibition; FAR 52.204-24) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ----------------------------------------------------------------- |
| `NDAA889-A-01` | Prohibit procurement of covered telecommunications equipment |
| `NDAA889-A-02` | Screen existing infrastructure for covered telecom equipment |
| `NDAA889-B-01` | Certify non-use of covered equipment in contract representations |
| `NDAA889-B-02` | Conduct due diligence on supply chain for covered equipment |
| `NDAA889-C-01` | Report discovery of covered equipment during contract performance |
| `NDAA889-D-01` | Flow-down Section 889 requirements to subcontractors |
| `NDAA889-E-01` | Maintain records of Section 889 compliance activities |
| `NDAA889-F-01` | Review and update Section 889 covered entity list |
## Policy templates
Written for NDAA 889:
* NDAA Section 889 Prohibited Technology Policy
* Section 889 Supply Chain Screening and Representation Policy
* Section 889 Subcontractor Flowdown and Compliance Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NDAA 889.
# NERC CIP (/docs/frameworks/americas/nerc-cip)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
North American energy sector cybersecurity: BES Cyber System inventory and software integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Americas |
| Country or scope | United States |
| Sector | Energy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NERC CIP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for NERC CIP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for NERC CIP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NERC-CIP010-R1-INV` Baseline Software Inventory | Baseline configurations must include the installed software on BES Cyber Systems, i.e. a component inventory (NERC CIP-010 R1, baseline configuration) | Scan |
| `NERC-CIP010-R1-VER` Baseline Version Records | The baseline must record commercially available or open-source software including version, so nearly all components need versions (NERC CIP-010 R1 Part 1.1) | Scan |
| `NERC-CIP010-R1.6` Software Source and Integrity Verification | Before installing software, the identity of the source and the integrity of the software must be verified, requiring integrity hashes (NERC CIP-010 R1 Part 1.6; CIP-013 R1 Part 1.2.5) | Scan |
| `NERC-CIP013-R1` Supply Chain Risk Management Plan | Responsible entities must have plans addressing vendor risk for high/medium impact BES Cyber Systems, presupposing known suppliers for procured software (NERC CIP-013 R1) | Scan |
| `NERC-CIP007-R2` Security Patch Management | Patch sources must be tracked and applicable security patches evaluated per software item, requiring components identifiable against patch and vulnerability sources (NERC CIP-007 R2) | Scan |
| `NERC-CIP010-VERSPEC` Exact Baseline Versions | Deviations from baseline can only be detected when baseline entries carry specific versions rather than ranges or placeholders (NERC CIP-010 R1/R2, configuration monitoring) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ------------------------------------------------------------------------- |
| `CIP-002-5.1a` | Identify and categorize BES Cyber Systems |
| `CIP-003-8-R1` | Implement cybersecurity policies for BES Cyber Systems |
| `CIP-004-6-R1` | Implement security awareness program for BES personnel |
| `CIP-005-7-R1` | Define and protect the Electronic Security Perimeter |
| `CIP-006-6-R1` | Implement Physical Security Plan for BES Cyber Systems |
| `CIP-007-6-R1` | Enable only necessary ports and services on BES Cyber Systems |
| `CIP-007-6-R2` | Deploy security patches to BES Cyber Systems |
| `CIP-008-6-R1` | Implement a Cyber Security Incident Response Plan |
| `CIP-009-6-R1` | Implement Recovery Plans for BES Cyber Systems |
| `CIP-010-4-R1` | Establish baseline configurations for BES Cyber Systems |
| `CIP-011-3-R1` | Implement information protection program for BES Cyber System Information |
| `CIP-013-2-R1` | Develop supply chain cybersecurity risk management plan |
## Policy templates
Written for NERC CIP:
* BES Cyber System Identification and Classification Policy
* Physical Security of BES Cyber Systems Policy
* NERC CIP Cyber Security Incident Reporting Policy
* NERC CIP Supply Chain Risk Management Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NERC CIP.
# New Hampshire DPA (/docs/frameworks/americas/new-hampshire-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
New Hampshire Data Privacy Act - controller obligations, consumer rights.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NH DPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NH DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for NH DPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for NH DPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NH-DPA-SEC` Data Security Practices | Controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices appropriate to the volume and nature of the personal data processed; verifiable integrity of the processing software evidences this (RSA ch. 507-H, controller-duties provision) | Scan |
| `NH-DPA-MIN` Minimisation Accountability | Personal data collection must be adequate, relevant and limited to what is reasonably necessary; a named processing platform with its components enumerated demonstrates the controller knows what it processes and where (RSA ch. 507-H, controller-duties provision) | Scan |
| `NH-DPA-PROC` Processor Obligations | Processors operate under binding contracts, assist controllers with security and assessment duties, and bind subcontractors equivalently; named suppliers on third-party components demonstrate this oversight (RSA ch. 507-H, processor provisions) | Scan |
| `NH-DPA-DPIA` Data Protection Assessment Readiness | Data protection assessments are required for targeted advertising, sale, risky profiling and sensitive data processing; assessments depend on recorded versions of the software performing that processing (RSA ch. 507-H, data protection assessment provisions) | Scan |
| `NH-DPA-RIGHTS` Consumer Rights Fulfilment | Consumers may access, correct, delete and port personal data and opt out of targeted advertising, sale and profiling, including via universal opt-out signals; the systems holding the data must be unambiguously identifiable to execute these rights (RSA ch. 507-H, consumer-rights provisions) | Scan |
| `NH-DPA-NOTICE` Privacy Notice Documentation | Controllers must provide a reasonably accessible, clear and meaningful privacy notice; supporting system documentation should carry document identity and a creation timestamp so the notice's claims remain auditable (RSA ch. 507-H, transparency provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ----------------------------------------------------------- |
| `NH-RSA-507-H:3` | Consumer Rights: Access, Correction, Deletion & Portability |
| `NH-RSA-507-H:4` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `NH-RSA-507-H:5` | Sensitive Data Consent |
| `NH-RSA-507-H:7` | Data Protection Assessment |
| `NH-RSA-507-H:8` | Processor Contracts |
| `NH-RSA-507-H:2` | Privacy Notice |
| `NH-RSA-507-H:6` | Consumer Appeals |
| `NH-RSA-507-H:9` | Universal Opt-Out Mechanism |
## Policy templates
Written for NH DPA:
* New Hampshire DPA State Privacy Notice
* New Hampshire DPA Consumer Rights Request Handling Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NH DPA.
# New Jersey CDPA (/docs/frameworks/americas/new-jersey-cdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
New Jersey Consumer Data Privacy Act - controller duties, consumer rights, opt-out.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NJ CDPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NJ CDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for NJ CDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for NJ CDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NJ-DPA-SEC` Data Security Practices | Controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices to protect the confidentiality, integrity and accessibility of personal data; integrity-verifiable software supports this duty (NJDPA, P.L. 2023, c. 266, controller-duties provision) | Scan |
| `NJ-DPA-MIN` Minimisation Accountability | Collection must be limited to what is adequate, relevant and reasonably necessary for disclosed purposes; a named processing platform with enumerated components is the evidentiary basis for that limitation (NJDPA, P.L. 2023, c. 266, controller-duties provision) | Scan |
| `NJ-DPA-PROC` Processor Obligations | Processors act only under binding contracts with controller instructions and flow-down duties to subcontractors; third-party processing components should be attributable to named suppliers (NJDPA, P.L. 2023, c. 266, processor provisions) | Scan |
| `NJ-DPA-DPIA` Data Protection Assessment Readiness | Data protection assessments are required for heightened-risk processing including targeted advertising, sale, profiling and sensitive data; risk assessment requires the versions of the processing software to be recorded (NJDPA, P.L. 2023, c. 266, data protection assessment provisions) | Scan |
| `NJ-DPA-OPTOUT` Universal Opt-Out and Rights Readiness | Controllers must honor consumer rights requests and universal opt-out preference signals for targeted advertising and sale; executing these across systems requires unambiguous identification of the components involved (NJDPA, P.L. 2023, c. 266, consumer-rights and opt-out provisions) | Scan |
| `NJ-DPA-CONTACT` Accountable Point of Contact | The required privacy notice must tell consumers how to contact the controller and exercise their rights; a recorded, reachable creator/owner contact for system documentation demonstrates that accountability chain (NJDPA, P.L. 2023, c. 266, privacy-notice provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------- | ----------------------------------------------------------- |
| `NJ-P2023-332-Sec3` | Consumer Rights: Access, Correction, Deletion & Portability |
| `NJ-P2023-332-Sec4` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `NJ-P2023-332-Sec5` | Sensitive Data Consent |
| `NJ-P2023-332-Sec8` | Data Protection Assessment |
| `NJ-P2023-332-Sec9` | Processor Agreements |
| `NJ-P2023-332-Sec2` | Privacy Notice Requirements |
| `NJ-P2023-332-Sec6` | Universal Opt-Out Signal |
| `NJ-P2023-332-Sec7` | Children's Data Protections |
## Policy templates
Written for NJ CDPA:
* New Jersey CDPA State Privacy Notice
* New Jersey CDPA Sensitive Data Consent Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NJ CDPA.
# Nicaragua Law No. 787 on Personal Data (/docs/frameworks/americas/nicaragua-law787)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | NI L787 |
| Region | Americas |
| Country or scope | Nicaragua |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers NI L787
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NI-L787-SEC` Security of Data Files | Controllers must adopt technical and organizational measures that guarantee the security and integrity of personal-data files and the systems that process them (Law No. 787/2012, data-security obligation) | Scan |
| `NI-L787-REG` Registration of Data Files | Data files must be registered and documented, which presupposes an inventory of the software systems that hold and process personal data (Law No. 787/2012, file-registration duty) | Scan |
| `NI-L787-PROC` Third-Party Processing Accountability | Processing entrusted to third parties requires contractual safeguards equivalent to the controller's, so the origin and supplier of processing components must be known (Law No. 787/2012, third-party processing obligation) | Scan |
| `NI-L787-QUAL` Data Quality and Currency | Personal data must be accurate and kept up to date, which requires knowing the exact versions of the software maintaining it (Law No. 787/2012, data-quality principle) | Scan |
| `NI-L787-DOC` Documented and Traceable Processing | Accountability to the supervisory authority requires processing environments to be documented in an identifiable, timestamped record (Law No. 787/2012, accountability to DIPRODAP) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NI L787.
# NIST AI RMF (/docs/frameworks/americas/nist-ai-rmf)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
AI Risk Management Framework: AI component inventory, transparency, AI versioning.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | AI RMF |
| Region | Americas |
| Country or scope | United States |
| Sector | AI |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers AI RMF
* **Scan requirements:** 4, all decided by a scan.
* **Controls:** the scan requirements below, plus 13 controls from Safeguard's control catalog for AI RMF.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for AI RMF and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 4 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | ------------------------------------------------------------------------------------- | ---------- |
| `AIRNMF-MAP-1` AI/ML Component Identification | NIST AI RMF requires identification of AI/ML components for risk categorization | Scan |
| `AIRNMF-MAP-3` AI Model Documentation | AI models must be documented with purpose, training data, and limitations | Scan |
| `AIRNMF-GOVERN-1` AI System Transparency | NIST AI RMF requires transparency about AI systems including component identification | Scan |
| `AIRNMF-MEASURE-2` AI Component Version Tracking | AI model versions must be tracked for drift detection and reproducibility | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | ------------------------------------------------------------ |
| `GOVERN-1.1` | Establish policies and processes for AI risk management |
| `GOVERN-1.2` | Integrate AI risk management into enterprise risk management |
| `GOVERN-4.1` | Define accountability for AI system outcomes |
| `MAP-1.1` | Identify context and intended purpose of AI systems |
| `MAP-2.1` | Identify and classify AI risks prior to deployment |
| `MAP-3.1` | Assess impact on individuals and society from AI systems |
| `MEASURE-1.1` | Test AI system performance against stated objectives |
| `MEASURE-2.1` | Evaluate AI system bias and fairness |
| `MEASURE-2.6` | Evaluate AI system security and adversarial robustness |
| `MANAGE-1.1` | Implement controls to manage AI risks |
| `MANAGE-2.2` | Maintain human oversight of high-risk AI decisions |
| `MANAGE-3.1` | Monitor AI system behavior in production |
| `MANAGE-4.1` | Plan for decommissioning of AI systems |
## Policy templates
Written for AI RMF:
* AI Governance and Accountability Policy
* AI Risk Identification and Categorization Policy
* AI System Evaluation and Measurement Policy
* AI Incident Management and Response Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AI RMF.
# NIST CSF 2.0 (Full) (/docs/frameworks/americas/nist-csf-2)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
GV.SC-07 SBOM, ID.AM-05 asset inventory, PR.DS-02 integrity, GV.SC-04 supplier risk.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CSF 2.0 |
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CSF 2.0
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 13 controls from Safeguard's control catalog for CSF 2.0.
* **Automated tests:** 835 map to its controls, and 360 connectors provide automated evidence for them. See [NIST CSF 2.0 and connectors](/docs/framework-connectors/nist-csf).
* **Policy templates:** 25: 3 written for CSF 2.0 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `CSF2-ID.AM-02` Software and Services Inventory | Inventories of software, services and systems must be maintained (NIST CSF 2.0 ID.AM-02) | Scan |
| `CSF2-GV.SC-04` Suppliers Known and Prioritized | Suppliers must be known and prioritized by criticality, presupposing a named supplier for the software components in use (NIST CSF 2.0 GV.SC-04) | Scan |
| `CSF2-GV.SC-07` Supplier and Product Risk Understanding | The risks posed by suppliers and their products must be understood and recorded, which for software requires components identifiable against risk and vulnerability data (NIST CSF 2.0 GV.SC-07) | Scan |
| `CSF2-GV.SC-07-SBOM` SBOM as Supply Chain Evidence | Understanding product risk is supported by obtaining bills of materials in standardized machine-readable form (NIST CSF 2.0 GV.SC-07 implementation examples referencing SBOMs) | Scan |
| `CSF2-ID.RA-01` Vulnerability Identification | Vulnerabilities in assets must be identified, validated and recorded, which requires current version information for the software in those assets (NIST CSF 2.0 ID.RA-01) | Scan |
| `CSF2-PR.DS-INT` Software Integrity Protection | The integrity of software and data must be protected and verifiable, supported by integrity hashes for components (NIST CSF 2.0 Protect function, data security integrity subcategory) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | --------------------------------------------------------- |
| `GV.OC-01` | Communicate organizational mission and cybersecurity risk |
| `GV.RM-01` | Define and communicate risk management strategy |
| `GV.SC-01` | Establish supply chain risk management program |
| `GV.SC-02` | Establish and maintain supplier security requirements |
| `ID.AM-01` | Maintain inventory of organizational assets |
| `ID.AM-07` | Inventory and manage data assets |
| `PR.AA-01` | Manage identities and credentials for authorized users |
| `PR.AA-05` | Control access based on least privilege |
| `DE.CM-01` | Monitor networks and systems for cybersecurity events |
| `DE.CM-09` | Monitor computing hardware and software supply chain |
| `RS.CO-01` | Coordinate incident response with stakeholders |
| `RC.RP-01` | Execute recovery plan for cybersecurity incidents |
| `RC.RP-05` | Integrate lessons learned into recovery plans |
## Policy templates
Written for CSF 2.0:
* Organizational Cybersecurity Strategy and Governance Policy
* Cybersecurity Risk Assessment Policy
* Cybersecurity Recovery and Resilience Planning Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CSF 2.0.
# NIST CSF 2.0 (/docs/frameworks/americas/nist-csf)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Cybersecurity Framework 2.0: identify, protect, detect, respond, and recover functions.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NIST CSF |
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NIST CSF
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for NIST CSF.
* **Automated tests:** none map to it directly. Evidence from the frameworks the crosswalk relates it to counts toward its controls where a reviewed or approved equivalent row links them ([the crosswalk](/docs/framework-connectors#through-the-crosswalk)).
* **Policy templates:** 25: 3 written for NIST CSF and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------- | ----------------------------------------------------------------------------------- | ---------- |
| `CSF-ID.AM-1` Asset Inventory | Software assets must be inventoried (NIST CSF ID.AM-1) | Scan |
| `CSF-ID.AM-2` Software Platform Enumeration | Software platforms and applications must be enumerated (NIST CSF ID.AM-2) | Scan |
| `CSF-ID.SC-1` Supply Chain Risk Policy | Supply chain risk management policy must be established (NIST CSF ID.SC-1) | Scan |
| `CSF-PR.DS-6` Integrity Checking | Integrity checking mechanisms must be used to verify software (NIST CSF PR.DS-6) | Scan |
| `CSF-DE.CM-4` Malicious Code Detection | Malicious code must be detectable in software (NIST CSF DE.CM-4) | Scan |
| `CSF-RS.AN-3` Forensic Evidence Preservation | Evidence must be preserved to support incident analysis (NIST CSF RS.AN-3) | Scan |
| `CSF-RC.IM-1` Recovery Plan Incorporated | Recovery plans must incorporate SBOM-driven dependency awareness (NIST CSF RC.IM-1) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ------------------------------------------------------- |
| `ID.AM-1` | Inventory physical and software assets |
| `ID.RA-1` | Identify and document asset vulnerabilities |
| `ID.GV-1` | Establish and communicate cybersecurity policy |
| `PR.AC-1` | Manage identities and credentials for authorized users |
| `PR.DS-1` | Protect data at rest |
| `PR.IP-1` | Maintain baseline configuration of systems |
| `DE.CM-1` | Monitor the network for cybersecurity events |
| `DE.AE-2` | Analyze detected events to understand attack targets |
| `RS.RP-1` | Execute an incident response plan |
| `RC.RP-1` | Execute a recovery plan post-incident |
| `RS.CO-2` | Report cybersecurity incidents per established criteria |
| `PR.AT-1` | Provide security awareness training to all users |
## Policy templates
Written for NIST CSF:
* Cybersecurity Supply Chain Risk Governance Policy
* Asset Identification and Management Policy
* Continuous Cybersecurity Monitoring Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NIST CSF.
# NIST Privacy Framework (/docs/frameworks/americas/nist-privacy-framework)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
NIST Privacy Framework v1.0 - Identify-P, Govern-P, Control-P, Communicate-P, Protect-P functions.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NIST PF |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NIST PF
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for NIST PF.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for NIST PF and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NIST-PF-ID-IM-P` Inventory and Mapping | Systems, products, and services that process data must be inventoried and the data processing environment mapped, which for software systems means an enumerated inventory of the components performing the processing (NIST Privacy Framework v1.0, ID.IM-P) | Scan |
| `NIST-PF-ID-IM-P-COMP` Complete Inventory Records | Inventory and mapping outcomes are only usable for privacy risk assessment if each inventoried element is recorded with sufficient detail: at minimum a name and version for every software component (NIST Privacy Framework v1.0, ID.IM-P subcategories) | Scan |
| `NIST-PF-ID-DE-P` Data Processing Ecosystem Risk Management | Organizations must identify, assess, and manage privacy risks arising from third parties in the data processing ecosystem, which requires knowing the supplier of each component in the processing stack (NIST Privacy Framework v1.0, ID.DE-P) | Scan |
| `NIST-PF-PR-DS-P` Data Security | Data must be managed consistent with the organization's risk strategy to protect confidentiality, integrity, and availability, implying verifiable integrity of the software components handling the data (NIST Privacy Framework v1.0, PR.DS-P) | Scan |
| `NIST-PF-GV-PO-P` Governance Policies and Accountability | Organizational privacy values, policies, and roles must be established and communicated, which entails accountable, attributable records of who produced the technical documentation for processing systems (NIST Privacy Framework v1.0, GV.PO-P) | Scan |
| `NIST-PF-CM-AW-P` Data Processing Awareness and Communication | Organizations must enable reliable communication about data processing to internal and external stakeholders, which is supported by interoperable, machine-readable descriptions of the processing systems (NIST Privacy Framework v1.0, CM.AW-P) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ------------------------------------- |
| `NIST-PF-ID.IM` | Identify: Inventory and Mapping |
| `NIST-PF-ID.BE` | Identify: Business Environment |
| `NIST-PF-ID.RA` | Identify: Risk Assessment |
| `NIST-PF-GV.PO` | Govern: Policies and Procedures |
| `NIST-PF-GV.RM` | Govern: Risk Management Strategy |
| `NIST-PF-GV.AT` | Govern: Awareness and Training |
| `NIST-PF-CT.DM` | Control: Data Management |
| `NIST-PF-CT.DP` | Control: Disassociated Processing |
| `NIST-PF-CM.AW` | Communicate: Awareness to Individuals |
| `NIST-PF-PR.AC` | Protect: Access Control |
| `NIST-PF-PR.DS` | Protect: Data Security |
| `NIST-PF-PR.MA` | Protect: Maintenance |
## Policy templates
Written for NIST PF:
* Privacy Risk Assessment Procedure (NIST Privacy Framework)
* Privacy Data Management Policy (NIST Privacy Framework Control-P)
* Privacy Awareness and Individual Communication Policy (NIST PF Communicate-P)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NIST PF.
# NIST SP 800-161 (/docs/frameworks/americas/nist-sp800-161)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Supply Chain Risk Management: C-SCRM practices for ICT supply chain risks.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SP 800-161 |
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SP 800-161
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for SP 800-161.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for SP 800-161 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SP800161-CM-8` System Component Inventory | An accurate, current inventory of system components must be developed and maintained (NIST SP 800-161 Rev. 1, control CM-8) | Scan |
| `SP800161-SR-4` Provenance | Provenance of systems and components must be documented, monitored and maintained, including who produced the composition record (NIST SP 800-161 Rev. 1, control SR-4) | Scan |
| `SP800161-SR-4-TRACE` Supply Chain Traceability | Provenance includes traceability of components through the supply chain, mapping to documented dependency relationships (NIST SP 800-161 Rev. 1, SR-4 traceability, incl. SBOM enhancement) | Scan |
| `SP800161-SR-11` Component Authenticity | Anti-counterfeit and authenticity controls require the ability to verify component integrity via cryptographic hashes (NIST SP 800-161 Rev. 1, control SR-11) | Scan |
| `SP800161-SR-3` Supply Chain Controls and Processes | Supply chain risk controls must be applied to suppliers of components, presupposing a named supplier for each component (NIST SP 800-161 Rev. 1, control SR-3) | Scan |
| `SP800161-RA-5` Vulnerability Monitoring | Components must be monitored and scanned for vulnerabilities, which requires identifiability against vulnerability databases via PURL or CPE (NIST SP 800-161 Rev. 1, control RA-5) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | -------------------------------------------------- |
| `SR-1` | Supply Chain Risk Management Policy and Procedures |
| `SR-2` | Supply Chain Risk Management Plan |
| `SR-4` | Provenance of Components and Software |
| `SR-5` | Acquisition Strategies and Supply Chain Controls |
| `SR-6` | Supplier Assessments and Reviews |
| `SR-8` | Notification Agreements with Suppliers |
| `SR-9` | Tamper Resistance and Detection |
| `SR-10` | Inspection of Systems and Components |
| `SR-11` | Component Authenticity |
| `SR-12` | Component Disposal |
| `SA-12` | Supply Chain Protection |
| `SA-15` | Development Process, Standards, and Tools |
## Policy templates
Written for SP 800-161:
* Supply Chain Risk Management Program Policy
* ICT Supplier Security Controls Policy
* ICT Component Authenticity and Tamper Resistance Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SP 800-161.
# NIST SP 800-171 (/docs/frameworks/americas/nist-sp800-171)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Protecting Controlled Unclassified Information (CUI): component identification, integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | 800-171 |
| Region | Americas |
| Country or scope | United States |
| Sector | Defense |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers 800-171
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for 800-171.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for 800-171 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SP800171-3.4.1-INV` Baseline Inventory of Software | Baseline configurations and inventories of organizational systems, including software, must be established and maintained (NIST SP 800-171 Rev. 2, requirement 3.4.1) | Scan |
| `SP800171-3.4.1-VER` Inventory Version Records | System inventories must reflect the software actually installed, which requires version information for components (NIST SP 800-171 Rev. 2, requirement 3.4.1) | Scan |
| `SP800171-3.11.2` Vulnerability Scanning | Systems must be scanned for vulnerabilities periodically and when new vulnerabilities are identified, requiring components identifiable via PURL or CPE (NIST SP 800-171 Rev. 2, requirement 3.11.2) | Scan |
| `SP800171-3.14.1` Flaw Identification and Remediation | System flaws must be identified, reported and corrected in a timely manner, supported by unique identifiers that let flaws be traced to specific components (NIST SP 800-171 Rev. 2, requirement 3.14.1) | Scan |
| `SP800171-3.14.2` Malicious Code Protection | Protection from malicious code at designated locations is supported by the ability to verify component integrity via hashes (NIST SP 800-171 Rev. 2, requirement 3.14.2) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ---------------------------------------------------------------- |
| `3.1.1` | Limit system access to authorized users |
| `3.1.2` | Limit system access to authorized transactions |
| `3.3.1` | Create and retain audit logs to enable monitoring |
| `3.4.1` | Establish and maintain baseline configurations |
| `3.5.3` | Use multi-factor authentication for CUI access |
| `3.6.1` | Establish an operational incident-handling capability |
| `3.11.1` | Assess the risk to organizational operations from CUI processing |
| `3.13.1` | Monitor, control, and protect communications at boundaries |
| `3.13.10` | Establish and manage cryptographic keys |
| `3.14.1` | Identify and correct information and system flaws |
| `3.12.1` | Periodically assess security controls |
| `3.9.2` | Ensure CUI is protected during and after personnel actions |
## Policy templates
Written for 800-171:
* Controlled Unclassified Information Access Control Policy
* CUI Cyber Incident Reporting Policy
* CUI System and Communications Protection Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to 800-171.
# NIST SP 800-207 (/docs/frameworks/americas/nist-sp800-207)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Zero Trust Architecture: component trust, supply chain least privilege, continuous verification.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Zero Trust |
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Zero Trust
* **Scan requirements:** 4, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for Zero Trust.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for Zero Trust and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 4 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------ | ---------------------------------------------------- | ---------- |
| `ZTA-3.1` Identity Verification Components | Zero Trust requires identity verification components | Scan |
| `ZTA-3.3` Micro-Segmentation Components | Zero Trust requires micro-segmentation | Scan |
| `ZTA-3.5` Continuous Validation Components | Zero Trust requires continuous validation | Scan |
| `ZTA-2.1` Asset Inventory for ZTA | Zero Trust requires complete asset inventory | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ---------------------------------------------------------- |
| `ZTA-1.1` | Treat all data sources and computing services as resources |
| `ZTA-1.2` | All communication secured regardless of network location |
| `ZTA-2.2` | Implement a Policy Enforcement Point |
| `ZTA-3.2` | Assess device health and posture before granting access |
| `ZTA-4.1` | Limit access using least-privilege and just-in-time access |
| `ZTA-4.2` | Apply micro-segmentation to limit lateral movement |
| `ZTA-5.1` | Collect and analyze telemetry to improve security posture |
| `ZTA-5.2` | Define and enforce dynamic access policies |
| `ZTA-6.1` | Protect data in transit using approved cryptography |
## Policy templates
Written for Zero Trust:
* Zero Trust Architecture Implementation Policy
* Zero Trust Device Trust and Compliance Policy
* Network Microsegmentation and East-West Traffic Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Zero Trust.
# NIST SP 800-218A (/docs/frameworks/americas/nist-sp800-218a)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
SSDF AI Supplement: AI-specific software development practices and supply chain controls.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | 218A |
| Region | Americas |
| Country or scope | United States |
| Sector | AI |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers 218A
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for 218A.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for 218A and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SP800218A-PS.3.2` Provenance Data / SBOM | Provenance data for all components of each software release must be collected, safeguarded and shared, e.g. as an SBOM in a standard machine-readable format (SP 800-218A profile of SSDF PS.3.2) | Scan |
| `SP800218A-PS.2.1` Integrity Verification Information | Integrity verification information such as cryptographic hashes must be made available to software acquirers (SP 800-218A profile of SSDF PS.2.1) | Scan |
| `SP800218A-PW.4.1` Well-Secured Component Reuse | Reused components, including AI frameworks and model artifacts, must be acquired from evaluated sources, presupposing a named supplier for each component (SP 800-218A profile of SSDF PW\.4.1) | Scan |
| `SP800218A-PW.4.4` Component Vulnerability Verification | Acquired components must be verified for known vulnerabilities before use, which requires knowing each component's exact version (SP 800-218A profile of SSDF PW\.4, component verification) | Scan |
| `SP800218A-RV.1.1` Vulnerability Monitoring | Vulnerability databases and sources must be monitored for issues affecting the software and its components, requiring identifiable components via PURL or CPE (SP 800-218A profile of SSDF RV.1.1) | Scan |
| `SP800218A-PS.3.2-PROV` Release Provenance Recording | Provenance collection includes recording who or what produced the composition data for each release (SP 800-218A profile of SSDF PS.3.2, provenance data) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ---------------------------------------------------------------- |
| `SSDF-AI-PO.1` | Define security and safety requirements for AI-enabled software |
| `SSDF-AI-PO.2` | Implement secure and trustworthy AI development environment |
| `SSDF-AI-PO.5` | Assess and manage AI supply chain risks |
| `SSDF-AI-PS.1` | Design AI software with security and safety in mind |
| `SSDF-AI-PS.2` | Verify and validate AI model integrity and outputs |
| `SSDF-AI-PS.3` | Secure training data and protect against data poisoning |
| `SSDF-AI-PW.1` | Use secure practices for AI model development and training |
| `SSDF-AI-PW.4` | Reuse vetted AI components and pretrained models responsibly |
| `SSDF-AI-RV.1` | Monitor and respond to AI-specific vulnerabilities in production |
| `SSDF-AI-RV.2` | Analyze root causes of AI system failures and vulnerabilities |
| `SSDF-AI-RV.3` | Remediate AI vulnerabilities and communicate to affected parties |
## Policy templates
Written for 218A:
* AI/ML Model Supply Chain Security Policy
* Secure Development Practices for AI-Enabled Software Policy
* AI/ML Vulnerability and Incident Response Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to 218A.
# NIST SP 800-37 RMF (/docs/frameworks/americas/nist-sp800-37)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Risk Management Framework - categorize, select, implement, assess, authorize, monitor system controls.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | RMF |
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers RMF
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 13 controls from Safeguard's control catalog for RMF.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for RMF and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `RMF-CAT-DESC` System Description and Categorization | The Categorize step requires documenting the characteristics of the system, including its components and boundary, before impact levels can be assigned: presupposing an enumerated inventory of the software composing the system (SP 800-37r2, Categorize step system-description task) | Scan |
| `RMF-PREP-BOUND` Authorization Boundary and Asset Identification | The Prepare step at system level requires identifying the system's assets and determining its authorization boundary, which requires the constituent components to be individually identifiable (SP 800-37r2, Prepare step asset-identification and boundary tasks) | Scan |
| `RMF-IMPL-DOC` Documented Control Implementation | The Implement step requires documenting how controls are implemented in the system's security and privacy plans, supported by formally identified, timestamped machine-readable system documentation (SP 800-37r2, Implement step documentation task) | Scan |
| `RMF-ASSESS-INTG` Assessable System Integrity | The Assess step requires determining whether controls are implemented correctly and operating as intended; assessing software integrity controls requires verifiable integrity evidence such as component hashes (SP 800-37r2, Assess step) | Scan |
| `RMF-MON-CHANGE` Continuous Monitoring of System Changes | The Monitor step requires ongoing detection and analysis of changes to the system and its environment of operation; detecting component-level change requires known versions for the software in use (SP 800-37r2, Monitor step change-monitoring task) | Scan |
| `RMF-SCRM` Supply Chain Risk Management Integration | Revision 2 explicitly integrates supply chain risk management across the RMF steps, requiring organizations to understand and manage risk from the suppliers of system components (SP 800-37r2, SCRM integration) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | --------------------------------------- |
| `RMF-CA` | Categorize Information System |
| `RMF-CA-1` | Categorize: System Characterization |
| `RMF-SE` | Select Security Controls |
| `RMF-SE-1` | Select: Tailoring & Supplementation |
| `RMF-IM` | Implement Security Controls |
| `RMF-AS` | Assess Security Controls |
| `RMF-AS-1` | Assess: Security Assessment Report |
| `RMF-AS-2` | Assess: Plan of Action & Milestones |
| `RMF-AU` | Authorize Information System |
| `RMF-AU-1` | Authorize: Authorization Package |
| `RMF-MO` | Monitor Security Controls |
| `RMF-MO-1` | Monitor: Continuous Monitoring Strategy |
| `RMF-MO-2` | Monitor: Configuration Management |
## Policy templates
Written for RMF:
* NIST RMF Authorization Package SOP
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to RMF.
# NIST SP 800-53 (/docs/frameworks/americas/nist-sp800-53)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Security & Privacy Controls: system component inventory, supply chain protection, software integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SP 800-53 |
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SP 800-53
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 15 controls from Safeguard's control catalog for SP 800-53.
* **Automated tests:** none map to it directly. Evidence from the frameworks the crosswalk relates it to counts toward its controls where a reviewed or approved equivalent row links them ([the crosswalk](/docs/framework-connectors#through-the-crosswalk)).
* **Policy templates:** 26: 4 written for SP 800-53 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NIST53-CM-8` System Component Inventory | The organization must develop and maintain an inventory of system components that accurately reflects the system (SP 800-53r5 CM-8) | Scan |
| `NIST53-CM-8-3` Inventory Accuracy and Detail | Component inventories must include the level of granularity needed for tracking and reporting, meaning each component is recorded with its name and version (SP 800-53r5 CM-8, incl. CM-8(3) automated detection support) | Scan |
| `NIST53-SI-7` Software Integrity Verification | Integrity verification mechanisms must be employed to detect unauthorized changes to software and firmware, which requires cryptographic hashes for delivered components (SP 800-53r5 SI-7) | Scan |
| `NIST53-SR-4` Provenance | The organization must document, monitor, and maintain valid provenance of systems and system components, including who created the accompanying inventory documentation (SP 800-53r5 SR-4) | Scan |
| `NIST53-SR-3` Supply Chain Controls and Processes | Supply chain risk management processes must identify and address weaknesses across suppliers, requiring that the supplier of each component is known and recorded (SP 800-53r5 SR-3) | Scan |
| `NIST53-RA-5` Vulnerability Monitoring and Scanning | Systems must be monitored and scanned for vulnerabilities, which requires components to carry standard identifiers (PURL/CPE) so they can be matched to vulnerability databases (SP 800-53r5 RA-5) | Scan |
| `NIST53-SI-2` Flaw Remediation | Software flaws must be identified, reported, and corrected, requiring known versions for every component so applicable patches can be determined (SP 800-53r5 SI-2) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | -------------------------------------------------------- |
| `AC-1` | Access Control Policy and Procedures |
| `AC-2` | Account Management |
| `AC-3` | Access Enforcement |
| `AU-2` | Event Logging |
| `AU-9` | Protection of Audit Information |
| `CM-2` | Baseline Configuration |
| `CM-6` | Configuration Settings |
| `IA-2` | Identification and Authentication (Organizational Users) |
| `IA-5` | Authenticator Management |
| `IR-4` | Incident Handling |
| `RA-5` | Vulnerability Monitoring and Scanning |
| `SC-7` | Boundary Protection |
| `SC-28` | Protection of Information at Rest |
| `SI-2` | Flaw Remediation |
| `SR-3` | Supply Chain Controls and Processes |
## Policy templates
Written for SP 800-53:
* Access Control Policy and Procedures
* Configuration Management Policy
* System and Information Integrity Policy
* Incident Response Policy and Procedures
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SP 800-53.
# NIST SP 800-63 (/docs/frameworks/americas/nist-sp800-63)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Digital Identity Guidelines - IAL/AAL/FAL identity assurance levels, phishing-resistant MFA.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | 800-63 |
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers 800-63
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for 800-63.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for 800-63 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SP80063A-UID` Unique, Resolvable Identity | Identity proofing requires resolving a claimed identity to a single, unique subject before it can be verified; by analogy the components of the identity system itself must each carry a unique standard identifier (SP 800-63A, identity resolution and enrollment requirements) | Scan |
| `SP80063A-COMPLETE` Complete Identity Evidence Records | Identity evidence must be collected and validated with enough attributes to distinguish the subject; applied to the identity infrastructure, every component record needs both a name and a version to be distinguishable (SP 800-63A, evidence collection and validation requirements) | Scan |
| `SP80063B-INTG` Authenticator and Verifier Integrity | Authentication at higher assurance levels depends on verifiers and authenticators resisting compromise and tampering, which requires cryptographic integrity verification of the software implementing them (SP 800-63B, authenticator and verifier requirements) | Scan |
| `SP80063C-PROV` Assertion Provenance | Federation requires relying parties to trust assertions based on who issued them and how they were protected, making recorded creator provenance essential for artifacts in the identity chain (SP 800-63C, assertion and federation requirements) | Scan |
| `SP80063B-VULN` Maintained, Unexpired Authentication Stack | Authenticator assurance depends on the verifier software staying current against known attacks such as phishing and replay; determining exposure requires the exact version of each component in the authentication stack (SP 800-63B, verifier compromise resistance requirements) | Scan |
| `SP80063-RECORDS` Enrollment and Lifecycle Records | CSPs must maintain records of enrollment, proofing, and authenticator lifecycle events for auditability, which is supported by formally identified, timestamped machine-readable documentation of the identity systems (SP 800-63A/B recordkeeping requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ---------------------------------- |
| `63-IAL1` | Identity Assurance Level 1 |
| `63-IAL2` | Identity Assurance Level 2 |
| `63-IAL3` | Identity Assurance Level 3 |
| `63-AAL1` | Authenticator Assurance Level 1 |
| `63-AAL2` | Authenticator Assurance Level 2 |
| `63-AAL3` | Authenticator Assurance Level 3 |
| `63-FAL1` | Federation Assurance Level 1 |
| `63-FAL2` | Federation Assurance Level 2 |
| `63-FAL3` | Federation Assurance Level 3 |
| `63-SEC4` | Identity Proofing Requirements |
| `63-SEC5` | Authenticator Lifecycle Management |
| `63-SEC6` | Federation & Assertions |
## Policy templates
Written for 800-63:
* NIST 800-63 Identity Proofing & Authenticator Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to 800-63.
# NIST SP 800-66 r2 (/docs/frameworks/americas/nist-sp800-66)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Implementing the HIPAA Security Rule - risk-based approach for healthcare regulated entities.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | 800-66 |
| Region | Americas |
| Country or scope | United States |
| Sector | Healthcare |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers 800-66
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for 800-66.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for 800-66 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SP80066-RA` Risk Analysis Foundation | Regulated entities must conduct an accurate and thorough assessment of risks to ePHI, which SP 800-66r2 grounds in first identifying where ePHI is created, received, stored, and transmitted: requiring an enumerated inventory of the software involved (HIPAA Security Rule risk analysis, 45 CFR 164.308(a)(1)(ii)(A), per SP 800-66r2) | Scan |
| `SP80066-ASSET` Technology Asset Identification | SP 800-66r2's risk assessment methodology calls for identifying and documenting the technology assets that handle ePHI so threats and vulnerabilities can be tied to them, requiring components to be individually identifiable (SP 800-66r2 risk assessment guidance) | Scan |
| `SP80066-INTG` Integrity Controls | Regulated entities must implement policies and technical mechanisms to protect ePHI from improper alteration or destruction, implying integrity verification of the software processing it (HIPAA Security Rule integrity standard, 45 CFR 164.312(c)(1), per SP 800-66r2) | Scan |
| `SP80066-MALW` Protection from Malicious Software | Security awareness and management processes must include procedures for guarding against and detecting malicious software, which requires knowing the exact versions of deployed components so known-vulnerable software can be found and patched (45 CFR 164.308(a)(5)(ii)(B), per SP 800-66r2) | Scan |
| `SP80066-BA` Business Associate Assurances | A covered entity may permit a business associate to handle ePHI only with satisfactory written assurances that the associate will appropriately safeguard it, requiring knowledge of the supplier behind each component and service in the ePHI flow (45 CFR 164.308(b), per SP 800-66r2) | Scan |
| `SP80066-DOC` Documentation Requirements | Policies, procedures, and required assessments must be maintained in written form and retained for six years, which is supported by formally identified, timestamped machine-readable documentation of the systems in scope (HIPAA documentation standard, 45 CFR 164.316, per SP 800-66r2) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------------- | ---------------------------------------------- |
| `800-66-RA` | Risk Analysis |
| `800-66-RM` | Risk Management Program |
| `800-66-AS` | Administrative Safeguards: Security Management |
| `800-66-AS-TRAIN` | Administrative Safeguards: Workforce Training |
| `800-66-AS-IR` | Administrative Safeguards: Incident Procedures |
| `800-66-PS` | Physical Safeguards |
| `800-66-TS` | Technical Safeguards: Access Control |
| `800-66-TS-AUDIT` | Technical Safeguards: Audit Controls |
| `800-66-TS-INTEGRITY` | Technical Safeguards: Integrity Controls |
| `800-66-TS-ENCRYPT` | Technical Safeguards: Transmission Security |
## Policy templates
Written for 800-66:
* NIST 800-66 HIPAA Risk Analysis Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to 800-66.
# NIST SP 800-82 (/docs/frameworks/americas/nist-sp800-82)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Industrial Control Systems (ICS/SCADA) security: asset inventory, patch management, supply chain.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SP 800-82 |
| Region | Americas |
| Country or scope | United States |
| Sector | Energy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SP 800-82
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for SP 800-82.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for SP 800-82 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NIST82-CM-8` OT Asset and Software Inventory | OT operators must maintain a current inventory of hardware and software assets in the control environment, tailored from the CM-8 component inventory control (SP 800-82r3, OT overlay of SP 800-53 CM-8) | Scan |
| `NIST82-SI-2` OT Patch Management | A patch and flaw-remediation program for OT requires knowing the exact version of every software component so patch applicability can be assessed before scheduled maintenance windows (SP 800-82r3 patch management guidance, OT overlay of SI-2) | Scan |
| `NIST82-RA-5` OT Vulnerability Identification | Because active scanning is often unsafe on ICS networks, vulnerability identification relies on matching inventoried components against advisories, requiring standard identifiers on components (SP 800-82r3 vulnerability management guidance, OT overlay of RA-5) | Scan |
| `NIST82-SI-7` Control System Software Integrity | Integrity of software and firmware deployed to control systems must be verifiable, which requires integrity hashes for delivered components (SP 800-82r3, OT overlay of SI-7) | Scan |
| `NIST82-SR` OT Supply Chain Protection | OT supply chain risk management requires knowing the vendor/supplier of each software component in the control environment to evaluate supplier trustworthiness (SP 800-82r3, OT overlay of the SR family) | Scan |
| `NIST82-DOC` Documented System Baseline | OT security programs must document system baselines in a form usable for change detection and incident response, favoring a machine-readable inventory format (SP 800-82r3 asset management guidance) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | ------------------------------------------ |
| `ICS-AC-1` | ICS Access Control Policy and Procedures |
| `ICS-SI-3` | Malicious Code Protection for ICS |
| `ICS-SC-7` | ICS Network Boundary Protection |
| `ICS-CM-6` | ICS Configuration Management |
| `ICS-IR-4` | ICS Incident Handling |
| `ICS-MA-4` | Secure Remote Maintenance of ICS |
| `ICS-PE-3` | Physical Access Control for ICS Facilities |
| `ICS-AU-2` | ICS Audit Event Logging |
| `ICS-RA-5` | ICS Vulnerability Scanning |
| `ICS-CP-9` | ICS Information System Backup |
| `ICS-SA-9` | External ICS Service Providers |
| `ICS-AT-3` | Role-Based ICS Security Training |
## Policy templates
Written for SP 800-82:
* Industrial Control System Security Policy
* OT/ICS Cyber Incident Response Policy
* OT Network Architecture and Segmentation Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SP 800-82.
# NIST SSDF (/docs/frameworks/americas/nist-ssdf)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
NIST Secure Software Development Framework: supply chain integrity, provenance, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Americas |
| Country or scope | United States |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NIST SSDF
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for NIST SSDF.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for NIST SSDF and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SSDF-PS-3-2` Provenance Data / SBOM | Producers should collect, safeguard, and share provenance data for all software release components, such as an SBOM identifying the creating tool or organization (SP 800-218 PS.3.2) | Scan |
| `SSDF-PS-2-1` Release Integrity Verification | Acquirers must be able to verify software release integrity, which requires publishing cryptographic hashes for released components (SP 800-218 PS.2.1) | Scan |
| `SSDF-PW-4-1` Acquire Well-Secured Components | Reused third-party components must be acquired from known, evaluated sources, requiring the supplier of each component to be identified (SP 800-218 PW\.4.1) | Scan |
| `SSDF-PW-4-4` Verify Acquired Components | Acquired components must be verified against their expected identity before reuse, requiring precise component identifiers such as PURLs (SP 800-218 PW\.4.4) | Scan |
| `SSDF-RV-1-1` Identify Vulnerabilities in Components | Producers must gather information on potential vulnerabilities in the software and its third-party components, which requires every component to carry an exact version for advisory matching (SP 800-218 RV.1.1) | Scan |
| `SSDF-PW-4-2` Complete Component Records | Well-secured reuse of software requires maintaining complete records of components in use, with both name and version documented for each (SP 800-218 PW\.4 practice group) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | ------------------------------------------------------------ |
| `PO.1.1` | Define security requirements for software development |
| `PO.2.1` | Implement a secure development environment |
| `PO.3.1` | Provide security training for developers |
| `PO.5.1` | Implement supply chain risk management for development tools |
| `PS.1.1` | Design software to meet security requirements |
| `PS.2.1` | Review and test software for security vulnerabilities |
| `PS.3.1` | Archive and protect software release artifacts |
| `PW.1.1` | Use secure coding standards |
| `PW.4.1` | Reuse existing well-secured software components |
| `PW.5.1` | Create source code securely |
| `PW.7.1` | Perform security testing throughout development |
| `RV.1.1` | Identify and confirm vulnerabilities in released software |
| `RV.2.1` | Analyze vulnerabilities to determine root causes |
| `RV.3.1` | Address vulnerabilities and notify affected parties |
## Policy templates
Written for NIST SSDF:
* Organization-Wide Software Security Requirements
* Software Integrity and Supply Chain Protection Policy
* Secure Software Development Practices Policy
* Vulnerability Response and Disclosure Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NIST SSDF.
# NY SHIELD Act (/docs/frameworks/americas/ny-shield-act)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
NY Stop Hacks and Improve Electronic Data Security Act - reasonable safeguards, breach notification.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SHIELD |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SHIELD
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for SHIELD.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for SHIELD and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NY-SHIELD-899BB` Reasonable Technical Safeguards | Businesses must develop, implement, and maintain reasonable safeguards to protect the security, confidentiality, and integrity of private information, which implies integrity assurance over the software systems processing it (NY GBL s.899-bb(2)) | Scan |
| `NY-SHIELD-SWDESIGN` Software and Network Risk Assessment | The statute's technical safeguards include assessing risks in network and software design and in information processing, which requires knowing exactly which software components and versions are deployed (NY GBL s.899-bb(2)(b)(ii)(B)) | Scan |
| `NY-SHIELD-RISKID` Identification of Foreseeable Risks | Administrative safeguards include identifying reasonably foreseeable internal and external risks, a task that presupposes an enumerated inventory of the systems and software holding private information (NY GBL s.899-bb(2)(b)(ii)(A)) | Scan |
| `NY-SHIELD-VENDOR` Service Provider Selection | Safeguards include selecting service providers capable of maintaining appropriate protections and requiring those safeguards by contract, which depends on knowing the supplier behind each component and service in use (NY GBL s.899-bb(2)(b)(ii)(A) service-provider element) | Scan |
| `NY-SHIELD-899AA` Breach Notification Readiness | Breaches of private information must be disclosed to affected New York residents and authorities; determining whose data was exposed and through which system requires individually identifiable components (NY GBL s.899-aa) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------------- | ------------------------------------------------------ |
| `SHIELD-ADMIN-1` | Administrative Safeguards |
| `SHIELD-ADMIN-2` | Employee Training & Management |
| `SHIELD-ADMIN-3` | Vendor & Third-Party Oversight |
| `SHIELD-TECH-1` | Technical Safeguards: Access Controls |
| `SHIELD-TECH-2` | Technical Safeguards: Encryption & Intrusion Detection |
| `SHIELD-PHYS-1` | Physical Safeguards |
| `SHIELD-PHYS-2` | Secure Disposal of Private Information |
| `SHIELD-BREACH-1` | Breach Notification |
| `SHIELD-PROG-1` | Reasonable Security Program |
| `SHIELD-PROG-2` | Program Evaluation & Adjustment |
| `SHIELD-SCOPE-1` | Scope of Private Information |
## Policy templates
Written for SHIELD:
* NY SHIELD Act Information Security Program
* NY SHIELD Act Breach Notification Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SHIELD.
# NY DFS 23 NYCRR 500 (/docs/frameworks/americas/nyc-dfs-500)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
NY DFS Cybersecurity Regulation - CISO, IR plan, MFA, encryption, third-party security policy.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | 23 NYCRR 500 |
| Region | Americas |
| Country or scope | United States |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers 23 NYCRR 500
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 15 controls from Safeguard's control catalog for 23 NYCRR 500.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for 23 NYCRR 500 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `NYDFS-500.13` Asset Inventory | Covered entities must maintain a complete, accurate, and documented inventory of their information systems as part of asset management, which for software means enumerating the components that make up each system (23 NYCRR 500.13(a), as amended 2023) | Scan |
| `NYDFS-500.13-TRK` Asset Tracking Detail | The asset inventory must track key information for each asset, such as owner, location, and support expiration, which at the software level requires each component record to carry at least a name and version (23 NYCRR 500.13(a) tracking requirements) | Scan |
| `NYDFS-500.09` Risk Assessment | Each covered entity must conduct periodic risk assessments of its information systems sufficient to inform the design of its cybersecurity program, which requires that system components be individually identifiable (23 NYCRR 500.09) | Scan |
| `NYDFS-500.11` Third-Party Service Provider Security Policy | Covered entities must implement written policies ensuring the security of information systems and nonpublic information accessible to or held by third-party service providers, which requires knowing the supplier behind each component in use (23 NYCRR 500.11) | Scan |
| `NYDFS-500.15` Encryption and Integrity Protection | Nonpublic information must be protected in transit and at rest through encryption or approved compensating controls, a protection posture that presupposes cryptographic integrity verification of the deployed software (23 NYCRR 500.15) | Scan |
| `NYDFS-500.16` Incident Response Readiness | Covered entities must maintain incident response and business continuity plans enabling prompt response and recovery from cybersecurity events; assessing which systems are affected requires known versions for the software in use (23 NYCRR 500.16) | Scan |
| `NYDFS-500.03` Documented Cybersecurity Policies | The cybersecurity program must be grounded in written, approved policies covering areas including asset inventory, systems operations, and vendor management, supported by formally identified and timestamped technical documentation (23 NYCRR 500.03) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | -------------------------------------- |
| `500.02` | Cybersecurity Program |
| `500.03` | Cybersecurity Policies |
| `500.04` | Chief Information Security Officer |
| `500.06` | Audit Trails |
| `500.07` | Access Privileges & Management |
| `500.08` | Application Security |
| `500.09` | Risk Assessment |
| `500.10` | Cybersecurity Personnel & Intelligence |
| `500.11` | Third-Party Service Provider Security |
| `500.12` | Multi-Factor Authentication |
| `500.13` | Limitations on Data Retention |
| `500.14` | Training & Monitoring |
| `500.15` | Encryption of NPI |
| `500.16` | Incident Response Plan |
| `500.17` | Notice to Superintendent |
## Policy templates
Written for 23 NYCRR 500:
* NY DFS Cybersecurity Policy
* Multi-Factor Authentication Policy
* Third-Party Service Provider Security Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to 23 NYCRR 500.
# Oregon OCPA (/docs/frameworks/americas/oregon-ocpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Oregon Consumer Privacy Act - consumer rights, controller duties, opt-out signals.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | OR OCPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers OR OCPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for OR OCPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for OR OCPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `OR-OCPA-SEC` Data Security Safeguards | Controllers must establish, implement and maintain safeguards that protect the confidentiality, integrity and accessibility of personal data, appropriate to its volume and nature; integrity-verifiable processing software supports this duty (ORS 646A.570 et seq., controller data-security duty) | Scan |
| `OR-OCPA-MIN` Minimisation Accountability | Collection must be limited to what is adequate, relevant and reasonably necessary for the specified purposes; that limitation presumes an inventory of the software systems through which consumer data flows (ORS 646A.570 et seq., controller duties) | Scan |
| `OR-OCPA-THIRDPARTY` Third-Party Disclosure Traceability | Oregon uniquely lets a consumer demand a list of the specific third parties to which the controller disclosed personal data; producing that list requires the third-party/vendor chain, including software suppliers, to be recorded (ORS 646A.570 et seq., consumer right to third-party list) | Scan |
| `OR-OCPA-DPIA` Data Protection Assessment Readiness | Controllers must conduct and retain data protection assessments for heightened-risk processing such as targeted advertising, sale, profiling and sensitive data; assessments depend on recorded versions of the processing software (ORS 646A.570 et seq., data protection assessments) | Scan |
| `OR-OCPA-RIGHTS` Consumer Rights and Opt-Out Signals | Consumers hold access, correction, deletion, portability and opt-out rights, and controllers must honor opt-out preference signals; executing these across systems requires unambiguous component identification (ORS 646A.570 et seq., consumer rights and opt-out provisions) | Scan |
| `OR-OCPA-DEPS` Data Flow Mapping | Because disclosure obligations reach specific downstream recipients, controllers should be able to map how data-processing components relate to one another; a documented dependency graph evidences that flow mapping (ORS 646A.570 et seq., disclosure and transparency provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------------- | ----------------------------------------------------------- |
| `ORS-646A.574` | Consumer Rights: Access, Correction, Deletion & Portability |
| `ORS-646A.574(1)(e)` | Opt-Out of Sale, Targeted Ads & Profiling |
| `ORS-646A.576` | Sensitive Data: Opt-In Consent |
| `ORS-646A.578` | Data Protection Assessment |
| `ORS-646A.579` | Processor Contracts |
| `ORS-646A.573` | Privacy Notice |
| `ORS-646A.575` | Appeals & Non-Discrimination |
| `ORS-646A.577` | Children's Data Protection |
## Policy templates
Written for OR OCPA:
* Oregon OCPA State Privacy Notice
* Oregon OCPA Data Protection Assessment Procedure
* Oregon OCPA Consumer Rights Request Handling Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to OR OCPA.
# Panama Law No. 81 of 2019 on Personal Data (/docs/frameworks/americas/panama-law81)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | PA L81 |
| Region | Americas |
| Country or scope | Panama |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers PA L81
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `PA-L81-SEC` Technical and Organizational Security Measures | Controllers must adopt technical and organizational measures to protect personal data against unauthorized access, loss or destruction, including encryption and access controls, presuming verifiable integrity of the processing software (Law No. 81 of 2019, security-measures obligation) | Scan |
| `PA-L81-BREACH` Breach Notification Readiness | Significant data breaches must be notified to ANTAI and affected data subjects; assessing scope and impact requires precisely identifiable components (PURL/CPE) in the processing stack (Law No. 81 of 2019, breach-notification obligation) | Scan |
| `PA-L81-ROPA` Record of Processing Activities | Organizations must maintain a record of their data-processing activities, which requires an enumerated inventory of the software systems and components that process personal data (Law No. 81 of 2019 with Executive Decree No. 285 of 2021, records obligation) | Scan |
| `PA-L81-PROC` Processor and Third-Party Safeguards | Processing performed by third parties on the controller's behalf must be governed by adequate safeguards, requiring the external suppliers of processing software and services to be identified (Law No. 81 of 2019, controller-processor obligations) | Scan |
| `PA-L81-DPO` Accountable Data Protection Contact | In prescribed cases organizations must appoint a data protection officer to oversee compliance, so processing documentation should record an accountable creator contact (Law No. 81 of 2019, DPO obligation) | Scan |
| `PA-L81-DOC` Dated, Identifiable Documentation | Demonstrating compliance to ANTAI requires dated, identifiable documentation of processing systems, satisfied by an SBOM with a document ID and creation timestamp (Law No. 81 of 2019, accountability principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PA L81.
# Paraguay Law No. 6534/2020 on Personal Data (/docs/frameworks/americas/paraguay-law6534)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | PY L6534 |
| Region | Americas |
| Country or scope | Paraguay |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers PY L6534
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `PY-6534-SEC` Security of Credit Data Systems | Entities processing personal credit data must safeguard it against unauthorised access, alteration or loss, evidenced by integrity hashes on the components of processing systems (Law No. 6534/2020, data-security duties) | Scan |
| `PY-6534-QUAL` Data Quality and Completeness | Credit data must be accurate, complete and up to date, a quality duty that extends to system records where every component carries both a name and a version (Law No. 6534/2020, data-quality and update obligations) | Scan |
| `PY-6534-SRC` Accountable Data Sources | Credit-information providers are accountable for the sources feeding their databases, so third-party software components must have identifiable, named suppliers (Law No. 6534/2020, obligations of credit-information bureaus and data sources) | Scan |
| `PY-6534-INV` Database System Inventory | Operating regulated credit-data databases presupposes an inventory of the software systems that store and process the data (Law No. 6534/2020, database-operation provisions) | Scan |
| `PY-6534-DOC` Traceable Records | Handling rectification claims and regulator inquiries requires system records to be identifiable, timestamped documents (Law No. 6534/2020, data-subject rights and oversight provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PY L6534.
# Peru Law 29733 (/docs/frameworks/americas/peru-29733)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Peruvian Personal Data Protection Law - principles, data subject rights, registration, cross-border transfers.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | PE 29733 |
| Region | Americas |
| Country or scope | Peru |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers PE 29733
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for PE 29733.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for PE 29733 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `PE-29733-9` Security Principle | The controller must adopt the technical, organizational and legal measures necessary to guarantee the security of personal data and avoid its alteration or loss; verifiable integrity of the software inventory evidences this (Law 29733 Art. 9) | Scan |
| `PE-29733-SEC` Security of Processing Systems | Data-bank owners must implement security measures appropriate to the processing performed; assessing and patching the processing stack requires known versions for its components (Law 29733, security-of-processing obligation) | Scan |
| `PE-29733-REG` National Registry of Data Banks | Personal data banks must be registered in the National Registry for Personal Data Protection with identifying details; a uniquely identified, timestamped SBOM supports registration-grade documentation of processing systems (Law 29733, data-bank registration obligation) | Scan |
| `PE-29733-XBORDER` Cross-Border Flow Readiness | Cross-border flows of personal data require guarantees of adequate protection in the destination; establishing what is transferred and by which systems requires precisely identifiable components (Law 29733, cross-border flow provision) | Scan |
| `PE-29733-PROC` Processing by Service Providers | Processing entrusted to a service provider (encargado) must be governed by the controller's instructions and equivalent safeguards, which requires knowing the suppliers behind the software used in processing (Law 29733, processor obligation) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | --------------------------------------------------- |
| `PE-Art5` | Consentimiento (Art. 5) |
| `PE-Art9` | Flujo Transfronterizo (Art. 9) |
| `PE-Art18` | Medidas de Seguridad (Art. 18) |
| `PE-Art19` | Derecho de Información (Art. 19) |
| `PE-Art20` | Derecho de Acceso (Art. 20) |
| `PE-Art21` | Derecho de Rectificación y Cancelación (Art. 21-22) |
| `PE-Art32` | Registro Nacional de Protección de Datos (Art. 32) |
| `PE-DS-01` | Datos Sensibles |
| `PE-ENC-01` | Cifrado y Control de Acceso |
| `PE-BR-01` | Notificación de Violaciones de Seguridad |
## Policy templates
Written for PE 29733:
* Aviso de Privacidad / Política de Privacidad: Marco LATAM
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PE 29733.
# Puerto Rico Act 111-2005 / US Frameworks (/docs/frameworks/americas/puerto-rico-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | PR Act 111 |
| Region | Americas |
| Country or scope | Puerto Rico |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers PR Act 111
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `PR-111-4052` Breach Notification Readiness | Database custodians must notify affected residents and report breaches to DACO within ten days of detection, which requires identifying precisely which components were compromised (10 L.P.R.A. § 4052) | Scan |
| `PR-111-4051` Data Bank Scope Awareness | Owners and custodians of data banks containing personal information must know what systems and software constitute those data banks (10 L.P.R.A. § 4051 definitions and scope) | Scan |
| `PR-111-CRYPTO` Cryptographic Protection | The notification duty is triggered when personal information is not protected by a cryptographic code, making verifiable cryptographic integrity of data-handling components the law's core safeguard (10 L.P.R.A. §§ 4051-4052, cryptographic-protection condition) | Scan |
| `PR-111-ASSESS` Scope and Severity Assessment | Determining whose personal information a breach compromised requires version-tracked knowledge of the software in the data-bank environment (10 L.P.R.A. § 4052, breach-assessment and notification duties) | Scan |
| `PR-111-DOC` Custodian Accountability Records | Custodians answering to DACO and affected citizens must hold identifiable, timestamped documentation of the systems holding personal information (10 L.P.R.A. §§ 4051-4055, custodian responsibilities) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PR Act 111.
# Quebec Law 25 (/docs/frameworks/americas/quebec-law25)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Quebec Bill 64 (Law 25) modernizing privacy - DPO, DPIA, automated decision-making, breach notification.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Law 25 |
| Region | Americas |
| Country or scope | Canada |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Law 25
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for Law 25.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for Law 25 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `QC-L25-10` Security Measures Proportionate to Sensitivity | Enterprises must take security measures ensuring the protection of personal information that are reasonable given its sensitivity, purpose, quantity and medium, which for processing software includes verifiable component integrity (Private Sector Act s. 10, as amended by Law 25) | Scan |
| `QC-L25-3.1` Privacy Governance and Responsible Person | A person in charge of the protection of personal information must be designated and governance policies established, which is supported by clearly attributed, provenance-bearing records of the systems processing personal information (Private Sector Act s. 3.1, as amended by Law 25) | Scan |
| `QC-L25-3.5` Confidentiality Incident Notification Readiness | Confidentiality incidents presenting a risk of serious injury must be notified to the Commission d'acces a l'information and affected persons, requiring the ability to pinpoint which components were involved (Private Sector Act ss. 3.5-3.8, as amended by Law 25) | Scan |
| `QC-L25-3.3` Privacy Impact Assessment of Systems | A privacy impact assessment is required for projects to acquire, develop or overhaul information systems involving personal information, which presumes an inventory of the components those systems comprise (Private Sector Act s. 3.3, as amended by Law 25) | Scan |
| `QC-L25-SP` Service Provider Contracts | Communicating personal information to a service provider requires a written mandate with protection obligations, extending to visibility over the third parties supplying processing software (Law 25 service-provider/outsourcing provisions) | Scan |
| `QC-L25-TRANS` Transparency of Processing | Persons must be informed about the collection and processing of their information, part of a documentation posture supported by identifiable, timestamped records of the processing environment (Law 25 transparency and information duties) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ------------------------------------------ |
| `QC-3.1` | Privacy Policy & Transparency |
| `QC-8` | Consent Management |
| `QC-8.1` | Collection Purpose Specification |
| `QC-12` | Sensitive Information Enhanced Protections |
| `QC-18.1` | Cross-Border Privacy Impact Assessment |
| `QC-21` | Privacy Officer Designation |
| `QC-23` | Privacy Impact Assessment |
| `QC-63.5` | Confidentiality Incident Response |
| `QC-65.1` | Automated Decision-Making Transparency |
## Policy templates
Written for Law 25:
* Quebec Law 25 Privacy Impact Assessment Procedure
* Quebec Law 25 Automated Decision-Making Disclosure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Law 25.
# Saint Kitts and Nevis Data Protection Act 2018 (/docs/frameworks/americas/saint-kitts-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | KN DPA 2018 |
| Region | Americas |
| Country or scope | Saint Kitts and Nevis |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers KN DPA 2018
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `KN-DPA-SEC` Security Principle | Data users must take practical steps to protect personal data from loss, misuse, modification, or unauthorized access, having regard to the security measures incorporated into the equipment and systems where data is stored; integrity hashes on those software components evidence such steps (DPA 2018, Security Principle, Part II) | Scan |
| `KN-DPA-INTEG` Data Integrity Principle | Personal data must be accurate, complete, and not misleading, which presumes the software performing the processing is itself fully identified by name and concrete version (DPA 2018, Data Integrity Principle, Part II) | Scan |
| `KN-DPA-PROC` Processor Reliability | Data users must ensure the reliability, integrity, and competence of processors and personnel with access to personal data, requiring named, accountable suppliers for the processing software (DPA 2018, data-processor obligations) | Scan |
| `KN-DPA-NOT` Notice and Transparency | Data users must give data subjects notice of the processing of their personal data, which presupposes documented, uniquely identified and timestamped records of the processing environment (DPA 2018, Notice and Choice Principle, Part II) | Scan |
| `KN-DPA-INV` Processing Records | The Act's obligations on data users to manage, retain, and disclose personal data responsibly presuppose a maintained inventory of the software components that perform the processing (DPA 2018, data-user obligations) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KN DPA 2018.
# Saint Lucia Data Protection Act (/docs/frameworks/americas/saint-lucia-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | LC DPA |
| Region | Americas |
| Country or scope | Saint Lucia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers LC DPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LC-DPA-SEC` Security Safeguards | Data controllers must protect personal data with appropriate technical and organizational safeguards against loss, unauthorized access, and alteration, including integrity of processing systems (DPA 2011, security-safeguards obligation) | Scan |
| `LC-DPA-ACC` Accuracy of Personal Data | Personal data must be accurate, complete, and kept up to date, requiring precise version tracking of the software maintaining it (DPA 2011, accuracy principle) | Scan |
| `LC-DPA-INV` Accountability for Processing Systems | A data controller is responsible for personal data under its control, presupposing an inventory of the systems and software components processing it (DPA 2011, controller-responsibility provisions) | Scan |
| `LC-DPA-PROC` Processing by Third Parties | Processing carried out on behalf of a controller must be under safeguards equivalent to the controller's own, so third-party component suppliers must be identified (DPA 2011, data-processor provisions) | Scan |
| `LC-DPA-DOC` Openness and Documentation | Controllers must document and make available their data-handling practices, met by an identifiable, timestamped record of the processing environment (DPA 2011, openness/notification provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LC DPA.
# Saint Vincent National ICT / Privacy Framework (/docs/frameworks/americas/saint-vincent-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | VC ICT/Priv |
| Region | Americas |
| Country or scope | Saint Vincent and the Grenadines |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers VC ICT/Priv
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `VC-PRIV-SEC` Security Safeguards | Public authorities must implement reasonable safeguards to protect personal information from unauthorized access, loss, or misuse; verifiable integrity hashes on the software handling that information evidence such safeguards (Privacy Act 2003, security-safeguards provisions) | Scan |
| `VC-PRIV-ACC` Accuracy and Correction | Personal information held must be accurate and individuals may demand corrections, which presumes the processing software is itself completely identified by name and version (Privacy Act 2003, correction-rights provisions) | Scan |
| `VC-PRIV-DISC` Use and Disclosure Limits | Personal information may be used or disclosed only for purposes directly related to its collection, so every third-party component involved in processing must have a named, accountable supplier (Privacy Act 2003, use-and-disclosure provisions) | Scan |
| `VC-PRIV-RET` Retention and Disposal | Personal information may be retained only as long as necessary and must be disposed of securely, which requires knowing exactly which software components, at which versions, hold the data (Privacy Act 2003, retention-and-disposal provisions) | Scan |
| `VC-PRIV-COMM` Commissioner Oversight | The Privacy Commissioner monitors public authorities' compliance, which presupposes documented, uniquely identified and timestamped records of the processing environment available for review (Privacy Act 2003, Privacy Commissioner functions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to VC ICT/Priv.
# SOC2 Type 2 (/docs/frameworks/americas/soc2-type2)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
AICPA Trust Services Criteria assessed for operating effectiveness across the observation window: recurring evidence snapshots, attestation history, and Availability, Confidentiality, and Processing Integrity in required scope alongside Security.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Americas |
| Country or scope | United States |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SOC2 Type 2
* **Scan requirements:** 61: 1 decided by a scan, 5 where a scan checks a prerequisite and evidence decides, 55 that need evidence or an attestation.
* **Controls:** the requirements below, under their published identifiers.
* **Automated tests:** 855 map to its controls, and 360 connectors provide automated evidence for them. See [SOC2 and connectors](/docs/framework-connectors/soc2).
* **Policy templates:** 26: 4 written for SOC2 Type 2 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 61 requirements against what the scan found, including the product's software inventory (SBOM).
* **Scan:** the scan decides whether the requirement is met.
* **Scan, then evidence:** the scan checks a prerequisite and fails the requirement when it is missing. Only evidence or an attestation can pass it.
* **Evidence:** a scan cannot see what the requirement asks for. It passes when a person attests it with evidence.
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- |
| `CC1.1` Commitment to Integrity and Ethical Values | The entity demonstrates a commitment to integrity and ethical values through established standards of conduct, evaluation of adherence, and timely remediation of deviations. | Evidence |
| `CC1.2` Board Oversight of Internal Control | The board of directors (or equivalent) demonstrates independence from management and exercises oversight of the development and performance of internal control. | Evidence |
| `CC1.3` Organizational Structure, Authority, and Responsibility | Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives. | Evidence |
| `CC1.4` Commitment to Competence | The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives, including background screening and security training. | Evidence |
| `CC1.5` Accountability for Internal Control Responsibilities | The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives. | Evidence |
| `CC2.1` Quality Information to Support Internal Control | The entity obtains or generates and uses relevant, quality information to support the functioning of internal control. | Evidence |
| `CC2.2` Internal Communication of Control Responsibilities | The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control. | Evidence |
| `CC2.3` External Communication | The entity communicates with external parties regarding matters affecting the functioning of internal control, including security commitments, incident notifications, and service level terms. | Evidence |
| `CC3.1` Specification of Objectives for Risk Assessment | The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives, including a stated risk appetite and tolerance. | Evidence |
| `CC3.2` Risk Identification and Analysis | The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed, maintaining a risk register with owners. | Evidence |
| `CC3.3` Fraud Risk Assessment | The entity considers the potential for fraud in assessing risks to the achievement of objectives. | Evidence |
| `CC3.4` Assessment of Significant Change | The entity identifies and assesses changes, including changes in technology, that could significantly impact the system of internal control. | Evidence |
| `CC4.1` Ongoing and Separate Evaluations of Controls | The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning, including continuous monitoring and internal audits. | Evidence |
| `CC4.2` Evaluation and Communication of Deficiencies | The entity evaluates and communicates internal control deficiencies in a timely manner to parties responsible for corrective action, tracking deficiencies to remediation. | Evidence |
| `CC5.1` Selection and Development of Control Activities | The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels, mapped to the risk register. | Evidence |
| `CC5.2` Technology General Controls | The entity selects and develops general control activities over technology to support the achievement of objectives, including MFA, endpoint protection, and security tooling deployment. | Evidence |
| `CC5.3` Deployment Through Policies and Procedures | The entity deploys control activities through policies that establish what is expected and procedures that put policies into action. | Evidence |
| `CC6.1` Logical Access Security: Protected Information Assets | The entity implements logical access security software, infrastructure, and architectures over protected information assets. A complete, current inventory of system components is the foundational prerequisite; full satisfaction additionally requires access management evidence (SSO/MFA, least privilege). | Scan, then evidence |
| `CC6.2` User Registration and Authorization | Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users; access requests require documented approval. | Evidence |
| `CC6.3` Access Modification and Removal | The entity authorizes, modifies, or removes access based on roles and responsibilities; terminated users are de-provisioned in a timely manner (within 24 hours is the auditor benchmark). | Evidence |
| `CC6.4` Restriction of Physical Access | The entity restricts physical access to facilities and protected information assets to authorized personnel. | Evidence |
| `CC6.5` Disposal of Assets and Data | The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data from those assets has been diminished. | Evidence |
| `CC6.6` Protection Against External Threats | The entity implements logical access security measures to protect against threats from sources outside its system boundaries, including firewalls, IDS/IPS, and network segmentation. | Evidence |
| `CC6.7` Protection of Data in Transmission and Movement | The entity restricts the transmission, movement, and removal of information to authorized users and processes, and protects it during transmission (TLS enforcement, encrypted transfer). | Evidence |
| `CC6.8` Prevention and Detection of Unauthorized Software | The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software. Verifiable component provenance (integrity hashes, known licenses) evidences detection capability for third-party software. | Scan, then evidence |
| `CC7.1` Vulnerability Detection and Monitoring | The entity uses detection and monitoring procedures to identify changes to configurations that introduce vulnerabilities, and susceptibilities to newly discovered vulnerabilities, including recurring vulnerability scanning of system components. | Scan |
| `CC7.2` Monitoring of System Components for Anomalies | The entity monitors system components and the operation of those components for anomalies indicative of malicious acts, natural disasters, and errors. Version identification of every component is the prerequisite for change and anomaly detection. | Scan, then evidence |
| `CC7.3` Evaluation of Security Events | The entity evaluates security events to determine whether they could or have resulted in a failure to meet objectives (security incidents) and, if so, takes action to prevent or address such failures. | Evidence |
| `CC7.4` Incident Response and Containment | The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents. | Evidence |
| `CC7.5` Recovery from Identified Security Incidents | The entity identifies, develops, and implements activities to recover from identified security incidents, including post-incident review and remediation of identified vulnerabilities within defined SLAs. | Evidence |
| `CC8.1` Authorized, Tested, and Approved Changes | The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures; production changes require prior approval and testing. | Evidence |
| `CC9.1` Business Disruption Risk Mitigation | The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions, including business continuity planning and testing. | Evidence |
| `CC9.2` Vendor and Business Partner Risk Management | The entity assesses and manages risks associated with vendors and business partners. A complete third-party software supplier inventory is the foundational evidence; full satisfaction additionally requires vendor assessments and agreements. | Scan, then evidence |
| `A1.1` Capacity Management | The entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and enable the implementation of additional capacity. | Evidence |
| `A1.2` Environmental Protections, Backup, and Recovery Infrastructure | The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure; backups are performed and restore-tested. | Evidence |
| `A1.3` Recovery Plan Testing | The entity tests recovery plan procedures supporting system recovery to meet its objectives, with defined RTO/RPO and documented test results. | Evidence |
| `C1.1` Identification and Protection of Confidential Information | The entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality, including data classification and inventory. | Evidence |
| `C1.2` Disposal of Confidential Information | The entity disposes of confidential information to meet the entity's objectives related to confidentiality, per a retention and disposal policy with evidence of destruction. | Evidence |
| `PI1.1` Processing Integrity Objectives and Specifications | The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications. | Evidence |
| `PI1.2` System Input Completeness and Accuracy | The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting that meet the entity's objectives. | Evidence |
| `PI1.3` System Processing Completeness and Accuracy | The entity implements policies and procedures over system processing to result in products, services, and reporting that meet the entity's objectives. | Evidence |
| `PI1.4` System Output Completeness and Accuracy | The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity's objectives. | Evidence |
| `PI1.5` Storage Integrity of Inputs, Items in Processing, and Outputs | The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications. Integrity hashes on stored software components evidence tamper detection. | Scan, then evidence |
| `P1.1` Privacy Notice | The entity provides notice to data subjects about its privacy practices to meet the entity's objectives related to privacy, and the notice is current, complete, and consistent with actual practice. | Evidence |
| `P2.1` Choice and Consent | The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information, and obtains consent where required. | Evidence |
| `P3.1` Collection Limited to Identified Purposes | Personal information is collected consistent with the entity's objectives related to privacy and limited to the purposes identified in the privacy notice. | Evidence |
| `P3.2` Explicit Consent for Sensitive Information | For information requiring explicit consent, the entity communicates the need for such consent and obtains it prior to collection. | Evidence |
| `P4.1` Use of Personal Information Limited to Identified Purposes | The entity limits the use of personal information to the purposes identified in the entity's objectives related to privacy. | Evidence |
| `P4.2` Retention of Personal Information | The entity retains personal information consistent with the entity's objectives related to privacy, per a documented retention schedule. | Evidence |
| `P4.3` Disposal of Personal Information | The entity securely disposes of personal information when retention is no longer required, with evidence of disposal. | Evidence |
| `P5.1` Data Subject Access | The entity grants identified and authenticated data subjects the ability to access their stored personal information for review and, upon request, provides physical or electronic copies. | Evidence |
| `P5.2` Data Subject Correction | The entity corrects, amends, or appends personal information based on information provided by data subjects and communicates such information to third parties, as committed or required. | Evidence |
| `P6.1` Disclosure Limited to Identified Purposes with Consent | The entity discloses personal information to third parties with the explicit consent of data subjects, and such consent is obtained prior to disclosure. | Evidence |
| `P6.2` Record of Authorized Disclosures | The entity creates and retains a complete, accurate, and timely record of authorized disclosures of personal information. | Evidence |
| `P6.3` Record of Unauthorized Disclosures | The entity creates and retains a complete, accurate, and timely record of detected or reported unauthorized disclosures (including breaches) of personal information. | Evidence |
| `P6.4` Third-Party Privacy Commitments | The entity obtains privacy commitments from vendors and other third parties who have access to personal information, consistent with the entity's privacy commitments. | Evidence |
| `P6.5` Third-Party Compliance Assessment | The entity obtains commitments from vendors and other third parties with access to personal information to notify the entity in the event of actual or suspected unauthorized disclosures, and assesses compliance as needed. | Evidence |
| `P6.6` Breach Notification to Data Subjects | The entity provides notification of breaches and incidents to affected data subjects, regulators, and others to meet the entity's objectives related to privacy. | Evidence |
| `P6.7` Accounting of Personal Information Held | The entity provides data subjects with an accounting of the personal information held and disclosure of the data subjects' personal information, upon request. | Evidence |
| `P7.1` Quality of Personal Information | The entity collects and maintains accurate, up-to-date, complete, and relevant personal information to meet the entity's objectives related to privacy. | Evidence |
| `P8.1` Privacy Inquiry, Complaint, and Dispute Resolution | The entity implements a process for receiving, addressing, resolving, and communicating the resolution of inquiries, complaints, and disputes from data subjects, with defined escalation and monitoring of unresolved matters. | Evidence |
## Policy templates
Written for SOC2 Type 2:
* SOC2 Type 2 Continuous Monitoring and Control Testing Policy
* SOC2 Type 2 Availability and Business Continuity Policy
* SOC2 Type 2 Incident Detection and Response Policy
* SOC2 Type 2 Vendor Risk Periodic Assessment Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SOC2 Type 2.
# SOC2 Type 1 (/docs/frameworks/americas/soc2)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
AICPA Trust Services Criteria (2017, 2022 Points of Focus), point-in-time assessment of control design: full CC1-CC9 Common Criteria, with Availability, Confidentiality, Processing Integrity, and Privacy visible as optional scope.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Americas |
| Country or scope | United States |
| Sector | General |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SOC2 Type 1
* **Scan requirements:** 61: 1 decided by a scan, 5 where a scan checks a prerequisite and evidence decides, 55 that need evidence or an attestation.
* **Controls:** the requirements below, under their published identifiers.
* **Automated tests:** 855 map to its controls, and 360 connectors provide automated evidence for them. See [SOC2 and connectors](/docs/framework-connectors/soc2).
* **Policy templates:** 26: 4 written for SOC2 Type 1 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 61 requirements against what the scan found, including the product's software inventory (SBOM).
* **Scan:** the scan decides whether the requirement is met.
* **Scan, then evidence:** the scan checks a prerequisite and fails the requirement when it is missing. Only evidence or an attestation can pass it.
* **Evidence:** a scan cannot see what the requirement asks for. It passes when a person attests it with evidence.
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------- |
| `CC1.1` Commitment to Integrity and Ethical Values | The entity demonstrates a commitment to integrity and ethical values through established standards of conduct, evaluation of adherence, and timely remediation of deviations. | Evidence |
| `CC1.2` Board Oversight of Internal Control | The board of directors (or equivalent) demonstrates independence from management and exercises oversight of the development and performance of internal control. | Evidence |
| `CC1.3` Organizational Structure, Authority, and Responsibility | Management establishes, with board oversight, structures, reporting lines, and appropriate authorities and responsibilities in the pursuit of objectives. | Evidence |
| `CC1.4` Commitment to Competence | The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with objectives, including background screening and security training. | Evidence |
| `CC1.5` Accountability for Internal Control Responsibilities | The entity holds individuals accountable for their internal control responsibilities in the pursuit of objectives. | Evidence |
| `CC2.1` Quality Information to Support Internal Control | The entity obtains or generates and uses relevant, quality information to support the functioning of internal control. | Evidence |
| `CC2.2` Internal Communication of Control Responsibilities | The entity internally communicates information, including objectives and responsibilities for internal control, necessary to support the functioning of internal control. | Evidence |
| `CC2.3` External Communication | The entity communicates with external parties regarding matters affecting the functioning of internal control, including security commitments, incident notifications, and service level terms. | Evidence |
| `CC3.1` Specification of Objectives for Risk Assessment | The entity specifies objectives with sufficient clarity to enable the identification and assessment of risks relating to objectives, including a stated risk appetite and tolerance. | Evidence |
| `CC3.2` Risk Identification and Analysis | The entity identifies risks to the achievement of its objectives across the entity and analyzes risks as a basis for determining how the risks should be managed, maintaining a risk register with owners. | Evidence |
| `CC3.3` Fraud Risk Assessment | The entity considers the potential for fraud in assessing risks to the achievement of objectives. | Evidence |
| `CC3.4` Assessment of Significant Change | The entity identifies and assesses changes, including changes in technology, that could significantly impact the system of internal control. | Evidence |
| `CC4.1` Ongoing and Separate Evaluations of Controls | The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning, including continuous monitoring and internal audits. | Evidence |
| `CC4.2` Evaluation and Communication of Deficiencies | The entity evaluates and communicates internal control deficiencies in a timely manner to parties responsible for corrective action, tracking deficiencies to remediation. | Evidence |
| `CC5.1` Selection and Development of Control Activities | The entity selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels, mapped to the risk register. | Evidence |
| `CC5.2` Technology General Controls | The entity selects and develops general control activities over technology to support the achievement of objectives, including MFA, endpoint protection, and security tooling deployment. | Evidence |
| `CC5.3` Deployment Through Policies and Procedures | The entity deploys control activities through policies that establish what is expected and procedures that put policies into action. | Evidence |
| `CC6.1` Logical Access Security: Protected Information Assets | The entity implements logical access security software, infrastructure, and architectures over protected information assets. A complete, current inventory of system components is the foundational prerequisite; full satisfaction additionally requires access management evidence (SSO/MFA, least privilege). | Scan, then evidence |
| `CC6.2` User Registration and Authorization | Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users; access requests require documented approval. | Evidence |
| `CC6.3` Access Modification and Removal | The entity authorizes, modifies, or removes access based on roles and responsibilities; terminated users are de-provisioned in a timely manner (within 24 hours is the auditor benchmark). | Evidence |
| `CC6.4` Restriction of Physical Access | The entity restricts physical access to facilities and protected information assets to authorized personnel. | Evidence |
| `CC6.5` Disposal of Assets and Data | The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data from those assets has been diminished. | Evidence |
| `CC6.6` Protection Against External Threats | The entity implements logical access security measures to protect against threats from sources outside its system boundaries, including firewalls, IDS/IPS, and network segmentation. | Evidence |
| `CC6.7` Protection of Data in Transmission and Movement | The entity restricts the transmission, movement, and removal of information to authorized users and processes, and protects it during transmission (TLS enforcement, encrypted transfer). | Evidence |
| `CC6.8` Prevention and Detection of Unauthorized Software | The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software. Verifiable component provenance (integrity hashes, known licenses) evidences detection capability for third-party software. | Scan, then evidence |
| `CC7.1` Vulnerability Detection and Monitoring | The entity uses detection and monitoring procedures to identify changes to configurations that introduce vulnerabilities, and susceptibilities to newly discovered vulnerabilities, including recurring vulnerability scanning of system components. | Scan |
| `CC7.2` Monitoring of System Components for Anomalies | The entity monitors system components and the operation of those components for anomalies indicative of malicious acts, natural disasters, and errors. Version identification of every component is the prerequisite for change and anomaly detection. | Scan, then evidence |
| `CC7.3` Evaluation of Security Events | The entity evaluates security events to determine whether they could or have resulted in a failure to meet objectives (security incidents) and, if so, takes action to prevent or address such failures. | Evidence |
| `CC7.4` Incident Response and Containment | The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents. | Evidence |
| `CC7.5` Recovery from Identified Security Incidents | The entity identifies, develops, and implements activities to recover from identified security incidents, including post-incident review and remediation of identified vulnerabilities within defined SLAs. | Evidence |
| `CC8.1` Authorized, Tested, and Approved Changes | The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures; production changes require prior approval and testing. | Evidence |
| `CC9.1` Business Disruption Risk Mitigation | The entity identifies, selects, and develops risk mitigation activities for risks arising from potential business disruptions, including business continuity planning and testing. | Evidence |
| `CC9.2` Vendor and Business Partner Risk Management | The entity assesses and manages risks associated with vendors and business partners. A complete third-party software supplier inventory is the foundational evidence; full satisfaction additionally requires vendor assessments and agreements. | Scan, then evidence |
| `A1.1` Capacity Management | The entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and enable the implementation of additional capacity. | Evidence |
| `A1.2` Environmental Protections, Backup, and Recovery Infrastructure | The entity authorizes, designs, develops or acquires, implements, operates, approves, maintains, and monitors environmental protections, software, data backup processes, and recovery infrastructure; backups are performed and restore-tested. | Evidence |
| `A1.3` Recovery Plan Testing | The entity tests recovery plan procedures supporting system recovery to meet its objectives, with defined RTO/RPO and documented test results. | Evidence |
| `C1.1` Identification and Protection of Confidential Information | The entity identifies and maintains confidential information to meet the entity's objectives related to confidentiality, including data classification and inventory. | Evidence |
| `C1.2` Disposal of Confidential Information | The entity disposes of confidential information to meet the entity's objectives related to confidentiality, per a retention and disposal policy with evidence of destruction. | Evidence |
| `PI1.1` Processing Integrity Objectives and Specifications | The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and product and service specifications. | Evidence |
| `PI1.2` System Input Completeness and Accuracy | The entity implements policies and procedures over system inputs, including controls over completeness and accuracy, to result in products, services, and reporting that meet the entity's objectives. | Evidence |
| `PI1.3` System Processing Completeness and Accuracy | The entity implements policies and procedures over system processing to result in products, services, and reporting that meet the entity's objectives. | Evidence |
| `PI1.4` System Output Completeness and Accuracy | The entity implements policies and procedures to make available or deliver output completely, accurately, and timely in accordance with specifications to meet the entity's objectives. | Evidence |
| `PI1.5` Storage Integrity of Inputs, Items in Processing, and Outputs | The entity implements policies and procedures to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications. Integrity hashes on stored software components evidence tamper detection. | Scan, then evidence |
| `P1.1` Privacy Notice | The entity provides notice to data subjects about its privacy practices to meet the entity's objectives related to privacy, and the notice is current, complete, and consistent with actual practice. | Evidence |
| `P2.1` Choice and Consent | The entity communicates choices available regarding the collection, use, retention, disclosure, and disposal of personal information, and obtains consent where required. | Evidence |
| `P3.1` Collection Limited to Identified Purposes | Personal information is collected consistent with the entity's objectives related to privacy and limited to the purposes identified in the privacy notice. | Evidence |
| `P3.2` Explicit Consent for Sensitive Information | For information requiring explicit consent, the entity communicates the need for such consent and obtains it prior to collection. | Evidence |
| `P4.1` Use of Personal Information Limited to Identified Purposes | The entity limits the use of personal information to the purposes identified in the entity's objectives related to privacy. | Evidence |
| `P4.2` Retention of Personal Information | The entity retains personal information consistent with the entity's objectives related to privacy, per a documented retention schedule. | Evidence |
| `P4.3` Disposal of Personal Information | The entity securely disposes of personal information when retention is no longer required, with evidence of disposal. | Evidence |
| `P5.1` Data Subject Access | The entity grants identified and authenticated data subjects the ability to access their stored personal information for review and, upon request, provides physical or electronic copies. | Evidence |
| `P5.2` Data Subject Correction | The entity corrects, amends, or appends personal information based on information provided by data subjects and communicates such information to third parties, as committed or required. | Evidence |
| `P6.1` Disclosure Limited to Identified Purposes with Consent | The entity discloses personal information to third parties with the explicit consent of data subjects, and such consent is obtained prior to disclosure. | Evidence |
| `P6.2` Record of Authorized Disclosures | The entity creates and retains a complete, accurate, and timely record of authorized disclosures of personal information. | Evidence |
| `P6.3` Record of Unauthorized Disclosures | The entity creates and retains a complete, accurate, and timely record of detected or reported unauthorized disclosures (including breaches) of personal information. | Evidence |
| `P6.4` Third-Party Privacy Commitments | The entity obtains privacy commitments from vendors and other third parties who have access to personal information, consistent with the entity's privacy commitments. | Evidence |
| `P6.5` Third-Party Compliance Assessment | The entity obtains commitments from vendors and other third parties with access to personal information to notify the entity in the event of actual or suspected unauthorized disclosures, and assesses compliance as needed. | Evidence |
| `P6.6` Breach Notification to Data Subjects | The entity provides notification of breaches and incidents to affected data subjects, regulators, and others to meet the entity's objectives related to privacy. | Evidence |
| `P6.7` Accounting of Personal Information Held | The entity provides data subjects with an accounting of the personal information held and disclosure of the data subjects' personal information, upon request. | Evidence |
| `P7.1` Quality of Personal Information | The entity collects and maintains accurate, up-to-date, complete, and relevant personal information to meet the entity's objectives related to privacy. | Evidence |
| `P8.1` Privacy Inquiry, Complaint, and Dispute Resolution | The entity implements a process for receiving, addressing, resolving, and communicating the resolution of inquiries, complaints, and disputes from data subjects, with defined escalation and monitoring of unresolved matters. | Evidence |
## Policy templates
Written for SOC2 Type 1:
* SOC2 Information Security Policy
* SOC2 Logical Access Management Policy
* SOC2 Change Management Policy
* SOC2 Vendor and Third-Party Risk Management Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SOC2 Type 1.
# SOX ITGC (/docs/frameworks/americas/sox-itgc)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Sarbanes-Oxley IT General Controls: change management, software inventory, supplier accountability.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SOX |
| Region | Americas |
| Country or scope | United States |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SOX
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for SOX.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for SOX and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SOX-404-INV` Inventory of Financially Relevant Software | Assessing internal control over financial reporting requires identifying the software components that make up in-scope financial systems (SOX §404; ITGC scoping practice) | Scan |
| `SOX-ITGC-CM` Change Management Evidence | ITGC change management requires that changes to in-scope software are tracked and auditable, which depends on known versions for every component (SOX §404 ITGC: change management domain) | Scan |
| `SOX-ITGC-SPEC` Deterministic Deployments | Reliable financial processing requires deterministic, reproducible software configurations: no floating or unspecified component versions (SOX §404 ITGC, change management / operations) | Scan |
| `SOX-ITGC-VEN` Supplier Accountability | Controls over third-party software used in financial reporting require knowing which vendor supplies each component so vendor controls (e.g. SOC reports) can be mapped (SOX §404 ITGC: third-party/vendor management practice) | Scan |
| `SOX-302-DOC` Auditable System Records | Officer certifications of internal control presuppose reliable, dated documentation of the systems in scope; an identified, timestamped SBOM supplies that record for software composition (SOX §302 certification duty) | Scan |
| `SOX-ITGC-INT` Program Integrity | ITGCs must provide assurance that financial application code is not altered without authorization, supported by integrity hashes on deployed components (SOX §404 ITGC: program change / operations integrity) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | --------------------------------------------------------- |
| `ITGC.AC.1` | Control User Access to Financial Systems |
| `ITGC.AC.2` | Control Privileged and Administrative Access |
| `ITGC.AC.3` | Segregate Incompatible Duties |
| `ITGC.CM.1` | Manage and Document Application Changes |
| `ITGC.CM.2` | Segregate Development from Production Environments |
| `ITGC.CM.3` | Control Infrastructure and Configuration Changes |
| `ITGC.OP.1` | Perform Data Backups and Verify Restorability |
| `ITGC.OP.2` | Monitor and Alert on IT Operations |
| `ITGC.OP.3` | Implement Incident Management Procedures |
| `ITGC.BC.1` | Establish Business Continuity and Disaster Recovery Plans |
| `ITGC.CM.4` | Maintain Program Change Audit Trail |
| `ITGC.AC.4` | Perform Periodic User Access Reviews |
| `ITGC.CM.5` | Implement Source Code Management and Version Control |
| `ITGC.OP.4` | Manage Third-Party IT Service Provider Risk |
## Policy templates
Written for SOX:
* SOX ITGC Access Control Policy for Financial Systems
* SOX ITGC Change Management Policy
* SOX ITGC IT Operations and Data Backup Policy
* SOX ITGC Third-Party IT Service Provider Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SOX.
# StateRAMP (/docs/frameworks/americas/stateramp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
State government cloud security: software component inventory, supply chain documentation.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Americas |
| Country or scope | United States |
| Sector | Cloud |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers StateRAMP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for StateRAMP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for StateRAMP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `STRAMP-CM-8` System Component Inventory | Providers must maintain an accurate inventory of the components of the authorized system, per the CM-8 control incorporated into StateRAMP baselines (StateRAMP baseline: NIST SP 800-53r5 CM-8) | Scan |
| `STRAMP-RA-5` Continuous Vulnerability Scanning | Continuous monitoring requires monthly vulnerability scanning, which depends on components carrying identifiers matchable to vulnerability databases (StateRAMP continuous monitoring: NIST SP 800-53r5 RA-5) | Scan |
| `STRAMP-SR-4` Supply Chain Documentation | Providers must document the provenance of system components, including who produced the supply chain documentation itself (StateRAMP baseline: NIST SP 800-53r5 SR-4) | Scan |
| `STRAMP-SR-3` Supplier Identification | Supply chain risk management processes require identifying the suppliers of system components (StateRAMP baseline: NIST SP 800-53r5 SR-3) | Scan |
| `STRAMP-SI-7` Software Integrity | Integrity verification of software must be supported, requiring hashes for the components in the deployed system (StateRAMP baseline: NIST SP 800-53r5 SI-7) | Scan |
| `STRAMP-SI-2` Flaw Remediation Data | Timely flaw remediation obligations require version data for all system components so patch applicability can be established (StateRAMP baseline: NIST SP 800-53r5 SI-2) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | ------------------------------------------------------ |
| `SRMP-AC-2` | Account management for state government cloud services |
| `SRMP-CA-2` | StateRAMP security control assessment |
| `SRMP-IR-6` | Report incidents to state CISO and StateRAMP PMO |
| `SRMP-SC-28` | Encrypt state government data at rest |
| `SRMP-RA-5` | Monthly vulnerability scanning for StateRAMP |
| `SRMP-CONMON` | StateRAMP continuous monitoring and reporting |
| `SRMP-AT-2` | Security awareness training for state data handlers |
| `SRMP-SA-9` | Manage subcontractors handling state government data |
| `SRMP-PL-8` | Maintain StateRAMP System Security Plan |
## Policy templates
Written for StateRAMP:
* StateRAMP Authorization and Cloud Procurement Policy
* State Government Data Classification and Cloud Handling Policy
* StateRAMP Vendor Management and Annual Review Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to StateRAMP.
# Suriname National Privacy Framework (/docs/frameworks/americas/suriname-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SR Privacy |
| Region | Americas |
| Country or scope | Suriname |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SR Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SR-CONST-17` Protection of Private Life in Information Systems | The constitutional protection of private life and correspondence implies integrity safeguards for systems that store or transmit personal information (Constitution of 1987 Art. 17) | Scan |
| `SR-FW-INV` Knowledge of Processing Systems | General duties of care over personal information require organizations to know which software systems and components handle it (Surinamese privacy framework, general duty of care) | Scan |
| `SR-FW-ID` Identifiability of Processing Components | Responding to privacy complaints or incidents requires that processing components carry standard identifiers (Surinamese privacy framework, incident-response readiness) | Scan |
| `SR-FW-VER` Maintained and Current Systems | The duty of care implies keeping processing software identified by version so defects affecting personal information can be assessed (Surinamese privacy framework, duty of care) | Scan |
| `SR-FW-DOC` Documented Processing Environment | Demonstrating responsible handling of personal information requires an identifiable, timestamped record of the processing environment (Surinamese privacy framework, accountability practice) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SR Privacy.
# Tennessee TIPA (/docs/frameworks/americas/tennessee-tipa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Tennessee Information Protection Act - controller duties, NIST Privacy Framework alignment.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | TN TIPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers TN TIPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for TN TIPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for TN TIPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TN-TIPA-SEC` Data Security Practices | Controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices appropriate to the volume and nature of personal information; integrity-verifiable processing software evidences those practices (Tenn. Code Ann. § 47-18-3201 et seq., controller-duties provision) | Scan |
| `TN-TIPA-NIST` NIST Privacy Framework Program Evidence | TIPA's affirmative defense rewards a documented, repeatable privacy program reasonably conforming to the NIST Privacy Framework; machine-readable, standardised documentation of processing systems (SPDX/CycloneDX) is characteristic of such a program (Tenn. Code Ann. § 47-18-3201 et seq., NIST-conformance affirmative defense) | Scan |
| `TN-TIPA-INV` Processing Inventory | Both the minimisation duty and NIST Privacy Framework's Identify function require knowing what systems and software process personal information; an enumerated component inventory is the baseline artifact (Tenn. Code Ann. § 47-18-3201 et seq., read with NIST PF Identify-P) | Scan |
| `TN-TIPA-PROC` Processor Obligations | Processing on a controller's behalf must be governed by binding contracts with flow-down to subcontractors; the supplier behind each third-party component should be named to demonstrate oversight (Tenn. Code Ann. § 47-18-3201 et seq., processor provisions) | Scan |
| `TN-TIPA-DPIA` Data Protection Assessment Readiness | Data protection assessments are required for targeted advertising, sale, risky profiling and sensitive data; assessing risk requires the versions of the software involved to be recorded (Tenn. Code Ann. § 47-18-3201 et seq., data protection assessment provisions) | Scan |
| `TN-TIPA-RIGHTS` Consumer Rights Fulfilment | Consumers may confirm processing, access, correct, delete and port personal information and opt out of targeted advertising, sale and profiling; fulfilling requests requires unambiguous identification of the components holding the data (Tenn. Code Ann. § 47-18-3201 et seq., consumer-rights provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ----------------------------------------------------------- |
| `TCA-47-18-3202` | Consumer Rights: Access, Correction, Deletion & Portability |
| `TCA-47-18-3203` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `TCA-47-18-3204` | Sensitive Data: Opt-In Consent |
| `TCA-47-18-3206` | Data Protection Assessment |
| `TCA-47-18-3207` | Processor Contracts |
| `TCA-47-18-3201` | Privacy Notice |
| `TCA-47-18-3205` | Controller Security & Minimization Duties |
| `TCA-47-18-3208` | Consumer Appeals |
## Policy templates
Written for TN TIPA:
* Tennessee TIPA State Privacy Notice
* Tennessee TIPA Data Protection Assessment Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TN TIPA.
# Texas TDPSA (/docs/frameworks/americas/texas-tdpsa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Texas Data Privacy and Security Act - controller obligations, consumer rights, sensitive data.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | TX TDPSA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers TX TDPSA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for TX TDPSA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for TX TDPSA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TX-TDPSA-101-SEC` Data Security Practices | Controllers must establish, implement and maintain reasonable administrative, technical and physical data security practices appropriate to the volume and nature of the personal data at issue; verifiable integrity of processing software evidences this (Tex. Bus. & Com. Code § 541.101) | Scan |
| `TX-TDPSA-101-MIN` Collection Limitation Accountability | Collection is limited to what is adequate, relevant and reasonably necessary for the disclosed purpose; demonstrating this requires a named processing platform with its software components enumerated (Tex. Bus. & Com. Code § 541.101) | Scan |
| `TX-TDPSA-104` Processor Obligations | Processors must assist controllers and operate under contracts specifying instructions, data categories and downstream flow-through to subcontractors; each third-party component should carry a named supplier (Tex. Bus. & Com. Code § 541.104) | Scan |
| `TX-TDPSA-105` Data Protection Assessments | Documented assessments are required for targeted advertising, sale, profiling with foreseeable risk, and sensitive data processing; credible assessment requires the versions of the involved software to be recorded (Tex. Bus. & Com. Code § 541.105) | Scan |
| `TX-TDPSA-051` Consumer Rights Fulfilment | Consumers may confirm processing, access, correct, delete, port their data and opt out of targeted advertising, sale and profiling; those requests can only be executed if the processing components are unambiguously identifiable (Tex. Bus. & Com. Code § 541.051) | Scan |
| `TX-TDPSA-NOTICE` Privacy Notice Documentation | Controllers must post a reasonably accessible and clear privacy notice including categories processed, sharing, and sale of sensitive or biometric data; supporting system documentation should be identified and timestamped (Tex. Bus. & Com. Code ch. 541 privacy-notice provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ----------------------------------------------------------- |
| `TX-BC-541.052` | Consumer Rights: Access, Correction, Deletion & Portability |
| `TX-BC-541.053` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `TX-BC-541.054` | Sensitive Data: Opt-In Consent |
| `TX-BC-541.101` | Data Protection Assessment |
| `TX-BC-541.102` | Processor Agreements |
| `TX-BC-541.051` | Privacy Notice & Transparency |
| `TX-BC-541.055` | Consumer Appeals |
| `TX-BC-541.103` | Controller Duties: Security & Minimization |
| `TX-BC-541.201` | Universal Opt-Out Mechanism |
## Policy templates
Written for TX TDPSA:
* Texas TDPSA State Privacy Notice
* Texas TDPSA Sensitive Data Consent Policy
* Texas TDPSA Data Protection Assessment Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TX TDPSA.
# Trinidad and Tobago Data Protection Act 2011 (/docs/frameworks/americas/trinidad-tobago-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TT DPA |
| Region | Americas |
| Country or scope | Trinidad and Tobago |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TT DPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TT-DPA-SEC` Security Safeguards Principle | Personal information must be protected by safeguards appropriate to its sensitivity, including integrity protection for the systems that store it (DPA 2011 s.6 General Privacy Principles, security safeguard) | Scan |
| `TT-DPA-ACC` Accuracy of Information | Organizations must keep personal information accurate and up to date, which requires precise version tracking of the software maintaining records (DPA 2011 s.6 General Privacy Principles, accuracy) | Scan |
| `TT-DPA-INV` Accountability for Processing Systems | An organization is accountable for personal information under its control, presupposing an inventory of the systems and components handling it (DPA 2011 s.6 General Privacy Principles, accountability) | Scan |
| `TT-DPA-TP` Third-Party Disclosure Controls | Disclosure to and processing by third parties must be controlled, so the suppliers behind processing components must be identified (DPA 2011, third-party disclosure provisions) | Scan |
| `TT-DPA-DOC` Openness and Documentation | Policies and practices about information handling must be documented and available, met by an identifiable, timestamped record of the software environment (DPA 2011 s.6 General Privacy Principles, openness) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TT DPA.
# TSA Pipeline Security Directives (/docs/frameworks/americas/tsa-pipeline)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
TSA Security Directives for pipeline operators - cybersecurity architecture, IR plans, vulnerability mgmt.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | TSA SD |
| Region | Americas |
| Country or scope | United States |
| Sector | Energy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers TSA SD
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for TSA SD.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for TSA SD and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TSA-SD02-INV` Critical Cyber System Identification | Owner/operators must identify their critical cyber systems in the Cybersecurity Implementation Plan; an enumerated inventory of the software components composing those systems is the foundational artifact (TSA SD Pipeline-2021-02 series, Cybersecurity Implementation Plan requirements) | Scan |
| `TSA-SD02-IDENT` Unambiguous Asset Identification | Risk-based defense of critical cyber systems requires each software asset to be matchable against vulnerability intelligence; components should carry standard identifiers (PURL/CPE) at a high coverage bar befitting critical infrastructure (TSA SD Pipeline-2021-02 series, asset identification provisions) | Scan |
| `TSA-SD02-PATCH` Patch and Update Management | Operators must apply security patches and updates for operating systems, applications, drivers and firmware on a risk-informed timeline to reduce the risk of exploitation of unpatched systems; this requires near-complete version records across the estate (TSA SD Pipeline-2021-02 series, patch-management provisions) | Scan |
| `TSA-SD02-VERS` Determinable Versions for Risk Assessment | Risk-based patch prioritisation collapses if deployed versions are indeterminate; vague version declarations (latest, wildcards, ranges) make exposure to a given CVE unassessable (TSA SD Pipeline-2021-02 series, vulnerability-management provisions) | Scan |
| `TSA-SD02-DETECT` Integrity Monitoring and Threat Detection | Continuous monitoring and detection policies must be able to detect malicious activity and unauthorised change on critical cyber systems; baseline integrity hashes for deployed components are the reference point for detecting tampering (TSA SD Pipeline-2021-02 series, monitoring and detection provisions) | Scan |
| `TSA-SD01-COORD` Cybersecurity Coordinator Contact | Owner/operators must designate a cybersecurity coordinator available to TSA and CISA 24/7 and report incidents to CISA within the mandated window; a recorded, reachable responsible contact in system documentation evidences that accountability chain (TSA SD Pipeline-2021-01, coordinator and incident-reporting requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | --------------------------------- |
| `TSA-IP-01` | Cybersecurity Implementation Plan |
| `TSA-IR-01` | Incident Response Plan |
| `TSA-VA-01` | Vulnerability Assessment |
| `TSA-NS-01` | Network Segmentation |
| `TSA-MFA-01` | Multi-Factor Authentication |
| `TSA-PM-01` | Patch & Update Management |
| `TSA-CA-01` | Cybersecurity Architecture Review |
| `TSA-AC-01` | Least Privilege Access Control |
| `TSA-LOG-01` | Security Logging & Monitoring |
| `TSA-PT-01` | Pipeline Cybersecurity Training |
## Policy templates
Written for TSA SD:
* Pipeline Cybersecurity Implementation Plan: TSA SD 2021-02
* Pipeline Cybersecurity Incident Response Plan: TSA SD 2021-02
* Pipeline Cybersecurity Vulnerability Assessment Plan: TSA SD 2021-02
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TSA SD.
# Turks and Caicos Data Protection Ordinance (/docs/frameworks/americas/turks-caicos-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TC DP Ord |
| Region | Americas |
| Country or scope | Turks and Caicos |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TC DP Ord
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TC-CONST-PRIV` Processing System Inventory | The constitutional protection of private and family life presumes entities can account for the systems and software processing personal information (Turks and Caicos Islands Constitution Order 2011, fundamental rights provisions) | Scan |
| `TC-ETO-REG` Regulation-Ready Documentation | The enabling power to regulate personal-data processing anticipates that processors maintain identifiable, timestamped documentation of their systems (Electronic Transactions Ordinance, data-processing regulation-making power) | Scan |
| `TC-SEC-BASE` Baseline Data Safeguards | Entities handling residents' personal data are expected to maintain baseline technical safeguards, including integrity verification of data-handling components (Turks and Caicos privacy framework, baseline safeguards pending dedicated legislation) | Scan |
| `TC-3P-ACC` Third-Party Accountability | Electronic-commerce operators relying on third-party services remain accountable for the personal data those parties touch, requiring supplier visibility for third-party software (Electronic Transactions Ordinance, electronic-commerce framework) | Scan |
| `TC-ID-READY` Incident Impact Readiness | Assessing the impact of a privacy incident requires the ability to identify precisely which software components hold or process personal information (Turks and Caicos privacy framework, incident-readiness expectation) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TC DP Ord.
# Uruguay Law 18.331 (/docs/frameworks/americas/uruguay-18331)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Uruguay Personal Data Protection Law - URCDP oversight, GDPR adequacy, data subject rights.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | UY 18331 |
| Region | Americas |
| Country or scope | Uruguay |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers UY 18331
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for UY 18331.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for UY 18331 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `UY-18331-10` Data Security Measures | Those responsible for databases must adopt the measures necessary to guarantee the security and confidentiality of personal data and prevent its adulteration, loss or unauthorised access, which for software includes verifiable component integrity (Law 18.331 Art. 10) | Scan |
| `UY-18331-REG` Database Registration with URCDP | Databases must be registered with the supervisory authority with identifying descriptions of the processing, requiring identifiable, dated documentation of the processing environment (Law 18.331 database registration provisions) | Scan |
| `UY-18331-QUAL` Data Quality (Veracity) Principle | Personal data must be truthful, adequate and up to date; a processing environment can only evidence this discipline if its own software inventory is complete with names and versions (Law 18.331 veracity/data quality principle) | Scan |
| `UY-18331-PROC` Processing on Behalf of Third Parties | Processing entrusted to third parties must preserve the security and confidentiality obligations of the law, which extends to recording the suppliers of software components used in processing (Law 18.331 third-party processing provisions) | Scan |
| `UY-18331-BREACH` Security Incident Notification Readiness | Regulatory updates require notifying the URCDP of security incidents affecting personal data, which requires the ability to identify precisely which components were involved (Decree 64/020 breach notification requirements under Law 18.331) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | -------------------------------------------- |
| `UY-7` | Data Quality Principles |
| `UY-11` | Consent & Lawful Basis |
| `UY-13` | Special Categories Prohibitions & Exceptions |
| `UY-23` | Data Subject Rights Procedures |
| `UY-28` | Security Obligations |
| `UY-31` | International Transfer Controls |
| `UY-URCDP` | URCDP Database Registration |
| `UY-PROC` | Data Processor Contracts |
| `UY-DPO` | Privacy Accountable Person |
## Policy templates
Written for UY 18331:
* Uruguay Data Subject Rights (ARCO) Procedure
* Uruguay URCDP Database Registration Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to UY 18331.
# Utah UCPA (/docs/frameworks/americas/utah-ucpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Utah Consumer Privacy Act - consumer rights, opt-out, controller duties.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | UT UCPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers UT UCPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for UT UCPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for UT UCPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `UT-UCPA-302-SEC` Reasonable and Appropriate Safeguards | Controllers must establish and maintain reasonable administrative, technical and physical safeguards designed to protect the confidentiality and integrity of personal data; integrity evidence for the processing software supports that duty (Utah Code § 13-61-302 controller security duty) | Scan |
| `UT-UCPA-INV` Processing System Accountability | Safeguards must be appropriate to the amount and nature of the data processed, which presumes the controller can enumerate the software systems that store or process consumer data (Utah Code § 13-61-302 controller security duty) | Scan |
| `UT-UCPA-301-PROC` Processor Contract Duties | Processors must process personal data only under a contract setting out instructions, duration and duties, and must assist controllers in meeting their obligations; the vendor behind each processing component should therefore be identified (Utah Code ch. 13-61 processor provisions) | Scan |
| `UT-UCPA-201-RIGHTS` Consumer Rights Response Readiness | Consumers may access and delete personal data, obtain a portable copy, and opt out of targeted advertising and sale; locating a consumer's data requires the processing components to be unambiguously identifiable (Utah Code § 13-61-201) | Scan |
| `UT-UCPA-BREACH` Breach Impact Assessment Readiness | Utah's security-breach notification regime obliges organisations to determine scope and affected systems quickly after an incident; recorded component versions make that impact analysis possible (Utah Code § 13-44-202 breach notification, read with UCPA safeguards) | Scan |
| `UT-UCPA-NOTICE` Privacy Notice Documentation | Controllers must provide consumers a reasonably accessible and clear privacy notice describing categories processed, purposes and sharing; supporting documentation should carry document identity and a creation timestamp (Utah Code ch. 13-61 transparency provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | -------------------------------------- |
| `UCA-13-61-202` | Consumer Rights: Access & Portability |
| `UCA-13-61-203` | Consumer Right to Delete |
| `UCA-13-61-201` | Opt-Out of Sale & Targeted Advertising |
| `UCA-13-61-204` | Sensitive Data Opt-Out |
| `UCA-13-61-301` | Privacy Notice Disclosure |
| `UCA-13-61-302` | Processor Agreements |
| `UCA-13-61-303` | Security & Data Minimization |
| `UCA-13-61-101` | Children's Data: COPPA Alignment |
## Policy templates
Written for UT UCPA:
* Utah UCPA State Privacy Notice
* Utah UCPA Consumer Rights Request Handling Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to UT UCPA.
# Venezuela Constitutional Habeas Data (/docs/frameworks/americas/venezuela-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | VE HabeasData |
| Region | Americas |
| Country or scope | Venezuela |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers VE HabeasData
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `VE-CONST-28` Habeas Data System Accountability | The habeas data right to access, correct, or destroy one's records requires the record-holder to know which systems and software components hold personal information (Constitution of 1999, Art. 28) | Scan |
| `VE-CONST-60` Limits on the Use of Informatics | The constitutional mandate to limit informatics so as to protect honor and private life implies that computerized processing of personal information must be identifiable and controllable (Constitution of 1999, Art. 60) | Scan |
| `VE-HD-INTG` Integrity of Records for Correction Rights | Effective correction and destruction of erroneous records presupposes integrity controls over the software maintaining them (Constitution of 1999 Art. 28, habeas data correction right) | Scan |
| `VE-INFOGOB-LIC` Public-Sector Software Licensing Transparency | The public-sector Infogobierno Law prioritizes free/libre software and requires knowing the licensing status of deployed components (Infogobierno Law 2013, free-software preference) | Scan |
| `VE-HD-DOC` Documented Processing for Habeas Data Response | Answering a habeas data petition about what data is held and how requires an identifiable, timestamped record of the processing environment (Constitution of 1999 Art. 28, habeas data access right) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to VE HabeasData.
# Virginia CDPA (/docs/frameworks/americas/virginia-cdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Consumer Data Protection Act - controller and processor obligations, consumer rights, DPIA.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | VA CDPA |
| Region | Americas |
| Country or scope | United States |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers VA CDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for VA CDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for VA CDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `VA-CDPA-578-SEC` Reasonable Data Security Practices | Controllers must establish and maintain reasonable administrative, technical and physical data security practices appropriate to the volume and nature of the personal data processed; verifiable integrity of the software processing that data is a core technical safeguard (Va. Code § 59.1-578(A)(3)) | Scan |
| `VA-CDPA-578-MIN` Data Minimisation Accountability | Collection must be limited to what is adequate, relevant and reasonably necessary for disclosed purposes; honoring this duty presumes the controller can name the processing system and enumerate the software components that touch personal data (Va. Code § 59.1-578(A)(1)) | Scan |
| `VA-CDPA-579` Processor and Vendor Oversight | Processing by third parties must be governed by binding contracts and processors must assist controllers with their obligations; oversight requires knowing who supplies each component in the processing stack (Va. Code § 59.1-579) | Scan |
| `VA-CDPA-580` Data Protection Assessment Readiness | Controllers must conduct data protection assessments for targeted advertising, sale, profiling and other heightened-risk processing; assessing risk credibly requires versioned identification of the software involved (Va. Code § 59.1-580) | Scan |
| `VA-CDPA-577` Consumer Rights Response Readiness | Controllers must respond to consumer access, correction, deletion and portability requests within 45 days; locating a consumer's data across systems depends on those systems' components being unambiguously identifiable (Va. Code § 59.1-577) | Scan |
| `VA-CDPA-578-NOTICE` Transparent Processing Documentation | Controllers must provide consumers a reasonably accessible, clear privacy notice describing their processing; the underlying system documentation should itself be identified and timestamped to support the notice's accuracy (Va. Code § 59.1-578, privacy-notice provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | ------------------------------------------------- |
| `59.1-577` | Consumer Rights: Access, Portability & Correction |
| `59.1-578` | Consumer Right to Delete |
| `59.1-580` | Opt-Out of Sale, Targeted Advertising & Profiling |
| `59.1-579` | Sensitive Data: Consent Requirement |
| `59.1-581` | Data Protection Assessment (DPA) Requirement |
| `59.1-583` | Processor Agreements |
| `59.1-576` | Privacy Notice Transparency |
| `59.1-582` | Appeal Process for Consumer Requests |
| `59.1-584` | Data Minimization & Purpose Limitation |
| `59.1-585` | Security Safeguards |
## Policy templates
Written for VA CDPA:
* Virginia CDPA State Privacy Notice
* Virginia CDPA Consumer Rights Request Handling Procedure
* Virginia CDPA Data Protection Assessment Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to VA CDPA.
# Washington My Health My Data Act (/docs/frameworks/americas/washington-mhmda)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Washington My Health My Data Act - consumer health data protection, consent, private right of action.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | WA MHMDA |
| Region | Americas |
| Country or scope | United States |
| Sector | Healthcare |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers WA MHMDA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for WA MHMDA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for WA MHMDA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `WA-MHMDA-SEC` Health Data Security and Access Restriction | Regulated entities must restrict internal access to consumer health data to what is necessary and maintain administrative, technical and physical data security practices satisfying a reasonable standard of care; given the sensitivity and the private right of action, integrity verification is expected at a high bar (RCW ch. 19.373, data-security and access-restriction provisions) | Scan |
| `WA-MHMDA-INV` Health Data Processing Inventory | Consent-gating every collection and share of consumer health data presumes the entity knows exactly which software systems collect or process it; an enumerated component inventory is the prerequisite artifact (RCW ch. 19.373, consent and collection provisions) | Scan |
| `WA-MHMDA-SHARE` Sharing and Sale Flow Control | Sharing requires separate consent and any sale requires the consumer's signed authorization; enforcing these gates demands a documented map of how data-handling components feed one another (RCW ch. 19.373, sharing-consent and sale-authorization provisions) | Scan |
| `WA-MHMDA-PROC` Processor Oversight | Processors may process consumer health data only per binding contract and the regulated entity remains responsible for their conduct; each third-party component should carry a named supplier to demonstrate that chain (RCW ch. 19.373, processor provisions) | Scan |
| `WA-MHMDA-RIGHTS` Consumer Rights and Withdrawal Readiness | Consumers may access their health data including a list of third parties it was shared with, withdraw consent, and have data deleted: including from backups and by notifying downstream recipients; executing this requires unambiguous identification of every system holding the data (RCW ch. 19.373, consumer-rights provisions) | Scan |
| `WA-MHMDA-POLICY` Health Data Privacy Policy Documentation | Regulated entities must maintain and prominently link a consumer health data privacy policy describing categories collected, sources, sharing and rights; identified, timestamped system documentation keeps that policy verifiably accurate (RCW ch. 19.373, privacy-policy provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ----------------------------------------------------------- |
| `RCW-70.372.010` | Consumer Health Data: Definition & Scope |
| `RCW-70.372.020` | Consent for Collection of Consumer Health Data |
| `RCW-70.372.030` | Consent for Sharing & Disclosure of Consumer Health Data |
| `RCW-70.372.040` | Prohibition on Sale of Consumer Health Data Without Consent |
| `RCW-70.372.050` | Geofencing Prohibition Near Healthcare Facilities |
| `RCW-70.372.060` | Consumer Rights: Access, Deletion & Withdrawal of Consent |
| `RCW-70.372.070` | Consumer Health Data Privacy Policy |
| `RCW-70.372.080` | Security for Consumer Health Data |
| `RCW-70.372.090` | Processor & Third-Party Agreements |
| `RCW-70.372.100` | Prohibited Practices: Surveillance & Inferencing |
| `RCW-70.372.110` | Private Right of Action & Enforcement |
## Policy templates
Written for WA MHMDA:
* Washington MHMDA Consumer Health Data Privacy Policy
* Washington MHMDA Consent for Collection & Sharing Procedure
* Washington MHMDA Geofencing Prohibition & Security Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to WA MHMDA.
# Algeria Law No. 18-07 on Protection of Personal Data (/docs/frameworks/middle-east-and-africa/algeria-law1807)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | DZ 18-07 |
| Region | Middle East & Africa |
| Country or scope | Algeria |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers DZ 18-07
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `DZ-1807-38` Technical and Organizational Security Measures | The controller must implement technical and organizational measures commensurate with the risks and data sensitivity to protect personal data against unauthorized access, loss, destruction, alteration or illicit processing, presuming integrity verification of processing software (Law No. 18-07, Art. 38) | Scan |
| `DZ-1807-PROC` Processor Security Guarantees | When processing is outsourced, the controller must select a processor offering sufficient technical and organizational security guarantees, formalized in a written contract, which requires third-party software suppliers to be identified (Law No. 18-07, processor-guarantee obligation) | Scan |
| `DZ-1807-DECL` Prior Declaration to the ANPDP | Processing operations are subject to prior declaration to (or authorization by) the ANPDP, which presupposes an accurate inventory of the software systems and components performing the processing (Law No. 18-07, declaration/authorization regime) | Scan |
| `DZ-1807-QUAL` Accuracy and Currency of Processing Systems | Data must be accurate and kept up to date; for the systems that process it, this requires knowing component versions so outdated or unmaintained software can be detected and corrected (Law No. 18-07, data-quality principle) | Scan |
| `DZ-1807-DOC` Auditable Processing Documentation | Accountability to the ANPDP, reinforced by the logging and impact-assessment duties added by Law No. 25-11, requires dated and identifiable documentation of processing systems such as an SBOM with document ID and timestamp (Law No. 18-07 as amended by Law No. 25-11) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DZ 18-07.
# Angola Law No. 22/11 on Protection of Personal Data (/docs/frameworks/middle-east-and-africa/angola-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AO PDPL |
| Region | Middle East & Africa |
| Country or scope | Angola |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AO PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AO-PDPL-SEC` Security Measures for Processing | Controllers must adopt technical and organisational measures to protect personal data against accidental or unlawful destruction, loss, alteration and unauthorised access, evidenced by integrity hashes on processing components (Law No. 22/11, security-of-processing obligations) | Scan |
| `AO-PDPL-NOT` Notification of Processing Operations | Processing operations must be notified to or authorised by the APD, which presupposes an inventory of the software systems performing the processing (Law No. 22/11, notification and authorisation regime) | Scan |
| `AO-PDPL-PROC` Subcontracted Processing Controls | Processing entrusted to a subcontractor must be governed by contract and offer sufficient security guarantees, so third-party software components must have named suppliers (Law No. 22/11, subcontracting provisions) | Scan |
| `AO-PDPL-ID` Identifiable Processing Components | Confidentiality and controlled access to processing systems require their components to be uniquely identifiable (Law No. 22/11, confidentiality and access-control duties) | Scan |
| `AO-PDPL-DOC` Traceable Documentation | Demonstrating lawful processing to the APD requires software records to be identifiable documents with a creation timestamp (Law No. 22/11, supervisory cooperation duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AO PDPL.
# Bahrain PDPL (/docs/frameworks/middle-east-and-africa/bahrain-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Bahrain Personal Data Protection Law - data subject rights, registration, cross-border transfers.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | BH PDPL |
| Region | Middle East & Africa |
| Country or scope | Bahrain |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers BH PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 6 controls from Safeguard's control catalog for BH PDPL.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for BH PDPL and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `BH-PDPL-SEC` Security and Integrity Measures | Data managers must apply technical and organizational measures protecting personal data against unauthorized or accidental destruction, loss or alteration; integrity hashes over the software inventory evidence such measures (Law 30/2018, security-of-processing obligation) | Scan |
| `BH-PDPL-NOTIF` Notification of Processing Operations | Certain processing operations must be notified to or authorized by the Personal Data Protection Authority with identifying details; a uniquely identified, timestamped SBOM supports notification-grade documentation of processing systems (Law 30/2018, notification/authorization provisions) | Scan |
| `BH-PDPL-PROC` Processing on Behalf of the Manager | Data processors acting for a data manager must offer sufficient guarantees and act only on instructions, which requires knowing which suppliers stand behind the processing software (Law 30/2018, processor-obligations provision) | Scan |
| `BH-PDPL-QUAL` Data Accuracy and Currency | Personal data must be accurate and kept up to date for its purpose; the parallel discipline for the processing estate requires components with complete names and versions (Law 30/2018, data-quality principles) | Scan |
| `BH-PDPL-XBORDER` Cross-Border Transfer Readiness | Transfers outside Bahrain are limited to jurisdictions with sufficient protection or require authorization; establishing what is transferred and by which systems requires precisely identifiable components (Law 30/2018, cross-border transfer provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ------------------------------------------ |
| `BPDPL-ART3` | Core Processing Principles (Art. 3-7) |
| `BPDPL-ART10` | Data Subject Rights (Art. 10-14) |
| `BPDPL-ART18` | Data Security Obligations (Art. 18) |
| `BPDPL-ART21` | Cross-Border Transfer Safeguards (Art. 21) |
| `BPDPL-DPO-1` | Data Protection Officer Appointment |
| `BPDPL-DPIA-1` | Data Protection Impact Assessment |
## Policy templates
Written for BH PDPL:
* Bahrain PDPL: Privacy Notice
* Bahrain PDPL: Information Security Policy
* Bahrain PDPL: Breach Notification Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BH PDPL.
# Benin Digital Code 2018 (Personal Data) (/docs/frameworks/middle-east-and-africa/benin-digital-code)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BJ Digital |
| Region | Middle East & Africa |
| Country or scope | Benin |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BJ Digital
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BJ-CN-SEC` Security of Processing | Controllers and processors must implement technical and organisational measures ensuring a level of security appropriate to the risk, protecting data integrity and confidentiality, evidenced by integrity hashes on processing components (Digital Code 2018, Book V security-of-processing obligations) | Scan |
| `BJ-CN-REC` Records of Processing Activities | Controllers must document their processing activities for the APDP, which presupposes an inventory of the software systems performing the processing (Digital Code 2018, Book V accountability and record-keeping duties) | Scan |
| `BJ-CN-PROC` Processor Guarantees | Controllers may only engage processors presenting sufficient guarantees under a binding contract, so third-party software components must have named suppliers (Digital Code 2018, Book V controller-processor provisions) | Scan |
| `BJ-CN-BRN` Breach Notification Readiness | Personal data breaches must be notified to the APDP, which requires the components of affected systems to be quickly identifiable (Digital Code 2018, Book V breach-notification duty) | Scan |
| `BJ-CN-FMT` Machine-Readable Compliance Records | Demonstrating compliance under a digital-first code is practical only if software records are produced in standard machine-readable formats with document identity (Digital Code 2018, Book V compliance-demonstration duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BJ Digital.
# Botswana Data Protection Act 2018 (/docs/frameworks/middle-east-and-africa/botswana-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BW DPA |
| Region | Middle East & Africa |
| Country or scope | Botswana |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BW DPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BW-DPA-SEC` Security Measures for Processing | Data controllers must implement appropriate technical and organisational measures to protect personal data against destruction, loss, alteration and unauthorised access, evidenced by integrity hashes on processing components (DPA 2018, security-of-processing obligations) | Scan |
| `BW-DPA-INV` Processing System Inventory | Notification of processing operations to the Commission presupposes that the controller maintains an inventory of the software systems used to process personal data (DPA 2018, notification and record-keeping provisions) | Scan |
| `BW-DPA-PROC` Processor Engagement Controls | Controllers must choose processors providing sufficient guarantees of security and ensure processing under contract, so third-party software components must have named suppliers (DPA 2018, controller-processor provisions) | Scan |
| `BW-DPA-ID` Component Identifiability | Investigating unauthorised access and cooperating with the Commission requires processing-system components to be uniquely identifiable (DPA 2018, enforcement and compliance provisions) | Scan |
| `BW-DPA-DOC` Traceable Documentation | Demonstrating lawful processing to the regulator requires software records to be identifiable documents with a creation timestamp (DPA 2018, accountability and notification duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BW DPA.
# Burkina Faso Law No. 010-2004 on Personal Data (/docs/frameworks/middle-east-and-africa/burkina-faso-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BF PDPL |
| Region | Middle East & Africa |
| Country or scope | Burkina Faso |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BF PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BF-PDPL-SEC` Security and Confidentiality of Processing | The controller must take all precautions to preserve the security of the data, notably preventing its alteration, damage or communication to unauthorized third parties, presuming integrity controls over the processing software (Law No. 010-2004/AN, security obligation, reinforced by Law No. 001-2021/AN) | Scan |
| `BF-PDPL-DECL` Prior Formalities with the CIL | Processing operations are subject to prior declaration to, or authorization by, the CIL, which presupposes an enumerated inventory of the systems and software components carrying out the processing (Law No. 010-2004/AN, declaration/authorization regime) | Scan |
| `BF-PDPL-PROC` Third-Party and Processor Accountability | Processing carried out on behalf of the controller must be entrusted only to parties offering sufficient security guarantees, requiring third-party software suppliers to be identified and vetted (Law No. 010-2004/AN, processor obligation) | Scan |
| `BF-PDPL-QUAL` Accuracy and Currency | Personal data must be accurate, complete and up to date; applied to processing systems this requires known component versions so outdated software can be identified and remediated (Law No. 010-2004/AN, data-quality principle) | Scan |
| `BF-PDPL-DOC` Auditable Processing Documentation | CIL oversight requires dated, identifiable documentation describing the processing and its security measures, satisfied by an SBOM with document ID and creation timestamp (Law No. 010-2004/AN, accountability to the CIL) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BF PDPL.
# Malabo Convention (AU) - Burundi (/docs/frameworks/middle-east-and-africa/burundi-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BI Malabo |
| Region | Middle East & Africa |
| Country or scope | Burundi |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BI Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BI-MAL-13` Transparent and Accurate Processing Records | Personal-data processing must be lawful, transparent and accurate, which presupposes a maintained record of the software components that perform the processing (Malabo Convention Art. 13). | Scan |
| `BI-MAL-13-6` Confidentiality Principle: Identifiable Components | The confidentiality principle requires knowing precisely which software handles personal data, so components must carry standard identifiers such as PURL or CPE that tie safeguards to specific packages (Malabo Convention Art. 13, Principle 6). | Scan |
| `BI-MAL-20` Processor and Third-Party Accountability | Processing performed on a controller's behalf must remain under the controller's authority and instructions, so third-party components need named, accountable suppliers (Malabo Convention Art. 20). | Scan |
| `BI-MAL-21` Security of Processing Systems | Controllers must take all appropriate precautions to keep data from being altered, destroyed or accessed by unauthorised third parties; integrity hashes on components let tampering be detected (Malabo Convention Art. 21). | Scan |
| `BI-MAL-21-V` Incident and Breach-Impact Readiness | Judging whether processing systems remain secure after an incident requires knowing the exact versions of the components in operation (Malabo Convention Art. 21). | Scan |
| `BI-MAL-10` Declared and Documented Processing | Preliminary formalities require processing operations to be declared to the supervisory authority, which presupposes dated, identifiable documentation of the systems used (Malabo Convention Art. 10, preliminary formalities). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BI Malabo.
# Cameroon Law 2010/012 on Cybersecurity (/docs/frameworks/middle-east-and-africa/cameroon-cyber)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CM Cyber |
| Region | Middle East & Africa |
| Country or scope | Cameroon |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CM Cyber
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CM-CYBER-AUD` Mandatory Security Audit Inventory | Electronic communication networks and information systems are subject to compulsory security audits examining components, policies, measures and resources, which requires an enumerated inventory of the software components in scope (Law No. 2010/012, Arts. 7, 13 and 14 audit framework) | Scan |
| `CM-CYBER-SEC` Security of Networks and Information Systems | Operators and providers must protect their networks and information systems and ensure conformity with laid-down security standards, presuming verifiable integrity of the software components deployed (Law No. 2010/012, security obligations verified via the Art. 13-14 audit regime) | Scan |
| `CM-CYBER-INC` Intrusion Notification Readiness | Operators must notify ANTIC of intrusions into their networks and information systems; assessing what was compromised requires precisely identifiable components (PURL/CPE) across those systems (Decree No. 2012/1643/PM implementing Law No. 2010/012) | Scan |
| `CM-CYBER-GRAPH` Auditable System Composition | A systematic audit of security components and actors requires the relationships between software components to be documented so auditors can trace how the system is composed (Law No. 2010/012, Art. 32 and Art. 61 audit provisions) | Scan |
| `CM-CYBER-VULN` Maintained, Patchable Systems | Ensuring conformity of information systems with security standards over successive audits requires known versions for every component so vulnerable software can be identified and remediated (Law No. 2010/012, audit-conformity obligation) | Scan |
| `CM-CYBER-DOC` Dated Audit Documentation | The recurring audit and certification regime requires dated, identifiable documentation of system composition, satisfied by an SBOM with document ID and creation timestamp (Law No. 2010/012, audit framework with Decree No. 2012/1643/PM) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CM Cyber.
# Cape Verde Law No. 133/V/2001 on Personal Data (/docs/frameworks/middle-east-and-africa/cape-verde-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CV PDPL |
| Region | Middle East & Africa |
| Country or scope | Cape Verde |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CV PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CV-PDPL-SEC` Security of Processing | Controllers must apply technical and organizational measures to protect personal data against accidental or unlawful destruction, loss, alteration and unauthorized access, presuming integrity controls over the processing software (Law No. 133/V/2001, security-of-processing obligation) | Scan |
| `CV-PDPL-NOT` Notification to the CNPD | Processing operations must be notified to the CNPD before they are carried out, which presupposes an enumerated inventory of the systems and software components performing the processing (Law No. 133/V/2001, notification regime) | Scan |
| `CV-PDPL-PROC` Processor Guarantees | Processing carried out on the controller's behalf must be entrusted to processors providing sufficient guarantees of technical security and organizational measures, requiring third-party software suppliers to be identified (Law No. 133/V/2001, processor obligation) | Scan |
| `CV-PDPL-QUAL` Data Quality and Currency | Personal data must be accurate and, where necessary, kept up to date; applied to processing systems this requires recorded component versions so outdated software can be identified (Law No. 133/V/2001, data-quality principle) | Scan |
| `CV-PDPL-DOC` Auditable Processing Documentation | CNPD oversight and the notification regime require dated, identifiable documentation of processing systems, satisfied by an SBOM bearing a document ID and creation timestamp (Law No. 133/V/2001, accountability to the CNPD) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CV PDPL.
# Malabo Convention (AU) - Central African Republic (/docs/frameworks/middle-east-and-africa/car-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CF Malabo |
| Region | Middle East & Africa |
| Country or scope | Central African Republic |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CF Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CF-MAL-21` Security of Processing Systems | The data controller must take all appropriate precautions, given the nature of the data, to prevent it from being altered, destroyed, or accessed by unauthorized third parties; verifiable integrity hashes on the software components that process data evidence this safeguard (Malabo Convention Art. 21) | Scan |
| `CF-MAL-20` Confidentiality and Controlled Processing | Processing must remain confidential and be carried out only by parties acting under the controller's authority, which requires that the suppliers behind processing software are known and accountable (Malabo Convention Art. 20) | Scan |
| `CF-MAL-13A` Accuracy of Processing | Personal data undergoing processing must be accurate and kept up to date, which presumes each software component handling it is fully identified by both name and a concrete version (Malabo Convention Art. 13) | Scan |
| `CF-MAL-13T` Transparency Principle | Controllers are bound by a principle of transparent processing, which presupposes documented, uniquely identified and timestamped records of the processing environment (Malabo Convention Art. 13) | Scan |
| `CF-MAL-10` Processing Formalities and Records | Personal-data processing operations are subject to preliminary formalities before the national protection authority, requiring an enumerable, named record of the software performing the processing (Malabo Convention Art. 10) | Scan |
| `CF-MAL-23` Sustainability of Processing Systems | Controllers must ensure processing systems remain adequate and reliable as technology evolves; declared component versions are the basis for keeping systems current and supportable (Malabo Convention Art. 23) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CF Malabo.
# Chad Law No. 007/PR/2015 on Protection of Personal Data (/docs/frameworks/middle-east-and-africa/chad-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TD PDPL |
| Region | Middle East & Africa |
| Country or scope | Chad |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TD PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TD-PDPL-SEC` Security Safeguards Including Encryption | Personal data must be protected by technical safeguards against unauthorized access, loss or alteration, with encryption expected for data in transit, presuming cryptographic integrity controls across the processing software (Law No. 007/PR/2015, security obligation) | Scan |
| `TD-PDPL-DPIA` High-Risk Processing Assessment | Impact assessments are required for high-risk processing activities, which presupposes that the processing system is named and its constituent software components are enumerated (Law No. 007/PR/2015, impact-assessment obligation) | Scan |
| `TD-PDPL-DPO` Responsible Contact for Data Protection | Entities processing large volumes of sensitive data must designate a data protection officer, so processing documentation should record an accountable creator contact (Law No. 007/PR/2015, DPO obligation) | Scan |
| `TD-PDPL-PROC` Third-Party Processing Accountability | Processing entrusted to third parties must remain subject to the controller's security and confidentiality duties, requiring the suppliers of processing software to be identified (Law No. 007/PR/2015, processor obligation) | Scan |
| `TD-PDPL-INV` Known Processing Systems | Lawful, fair and non-fraudulent collection, processing, storage and transmission of personal data presupposes that the organization knows which software components handle the data (Law No. 007/PR/2015, lawful-processing principles) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TD PDPL.
# Malabo Convention (AU) - Comoros (/docs/frameworks/middle-east-and-africa/comoros-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | KM Malabo |
| Region | Middle East & Africa |
| Country or scope | Comoros |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers KM Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `KM-MAL-13` Transparent and Accurate Processing Records | Personal-data processing must be lawful, transparent and accurate, which presupposes a maintained record of the software components that perform the processing (Malabo Convention Art. 13). | Scan |
| `KM-MAL-13-6` Confidentiality Principle: Identifiable Components | The confidentiality principle requires knowing precisely which software handles personal data, so components must carry standard identifiers such as PURL or CPE that tie safeguards to specific packages (Malabo Convention Art. 13, Principle 6). | Scan |
| `KM-MAL-20` Processor and Third-Party Accountability | Processing performed on a controller's behalf must remain under the controller's authority and instructions, so third-party components need named, accountable suppliers (Malabo Convention Art. 20). | Scan |
| `KM-MAL-21` Security of Processing Systems | Controllers must take all appropriate precautions to keep data from being altered, destroyed or accessed by unauthorised third parties; integrity hashes on components let tampering be detected (Malabo Convention Art. 21). | Scan |
| `KM-MAL-21-V` Incident and Breach-Impact Readiness | Judging whether processing systems remain secure after an incident requires knowing the exact versions of the components in operation (Malabo Convention Art. 21). | Scan |
| `KM-MAL-10` Declared and Documented Processing | Preliminary formalities require processing operations to be declared to the supervisory authority, which presupposes dated, identifiable documentation of the systems used (Malabo Convention Art. 10, preliminary formalities). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KM Malabo.
# Congo Law 29-2019 on Data Protection (/docs/frameworks/middle-east-and-africa/congo-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CG Law 29 |
| Region | Middle East & Africa |
| Country or scope | Republic of the Congo |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CG Law 29
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CG-29-SEC` Protective Security Measures | Organizations must implement protective measures, including encryption, to prevent unauthorized access, loss, or alteration of personal data; integrity hashes across processing components evidence those measures (Law 29-2019, security-of-processing obligations) | Scan |
| `CG-29-ACC` Accurate, Purpose-Bound Data | Processing must be limited to specified, legitimate purposes with accurate data, presuming each processing component is fully identified by both name and a concrete version (Law 29-2019, processing principles) | Scan |
| `CG-29-PROC` Third-Party and Transfer Accountability | Data may reach third parties or cross borders only under adequate safeguards, so third-party software components must carry named, accountable suppliers (Law 29-2019, third-party and cross-border transfer provisions) | Scan |
| `CG-29-INV` Processing Software Inventory | Controller obligations under the law presuppose an enumerable, named inventory of the software components that collect and process personal data (Law 29-2019, controller obligations) | Scan |
| `CG-29-BREACH` Compromise Assessment Readiness | Safeguarding personal data against loss or unauthorized access requires that processing components are identifiable via standard identifiers so any compromise can be scoped (Law 29-2019, data-security obligations) | Scan |
| `CG-29-TRANS` Transparent Processing | Processing must be transparent to data subjects, presupposing documented, uniquely identified and timestamped records of the processing environment (Law 29-2019, transparency principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CG Law 29.
# Malabo Convention (AU) - Djibouti (/docs/frameworks/middle-east-and-africa/djibouti-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | DJ Malabo |
| Region | Middle East & Africa |
| Country or scope | Djibouti |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers DJ Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `DJ-MAL-13` Transparent and Accurate Processing Records | Personal-data processing must be lawful, transparent and accurate, which presupposes a maintained record of the software components that perform the processing (Malabo Convention Art. 13). | Scan |
| `DJ-MAL-13-6` Confidentiality Principle: Identifiable Components | The confidentiality principle requires knowing precisely which software handles personal data, so components must carry standard identifiers such as PURL or CPE that tie safeguards to specific packages (Malabo Convention Art. 13, Principle 6). | Scan |
| `DJ-MAL-20` Processor and Third-Party Accountability | Processing performed on a controller's behalf must remain under the controller's authority and instructions, so third-party components need named, accountable suppliers (Malabo Convention Art. 20). | Scan |
| `DJ-MAL-21` Security of Processing Systems | Controllers must take all appropriate precautions to keep data from being altered, destroyed or accessed by unauthorised third parties; integrity hashes on components let tampering be detected (Malabo Convention Art. 21). | Scan |
| `DJ-MAL-21-V` Incident and Breach-Impact Readiness | Judging whether processing systems remain secure after an incident requires knowing the exact versions of the components in operation (Malabo Convention Art. 21). | Scan |
| `DJ-MAL-10` Declared and Documented Processing | Preliminary formalities require processing operations to be declared to the supervisory authority, which presupposes dated, identifiable documentation of the systems used (Malabo Convention Art. 10, preliminary formalities). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DJ Malabo.
# DR Congo Digital Code 2023 (Personal Data) (/docs/frameworks/middle-east-and-africa/drc-digital-code)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CD Digital |
| Region | Middle East & Africa |
| Country or scope | DR Congo |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CD Digital
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CD-DC-SEC` Security of Personal Data Processing | Controllers must protect personal data through technical and organizational measures against unauthorized access, alteration or destruction, presuming verifiable integrity of the software components that process the data (Ordinance-Law No. 23/010, personal-data provisions, Title III) | Scan |
| `CD-DC-INV` Data Governance and Processing Inventory | The Code's data-governance regime and supervisory-authority oversight presuppose that organizations can enumerate the systems and software components that process personal data (Ordinance-Law No. 23/010, data-governance provisions) | Scan |
| `CD-DC-PROC` Platform and Third-Party Accountability | The Code regulates digital platforms and processing performed by third parties, requiring the external suppliers of processing software and services to be identified and accountable (Ordinance-Law No. 23/010, platform and processor provisions) | Scan |
| `CD-DC-CYBER` Cybersecurity Hygiene of Digital Systems | The Code's cybersecurity chapter obliges operators of digital systems to keep them secure against interference and misuse, which requires known component versions so vulnerable software can be patched (Ordinance-Law No. 23/010, cybersecurity provisions) | Scan |
| `CD-DC-DOC` Documented, Dated System Records | Accountability to the future data-protection supervisory authority requires dated and identifiable documentation of processing systems, satisfied by an SBOM with document ID and creation timestamp (Ordinance-Law No. 23/010, accountability provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CD Digital.
# Egypt PDPL (Law 151/2020) (/docs/frameworks/middle-east-and-africa/egypt-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Egypt Personal Data Protection Law - licensing, DPO, data subject rights, cross-border transfers.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | EG PDPL |
| Region | Middle East & Africa |
| Country or scope | Egypt |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers EG PDPL
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for EG PDPL.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for EG PDPL and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `EG-PDPL-SEC` Security of Processing | Controllers and processors must apply technical and organizational measures securing personal data against breach, alteration or unlawful processing; verifiable integrity of the software inventory evidences such measures (Law 151/2020, security-of-processing obligations) | Scan |
| `EG-PDPL-DPO` Data Protection Officer | Entities processing personal data must appoint a data protection officer responsible for compliance, providing a reachable accountability contact for the systems described in the SBOM (Law 151/2020, DPO-appointment obligation) | Scan |
| `EG-PDPL-LIC` Licensing and Permits | Processing activities require licenses or permits from the Personal Data Protection Centre, which presupposes identified, dated documentation of the processing systems being licensed (Law 151/2020, licensing/permit provisions) | Scan |
| `EG-PDPL-PROC` Processor Obligations | Processors must process data only per the controller's instructions and maintain their own compliance, requiring the controller to know which suppliers stand behind the processing software (Law 151/2020, processor-obligations provision) | Scan |
| `EG-PDPL-BREACH` Breach Reporting Readiness | Breaches of personal data must be reported to the Centre and affected data subjects within short deadlines; rapid impact assessment requires known versions across the software estate (Law 151/2020, breach-notification obligation) | Scan |
| `EG-PDPL-XBORDER` Cross-Border Transfer Permits | Transfer of personal data outside Egypt requires a permit and an adequate level of protection; determining which systems transfer what requires precisely identifiable components (Law 151/2020, cross-border transfer provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ---------------------------------------------- |
| `EPDPL-ART2` | Core Data Processing Principles (Art. 2-7) |
| `EPDPL-ART14` | Data Subject Rights (Art. 14) |
| `EPDPL-ART28` | Data Protection Officer (Art. 28) |
| `EPDPL-ART31` | Data Breach Notification (Art. 31) |
| `EPDPL-ART39` | Cross-Border Data Transfers (Art. 39) |
| `EPDPL-SEC-1` | Technical and Organisational Security Measures |
| `EPDPL-PROC-1` | Processor Registration and Agreements |
## Policy templates
Written for EG PDPL:
* Egypt PDPL: Privacy Notice
* Egypt PDPL: Data Breach Notification Procedure
* Egypt PDPL: Data Subject Rights Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to EG PDPL.
# Malabo Convention (AU) - Equatorial Guinea (/docs/frameworks/middle-east-and-africa/eq-guinea-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GQ Malabo |
| Region | Middle East & Africa |
| Country or scope | Equatorial Guinea |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GQ Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GQ-MAL-SEC` Security Obligations of the Data Controller | Data controllers must take all appropriate precautions to secure personal data and prevent it from being deformed, damaged, or accessed by unauthorized third parties, implying integrity controls over processing systems (Malabo Convention, controller security obligations, Art. 21-area) | Scan |
| `GQ-MAL-QUAL` Accuracy and Currency of Data | The Convention's basic processing principles require personal data to be accurate and kept up to date, which requires tracked versions of the software maintaining it (Malabo Convention, basic principles governing processing, Art. 13-area) | Scan |
| `GQ-MAL-INV` Accountability for Processing Systems | Controller accountability for lawful processing presupposes an inventory of the software systems and components that process personal data (Malabo Convention, controller obligations) | Scan |
| `GQ-MAL-PROC` Third-Party Processing Safeguards | Processing carried out through processors or third parties must offer sufficient guarantees, so the suppliers of processing components must be identified (Malabo Convention, processor/confidentiality obligations) | Scan |
| `GQ-MAL-CYB` National Cybersecurity Readiness | The Convention's cybersecurity chapter requires parties to promote the security of information systems, including the ability to identify the components of critical systems (Malabo Convention, national cybersecurity framework provisions) | Scan |
| `GQ-MAL-DOC` Transparency of Processing | The transparency principle requires documented, identifiable information about processing, met by a timestamped machine-readable record of the software environment (Malabo Convention, transparency principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GQ Malabo.
# Malabo Convention (AU) - Eritrea (/docs/frameworks/middle-east-and-africa/eritrea-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | ER Malabo |
| Region | Middle East & Africa |
| Country or scope | Eritrea |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers ER Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ER-MAL-13` Transparent and Accurate Processing Records | Personal-data processing must be lawful, transparent and accurate, which presupposes a maintained record of the software components that perform the processing (Malabo Convention Art. 13). | Scan |
| `ER-MAL-13-6` Confidentiality Principle: Identifiable Components | The confidentiality principle requires knowing precisely which software handles personal data, so components must carry standard identifiers such as PURL or CPE that tie safeguards to specific packages (Malabo Convention Art. 13, Principle 6). | Scan |
| `ER-MAL-20` Processor and Third-Party Accountability | Processing performed on a controller's behalf must remain under the controller's authority and instructions, so third-party components need named, accountable suppliers (Malabo Convention Art. 20). | Scan |
| `ER-MAL-21` Security of Processing Systems | Controllers must take all appropriate precautions to keep data from being altered, destroyed or accessed by unauthorised third parties; integrity hashes on components let tampering be detected (Malabo Convention Art. 21). | Scan |
| `ER-MAL-21-V` Incident and Breach-Impact Readiness | Judging whether processing systems remain secure after an incident requires knowing the exact versions of the components in operation (Malabo Convention Art. 21). | Scan |
| `ER-MAL-10` Declared and Documented Processing | Preliminary formalities require processing operations to be declared to the supervisory authority, which presupposes dated, identifiable documentation of the systems used (Malabo Convention Art. 10, preliminary formalities). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ER Malabo.
# Eswatini Data Protection Act 2022 (/docs/frameworks/middle-east-and-africa/eswatini-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SZ DPA |
| Region | Middle East & Africa |
| Country or scope | Eswatini |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SZ DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SZ-DPA-SEC` Security Safeguards | Data controllers must implement security measures preventing unauthorized access, loss or misuse of personal data, presuming verifiable integrity of the software components in the processing stack (Data Protection Act 2022, security-safeguards obligation) | Scan |
| `SZ-DPA-BREACH` 72-Hour Breach Notification Readiness | Personal data breaches must be reported within 72 hours of awareness; assessing scope that quickly requires precisely identifiable components (PURL/CPE) in the systems that process personal data (Data Protection Act 2022, breach-notification obligation) | Scan |
| `SZ-DPA-PROC` Processor Obligations | The Act binds processors as well as controllers, wherever domiciled, requiring the third-party suppliers of processing software and services to be identified and accountable (Data Protection Act 2022, controller-processor obligations) | Scan |
| `SZ-DPA-REC` Accountable Records of Processing | Accountability to the Commission presupposes that the organization can enumerate the systems and software components used to process personal data (Data Protection Act 2022, accountability obligations) | Scan |
| `SZ-DPA-QUAL` Complete and Accurate Records | Data must be collected for explicit purposes and kept accurate; applied to the processing stack, each component should carry both a name and a version so the record is complete (Data Protection Act 2022, data-quality principle) | Scan |
| `SZ-DPA-DOC` Dated, Identifiable Documentation | Demonstrating compliance to the Commission requires dated, identifiable documentation of processing systems, satisfied by an SBOM with a document ID and creation timestamp (Data Protection Act 2022, accountability principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SZ DPA.
# Ethiopia Personal Data Protection Proclamation 1321/2024 (/docs/frameworks/middle-east-and-africa/ethiopia-pdpp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | ET PDPP |
| Region | Middle East & Africa |
| Country or scope | Ethiopia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers ET PDPP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ET-PDPP-SEC` Security of Processing | Controllers and processors must implement appropriate technical and organizational security measures, including encryption, to protect personal data, which presumes verifiable integrity of the software components that process it (Proclamation No. 1321/2024, security-measures obligation) | Scan |
| `ET-PDPP-ROPA` Records of Processing Activities | Controllers and processors must maintain detailed records of processing operations for transparency and accountability, which requires an enumerated inventory of the software systems and components involved (Proclamation No. 1321/2024, records-of-processing obligation) | Scan |
| `ET-PDPP-BREACH` Breach Notification Readiness | Data breaches must be notified to the Ethiopian Communications Authority within 72 hours; assessing scope and impact that quickly requires precisely identifiable components (PURL/CPE) in the processing stack (Proclamation No. 1321/2024, breach-notification obligation) | Scan |
| `ET-PDPP-PROC` Processor and Third-Party Obligations | Processing on behalf of a controller must be governed by binding obligations and adequate guarantees, requiring the third-party suppliers of processing software to be identified and accountable (Proclamation No. 1321/2024, controller-processor obligations) | Scan |
| `ET-PDPP-DPIA` Impact Assessment for High-Risk Processing | A data protection impact assessment is required for high-risk processing, which presupposes that the processing system is named and its constituent components are known (Proclamation No. 1321/2024, DPIA obligation) | Scan |
| `ET-PDPP-DOC` Accountable, Dated Documentation | Accountability to the supervisory authority requires dated, identifiable documentation of processing systems, satisfied by an SBOM with a document identifier and creation timestamp (Proclamation No. 1321/2024, accountability principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ET PDPP.
# Gabon Law No. 001/2011 on Protection of Personal Data (/docs/frameworks/middle-east-and-africa/gabon-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GA PDPL |
| Region | Middle East & Africa |
| Country or scope | Gabon |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GA PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GA-PDPL-SEC` Security and Confidentiality of Processing | Controllers must take technical precautions to protect personal data against accidental or unlawful destruction, loss, alteration and unauthorized access, which presumes integrity controls over the processing software itself (Law No. 001/2011, security-of-processing obligation) | Scan |
| `GA-PDPL-DECL` Prior Declaration of Processing | Processing operations must be declared to the CNPDCP before they begin, which requires the controller to know and enumerate the software systems and components that process personal data (Law No. 001/2011, prior-declaration regime) | Scan |
| `GA-PDPL-PROC` Processor Guarantees | Where processing is outsourced, the controller must choose a processor providing sufficient guarantees of security and confidentiality, requiring third-party software suppliers to be identified and vetted (Law No. 001/2011, processor-oversight obligation) | Scan |
| `GA-PDPL-QUAL` Data Quality and Currency | Personal data must be accurate, complete and kept up to date, which for processing systems means knowing the exact versions of the software in use so stale or unmaintained components can be identified (Law No. 001/2011, data-quality principle) | Scan |
| `GA-PDPL-DOC` Documented Processing Records | The declaration regime and CNPDCP oversight presuppose auditable, dated documentation of the systems that process personal data, satisfied by an SBOM with a document identifier and creation timestamp (Law No. 001/2011, accountability to the CNPDCP) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GA PDPL.
# Malabo Convention (AU) - Gambia (/docs/frameworks/middle-east-and-africa/gambia-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GM Malabo |
| Region | Middle East & Africa |
| Country or scope | Gambia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GM Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GM-MAL-21` Security of Processing Systems | The data controller must take all appropriate precautions, given the nature of the data, to prevent it from being altered, destroyed, or accessed by unauthorized third parties; verifiable integrity hashes on the software components that process data evidence this safeguard (Malabo Convention Art. 21) | Scan |
| `GM-MAL-20` Confidentiality and Controlled Processing | Processing must remain confidential and be carried out only by parties acting under the controller's authority, which requires that the suppliers behind processing software are known and accountable (Malabo Convention Art. 20) | Scan |
| `GM-MAL-13A` Accuracy of Processing | Personal data undergoing processing must be accurate and kept up to date, which presumes each software component handling it is fully identified by both name and a concrete version (Malabo Convention Art. 13) | Scan |
| `GM-MAL-13T` Transparency Principle | Controllers are bound by a principle of transparent processing, which presupposes documented, uniquely identified and timestamped records of the processing environment (Malabo Convention Art. 13) | Scan |
| `GM-MAL-10` Processing Formalities and Records | Personal-data processing operations are subject to preliminary formalities before the national protection authority, requiring an enumerable, named record of the software performing the processing (Malabo Convention Art. 10) | Scan |
| `GM-MAL-23` Sustainability of Processing Systems | Controllers must ensure processing systems remain adequate and reliable as technology evolves; declared component versions are the basis for keeping systems current and supportable (Malabo Convention Art. 23) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GM Malabo.
# Ghana Data Protection Act (/docs/frameworks/middle-east-and-africa/ghana-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Ghana Data Protection Act - DPC registration, data subject rights, consent, security safeguards.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | GH DPA |
| Region | Middle East & Africa |
| Country or scope | Ghana |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers GH DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for GH DPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for GH DPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GH-DPA-SEC` Security Measures | A data controller must take appropriate technical and organisational measures to prevent loss, damage, or unauthorised destruction of personal data, which presupposes integrity controls over the processing systems and software in use (Act 843, security-measures obligation, s.28) | Scan |
| `GH-DPA-REG` Registration and Accountability | Data controllers must register with the Data Protection Commission and remain accountable for the processing they carry out, which requires an identified, documented account of the systems and software assets that process personal data (Act 843, registration of data controllers provisions) | Scan |
| `GH-DPA-INV` Accountability for Processing Systems | The accountability principle requires a data controller to be able to demonstrate what processing occurs under its control, which is only possible if the software components making up its processing systems are enumerated (Act 843, data protection principles, s.17-18) | Scan |
| `GH-DPA-PROC` Data Processor Safeguards | Where processing is carried out by a data processor on behalf of a controller, the controller must ensure the processor provides sufficient safeguards, which requires knowing who supplies each part of the processing stack (Act 843, processing-by-processor obligation, s.30) | Scan |
| `GH-DPA-QLTY` Quality and Completeness of Records | Personal data and the records describing processing must be complete, accurate, and kept up to date; applied to the software inventory this means every component record carries both a name and a version (Act 843, data quality obligation) | Scan |
| `GH-DPA-BREACH` Security Breach Response Readiness | A controller must notify the Commission and affected data subjects where there are reasonable grounds to believe personal data has been compromised; assessing the scope of a compromise requires that deployed components are individually identifiable with known versions (Act 843, notification-of-security-compromise obligation, s.31) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ------------------------------------------------ |
| `GDPA-S17` | Core Data Protection Principles (Sections 17-20) |
| `GDPA-S28` | Data Security Requirements (Section 28) |
| `GDPA-S31` | Data Subject Rights (Section 31) |
| `GDPA-S47` | Cross-Border Data Transfers (Section 47) |
| `GDPA-REG-1` | Data Controller Registration with DPC |
| `GDPA-CONSENT-1` | Consent and Lawful Processing Basis |
| `GDPA-BREACH-1` | Data Breach Reporting |
## Policy templates
Written for GH DPA:
* Ghana DPA: Privacy Notice
* Ghana DPA: Data Breach Reporting Procedure
* Ghana DPA: Cross-Border Data Transfer Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GH DPA.
# Malabo Convention (AU) - Guinea-Bissau (/docs/frameworks/middle-east-and-africa/guinea-bissau-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GW Malabo |
| Region | Middle East & Africa |
| Country or scope | Guinea-Bissau |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GW Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GW-MAL-21` Security of Processing Systems | The data controller must take all appropriate precautions, given the nature of the data, to prevent it from being altered, destroyed, or accessed by unauthorized third parties; verifiable integrity hashes on the software components that process data evidence this safeguard (Malabo Convention Art. 21) | Scan |
| `GW-MAL-20` Confidentiality and Controlled Processing | Processing must remain confidential and be carried out only by parties acting under the controller's authority, which requires that the suppliers behind processing software are known and accountable (Malabo Convention Art. 20) | Scan |
| `GW-MAL-13A` Accuracy of Processing | Personal data undergoing processing must be accurate and kept up to date, which presumes each software component handling it is fully identified by both name and a concrete version (Malabo Convention Art. 13) | Scan |
| `GW-MAL-13T` Transparency Principle | Controllers are bound by a principle of transparent processing, which presupposes documented, uniquely identified and timestamped records of the processing environment (Malabo Convention Art. 13) | Scan |
| `GW-MAL-10` Processing Formalities and Records | Personal-data processing operations are subject to preliminary formalities before the national protection authority, requiring an enumerable, named record of the software performing the processing (Malabo Convention Art. 10) | Scan |
| `GW-MAL-23` Sustainability of Processing Systems | Controllers must ensure processing systems remain adequate and reliable as technology evolves; declared component versions are the basis for keeping systems current and supportable (Malabo Convention Art. 23) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GW Malabo.
# Guinea Law L/2016/037 on Data Protection (/docs/frameworks/middle-east-and-africa/guinea-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GN Law 2016 |
| Region | Middle East & Africa |
| Country or scope | Guinea |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GN Law 2016
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GN-037-SEC` Security of Processing Systems | Both the cybersecurity and data-protection parts of the law require systems handling personal data to be protected against intrusion and alteration; integrity hashes across components evidence this (Law L/2016/037/AN, security and cybersecurity provisions) | Scan |
| `GN-037-LEG` Legitimate, Accurate Processing | Processing is legitimate only on consent or another lawful basis and the data handled must be accurate, presuming each processing component is fully identified by name and a concrete version (Law L/2016/037/AN, legitimacy-of-processing provisions) | Scan |
| `GN-037-PROC` Third-Party Processing Accountability | Data processed through third-party software must remain attributable to named, accountable suppliers to prevent unlawful disclosure of personal or sensitive data (Law L/2016/037/AN, processing and sensitive-data provisions) | Scan |
| `GN-037-INV` Processing Software Inventory | Controller obligations presuppose an enumerable, named inventory of the software components that collect and process personal data (Law L/2016/037/AN, controller obligations) | Scan |
| `GN-037-CYB` Cybersecurity Version Hygiene | The cybercrime part of the law targets intrusion into information systems, and defending such systems requires deployed components to carry concrete, known versions for vulnerability assessment (Law L/2016/037/AN, Part 1 cybersecurity provisions) | Scan |
| `GN-037-TRANS` Documented Processing Environment | Fair and lawful processing presupposes documented, uniquely identified and timestamped records of the processing environment (Law L/2016/037/AN, fair-processing provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GN Law 2016.
# Middle East & Africa (/docs/frameworks/middle-east-and-africa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Laws, regulations and standards of the Middle East and Africa. Each framework's page lists what a scan checks, its controls, its policy templates and its automated tests. How coverage works: [Compliance frameworks](/docs/frameworks).
| Framework | Country or scope | Sector | Scan requirements | Catalog controls |
| --------------------------------------------------------------------------------------------------------------------- | ------------------------ | ---------- | ----------------- | ---------------- |
| [Algeria Law No. 18-07 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/algeria-law1807) | Algeria | Privacy | 5 | None |
| [Angola Law No. 22/11 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/angola-pdpl) | Angola | Privacy | 5 | None |
| [Bahrain PDPL](/docs/frameworks/middle-east-and-africa/bahrain-pdpl) | Bahrain | Privacy | 5 | 6 |
| [Benin Digital Code 2018 (Personal Data)](/docs/frameworks/middle-east-and-africa/benin-digital-code) | Benin | Privacy | 5 | None |
| [Botswana Data Protection Act 2018](/docs/frameworks/middle-east-and-africa/botswana-dpa) | Botswana | Privacy | 5 | None |
| [Burkina Faso Law No. 010-2004 on Personal Data](/docs/frameworks/middle-east-and-africa/burkina-faso-pdpl) | Burkina Faso | Privacy | 5 | None |
| [Cameroon Law 2010/012 on Cybersecurity](/docs/frameworks/middle-east-and-africa/cameroon-cyber) | Cameroon | Government | 6 | None |
| [Cape Verde Law No. 133/V/2001 on Personal Data](/docs/frameworks/middle-east-and-africa/cape-verde-pdpl) | Cape Verde | Privacy | 5 | None |
| [Chad Law No. 007/PR/2015 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/chad-pdpl) | Chad | Privacy | 5 | None |
| [Congo Law 29-2019 on Data Protection](/docs/frameworks/middle-east-and-africa/congo-dp) | Republic of the Congo | Privacy | 6 | None |
| [Cote d'Ivoire Law No. 2013-450 on Personal Data](/docs/frameworks/middle-east-and-africa/ivory-coast-pdpl) | Cote d'Ivoire | Privacy | 5 | None |
| [DR Congo Digital Code 2023 (Personal Data)](/docs/frameworks/middle-east-and-africa/drc-digital-code) | DR Congo | Privacy | 5 | None |
| [Egypt PDPL (Law 151/2020)](/docs/frameworks/middle-east-and-africa/egypt-pdpl) | Egypt | Privacy | 6 | 7 |
| [Eswatini Data Protection Act 2022](/docs/frameworks/middle-east-and-africa/eswatini-dpa) | Eswatini | Privacy | 6 | None |
| [Ethiopia Personal Data Protection Proclamation 1321/2024](/docs/frameworks/middle-east-and-africa/ethiopia-pdpp) | Ethiopia | Privacy | 6 | None |
| [Gabon Law No. 001/2011 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/gabon-pdpl) | Gabon | Privacy | 5 | None |
| [Ghana Data Protection Act](/docs/frameworks/middle-east-and-africa/ghana-dpa) | Ghana | Privacy | 6 | 7 |
| [Guinea Law L/2016/037 on Data Protection](/docs/frameworks/middle-east-and-africa/guinea-dp) | Guinea | Privacy | 6 | None |
| [Iran Computer Crimes Law 2009](/docs/frameworks/middle-east-and-africa/iran-ccl) | Iran | Government | 5 | None |
| [Iraq National Privacy Framework](/docs/frameworks/middle-east-and-africa/iraq-dp) | Iraq | Privacy | 5 | None |
| [Israel INCD](/docs/frameworks/middle-east-and-africa/israel-incd) | Israel | Government | 5 | 11 |
| [Jordan PDP Law](/docs/frameworks/middle-east-and-africa/jordan-pdp) | Jordan | Privacy | 5 | 9 |
| [Kenya Data Protection Act 2019](/docs/frameworks/middle-east-and-africa/kenya-dpa) | Kenya | Privacy | 6 | 7 |
| [Kuwait Cybersecurity Law](/docs/frameworks/middle-east-and-africa/kuwait-cyber) | Kuwait | Government | 5 | 9 |
| [Lebanon Law 81](/docs/frameworks/middle-east-and-africa/lebanon-81) | Lebanon | Privacy | 5 | 8 |
| [Lesotho Data Protection Act 2011](/docs/frameworks/middle-east-and-africa/lesotho-dpa) | Lesotho | Privacy | 5 | None |
| [Madagascar Law No. 2014-038 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/madagascar-pdpl) | Madagascar | Privacy | 5 | None |
| [Malabo Convention (AU) - Burundi](/docs/frameworks/middle-east-and-africa/burundi-dp) | Burundi | Privacy | 6 | None |
| [Malabo Convention (AU) - Central African Republic](/docs/frameworks/middle-east-and-africa/car-dp) | Central African Republic | Privacy | 6 | None |
| [Malabo Convention (AU) - Comoros](/docs/frameworks/middle-east-and-africa/comoros-dp) | Comoros | Privacy | 6 | None |
| [Malabo Convention (AU) - Djibouti](/docs/frameworks/middle-east-and-africa/djibouti-dp) | Djibouti | Privacy | 6 | None |
| [Malabo Convention (AU) - Equatorial Guinea](/docs/frameworks/middle-east-and-africa/eq-guinea-dp) | Equatorial Guinea | Privacy | 6 | None |
| [Malabo Convention (AU) - Eritrea](/docs/frameworks/middle-east-and-africa/eritrea-dp) | Eritrea | Privacy | 6 | None |
| [Malabo Convention (AU) - Gambia](/docs/frameworks/middle-east-and-africa/gambia-dp) | Gambia | Privacy | 6 | None |
| [Malabo Convention (AU) - Guinea-Bissau](/docs/frameworks/middle-east-and-africa/guinea-bissau-dp) | Guinea-Bissau | Privacy | 6 | None |
| [Malabo Convention (AU) - Liberia](/docs/frameworks/middle-east-and-africa/liberia-dp) | Liberia | Privacy | 6 | None |
| [Malabo Convention (AU) - Libya](/docs/frameworks/middle-east-and-africa/libya-dp) | Libya | Privacy | 6 | None |
| [Malabo Convention (AU) - Mozambique](/docs/frameworks/middle-east-and-africa/mozambique-dp) | Mozambique | Privacy | 6 | None |
| [Malabo Convention (AU) - Namibia](/docs/frameworks/middle-east-and-africa/namibia-dp) | Namibia | Privacy | 6 | None |
| [Malabo Convention (AU) - Sao Tome](/docs/frameworks/middle-east-and-africa/sao-tome-dp) | Sao Tome and Principe | Privacy | 6 | None |
| [Malabo Convention (AU) - Sierra Leone](/docs/frameworks/middle-east-and-africa/sierra-leone-dp) | Sierra Leone | Privacy | 6 | None |
| [Malabo Convention (AU) - South Sudan](/docs/frameworks/middle-east-and-africa/south-sudan-dp) | South Sudan | Privacy | 6 | None |
| [Malabo Convention (AU) - Sudan](/docs/frameworks/middle-east-and-africa/sudan-dp) | Sudan | Privacy | 6 | None |
| [Malawi Data Protection Act 2024](/docs/frameworks/middle-east-and-africa/malawi-dpa) | Malawi | Privacy | 6 | None |
| [Mali Law No. 2013-015 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/mali-pdpl) | Mali | Privacy | 5 | None |
| [Mauritania Law 2017-020 on Data Protection](/docs/frameworks/middle-east-and-africa/mauritania-dp) | Mauritania | Privacy | 6 | None |
| [Mauritius Data Protection Act 2017](/docs/frameworks/middle-east-and-africa/mauritius-dpa) | Mauritius | Privacy | 5 | None |
| [Morocco Law 09-08](/docs/frameworks/middle-east-and-africa/morocco-0908) | Morocco | Privacy | 5 | 9 |
| [Niger Law No. 2017-28 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/niger-pdpl) | Niger | Privacy | 5 | None |
| [Nigeria NDPR / NDPA](/docs/frameworks/middle-east-and-africa/nigeria-ndpr) | Nigeria | Privacy | 6 | 7 |
| [Oman PDPL](/docs/frameworks/middle-east-and-africa/oman-pdpl) | Oman | Privacy | 5 | 6 |
| [Palestine Data Protection Framework](/docs/frameworks/middle-east-and-africa/palestine-dp) | Palestine | Privacy | 5 | None |
| [Qatar PDPL](/docs/frameworks/middle-east-and-africa/qatar-pdpl) | Qatar | Privacy | 5 | 6 |
| [Rwanda Law No. 058/2021 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/rwanda-pdpl) | Rwanda | Privacy | 5 | None |
| [SAMA Cybersecurity Framework](/docs/frameworks/middle-east-and-africa/saudi-sama-cyber) | Saudi Arabia | Finance | 6 | 10 |
| [Saudi Arabia NCA ECC](/docs/frameworks/middle-east-and-africa/saudi-nca) | Saudi Arabia | Government | 6 | 18 |
| [Saudi PDPL](/docs/frameworks/middle-east-and-africa/saudi-pdpl) | Saudi Arabia | Privacy | 6 | 10 |
| [Senegal Law No. 2008-12 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/senegal-pdpl) | Senegal | Privacy | 5 | None |
| [Seychelles Data Protection Act 2003](/docs/frameworks/middle-east-and-africa/seychelles-dpa) | Seychelles | Privacy | 5 | None |
| [Sierra Leone Cyber Security and Crime Act 2021](/docs/frameworks/middle-east-and-africa/sierra-leone-cyber) | Sierra Leone | Government | 6 | None |
| [Somalia Data Protection Act 2023](/docs/frameworks/middle-east-and-africa/somalia-dpa) | Somalia | Privacy | 6 | None |
| [South Africa POPIA](/docs/frameworks/middle-east-and-africa/south-africa-popia) | South Africa | Privacy | 6 | 8 |
| [Syria Cybercrime Law No. 20 of 2022](/docs/frameworks/middle-east-and-africa/syria-cyber) | Syria | Government | 5 | None |
| [Syria National Privacy Framework](/docs/frameworks/middle-east-and-africa/syria-dp) | Syria | Privacy | 5 | None |
| [Tanzania Cybercrimes Act 2015](/docs/frameworks/middle-east-and-africa/tanzania-cybercrimes) | Tanzania | Government | 5 | None |
| [Tanzania Personal Data Protection Act 2022](/docs/frameworks/middle-east-and-africa/tanzania-pdpa) | Tanzania | Privacy | 5 | None |
| [Togo Law No. 2019-014 on Protection of Personal Data](/docs/frameworks/middle-east-and-africa/togo-pdpl) | Togo | Privacy | 5 | None |
| [Tunisia Organic Law No. 2004-63 on Personal Data](/docs/frameworks/middle-east-and-africa/tunisia-pdpl) | Tunisia | Privacy | 5 | None |
| [Turkey KVKK](/docs/frameworks/middle-east-and-africa/turkey-kvkk) | Turkey | Privacy | 6 | 8 |
| [UAE NESA IA Standards](/docs/frameworks/middle-east-and-africa/uae-nesa) | United Arab Emirates | Government | 6 | 8 |
| [UAE PDPL](/docs/frameworks/middle-east-and-africa/uae-pdpl) | United Arab Emirates | Privacy | 5 | 8 |
| [Uganda Data Protection and Privacy Act 2019](/docs/frameworks/middle-east-and-africa/uganda-dppa) | Uganda | Privacy | 5 | None |
| [Yemen National Privacy Framework](/docs/frameworks/middle-east-and-africa/yemen-dp) | Yemen | Privacy | 5 | None |
| [Zambia Cyber Security and Cyber Crimes Act 2021](/docs/frameworks/middle-east-and-africa/zambia-cscca) | Zambia | Government | 6 | None |
| [Zambia Data Protection Act No. 3 of 2021](/docs/frameworks/middle-east-and-africa/zambia-dpa) | Zambia | Privacy | 5 | None |
| [Zimbabwe Cyber and Data Protection Act 2021](/docs/frameworks/middle-east-and-africa/zimbabwe-cdpa) | Zimbabwe | Privacy | 6 | None |
# Iran Computer Crimes Law 2009 (/docs/frameworks/middle-east-and-africa/iran-ccl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | IR CCL |
| Region | Middle East & Africa |
| Country or scope | Iran |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers IR CCL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IR-CCL-1` Systems Protected by Security Measures | Unauthorized access is only an offence against data and systems protected by security measures, so operators must know precisely which software assets (PURL/CPE) constitute their protected systems (Computer Crimes Law 2009, Art. 1) | Scan |
| `IR-CCL-8` Detection of Data Alteration and Deletion | Unauthorized deletion, destruction or alteration of another's data is criminalized; detecting and evidencing such tampering requires integrity hashes over the system's software components (Computer Crimes Law 2009, Art. 8) | Scan |
| `IR-CCL-SYS` System Interference Resilience | The law criminalizes interference with and disruption of computer and telecommunication systems; maintaining and restoring such systems requires known versions for the software components in use (Computer Crimes Law 2009, system-interference offences) | Scan |
| `IR-CCL-INV` Enumerated Protected Systems | Custodianship duties over protected systems presuppose that each system is named and its constituent software components enumerated (Computer Crimes Law 2009, protected-system provisions) | Scan |
| `IR-CCL-SP` Service Provider Record Duties | Service providers are subject to retention and cooperation duties regarding the systems they operate, which requires dated, identifiable documentation of system composition (Computer Crimes Law 2009, service-provider obligations) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to IR CCL.
# Iraq National Privacy Framework (/docs/frameworks/middle-east-and-africa/iraq-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | IQ Privacy |
| Region | Middle East & Africa |
| Country or scope | Iraq |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers IQ Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IQ-CONST-17` Constitutional Privacy Protection | Every individual is guaranteed personal privacy, so systems that handle personal information must be identifiable via standard identifiers in order to protect that right (Constitution of Iraq 2005, Art. 17) | Scan |
| `IQ-CONST-40` Communications Confidentiality | Confidentiality of communications and correspondence may not be violated, requiring verifiable integrity of the software components that carry or process communications (Constitution of Iraq 2005, Art. 40) | Scan |
| `IQ-PDPL-VER` Draft-Law Security Obligation | The draft data-protection law obliges controllers to secure personal data, which requires that processing components carry known, concrete versions so weaknesses can be assessed and remedied (draft Personal Data Protection Law 2021, security obligations) | Scan |
| `IQ-PDPL-REC` Records of Processing | Accountability duties in the draft law presuppose a maintained, named inventory of the software components that perform personal-data processing (draft Personal Data Protection Law 2021, accountability provisions) | Scan |
| `IQ-PDPL-TRANS` Transparency of Processing | Data subjects are owed transparency about processing of their data, presupposing documented, uniquely identified and timestamped records of the processing environment (draft Personal Data Protection Law 2021, transparency provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to IQ Privacy.
# Israel INCD (/docs/frameworks/middle-east-and-africa/israel-incd)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National Cyber Directorate: software component inventory, supply chain risk management.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | INCD |
| Region | Middle East & Africa |
| Country or scope | Israel |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers INCD
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for INCD.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for INCD and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `IL-INCD-INV` Software Asset Inventory | Organizations must map and maintain an up-to-date inventory of the software assets and components in their environment (INCD Cyber Defense Methodology, asset management controls) | Scan |
| `IL-INCD-VER` Version and Patch Tracking | Patch management requires tracking the installed version of each software component to determine update status (INCD Cyber Defense Methodology, patch and update management controls) | Scan |
| `IL-INCD-SUP` Supply Chain Risk Management | Risks from suppliers and third-party software must be assessed and managed, presupposing that the supplier of each component is known (INCD supply chain risk management guidance) | Scan |
| `IL-INCD-INT` Software Integrity Verification | Software obtained and deployed must be verifiable as authentic and unmodified, supported by integrity hashes for components (INCD Cyber Defense Methodology, software integrity controls) | Scan |
| `IL-INCD-VULN` Vulnerability Identification | Organizations must identify vulnerabilities affecting their assets, which requires components identifiable against vulnerability databases via PURL or CPE (INCD Cyber Defense Methodology, vulnerability management controls) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------ | ---------------------------------------------------- |
| `INCD-CDM-GOV` | Establish Organisational Cyber Governance |
| `INCD-CDM-RISK` | Conduct Cyber Risk Assessment Using INCD Methodology |
| `INCD-CDM-ASSET` | Identify and Classify Cyber Assets |
| `INCD-CDM-PROTECT` | Implement Baseline Cyber Protection Controls |
| `INCD-CDM-DETECT` | Deploy Cyber Threat Detection Capabilities |
| `INCD-CDM-IR` | Maintain Cyber Incident Response Capability |
| `INCD-SC-1` | Assess Cyber Risks in the ICT Supply Chain |
| `INCD-SC-2` | Secure Software Supply Chain and SBOM |
| `INCD-SC-3` | Govern Third-Party Remote Access to Critical Systems |
| `INCD-CDM-RECOV` | Establish Cyber Recovery and Resilience Plans |
| `INCD-TRAIN-1` | Conduct Cyber Awareness and Training Programme |
## Policy templates
Written for INCD:
* Organisational Cyber Defence Policy (INCD Methodology)
* ICT Supply Chain Cyber Security Policy (INCD)
* Cyber Awareness, Training, and Recovery Policy (INCD)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to INCD.
# Cote d'Ivoire Law No. 2013-450 on Personal Data (/docs/frameworks/middle-east-and-africa/ivory-coast-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CI PDPL |
| Region | Middle East & Africa |
| Country or scope | Cote d'Ivoire |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CI PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CI-PDPL-SEC` Security of Processing | Controllers must take all appropriate precautions to preserve the security and integrity of personal data and to prevent alteration, damage or unauthorised access, evidenced by integrity hashes on processing components (Law No. 2013-450, security obligations) | Scan |
| `CI-PDPL-DECL` Processing Formalities and Inventory | Processing operations are subject to declaration or authorisation before ARTCI, which presupposes an inventory of the software systems used for processing (Law No. 2013-450, prior-formalities regime) | Scan |
| `CI-PDPL-PROC` Subcontractor Guarantees | Processing entrusted to a subcontractor must occur under contract with sufficient security guarantees, so third-party software components must carry named suppliers (Law No. 2013-450, subcontracting provisions) | Scan |
| `CI-PDPL-ID` Identifiable Components | Confidentiality duties and ARTCI enforcement require the components of processing systems to be uniquely identifiable (Law No. 2013-450, confidentiality and enforcement provisions) | Scan |
| `CI-PDPL-DOC` Traceable Documentation | Demonstrating conformity to ARTCI requires software records to be identifiable documents with a creation timestamp (Law No. 2013-450, supervisory cooperation duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CI PDPL.
# Jordan PDP Law (/docs/frameworks/middle-east-and-africa/jordan-pdp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Jordan Personal Data Protection Law (2023) - controller obligations, data subject rights, cross-border.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | JO PDP |
| Region | Middle East & Africa |
| Country or scope | Jordan |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers JO PDP
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for JO PDP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for JO PDP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `JO-PDP-SEC` Technical and Organisational Safeguards | Controllers must apply appropriate technical and organisational measures to protect personal data from loss, alteration or unauthorised access, which includes verifiable integrity of the software processing the data (Law No. 24/2023 controller security obligations) | Scan |
| `JO-PDP-BREACH` Breach Notification Readiness | Data breaches must be notified to the supervisory authority and affected data subjects, which requires the ability to identify precisely which processing components were affected (Law No. 24/2023 breach notification obligation) | Scan |
| `JO-PDP-PROC` Processor Engagement Duties | Controllers remain responsible when engaging processors and must ensure processors provide adequate protection guarantees, extending to visibility over software component suppliers (Law No. 24/2023 processor obligations) | Scan |
| `JO-PDP-ACC` Accountability for Processing Means | Controllers must be able to demonstrate lawful processing to the Personal Data Protection Council, which presumes documented knowledge of the systems and components performing the processing (Law No. 24/2023 accountability and oversight provisions) | Scan |
| `JO-PDP-TRANS` Documented Processing Transparency | Data subjects must be informed about processing and its purposes, part of a documentation duty that is supported by identifiable, timestamped records of the processing environment (Law No. 24/2023 transparency and notice obligations) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------- | ------------------------------------------ |
| `JO-4` | Lawfulness, Fairness & Transparency |
| `JO-6` | Purpose, Minimisation & Storage Limitation |
| `JO-9` | Consent Requirements |
| `JO-12` | Sensitive Data Processing |
| `JO-13` | Data Subject Rights Implementation |
| `JO-21` | Controller Accountability Measures |
| `JO-27` | Cross-Border Data Transfer Safeguards |
| `JO-31` | Data Protection Officer Appointment |
| `JO-32` | Breach Notification Obligation |
## Policy templates
Written for JO PDP:
* Jordan PDP Cross-Border Data Transfer Policy
* Jordan PDP Breach Notification Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to JO PDP.
# Kenya Data Protection Act 2019 (/docs/frameworks/middle-east-and-africa/kenya-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Kenya Data Protection Act - registration with ODPC, data subject rights, cross-border transfers.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | KE DPA |
| Region | Middle East & Africa |
| Country or scope | Kenya |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers KE DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for KE DPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for KE DPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `KE-DPA-41` Data Protection by Design and Security Safeguards | Controllers and processors must implement appropriate technical and organizational safeguards, integrated into processing from the design stage, to secure personal data; verifiable integrity across the software inventory evidences those safeguards (DPA 2019 s. 41) | Scan |
| `KE-DPA-43` Breach Notification Readiness | Breaches posing real risk of harm must be notified to the Data Commissioner and affected data subjects within statutory deadlines; rapid breach scoping requires known versions across the processing software (DPA 2019 s. 43) | Scan |
| `KE-DPA-18` Registration with the ODPC | Data controllers and processors must register with the Data Commissioner, supplying identifying particulars of their processing; a uniquely identified, timestamped SBOM supports registration-grade documentation of processing systems (DPA 2019 s. 18) | Scan |
| `KE-DPA-25` Processing Principles Including Accuracy | Personal data must be accurate, kept up to date, and processed in line with the Act's principles; the parallel discipline for the processing environment requires components carrying complete names and versions (DPA 2019 s. 25) | Scan |
| `KE-DPA-PROC` Processing Through Processors | Processing performed on a controller's behalf must be under a written contract with adequate security guarantees, requiring visibility into the suppliers behind the processing software (DPA 2019, processor-engagement provision) | Scan |
| `KE-DPA-XBORDER` Transfer Outside Kenya Readiness | Transfers of personal data outside Kenya require proof of appropriate safeguards or adequacy; determining which systems transfer what requires precisely identifiable components (DPA 2019, conditions for transfer out of Kenya) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ------------------------------------------- |
| `KDPA-S25` | Data Processing Principles (Sections 25-28) |
| `KDPA-S30` | Consent Requirements (Sections 30-31) |
| `KDPA-S37` | Data Subject Rights (Section 37) |
| `KDPA-S41` | Data Security Requirements (Section 41) |
| `KDPA-S48` | Cross-Border Data Transfers (Section 48) |
| `KDPA-REG-1` | Data Controller and Processor Registration |
| `KDPA-DPO-1` | Data Protection Officer Requirements |
## Policy templates
Written for KE DPA:
* Kenya DPA: Privacy Notice
* Kenya DPA: Data Breach Notification Procedure
* Kenya DPA: Cross-Border Data Transfer Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KE DPA.
# Kuwait Cybersecurity Law (/docs/frameworks/middle-east-and-africa/kuwait-cyber)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Kuwait National Cyber Security Strategy and DCC guidelines - critical infrastructure protection.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | KW Cyber |
| Region | Middle East & Africa |
| Country or scope | Kuwait |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers KW Cyber
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for KW Cyber.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for KW Cyber and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `KW-CYBER-ASSET` Critical Asset Identification | Operators of critical national infrastructure must identify and classify the information assets and systems they rely on, which for software means a documented component inventory (Kuwait NCSS critical infrastructure protection pillar) | Scan |
| `KW-CYBER-RISK` Cyber Risk Assessment Capability | National cybersecurity guidance requires risk assessments over critical systems, which is only possible when components are unambiguously identifiable for matching against known threats (Kuwait NCSS / CITRA risk management guidance) | Scan |
| `KW-CYBER-INT` System Integrity Protection | Baseline controls call for protecting the integrity of systems supporting critical services against tampering, evidenced by cryptographic hashes on deployed software artifacts (CITRA cybersecurity framework technical controls) | Scan |
| `KW-CYBER-VENDOR` Third-Party and Vendor Oversight | CITRA guidance requires managing risks introduced by service providers and technology vendors, which extends to recording who supplies each software component (CITRA third-party/outsourcing security guidance) | Scan |
| `KW-CYBER-IR` Incident Response Readiness | Entities must be able to report and respond to cyber incidents in coordination with national authorities, requiring version-level knowledge of deployed software to scope impact quickly (Kuwait NCSS incident response and coordination pillar) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | --------------------------------------------- |
| `KW-GOV-1` | Cybersecurity Governance Structure |
| `KW-GOV-2` | Cybersecurity Policy Framework |
| `KW-RISK-1` | National Cyber Risk Assessment |
| `KW-ASSET-1` | Asset Inventory & Classification |
| `KW-IAM-1` | Access Control & Privileged Access Management |
| `KW-INC-1` | Incident Detection & Response |
| `KW-INC-2` | Cyber Incident Reporting to DCC |
| `KW-BCP-1` | Business Continuity & Disaster Recovery |
| `KW-BCP-2` | Backup & Recovery Controls |
## Policy templates
Written for KW Cyber:
* Kuwait Cybersecurity Programme Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KW Cyber.
# Lebanon Law 81 (/docs/frameworks/middle-east-and-africa/lebanon-81)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Lebanon Electronic Transactions and Personal Data Law - consent, controller duties, breach handling.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | LB Law 81 |
| Region | Middle East & Africa |
| Country or scope | Lebanon |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers LB Law 81
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for LB Law 81.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for LB Law 81 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LB-81-SEC` Data Security Duty | Entities processing personal data must take measures to preserve the security and confidentiality of the data and prevent unauthorised alteration or access, which for software includes verifiable integrity of processing components (Law 81/2018 personal data security provisions) | Scan |
| `LB-81-CTRL` Controller Responsibility for Processing Means | Controllers bear responsibility for the processing they carry out, presuming documented knowledge of the systems and software components used (Law 81/2018 controller obligations) | Scan |
| `LB-81-PERMIT` Declaration and Permit Documentation | Certain processing operations require prior declaration or licence from the competent ministry with a description of the processing, requiring identifiable, timestamped documentation of the processing environment (Law 81/2018 declaration/licensing regime) | Scan |
| `LB-81-BREACH` Breach Handling Readiness | Handling security incidents affecting personal data requires the ability to determine which specific components and versions were involved in the compromised processing (Law 81/2018 security and breach handling duties) | Scan |
| `LB-81-THIRD` Third-Party Processing Oversight | Where processing is entrusted to third parties, the controller must ensure equivalent protection of the data, which extends to recording the suppliers of software used in processing (Law 81/2018 third-party processing provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | ----------------------------------------- |
| `LB-87` | Electronic Transactions Legal Recognition |
| `LB-90` | Consent for Electronic Processing |
| `LB-93` | Controller Registration & Notification |
| `LB-95` | Purpose Limitation & Lawful Processing |
| `LB-98` | Information Security & Encryption |
| `LB-100` | Security Breach Response |
| `LB-102` | Data Subject Access & Correction Rights |
| `LB-DPO` | Data Protection Focal Point |
## Policy templates
Written for LB Law 81:
* Lebanon Electronic Transactions & Data Protection Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LB Law 81.
# Lesotho Data Protection Act 2011 (/docs/frameworks/middle-east-and-africa/lesotho-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | LS DPA |
| Region | Middle East & Africa |
| Country or scope | Lesotho |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers LS DPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LS-DPA-SEC` Security Measures for Integrity of Data | A data controller must secure the integrity of personal information against loss, damage, unauthorized destruction and unlawful access, presuming integrity verification of the software that processes it (Data Protection Act 2011, Part III security-measures principle) | Scan |
| `LS-DPA-NOT` Notification with Description of Security Measures | Controllers must notify the Commission of processing, including a general description of security measures, which presupposes an enumerated inventory of the processing systems and their components (Data Protection Act 2011, notification obligation) | Scan |
| `LS-DPA-CTRL` Identified, Accountable Controller | The notification must state the name and address of the controller, so processing documentation should record who created and is accountable for the system description (Data Protection Act 2011, notification obligation) | Scan |
| `LS-DPA-QUAL` Data Quality Principle | Information must be complete, accurate and not misleading; applied to the processing stack this requires each component to carry both a name and a version (Data Protection Act 2011, Part III data-quality principle) | Scan |
| `LS-DPA-DOC` Dated, Identifiable Processing Records | Commission oversight of notified processing requires dated and identifiable documentation of the systems involved, satisfied by an SBOM with a document ID and creation timestamp (Data Protection Act 2011, accountability to the Commission) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LS DPA.
# Malabo Convention (AU) - Liberia (/docs/frameworks/middle-east-and-africa/liberia-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | LR Malabo |
| Region | Middle East & Africa |
| Country or scope | Liberia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers LR Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LR-MAL-21` Security of Processing Systems | The data controller must take all appropriate precautions, given the nature of the data, to prevent it from being altered, destroyed, or accessed by unauthorized third parties; verifiable integrity hashes on the software components that process data evidence this safeguard (Malabo Convention Art. 21) | Scan |
| `LR-MAL-20` Confidentiality and Controlled Processing | Processing must remain confidential and be carried out only by parties acting under the controller's authority, which requires that the suppliers behind processing software are known and accountable (Malabo Convention Art. 20) | Scan |
| `LR-MAL-13A` Accuracy of Processing | Personal data undergoing processing must be accurate and kept up to date, which presumes each software component handling it is fully identified by both name and a concrete version (Malabo Convention Art. 13) | Scan |
| `LR-MAL-13T` Transparency Principle | Controllers are bound by a principle of transparent processing, which presupposes documented, uniquely identified and timestamped records of the processing environment (Malabo Convention Art. 13) | Scan |
| `LR-MAL-10` Processing Formalities and Records | Personal-data processing operations are subject to preliminary formalities before the national protection authority, requiring an enumerable, named record of the software performing the processing (Malabo Convention Art. 10) | Scan |
| `LR-MAL-23` Sustainability of Processing Systems | Controllers must ensure processing systems remain adequate and reliable as technology evolves; declared component versions are the basis for keeping systems current and supportable (Malabo Convention Art. 23) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LR Malabo.
# Malabo Convention (AU) - Libya (/docs/frameworks/middle-east-and-africa/libya-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | LY Malabo |
| Region | Middle East & Africa |
| Country or scope | Libya |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers LY Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LY-MAL-21` Security of Processing Systems | The data controller must take all appropriate precautions, given the nature of the data, to prevent it from being altered, destroyed, or accessed by unauthorized third parties; verifiable integrity hashes on the software components that process data evidence this safeguard (Malabo Convention Art. 21) | Scan |
| `LY-MAL-20` Confidentiality and Controlled Processing | Processing must remain confidential and be carried out only by parties acting under the controller's authority, which requires that the suppliers behind processing software are known and accountable (Malabo Convention Art. 20) | Scan |
| `LY-MAL-13A` Accuracy of Processing | Personal data undergoing processing must be accurate and kept up to date, which presumes each software component handling it is fully identified by both name and a concrete version (Malabo Convention Art. 13) | Scan |
| `LY-MAL-13T` Transparency Principle | Controllers are bound by a principle of transparent processing, which presupposes documented, uniquely identified and timestamped records of the processing environment (Malabo Convention Art. 13) | Scan |
| `LY-MAL-10` Processing Formalities and Records | Personal-data processing operations are subject to preliminary formalities before the national protection authority, requiring an enumerable, named record of the software performing the processing (Malabo Convention Art. 10) | Scan |
| `LY-MAL-23` Sustainability of Processing Systems | Controllers must ensure processing systems remain adequate and reliable as technology evolves; declared component versions are the basis for keeping systems current and supportable (Malabo Convention Art. 23) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LY Malabo.
# Madagascar Law No. 2014-038 on Protection of Personal Data (/docs/frameworks/middle-east-and-africa/madagascar-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MG PDPL |
| Region | Middle East & Africa |
| Country or scope | Madagascar |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MG PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MG-PDPL-SEC` Security and Confidentiality of Processing | Controllers must take all necessary precautions to preserve the security of personal data and prevent its alteration, damage or access by unauthorised third parties, evidenced by integrity hashes on processing components (Law No. 2014-038, security obligations) | Scan |
| `MG-PDPL-DECL` Declaration of Processing Systems | Automated processing of personal data is subject to declaration or authorisation formalities, which presupposes an inventory of the software systems carrying out the processing (Law No. 2014-038, prior-formalities regime) | Scan |
| `MG-PDPL-PROC` Subcontracted Processing Guarantees | Processing carried out on behalf of a controller must offer sufficient security guarantees under contract, so third-party software components must have named suppliers (Law No. 2014-038, subcontracting provisions) | Scan |
| `MG-PDPL-ID` Identifiable Components | Controlling access to processing systems and investigating unauthorised access requires their components to be uniquely identifiable (Law No. 2014-038, confidentiality and access-control duties) | Scan |
| `MG-PDPL-DOC` Traceable Documentation | Cooperation with the supervisory commission requires software records to be identifiable documents with a creation timestamp (Law No. 2014-038, supervisory cooperation duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MG PDPL.
# Malawi Data Protection Act 2024 (/docs/frameworks/middle-east-and-africa/malawi-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MW DPA |
| Region | Middle East & Africa |
| Country or scope | Malawi |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MW DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `MW-DPA-SEC` Security Measures Including Encryption | Controllers and processors must implement technical and organizational measures such as pseudonymisation, encryption and regular risk assessments, presuming cryptographic integrity verification of the processing software (Data Protection Act 2024, security-of-processing obligation) | Scan |
| `MW-DPA-BREACH` 72-Hour Breach Notification Readiness | Data breaches must be notified to MACRA within 72 hours; determining what was affected that quickly requires precisely identifiable components (PURL/CPE) in the processing stack (Data Protection Act 2024, breach-notification obligation) | Scan |
| `MW-DPA-ROPA` Records of Processing | Controllers and processors must maintain records demonstrating compliance, which requires an enumerated inventory of the software systems and components that process personal data (Data Protection Act 2024, records/accountability obligation) | Scan |
| `MW-DPA-PROC` Processor Engagement Safeguards | Processing on behalf of a controller may only be entrusted to processors giving sufficient guarantees of appropriate security measures, requiring third-party software suppliers to be identified (Data Protection Act 2024, controller-processor obligation) | Scan |
| `MW-DPA-DPO` Accountable Data Protection Contact | A data protection officer must be designated in prescribed circumstances, so processing documentation should record an accountable creator contact (Data Protection Act 2024, DPO obligation) | Scan |
| `MW-DPA-DPIA` Impact Assessment for High-Risk Processing | Data protection impact assessments are required for high-risk processing, which presupposes that the processing system is named and its constituent components are known (Data Protection Act 2024, DPIA obligation) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MW DPA.
# Mali Law No. 2013-015 on Protection of Personal Data (/docs/frameworks/middle-east-and-africa/mali-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | ML PDPL |
| Region | Middle East & Africa |
| Country or scope | Mali |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers ML PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `ML-PDPL-SEC` Security of Processing | Controllers must take all useful precautions to preserve the security of personal data and prevent its alteration, damage or access by unauthorized third parties, presuming integrity controls over processing software (Law No. 2013-015, security-of-processing obligation) | Scan |
| `ML-PDPL-DECL` Prior Formalities with the APDP | Processing of personal data is subject to prior declaration to, or authorization by, the APDP, which presupposes an inventory of the software systems and components performing the processing (Law No. 2013-015, declaration/authorization regime) | Scan |
| `ML-PDPL-PROC` Processor Oversight | Outsourced processing requires a processor presenting sufficient security and confidentiality guarantees, acting only on the controller's instructions, which requires third-party software suppliers to be identified (Law No. 2013-015, processor-oversight obligation) | Scan |
| `ML-PDPL-QUAL` Data Quality and Maintained Systems | Personal data must be accurate and kept up to date, which for the systems processing it requires knowing component versions so stale or unmaintained software can be identified (Law No. 2013-015, data-quality principle) | Scan |
| `ML-PDPL-DOC` Documented Processing Records | APDP oversight and the declaration regime require dated, identifiable documentation of processing systems, satisfied by an SBOM bearing a document ID and creation timestamp (Law No. 2013-015, accountability to the APDP) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ML PDPL.
# Mauritania Law 2017-020 on Data Protection (/docs/frameworks/middle-east-and-africa/mauritania-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MR Law 2017 |
| Region | Middle East & Africa |
| Country or scope | Mauritania |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MR Law 2017
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MR-020-SEC` Security of Personal Data | Controllers must protect personal data during collection, recording, processing, storage, and transmission; verifiable integrity hashes on processing components evidence these safeguards (Law 2017-020, security obligations) | Scan |
| `MR-020-ACC` Adequate, Relevant, Accurate Data | Data processed must be adequate, relevant, not excessive, and accurate, presuming each processing component is fully identified by both name and a concrete version (Law 2017-020, data-quality principles) | Scan |
| `MR-020-DECL` Formalities Before the APD | Processing operations are subject to declaration or authorization formalities before the Personal Data Protection Authority, requiring an enumerable, named record of the software performing the processing (Law 2017-020, prior-formalities provisions) | Scan |
| `MR-020-PROC` Processor Accountability | Processing carried out through third parties must remain under the controller's responsibility, so third-party software components must carry named, accountable suppliers (Law 2017-020, processor provisions) | Scan |
| `MR-020-RET` Retention Limitation | Personal data may be retained only as long as necessary for its declared purposes, which requires knowing exactly which software components, at which versions, hold the data (Law 2017-020, retention-limitation principle) | Scan |
| `MR-020-TRANS` Transparent and Fair Processing | Collection and processing must be lawful, fair, and non-fraudulent, presupposing documented, uniquely identified and timestamped records of the processing environment (Law 2017-020, fair-processing principles) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MR Law 2017.
# Mauritius Data Protection Act 2017 (/docs/frameworks/middle-east-and-africa/mauritius-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MU DPA |
| Region | Middle East & Africa |
| Country or scope | Mauritius |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MU DPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MU-DPA-31` Security of Processing | Controllers and processors must implement appropriate security and organisational measures, proportionate to the risk, protecting personal data against unauthorised alteration and destruction, evidenced by integrity hashes on processing components (DPA 2017, s. 31) | Scan |
| `MU-DPA-REC` Record of Processing Operations | Controllers must maintain a record of their processing operations, which presupposes an inventory of the software systems that carry out the processing (DPA 2017, record-keeping obligation, s. 33) | Scan |
| `MU-DPA-BRN` 72-Hour Breach Notification Readiness | Personal data breaches must be notified to the Data Protection Commissioner without undue delay (72 hours where feasible), which requires affected components to be quickly identifiable (DPA 2017, s. 25 breach notification) | Scan |
| `MU-DPA-PROC` Processor Guarantees | Controllers may only use processors providing sufficient guarantees, acting under a binding contract, so third-party software components must have named suppliers (DPA 2017, controller-processor provisions) | Scan |
| `MU-DPA-DOC` Demonstrable Compliance Records | The accountability principle requires controllers to demonstrate compliance to the Commissioner, so software records must be identifiable, timestamped documents with a recorded creator (DPA 2017, accountability duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MU DPA.
# Morocco Law 09-08 (/docs/frameworks/middle-east-and-africa/morocco-0908)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Morocco Personal Data Protection Law 09-08 - CNDP oversight, consent, cross-border transfer.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | MA 09-08 |
| Region | Middle East & Africa |
| Country or scope | Morocco |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers MA 09-08
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for MA 09-08.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for MA 09-08 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MA-0908-SEC` Security and Confidentiality of Processing | Controllers must implement appropriate technical and organisational measures to protect personal data against destruction, alteration and unauthorised access, which for software systems includes verifiable artifact integrity (Law 09-08 security-of-processing obligation, Art. 23-style) | Scan |
| `MA-0908-PROC` Processor Guarantees | Processing carried out on the controller's behalf must be entrusted only to processors providing sufficient security guarantees, which extends to knowing the suppliers of processing software components (Law 09-08 processor provisions) | Scan |
| `MA-0908-DECL` Prior Declaration to the CNDP | Processing operations require prior declaration or authorisation filed with the CNDP describing the processing and the systems used, requiring identifiable, dated documentation of the processing platform (Law 09-08 declaration/authorisation regime) | Scan |
| `MA-0908-QUAL` Data Quality Discipline | Personal data must be adequate, relevant, accurate and up to date; a processing environment demonstrates this discipline only if its own software inventory is complete with names and versions (Law 09-08 data quality principles) | Scan |
| `MA-0908-INV` Knowledge of Processing Systems | The controller's responsibility for the means of processing presumes maintained knowledge of what software constitutes those means, i.e. a non-empty component inventory (Law 09-08 controller responsibility provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | --------------------------------------- |
| `MA-3` | Data Processing Principles |
| `MA-8` | Sensitive Data Prohibition & Exceptions |
| `MA-12` | Data Subject Rights Procedures |
| `MA-17` | CNDP Declaration & Prior Authorisation |
| `MA-33` | Cross-Border Transfer Controls |
| `MA-41` | Security & Breach Management |
| `MA-CNDP` | CNDP Oversight Cooperation |
| `MA-PROC` | Processor Agreements |
| `MA-ROPA` | Records of Processing Activities |
## Policy templates
Written for MA 09-08:
* Morocco CNDP Declaration Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MA 09-08.
# Malabo Convention (AU) - Mozambique (/docs/frameworks/middle-east-and-africa/mozambique-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MZ Malabo |
| Region | Middle East & Africa |
| Country or scope | Mozambique |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MZ Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MZ-MAL-13` Transparent and Accurate Processing Records | Personal-data processing must be lawful, transparent and accurate, which presupposes a maintained record of the software components that perform the processing (Malabo Convention Art. 13). | Scan |
| `MZ-MAL-13-6` Confidentiality Principle: Identifiable Components | The confidentiality principle requires knowing precisely which software handles personal data, so components must carry standard identifiers such as PURL or CPE that tie safeguards to specific packages (Malabo Convention Art. 13, Principle 6). | Scan |
| `MZ-MAL-20` Processor and Third-Party Accountability | Processing performed on a controller's behalf must remain under the controller's authority and instructions, so third-party components need named, accountable suppliers (Malabo Convention Art. 20). | Scan |
| `MZ-MAL-21` Security of Processing Systems | Controllers must take all appropriate precautions to keep data from being altered, destroyed or accessed by unauthorised third parties; integrity hashes on components let tampering be detected (Malabo Convention Art. 21). | Scan |
| `MZ-MAL-21-V` Incident and Breach-Impact Readiness | Judging whether processing systems remain secure after an incident requires knowing the exact versions of the components in operation (Malabo Convention Art. 21). | Scan |
| `MZ-MAL-10` Declared and Documented Processing | Preliminary formalities require processing operations to be declared to the supervisory authority, which presupposes dated, identifiable documentation of the systems used (Malabo Convention Art. 10, preliminary formalities). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MZ Malabo.
# Malabo Convention (AU) - Namibia (/docs/frameworks/middle-east-and-africa/namibia-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | NA Malabo |
| Region | Middle East & Africa |
| Country or scope | Namibia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers NA Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NA-MAL-13` Transparent and Accurate Processing Records | Personal-data processing must be lawful, transparent and accurate, which presupposes a maintained record of the software components that perform the processing (Malabo Convention Art. 13). | Scan |
| `NA-MAL-13-6` Confidentiality Principle: Identifiable Components | The confidentiality principle requires knowing precisely which software handles personal data, so components must carry standard identifiers such as PURL or CPE that tie safeguards to specific packages (Malabo Convention Art. 13, Principle 6). | Scan |
| `NA-MAL-20` Processor and Third-Party Accountability | Processing performed on a controller's behalf must remain under the controller's authority and instructions, so third-party components need named, accountable suppliers (Malabo Convention Art. 20). | Scan |
| `NA-MAL-21` Security of Processing Systems | Controllers must take all appropriate precautions to keep data from being altered, destroyed or accessed by unauthorised third parties; integrity hashes on components let tampering be detected (Malabo Convention Art. 21). | Scan |
| `NA-MAL-21-V` Incident and Breach-Impact Readiness | Judging whether processing systems remain secure after an incident requires knowing the exact versions of the components in operation (Malabo Convention Art. 21). | Scan |
| `NA-MAL-10` Declared and Documented Processing | Preliminary formalities require processing operations to be declared to the supervisory authority, which presupposes dated, identifiable documentation of the systems used (Malabo Convention Art. 10, preliminary formalities). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NA Malabo.
# Niger Law No. 2017-28 on Protection of Personal Data (/docs/frameworks/middle-east-and-africa/niger-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | NE PDPL |
| Region | Middle East & Africa |
| Country or scope | Niger |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers NE PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NE-PDPL-SEC` Technical and Organizational Security Measures | Controllers must implement all appropriate technical and organizational measures to preserve security and confidentiality, protecting data against accidental or unlawful destruction, loss, alteration, distribution or access, presuming integrity controls on processing software (Law No. 2017-28, security-of-processing obligation) | Scan |
| `NE-PDPL-DECL` Prior Formalities with the HAPDP | Processing operations are subject to prior declaration to, or authorization by, the HAPDP, which presupposes an inventory of the software systems and components performing the processing (Law No. 2017-28, declaration/authorization regime) | Scan |
| `NE-PDPL-PROC` Processor and Subcontractor Duties | Persons processing data on behalf of the controller are bound by the same security and confidentiality duties, requiring the third-party suppliers involved in processing systems to be identified (Law No. 2017-28, processor obligation) | Scan |
| `NE-PDPL-INFO` Transparency Toward Data Subjects | Data subjects must be informed of the identity of the controller, the categories of data collected and the purposes of processing; verifiable documentation of the processing system supports this duty (Law No. 2017-28, information rights) | Scan |
| `NE-PDPL-QUAL` Data Quality and Maintained Systems | Data must be accurate and kept up to date, which applied to the processing stack requires component versions to be recorded so unmaintained software is detectable (Law No. 2017-28, data-quality principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NE PDPL.
# Nigeria NDPR / NDPA (/docs/frameworks/middle-east-and-africa/nigeria-ndpr)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Nigeria Data Protection Regulation / Act - DPO, data subject rights, breach notification, registration.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NDPR |
| Region | Middle East & Africa |
| Country or scope | Nigeria |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NDPR
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for NDPR.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for NDPR and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NG-NDPA-SEC` Security of Processing | Controllers and processors must implement appropriate technical and organizational measures to secure personal data against loss, misuse or alteration; verifiable integrity across the software inventory evidences such measures (NDPA 2023, security-of-processing obligation) | Scan |
| `NG-NDPA-PRIN` Processing Principles Including Accuracy | Personal data must be processed accurately, kept up to date, and limited to its purpose; the same accuracy discipline for the processing environment requires components with complete names and versions (NDPA 2023, data-processing principles) | Scan |
| `NG-NDPA-BREACH` Breach Notification Readiness | Personal data breaches likely to risk rights and freedoms must be notified to the NDPC within a short statutory window; rapid breach scoping requires known versions across the processing software (NDPA 2023, breach-notification obligation) | Scan |
| `NG-NDPA-PROC` Engagement of Processors | Controllers may engage only processors providing sufficient compliance guarantees under a binding agreement, requiring visibility into the suppliers behind the processing software (NDPA 2023, processor-engagement provision) | Scan |
| `NG-NDPA-DPO` Data Protection Officer | Controllers of major importance must designate a data protection officer, providing a reachable accountability contact for the systems described in the SBOM (NDPA 2023, DPO-designation obligation) | Scan |
| `NG-NDPA-REG` Registration of Controllers of Major Importance | Data controllers and processors of major importance must register with the NDPC with identifying particulars; a uniquely identified, timestamped SBOM supports registration-grade documentation of processing systems (NDPA 2023, registration obligation) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | -------------------------------------------------- |
| `NDPR-2.1` | Core Data Processing Principles (Art. 2.1) |
| `NDPR-2.5` | Data Security Obligations (Art. 2.5) |
| `NDPR-2.6` | Compliance Audit Obligations (Art. 2.6) |
| `NDPR-3.1` | Data Subject Rights (Art. 3.1) |
| `NDPR-DPCO-1` | DPCO Registration and Data Controller Registration |
| `NDPR-XBORDER-1` | Cross-Border Data Transfer Controls |
| `NDPR-BREACH-1` | Data Breach Notification |
## Policy templates
Written for NDPR:
* NDPR: Privacy Policy Notice
* NDPR: Data Subject Rights Procedure
* NDPR: Information Security Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NDPR.
# Oman PDPL (/docs/frameworks/middle-east-and-africa/oman-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Sultanate of Oman Personal Data Protection Law - consent, processor duties, sensitive data, transfers.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | OM PDPL |
| Region | Middle East & Africa |
| Country or scope | Oman |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers OM PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 6 controls from Safeguard's control catalog for OM PDPL.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for OM PDPL and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `OM-PDPL-SEC` Security of Personal Data | Controllers and processors must implement measures ensuring personal data is protected against breach, loss or unlawful processing; verifiable integrity of the software inventory evidences such measures (RD 6/2022, security-of-processing obligation) | Scan |
| `OM-PDPL-PROC` Processor Duties | Processing carried out on the controller's behalf must be bound by the controller's instructions and equivalent safeguards, requiring visibility into the suppliers behind the processing software (RD 6/2022, processor-obligations provision) | Scan |
| `OM-PDPL-BREACH` Breach Notification Readiness | Breaches of personal data must be notified to the competent authority and affected data subjects; assessing scope quickly requires known versions across the software handling the data (RD 6/2022, breach-notification obligation) | Scan |
| `OM-PDPL-XBORDER` Cross-Border Transfer Readiness | Transfers of personal data outside Oman are conditioned on adequate protection and must not prejudice data subjects; determining which systems transfer what requires precisely identifiable components (RD 6/2022, cross-border transfer provisions) | Scan |
| `OM-PDPL-TRANS` Transparency Toward Data Subjects | Data subjects must be informed of the processing of their data and its purposes; identified, timestamped documentation of the processing environment operationalizes this duty (RD 6/2022, transparency/notice obligations) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------------- | ------------------------------------- |
| `OPDPL-ART5` | Data Subject Rights (Art. 5-9) |
| `OPDPL-ART11` | Data Security Requirements (Art. 11) |
| `OPDPL-ART13` | Cross-Border Data Transfers (Art. 13) |
| `OPDPL-ART14` | Data Breach Notification (Art. 14) |
| `OPDPL-CONSENT-1` | Consent and Lawful Processing Basis |
| `OPDPL-PROC-1` | Data Processing Agreements |
## Policy templates
Written for OM PDPL:
* Oman PDPL: Privacy Notice
* Oman PDPL: Data Breach Notification Procedure
* Oman PDPL: Cross-Border Data Transfer Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to OM PDPL.
# Palestine Data Protection Framework (/docs/frameworks/middle-east-and-africa/palestine-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | PS DP Frwk |
| Region | Middle East & Africa |
| Country or scope | Palestine |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers PS DP Frwk
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `PS-DP-SEC` Security of Personal Data | The draft data-protection decree obliges controllers to safeguard personal data against unauthorized access or alteration; integrity hashes on processing components evidence such safeguards (draft Personal Data Protection Law by Decree, security obligations) | Scan |
| `PS-DP-BL` Constitutional Privacy Safeguard | The Basic Law protects fundamental rights and the sanctity of private life, so systems handling personal information must be identifiable via standard identifiers to honor that guarantee (Amended Basic Law of 2003, privacy and fundamental-rights guarantees) | Scan |
| `PS-DP-REC` Records of Processing | Accountability obligations in the draft decree presuppose a maintained, named inventory of the software components performing personal-data processing (draft Personal Data Protection Law by Decree, accountability provisions) | Scan |
| `PS-DP-TRANS` Transparency of Processing | Data subjects are owed transparency about how their data is handled, which presupposes documented, uniquely identified and timestamped records of the processing environment (draft Personal Data Protection Law by Decree, transparency provisions) | Scan |
| `PS-DP-PROC` Third-Party Accountability | Processing entrusted to third parties must remain accountable to the controller, requiring named suppliers for third-party software components (draft Personal Data Protection Law by Decree, processor provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PS DP Frwk.
# Qatar PDPL (/docs/frameworks/middle-east-and-africa/qatar-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Qatar Personal Data Privacy Protection Law - consent, data subject rights, sensitive data, breach notification.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | QA PDPL |
| Region | Middle East & Africa |
| Country or scope | Qatar |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers QA PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 6 controls from Safeguard's control catalog for QA PDPL.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for QA PDPL and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `QA-PDPL-SEC` Protective Precautions | Controllers must take appropriate administrative, technical and financial precautions to protect personal data against loss, damage or unauthorized disclosure; verifiable integrity of the processing software evidences such precautions (Law 13/2016, data-protection precautions obligation) | Scan |
| `QA-PDPL-BREACH` Breach Notification Readiness | Controllers must notify the competent department and affected individuals of breaches liable to cause serious harm; assessing a breach quickly requires known versions across the software estate (Law 13/2016, breach-notification obligation) | Scan |
| `QA-PDPL-PROC` Processor Compliance | Processors acting for controllers must comply with the controller's instructions and the law's protections, which requires visibility into the suppliers behind the processing software (Law 13/2016, processor-obligations provision) | Scan |
| `QA-PDPL-QUAL` Accuracy of Processing | Personal data must be processed accurately for legitimate purposes; the same accuracy discipline applied to the processing environment requires components with complete names and versions (Law 13/2016, lawful/accurate processing principles) | Scan |
| `QA-PDPL-TRANS` Transparency of Processing | Individuals are entitled to know how their data is processed and by whom; identified, timestamped documentation of the processing environment operationalizes this transparency (Law 13/2016, transparency and data subject information duties) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------------- | ------------------------------------------------------- |
| `QPDPL-ART11` | Data Subject Rights: Access and Correction (Art. 11-13) |
| `QPDPL-ART14` | Data Security Requirements (Art. 14) |
| `QPDPL-ART15` | Controller Obligations and Accountability (Art. 15-18) |
| `QPDPL-ART19` | Cross-Border Data Transfers (Art. 19) |
| `QPDPL-CONSENT-1` | Consent Management |
| `QPDPL-SENS-1` | Sensitive Data Processing Controls |
## Policy templates
Written for QA PDPL:
* Qatar PDPL: Privacy Notice
* Qatar PDPL: Data Subject Rights Procedure
* Qatar PDPL: Cross-Border Data Transfer Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to QA PDPL.
# Rwanda Law No. 058/2021 on Protection of Personal Data (/docs/frameworks/middle-east-and-africa/rwanda-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | RW PDPL |
| Region | Middle East & Africa |
| Country or scope | Rwanda |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers RW PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `RW-PDP-SEC` Security of Processing | Controllers and processors must adopt appropriate technical and organisational security measures for personal data, evidenced by integrity hashes on the components of processing systems (Law No. 058/2021, security-of-processing obligations) | Scan |
| `RW-PDP-BRN48` 48-Hour Breach Notification Readiness | Personal data breaches must be notified to the supervisory authority within 48 hours, an aggressive deadline that requires components to be immediately identifiable via PURL or CPE (Law No. 058/2021, breach-notification provisions) | Scan |
| `RW-PDP-REG` Registration and Records of Processing | Controllers and processors must register with the NCSA and maintain records of processing activities, which presupposes an inventory of the software performing that processing (Law No. 058/2021, registration and record-keeping duties) | Scan |
| `RW-PDP-PROC` Processor Guarantees | Controllers may only engage processors offering sufficient security guarantees under contract, so third-party software components must carry named suppliers (Law No. 058/2021, controller-processor provisions) | Scan |
| `RW-PDP-VER` Known Software Versions | Assessing breach impact and keeping processing systems secure over time requires the exact versions of software components to be recorded (Law No. 058/2021, security and breach-assessment duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to RW PDPL.
# Malabo Convention (AU) - Sao Tome (/docs/frameworks/middle-east-and-africa/sao-tome-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | ST Malabo |
| Region | Middle East & Africa |
| Country or scope | Sao Tome and Principe |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers ST Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ST-MAL-13` Transparent and Accurate Processing Records | Personal-data processing must be lawful, transparent and accurate, which presupposes a maintained record of the software components that perform the processing (Malabo Convention Art. 13). | Scan |
| `ST-MAL-13-6` Confidentiality Principle: Identifiable Components | The confidentiality principle requires knowing precisely which software handles personal data, so components must carry standard identifiers such as PURL or CPE that tie safeguards to specific packages (Malabo Convention Art. 13, Principle 6). | Scan |
| `ST-MAL-20` Processor and Third-Party Accountability | Processing performed on a controller's behalf must remain under the controller's authority and instructions, so third-party components need named, accountable suppliers (Malabo Convention Art. 20). | Scan |
| `ST-MAL-21` Security of Processing Systems | Controllers must take all appropriate precautions to keep data from being altered, destroyed or accessed by unauthorised third parties; integrity hashes on components let tampering be detected (Malabo Convention Art. 21). | Scan |
| `ST-MAL-21-V` Incident and Breach-Impact Readiness | Judging whether processing systems remain secure after an incident requires knowing the exact versions of the components in operation (Malabo Convention Art. 21). | Scan |
| `ST-MAL-10` Declared and Documented Processing | Preliminary formalities require processing operations to be declared to the supervisory authority, which presupposes dated, identifiable documentation of the systems used (Malabo Convention Art. 10, preliminary formalities). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ST Malabo.
# Saudi Arabia NCA ECC (/docs/frameworks/middle-east-and-africa/saudi-nca)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National Cybersecurity Authority Essential Cybersecurity Controls: asset management, vulnerability management.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NCA ECC |
| Region | Middle East & Africa |
| Country or scope | Saudi Arabia |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NCA ECC
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 18 controls from Safeguard's control catalog for NCA ECC.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for NCA ECC and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SA-ECC-2-1` Asset Management | Entities must maintain an accurate and up-to-date inventory of information and technology assets, which for software means an inventory of components in use (NCA ECC Domain 2, Asset Management subdomain) | Scan |
| `SA-ECC-VULN` Vulnerability Management | Technical vulnerabilities must be identified and assessed periodically, requiring software components to carry identifiers matchable against vulnerability sources (NCA ECC Domain 2, Vulnerability Management subdomain) | Scan |
| `SA-ECC-PATCH` Patch Management | Security patches and updates must be applied in a timely manner, which requires knowing the version of each software component to determine applicability (NCA ECC Domain 2, Patch Management subdomain) | Scan |
| `SA-ECC-INTEG` Systems Protection and Integrity | Information system protection controls include safeguarding the integrity of deployed software, supported by cryptographic hashes for components (NCA ECC Domain 2, Information System and Processing Facilities Protection subdomain) | Scan |
| `SA-ECC-4-1` Third-Party Cybersecurity | Cybersecurity requirements must be applied to third parties and outsourcing arrangements, requiring the supplier of externally sourced software components to be known (NCA ECC Domain 4, Third-Party and Cloud Computing Cybersecurity) | Scan |
| `SA-ECC-DOC` Documented and Auditable Records | ECC compliance must be documented and subject to periodic review and audit; a dated, identifiable SBOM provides the auditable software-asset record (NCA ECC Domain 1, Cybersecurity Governance: periodical review and audit) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | -------------------------------------------------- |
| `ECC-1-1` | Establish a Cybersecurity Strategy and Programme |
| `ECC-1-2` | Define Cybersecurity Roles and Responsibilities |
| `ECC-1-3` | Establish Cybersecurity Policies and Procedures |
| `ECC-2-1` | Manage Cybersecurity Risk |
| `ECC-2-2` | Manage Cybersecurity in the Supply Chain |
| `ECC-2-3` | Manage Asset Cybersecurity |
| `ECC-2-4` | Manage Identity and Access |
| `ECC-2-5` | Protect Information Assets |
| `ECC-2-6` | Manage Vulnerabilities and Patches |
| `ECC-2-7` | Perform Cybersecurity Event Logging and Monitoring |
| `ECC-2-9` | Manage Cybersecurity Incidents |
| `ECC-2-12` | Manage Cybersecurity in Change Management |
| `ECC-2-13` | Ensure Business Continuity and Disaster Recovery |
| `ECC-3-1` | Secure Network Architecture |
| `ECC-4-1` | Govern Cybersecurity in Cloud Computing |
| `ECC-4-2` | Secure Industrial Control Systems |
| `ECC-5-1` | Manage Cybersecurity Compliance |
| `ECC-5-2` | Manage Cybersecurity Audit |
## Policy templates
Written for NCA ECC:
* Enterprise Cybersecurity Policy (NCA ECC)
* Identity, Access Management and Vulnerability Management Policy (NCA ECC)
* Cybersecurity Incident Management and BCP Policy (NCA ECC)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NCA ECC.
# Saudi PDPL (/docs/frameworks/middle-east-and-africa/saudi-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Saudi Personal Data Protection Law - consent, data subject rights, cross-border, controller registration.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SA PDPL |
| Region | Middle East & Africa |
| Country or scope | Saudi Arabia |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SA PDPL
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for SA PDPL.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for SA PDPL and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SA-PDPL-19` Security and Protection Measures | Controllers must take the necessary organisational, administrative and technical measures to protect personal data, including during transfer, which for software systems entails verifiable integrity of the components processing the data (PDPL Art. 19) | Scan |
| `SA-PDPL-20` Breach Notification Readiness | Controllers must notify SDAIA of personal data breaches that harm data or data subjects, which requires being able to pinpoint exactly which system components were compromised (PDPL Art. 20) | Scan |
| `SA-PDPL-8` Processor Selection Guarantees | Controllers may only engage processors that provide sufficient guarantees to protect personal data and must verify their compliance, extending to visibility over the suppliers of processing software (PDPL Art. 8) | Scan |
| `SA-PDPL-ROPA` Records of Processing Activities | Controllers must maintain records of their processing activities including descriptions of the processing and its means, which presumes an inventory of the software performing that processing (PDPL records-of-processing obligation and Implementing Regulation) | Scan |
| `SA-PDPL-PRIV` Privacy Policy Transparency | Controllers must make an accessible privacy policy available before collection begins, part of a broader documentation duty that includes identifiable, dated records of the processing environment (PDPL privacy policy/transparency obligation) | Scan |
| `SA-PDPL-UPD` Maintained and Current Systems | The duty to keep protection measures effective over time implies knowing the versions of deployed components so vulnerable or outdated software can be found and updated (PDPL Art. 19 ongoing security obligation) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ------------------------------- |
| `PDPL-4` | Lawfulness & Purpose Limitation |
| `PDPL-6` | Data Minimisation & Accuracy |
| `PDPL-8` | Retention Limitation |
| `PDPL-10` | Consent Management |
| `PDPL-13` | Sensitive Data Consent |
| `PDPL-14` | Privacy Notice Transparency |
| `PDPL-16` | Data Subject Rights Fulfilment |
| `PDPL-23` | Cross-Border Transfer Controls |
| `PDPL-29` | Breach Notification |
| `PDPL-34` | NDMO Registration |
## Policy templates
Written for SA PDPL:
* Saudi PDPL Privacy Notice
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SA PDPL.
# SAMA Cybersecurity Framework (/docs/frameworks/middle-east-and-africa/saudi-sama-cyber)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Saudi Central Bank Cybersecurity Framework - Leadership, Risk, Resilience domains for financial sector.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SAMA CSF |
| Region | Middle East & Africa |
| Country or scope | Saudi Arabia |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SAMA CSF
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for SAMA CSF.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for SAMA CSF and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SA-SAMA-ASSET` Asset Management and Inventory | Member organisations must maintain an accurate and complete inventory of information assets, which for applications includes the software components they are built from (SAMA CSF Operations & Technology domain, asset management subdomain) | Scan |
| `SA-SAMA-VULN` Vulnerability Management | A vulnerability management process must ensure weaknesses in technology are identified and remediated in a timely manner, which requires version-level knowledge of all deployed components (SAMA CSF Operations & Technology domain, vulnerability management subdomain) | Scan |
| `SA-SAMA-D4` Third Party Cyber Security | Cyber security requirements must be enforced across outsourcing and supplier relationships, so the provenance and supplier of software components must be documented (SAMA CSF Domain 4, Third Party Cyber Security) | Scan |
| `SA-SAMA-INT` Application and Infrastructure Integrity | Security standards for applications and infrastructure must protect against unauthorised modification, which is evidenced by cryptographic integrity hashes on software artifacts (SAMA CSF Operations & Technology domain, application/infrastructure security subdomains) | Scan |
| `SA-SAMA-D2` Cyber Risk Identification | The cyber security risk management process must identify risks across information assets, which requires that assets and their components be unambiguously identifiable (SAMA CSF Domain 2, Cyber Security Risk Management and Compliance) | Scan |
| `SA-SAMA-DOC` Documented Security Baseline | Cyber security documentation must be maintained, current and traceable, which for software estates means identifiable, timestamped bills of materials (SAMA CSF governance and documentation requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | --------------------------------------------- |
| `SAMA-1.1` | Cyber Governance Framework Establishment |
| `SAMA-1.2` | Cybersecurity Strategy & Policy |
| `SAMA-2.1` | Cyber Risk Management Process |
| `SAMA-2.2` | Cyber Risk Register |
| `SAMA-3.1` | Security Operations & Monitoring |
| `SAMA-3.2` | Vulnerability & Patch Management |
| `SAMA-3.3` | Identity & Access Management |
| `SAMA-4.1` | Third-Party Cyber Risk Assessment |
| `SAMA-4.2` | Third-Party Contractual Security Requirements |
| `SAMA-4.4` | Third-Party Ongoing Monitoring |
## Policy templates
Written for SAMA CSF:
* SAMA CSF Cyber Governance Charter
* SAMA Third-Party Cybersecurity Management Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SAMA CSF.
# Senegal Law No. 2008-12 on Protection of Personal Data (/docs/frameworks/middle-east-and-africa/senegal-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SN PDPL |
| Region | Middle East & Africa |
| Country or scope | Senegal |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SN PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SN-PDPL-70` Security Obligation | The controller must take every useful precaution, given the nature of the data and the risks of processing, to preserve data security and prevent alteration, damage or unauthorised access, evidenced by integrity hashes on processing components (Law No. 2008-12, Art. 70 security obligation) | Scan |
| `SN-PDPL-DECL` Declaration of Processing | Processing of personal data requires prior declaration to or authorisation by the CDP, which presupposes an inventory of the software systems performing the processing (Law No. 2008-12, prior-formalities regime) | Scan |
| `SN-PDPL-PROC` Subcontractor Guarantees | Data processing entrusted to a subcontractor must be governed by contract and offer sufficient guarantees of security, so third-party software components must have named suppliers (Law No. 2008-12, subcontracting provisions) | Scan |
| `SN-PDPL-CONF` Confidentiality and Access Control | Only authorised persons may access personal data, which requires the components of processing systems to be uniquely identifiable so access paths can be controlled and audited (Law No. 2008-12, confidentiality obligations) | Scan |
| `SN-PDPL-DOC` Traceable Documentation | Demonstrating conformity to the CDP requires software records to be identifiable, timestamped documents (Law No. 2008-12, supervisory cooperation duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SN PDPL.
# Seychelles Data Protection Act 2003 (/docs/frameworks/middle-east-and-africa/seychelles-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SC DPA |
| Region | Middle East & Africa |
| Country or scope | Seychelles |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SC DPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SC-DPA-SEC` Security Principle | Appropriate security measures must be taken against unauthorized access to, or alteration, disclosure or destruction of, personal data, presuming integrity controls over the software that processes it (Data Protection Act 2003, security principle; carried forward in the Data Protection Act 2023) | Scan |
| `SC-DPA-REG` Registration of Data Users | Persons holding or processing personal data must register particulars of the data held and the purposes of processing, which presupposes an enumerated inventory of the processing systems and their components (Data Protection Act 2003, registration regime) | Scan |
| `SC-DPA-QUAL` Accuracy and Currency Principle | Personal data must be accurate and, where necessary, kept up to date; applied to the processing stack this requires each component to carry both a name and a version (Data Protection Act 2003, accuracy principle) | Scan |
| `SC-DPA-BUR` Third-Party Processing Accountability | Processing carried out by service bureaus or other third parties on behalf of a data user remains subject to the Act's security and registration duties, requiring third-party software suppliers to be identified (Data Protection Act 2003, third-party processing provisions) | Scan |
| `SC-DPA-DOC` Identifiable, Dated Records | Registration and supervisory oversight require dated, identifiable documentation of the data held and the systems processing it, satisfied by an SBOM with document ID and creation timestamp (Data Protection Act 2003, registration and oversight regime) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SC DPA.
# Sierra Leone Cyber Security and Crime Act 2021 (/docs/frameworks/middle-east-and-africa/sierra-leone-cyber)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SL Cyber Act |
| Region | Middle East & Africa |
| Country or scope | Sierra Leone |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SL Cyber Act
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `SL-CSC-CSIRT` Incident Response Readiness | The National Cybersecurity Coordination Centre coordinates incident response nationally, and cooperating with it requires an enumerable, named inventory of deployed software assets (Cybersecurity and Crime Act 2021, Part II, ss. 2-3) | Scan |
| `SL-CSC-CNII` Critical Infrastructure Integrity | Designated Critical National Information Infrastructure must be protected against compromise, evidenced by verifiable integrity hashes across the software components operating it (Cybersecurity and Crime Act 2021, Part III) | Scan |
| `SL-CSC-CNII-ID` Identifiable Infrastructure Components | Designating and protecting critical infrastructure presupposes that its software components are identifiable via standard identifiers (Cybersecurity and Crime Act 2021, Part III CNII provisions) | Scan |
| `SL-CSC-VULN` Vulnerability Management Readiness | Preventing the unauthorized access and system-interference offenses the Act criminalizes requires deployed components to carry concrete, known versions for vulnerability assessment and patching (Cybersecurity and Crime Act 2021, offense and CSIRT provisions) | Scan |
| `SL-CSC-EVID` Evidence-Grade Documentation | The Act's electronic-evidence procedures presuppose documented, uniquely identified and timestamped records of the software environment under investigation (Cybersecurity and Crime Act 2021, electronic-evidence provisions) | Scan |
| `SL-CSC-SUP` Supply-Chain Accountability for CNII | Protective measures for critical-infrastructure operators encompass knowing and vetting the sources of deployed software, requiring named suppliers for its components (Cybersecurity and Crime Act 2021, Part III protection directives) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SL Cyber Act.
# Malabo Convention (AU) - Sierra Leone (/docs/frameworks/middle-east-and-africa/sierra-leone-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SL Malabo |
| Region | Middle East & Africa |
| Country or scope | Sierra Leone |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SL Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SL-MAL-21` Security of Processing Systems | The data controller must take all appropriate precautions, given the nature of the data, to prevent it from being altered, destroyed, or accessed by unauthorized third parties; verifiable integrity hashes on the software components that process data evidence this safeguard (Malabo Convention Art. 21) | Scan |
| `SL-MAL-20` Confidentiality and Controlled Processing | Processing must remain confidential and be carried out only by parties acting under the controller's authority, which requires that the suppliers behind processing software are known and accountable (Malabo Convention Art. 20) | Scan |
| `SL-MAL-13A` Accuracy of Processing | Personal data undergoing processing must be accurate and kept up to date, which presumes each software component handling it is fully identified by both name and a concrete version (Malabo Convention Art. 13) | Scan |
| `SL-MAL-13T` Transparency Principle | Controllers are bound by a principle of transparent processing, which presupposes documented, uniquely identified and timestamped records of the processing environment (Malabo Convention Art. 13) | Scan |
| `SL-MAL-10` Processing Formalities and Records | Personal-data processing operations are subject to preliminary formalities before the national protection authority, requiring an enumerable, named record of the software performing the processing (Malabo Convention Art. 10) | Scan |
| `SL-MAL-23` Sustainability of Processing Systems | Controllers must ensure processing systems remain adequate and reliable as technology evolves; declared component versions are the basis for keeping systems current and supportable (Malabo Convention Art. 23) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SL Malabo.
# Somalia Data Protection Act 2023 (/docs/frameworks/middle-east-and-africa/somalia-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SO DPA 2023 |
| Region | Middle East & Africa |
| Country or scope | Somalia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SO DPA 2023
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SO-DPA-SEC` Data Security Measures | Controllers must implement security measures protecting personal data against unauthorized access, loss, or alteration; integrity hashes across processing components evidence those measures (DPA 2023, Data Security and Data Impact Assessments chapter) | Scan |
| `SO-DPA-BRE` Breach Notification Readiness | Data breaches must be reported to the Data Protection Authority, which requires that affected components are identifiable via standard identifiers to scope the breach quickly (DPA 2023, breach-notification obligations) | Scan |
| `SO-DPA-VEND` Vendor Management | Controllers are responsible for the vendors that process personal data on their behalf, so third-party software components must carry named, accountable suppliers (DPA 2023, vendor-management obligations) | Scan |
| `SO-DPA-REG` Registration and Records | Registration with the Data Protection Authority and cooperation duties presuppose an enumerable, named inventory of the software components performing processing (DPA 2023, Registration and Fees chapter) | Scan |
| `SO-DPA-PRIN` Accuracy of Processing | Processing principles require personal data to be accurate and up to date, presuming each processing component is fully identified by both name and a concrete version (DPA 2023, Principles Governing Processing of Personal Data chapter) | Scan |
| `SO-DPA-TRANS` Transparent Processing | Data subjects are owed transparent information about processing, presupposing documented, uniquely identified and timestamped records of the processing environment (DPA 2023, data-subject rights chapter) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SO DPA 2023.
# South Africa POPIA (/docs/frameworks/middle-east-and-africa/south-africa-popia)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Protection of Personal Information Act - eight conditions for lawful processing, IR, accountability.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | POPIA |
| Region | Middle East & Africa |
| Country or scope | South Africa |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers POPIA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for POPIA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for POPIA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ZA-POPIA-19` Security Safeguards | Responsible parties must secure the integrity and confidentiality of personal information through appropriate, reasonable technical and organizational measures; integrity hashes over the software inventory evidence such safeguards (POPIA s. 19) | Scan |
| `ZA-POPIA-21` Operator Security | Processing by an operator must be governed by a written contract obliging the operator to maintain the security safeguards, which requires knowing the suppliers behind the software in the processing chain (POPIA s. 21) | Scan |
| `ZA-POPIA-22` Breach Notification Readiness | Security compromises must be notified to the Information Regulator and affected data subjects as soon as reasonably possible; assessing a compromise quickly requires known versions across the software estate (POPIA s. 22) | Scan |
| `ZA-POPIA-17` Documentation of Processing Operations | Responsible parties must maintain documentation of all processing operations under their responsibility; an identified, timestamped SBOM of the processing systems contributes directly to that documentation (POPIA s. 17) | Scan |
| `ZA-POPIA-16` Information Quality | Reasonable steps must be taken to ensure personal information is complete, accurate and updated; the parallel discipline for the processing environment requires components carrying both name and version (POPIA s. 16) | Scan |
| `ZA-POPIA-IO` Information Officer Accountability | An information officer must encourage and ensure compliance with the conditions for lawful processing, providing a reachable accountability contact for the systems described in the SBOM (POPIA, information-officer duties) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------------- | ----------------------------------------------------------- |
| `POPIA-S8` | Accountability (Section 8) |
| `POPIA-S9` | Processing Limitation (Section 9) |
| `POPIA-S13` | Purpose Specification (Section 13) |
| `POPIA-S19` | Security Safeguards (Section 19) |
| `POPIA-S22` | Notification of Security Compromise (Section 22) |
| `POPIA-S23` | Data Subject Rights: Access and Correction (Sections 23-25) |
| `POPIA-XBORDER-1` | Cross-Border Transfer Conditions |
| `POPIA-IO-1` | Information Officer Registration and Duties |
## Policy templates
Written for POPIA:
* POPIA: Privacy Notice (PAIA Section 51 / POPIA)
* POPIA: Security Compromise Notification Procedure (Section 22)
* POPIA: Data Subject Rights Procedure (Sections 23-25)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to POPIA.
# Malabo Convention (AU) - South Sudan (/docs/frameworks/middle-east-and-africa/south-sudan-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SS Malabo |
| Region | Middle East & Africa |
| Country or scope | South Sudan |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SS Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SS-MAL-21` Security of Processing Systems | The data controller must take all appropriate precautions, given the nature of the data, to prevent it from being altered, destroyed, or accessed by unauthorized third parties; verifiable integrity hashes on the software components that process data evidence this safeguard (Malabo Convention Art. 21) | Scan |
| `SS-MAL-20` Confidentiality and Controlled Processing | Processing must remain confidential and be carried out only by parties acting under the controller's authority, which requires that the suppliers behind processing software are known and accountable (Malabo Convention Art. 20) | Scan |
| `SS-MAL-13A` Accuracy of Processing | Personal data undergoing processing must be accurate and kept up to date, which presumes each software component handling it is fully identified by both name and a concrete version (Malabo Convention Art. 13) | Scan |
| `SS-MAL-13T` Transparency Principle | Controllers are bound by a principle of transparent processing, which presupposes documented, uniquely identified and timestamped records of the processing environment (Malabo Convention Art. 13) | Scan |
| `SS-MAL-10` Processing Formalities and Records | Personal-data processing operations are subject to preliminary formalities before the national protection authority, requiring an enumerable, named record of the software performing the processing (Malabo Convention Art. 10) | Scan |
| `SS-MAL-23` Sustainability of Processing Systems | Controllers must ensure processing systems remain adequate and reliable as technology evolves; declared component versions are the basis for keeping systems current and supportable (Malabo Convention Art. 23) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SS Malabo.
# Malabo Convention (AU) - Sudan (/docs/frameworks/middle-east-and-africa/sudan-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SD Malabo |
| Region | Middle East & Africa |
| Country or scope | Sudan |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SD Malabo
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SD-MAL-21` Security of Processing Systems | The data controller must take all appropriate precautions, given the nature of the data, to prevent it from being altered, destroyed, or accessed by unauthorized third parties; verifiable integrity hashes on the software components that process data evidence this safeguard (Malabo Convention Art. 21) | Scan |
| `SD-MAL-20` Confidentiality and Controlled Processing | Processing must remain confidential and be carried out only by parties acting under the controller's authority, which requires that the suppliers behind processing software are known and accountable (Malabo Convention Art. 20) | Scan |
| `SD-MAL-13A` Accuracy of Processing | Personal data undergoing processing must be accurate and kept up to date, which presumes each software component handling it is fully identified by both name and a concrete version (Malabo Convention Art. 13) | Scan |
| `SD-MAL-13T` Transparency Principle | Controllers are bound by a principle of transparent processing, which presupposes documented, uniquely identified and timestamped records of the processing environment (Malabo Convention Art. 13) | Scan |
| `SD-MAL-10` Processing Formalities and Records | Personal-data processing operations are subject to preliminary formalities before the national protection authority, requiring an enumerable, named record of the software performing the processing (Malabo Convention Art. 10) | Scan |
| `SD-MAL-23` Sustainability of Processing Systems | Controllers must ensure processing systems remain adequate and reliable as technology evolves; declared component versions are the basis for keeping systems current and supportable (Malabo Convention Art. 23) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SD Malabo.
# Syria Cybercrime Law No. 20 of 2022 (/docs/frameworks/middle-east-and-africa/syria-cyber)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SY Cyber Law |
| Region | Middle East & Africa |
| Country or scope | Syria |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SY Cyber Law
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SY-CYB-4` Provider Data-Retention Readiness | Internet service providers must keep copies of traffic data and hosted digital content, which presupposes documented, uniquely identified and timestamped records of the hosting and processing software (Cybercrime Law No. 20 of 2022, Art. 4) | Scan |
| `SY-CYB-INT` Data and System Integrity | Offenses against the integrity of data and information systems oblige operators to maintain controls that detect tampering, evidenced by integrity hashes across deployed components (Cybercrime Law No. 20 of 2022, data- and system-integrity offenses) | Scan |
| `SY-CYB-INV` Software Asset Inventory | Meeting provider cooperation and retention duties requires an enumerable, named inventory of the software components operating the service (Cybercrime Law No. 20 of 2022, service-provider obligations) | Scan |
| `SY-CYB-VER` Known Component Versions | Preventing unauthorized access to networks and systems requires that deployed components carry concrete, known versions so vulnerabilities can be assessed and patched (Cybercrime Law No. 20 of 2022, unauthorized-access offenses) | Scan |
| `SY-CYB-ID` Identifiable System Components | Investigating and attributing offenses against information systems presupposes that system components are identifiable via standard identifiers (Cybercrime Law No. 20 of 2022, investigation and evidence provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SY Cyber Law.
# Syria National Privacy Framework (/docs/frameworks/middle-east-and-africa/syria-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SY Privacy |
| Region | Middle East & Africa |
| Country or scope | Syria |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SY Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SY-DP-SEC` Protection Against Unauthorized Access | Unauthorized access to and alteration of personal data are criminalized, so controllers need verifiable integrity of the components that store and process such data (Cybercrime Law No. 20 of 2022, unauthorized-access and data offenses) | Scan |
| `SY-DP-COLL` Lawful Collection Accountability | Because unapproved collection or dissemination of personal data is penalized, an organization must maintain a named inventory of every software component that collects or processes such data (Cybercrime Law No. 20 of 2022, data-collection offenses) | Scan |
| `SY-DP-ID` Identifiable Processing Components | Assessing exposure of private data requires that processing components are identifiable via standard identifiers (constitutional privacy guarantees, applied to incident assessment) | Scan |
| `SY-DP-CONST` Constitutional Privacy Documentation | The Constitution guarantees the privacy of private life and communications, and demonstrating respect for it presupposes documented, uniquely identified and timestamped records of the processing environment (Constitution of Syria 2012, privacy guarantees) | Scan |
| `SY-DP-PROC` Third-Party Processing Accountability | Data handled through third-party software must remain attributable to accountable, named suppliers to avoid unlawful disclosure (Cybercrime Law No. 20 of 2022, data-dissemination offenses) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SY Privacy.
# Tanzania Cybercrimes Act 2015 (/docs/frameworks/middle-east-and-africa/tanzania-cybercrimes)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TZ Cyber |
| Region | Middle East & Africa |
| Country or scope | Tanzania |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TZ Cyber
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TZ-CYBER-4` Defense Against Illegal Access | The Act criminalizes unauthorized access to computer systems; defending against and prosecuting such access requires organizations to precisely identify the software assets (PURL/CPE) that make up their systems (Cybercrimes Act 2015, s. 4) | Scan |
| `TZ-CYBER-7` Detection of Illegal Data Interference | Unlawful damaging, deletion, alteration or suppression of computer data is an offence; detecting and evidencing such interference requires integrity hashes for the components of the system (Cybercrimes Act 2015, s. 7) | Scan |
| `TZ-CYBER-9` System Interference Resilience | Serious hindering of a computer system's functioning is an offence; maintaining and restoring system integrity requires known versions for the software components in use (Cybercrimes Act 2015, s. 9) | Scan |
| `TZ-CYBER-CII` Critical Information Infrastructure Protection | The Act provides for the protection of critical information infrastructure, which presupposes that each protected system is named and its constituent components enumerated (Cybercrimes Act 2015, critical-information-infrastructure provisions) | Scan |
| `TZ-CYBER-SP` Service Provider Accountability | The Act defines liabilities and duties of service providers whose systems carry or host data, requiring the third-party suppliers of system software to be identified (Cybercrimes Act 2015, service-provider liability provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TZ Cyber.
# Tanzania Personal Data Protection Act 2022 (/docs/frameworks/middle-east-and-africa/tanzania-pdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TZ PDPA |
| Region | Middle East & Africa |
| Country or scope | Tanzania |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TZ PDPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TZ-PDPA-SEC` Security Safeguards for Processing | Controllers and processors must establish appropriate technical and organisational measures to protect personal data against loss, unlawful access and alteration, evidenced by integrity hashes on processing-system components (PDPA 2022, security-of-processing obligations) | Scan |
| `TZ-PDPA-REG` Registration and Processing Records | Mandatory registration of controllers and processors with the Commission presupposes an accurate inventory of the software systems used to process personal data (PDPA 2022, registration provisions, Part III) | Scan |
| `TZ-PDPA-PROC` Processor Engagement Controls | Processing on behalf of a controller must be governed by adequate guarantees, so third-party software components must have identifiable suppliers (PDPA 2022, controller-processor obligations) | Scan |
| `TZ-PDPA-BRN` Breach Notification Readiness | Personal data breaches must be notified to the Commission, which requires the components of affected systems to be identifiable so impact can be assessed (PDPA 2022, breach-notification duty) | Scan |
| `TZ-PDPA-DOC` Demonstrable Documentation | Accountability to the Personal Data Protection Commission requires software records to be identifiable, timestamped documents (PDPA 2022, accountability and compliance-demonstration duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TZ PDPA.
# Togo Law No. 2019-014 on Protection of Personal Data (/docs/frameworks/middle-east-and-africa/togo-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TG PDPL |
| Region | Middle East & Africa |
| Country or scope | Togo |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TG PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TG-PDPL-SEC` Security of Processing | Controllers must implement appropriate technical and organisational measures to protect personal data against destruction, loss, alteration and unauthorised access, evidenced by integrity hashes on processing components (Law No. 2019-014, security-of-processing obligations) | Scan |
| `TG-PDPL-DECL` Processing Formalities and Inventory | Processing is subject to formalities before the IPDCP, which presupposes an inventory of the software systems used to process personal data (Law No. 2019-014, prior-formalities and accountability provisions) | Scan |
| `TG-PDPL-PROC` Processor Guarantees | Processing on behalf of a controller must be governed by contract with sufficient security guarantees, so third-party software components must have named suppliers (Law No. 2019-014, controller-processor provisions) | Scan |
| `TG-PDPL-ID` Identifiable Components | Confidentiality duties and incident investigation require the components of processing systems to be uniquely identifiable via PURL or CPE (Law No. 2019-014, confidentiality and enforcement provisions) | Scan |
| `TG-PDPL-DOC` Traceable Documentation | Demonstrating conformity to the supervisory authority requires software records to be identifiable, timestamped documents (Law No. 2019-014, supervisory cooperation duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TG PDPL.
# Tunisia Organic Law No. 2004-63 on Personal Data (/docs/frameworks/middle-east-and-africa/tunisia-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TN PDPL |
| Region | Middle East & Africa |
| Country or scope | Tunisia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TN PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TN-PDPL-18` Security Precautions for Processing | The controller and its agents must take all necessary precautions to preserve the security of personal data and prevent third parties from modifying or damaging it, implying integrity controls over the processing environment (Organic Act 2004-63, Arts. 18-19) | Scan |
| `TN-PDPL-19` Integrity During Communication and Transport | Precautions must prevent data from being read, copied, modified, erased or deleted during communication or transport, which requires verifiable integrity (hashes) for the software components that handle the data (Organic Act 2004-63, Art. 19) | Scan |
| `TN-PDPL-23` Confidentiality Including Agents and Subcontractors | The controller, any processor and their agents must guarantee data confidentiality even after processing ends, requiring the third parties and suppliers involved in processing systems to be identified (Organic Act 2004-63, Art. 23) | Scan |
| `TN-PDPL-DECL` Prior Declaration to the INPDP | Processing operations require prior declaration to, or authorization from, the INPDP, which presupposes an inventory of the systems and software components that carry out the processing (Organic Act 2004-63, prior-declaration regime) | Scan |
| `TN-PDPL-DOC` Documented and Auditable Processing | INPDP oversight and the declaration regime require dated, identifiable documentation of processing systems, satisfied by an SBOM bearing a document ID and creation timestamp (Organic Act 2004-63, accountability to the INPDP) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TN PDPL.
# Turkey KVKK (/docs/frameworks/middle-east-and-africa/turkey-kvkk)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Turkey Personal Data Protection Law - VERBIS registration, lawful processing, data subject rights.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | KVKK |
| Region | Middle East & Africa |
| Country or scope | Turkey |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers KVKK
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for KVKK.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for KVKK and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TR-KVKK-12` Data Security Obligations | Controllers must take all necessary technical and organizational measures to prevent unlawful processing and ensure an appropriate security level; verifiable integrity across the software inventory evidences such measures (Law 6698 Art. 12) | Scan |
| `TR-KVKK-12-5` Breach Notification Readiness | If processed data is obtained by others unlawfully, the controller must notify the data subject and the Board without delay; rapid breach scoping requires known versions across the processing software (Law 6698 Art. 12(5)) | Scan |
| `TR-KVKK-16` VERBIS Registration | Data controllers must register with the Data Controllers' Registry (VERBIS) before processing, declaring identifying details of their processing; a uniquely identified, timestamped SBOM supports registry-grade documentation (Law 6698 Art. 16) | Scan |
| `TR-KVKK-4` General Principles Including Accuracy | Processing must be accurate, up to date where necessary, and limited to its purpose; applying the same discipline to the processing environment requires components with complete names and versions (Law 6698 Art. 4) | Scan |
| `TR-KVKK-9` Transfers Abroad Readiness | Personal data may be transferred abroad only with consent or under adequate-protection conditions approved by the Board; determining which systems transfer what requires precisely identifiable components (Law 6698 Art. 9) | Scan |
| `TR-KVKK-12-2` Joint Security Responsibility with Processors | Where data is processed on the controller's behalf, controller and processor are jointly responsible for the security measures, requiring visibility into the suppliers behind the processing software (Law 6698 Art. 12(2)) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | ---------------------------------------------------- |
| `KVKK-ART4` | Core Data Processing Principles (Art. 4) |
| `KVKK-ART5` | Lawful Basis for Processing Personal Data (Art. 5-6) |
| `KVKK-ART9` | Cross-Border Data Transfers (Art. 9) |
| `KVKK-ART10` | Obligation to Inform Data Subjects (Art. 10) |
| `KVKK-ART11` | Data Subject Rights (Art. 11) |
| `KVKK-ART12` | Data Security Obligations (Art. 12) |
| `KVKK-ART16` | VERBİS Registration (Art. 16) |
| `KVKK-DPIA-1` | Data Processing Impact Assessment |
## Policy templates
Written for KVKK:
* KVKK: Aydınlatma Metni / Illumination Text
* KVKK: Data Subject Application Procedure (Başvuru Prosedürü)
* KVKK: Data Breach Notification Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KVKK.
# UAE NESA IA Standards (/docs/frameworks/middle-east-and-africa/uae-nesa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
UAE National Electronic Security Authority Information Assurance standard - control families M1-T15.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NESA IA |
| Region | Middle East & Africa |
| Country or scope | United Arab Emirates |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NESA IA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for NESA IA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for NESA IA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AE-NESA-ASSET` Asset Inventory | Entities must identify and inventory their information assets, including the software composing critical systems; a populated component inventory is the direct SBOM expression (UAE IA Standards, asset-management control family) | Scan |
| `AE-NESA-ASSET-ID` Unique Asset Identification | Inventoried assets must be uniquely identified so ownership and protection responsibilities can be assigned; standard package identifiers on components satisfy this at SBOM level (UAE IA Standards, asset-management control family) | Scan |
| `AE-NESA-3P` Third-Party Security | Security requirements must be enforced across third-party and outsourcing relationships, which requires the supplier behind each software component to be recorded (UAE IA Standards, third-party security control family) | Scan |
| `AE-NESA-INT` System Acquisition and Integrity | Controls on acquisition, development and maintenance require assuring the integrity of system software; cryptographic hashes across deployed components evidence this (UAE IA Standards, systems acquisition/development/maintenance control family) | Scan |
| `AE-NESA-OPS` Operations Security and Patching | Operations security controls require managing technical vulnerabilities and applying updates, demonstrable only when component versions are recorded (UAE IA Standards, operations-management control family) | Scan |
| `AE-NESA-ISMS` Documented Security Management | The management control families require documented, maintained information security governance; an identified, timestamped SBOM document contributes to that documentation baseline (UAE IA Standards, management control families M1+) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | -------------------------------------- |
| `NESA-M1` | Information Security Governance (M1) |
| `NESA-M2` | Risk Management Framework (M2) |
| `NESA-M3` | Compliance and Legal Requirements (M3) |
| `NESA-T1` | Network Security Architecture (T1) |
| `NESA-T3` | Identity and Access Management (T3) |
| `NESA-T7` | Cryptographic Controls (T7) |
| `NESA-T10` | Vulnerability Management (T10) |
| `NESA-T13` | Incident Management (T13) |
## Policy templates
Written for NESA IA:
* UAE NESA: Information Assurance Standards Security Policy
* UAE NESA: Cyber Incident Notification Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NESA IA.
# UAE PDPL (/docs/frameworks/middle-east-and-africa/uae-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
UAE Federal Data Protection Law - data subject rights, controller and processor obligations.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Middle East & Africa |
| Country or scope | United Arab Emirates |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers UAE PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for UAE PDPL.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for UAE PDPL and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AE-PDPL-SEC` Security of Processing | Controllers and processors must apply appropriate technical and organizational measures to protect personal data against breach, alteration or loss; verifiable integrity of the software inventory evidences such measures (Federal Decree-Law 45/2021, security-of-processing obligation) | Scan |
| `AE-PDPL-ROPA` Records of Processing | Controllers and processors must maintain records of their processing activities available to the UAE Data Office; an enumerated inventory of the software components performing processing underpins such records (Federal Decree-Law 45/2021, record-of-processing obligation) | Scan |
| `AE-PDPL-PROC` Processor Engagement | Controllers must engage processors that provide sufficient guarantees and bind them by contract, which requires knowing the suppliers behind the software used in processing (Federal Decree-Law 45/2021, processor-obligations provision) | Scan |
| `AE-PDPL-BREACH` Breach Notification Readiness | Personal data breaches endangering privacy must be notified to the UAE Data Office; rapid impact assessment requires the versions of affected software to be known (Federal Decree-Law 45/2021, breach-notification obligation) | Scan |
| `AE-PDPL-XBORDER` Cross-Border Transfer Readiness | Transfers of personal data outside the UAE are permitted only under adequacy or appropriate safeguards; determining which systems transfer what requires precisely identifiable components (Federal Decree-Law 45/2021, cross-border transfer provisions) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ------------------------------------------------------------- |
| `PDPL-ART4` | Lawful Basis for Processing (Art. 4) |
| `PDPL-ART6` | Consent Requirements (Art. 6) |
| `PDPL-ART9` | Data Subject Rights: Access, Correction, Deletion (Art. 9-12) |
| `PDPL-ART22` | Data Breach Notification (Art. 22) |
| `PDPL-ART23` | Cross-Border Data Transfers (Art. 23) |
| `PDPL-ART24` | Controller and Processor Obligations (Art. 24) |
| `PDPL-SEC-1` | Technical and Organisational Security Measures |
| `PDPL-REG-1` | Registration with UAE Data Office |
## Policy templates
Written for UAE PDPL:
* UAE PDPL: Privacy Notice
* UAE PDPL: Cross-Border Data Transfer Policy
* UAE PDPL: Data Breach Notification Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to UAE PDPL.
# Uganda Data Protection and Privacy Act 2019 (/docs/frameworks/middle-east-and-africa/uganda-dppa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | UG DPPA |
| Region | Middle East & Africa |
| Country or scope | Uganda |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers UG DPPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `UG-DPPA-20` Security of Data | Controllers and processors must secure the integrity of personal data by adopting appropriate technical and organisational safeguards against loss, damage and unauthorised access, evidenced by integrity hashes on processing components (DPPA 2019, s. 20) | Scan |
| `UG-DPPA-BRN` Breach Notification Readiness | Unauthorised access to or acquisition of personal data must be notified to the Personal Data Protection Office, which requires affected components to be quickly identifiable (DPPA 2019, s. 23 breach notification) | Scan |
| `UG-DPPA-PROC` Processor Oversight | A data processor may only process on the controller's instructions under adequate safeguards, so third-party software components must have named suppliers (DPPA 2019, processor obligations, Part IV) | Scan |
| `UG-DPPA-REG` Registration and Accountability Records | Controllers must register with the Personal Data Protection Office and account for their processing, which presupposes an inventory of the software systems that process personal data (DPPA 2019, registration provisions and Regulations 2021) | Scan |
| `UG-DPPA-DOC` Demonstrable Documentation | Accountability to the regulator requires software records to be identifiable, timestamped documents whose creator is recorded (DPPA 2019, accountability principle, s. 3) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to UG DPPA.
# Yemen National Privacy Framework (/docs/frameworks/middle-east-and-africa/yemen-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | YE Privacy |
| Region | Middle East & Africa |
| Country or scope | Yemen |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers YE Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `YE-CONST-COMM` Sanctity of Communications | The Constitution guarantees the sanctity and confidentiality of correspondence and communications, requiring verifiable integrity of the software components that carry or process them (Constitution of Yemen, Arts. 52-53 communications-privacy guarantees) | Scan |
| `YE-TEL-CONF` Telecommunications Confidentiality | Confidentiality of communications must be ensured by service operators under the Telecommunications Law, so the software components they deploy must carry named, accountable suppliers (Yemen Telecommunications Law, confidentiality provisions) | Scan |
| `YE-DP-INV` Knowledge of Processing Assets | Protecting communications and personal information presupposes an enumerable, named inventory of the software components involved in handling it (constitutional privacy guarantees, applied to processing systems) | Scan |
| `YE-DP-ID` Breach-Impact Readiness | Assessing any compromise of private communications requires that the components handling them are identifiable via standard identifiers (constitutional privacy guarantees, applied to incident assessment) | Scan |
| `YE-DP-DOC` Documented Processing Environment | Demonstrating respect for privacy guarantees presupposes documented, uniquely identified and timestamped records of the processing environment (constitutional privacy guarantees, applied to documentation) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to YE Privacy.
# Zambia Cyber Security and Cyber Crimes Act 2021 (/docs/frameworks/middle-east-and-africa/zambia-cscca)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | ZM Cyber |
| Region | Middle East & Africa |
| Country or scope | Zambia |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers ZM Cyber
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `ZM-CSCCA-CII` Protection Measures for Critical Information Infrastructure | Operators of critical information infrastructure must apply prescribed protection and security measures, which presumes verifiable integrity of the software components running on those systems (Cyber Security and Cyber Crimes Act 2021, Part V) | Scan |
| `ZM-CSCCA-REG` Registration and Auditing of Critical Systems | Critical information systems are subject to registration and periodic audit, which requires an enumerated, auditable inventory of the software components they contain (Cyber Security and Cyber Crimes Act 2021, Part V) | Scan |
| `ZM-CSCCA-INC` Security Incident Reporting Readiness | Security incidents affecting critical information must be reported to the authority; assessing what was compromised requires precisely identifiable components (PURL/CPE) across the affected systems (Cyber Security and Cyber Crimes Act 2021, Part V incident-reporting obligation) | Scan |
| `ZM-CSCCA-VULN` Maintained, Patchable Software | Keeping critical systems resilient against cyber threats requires knowing the version of every software component so vulnerable software can be found and patched (Cyber Security and Cyber Crimes Act 2021, cybersecurity obligations) | Scan |
| `ZM-CSCCA-SUP` Service Provider and Supply-Chain Accountability | The Act imposes duties on service providers and controllers of critical information, including controlled localization and externalization, requiring the suppliers of system software to be identified and vetted (Cyber Security and Cyber Crimes Act 2021, Part V and service-provider obligations) | Scan |
| `ZM-CSCCA-AUD` Machine-Auditable System Records | Mandatory auditing of critical information systems is only practicable when system composition is documented in a standard machine-readable format such as SPDX or CycloneDX (Cyber Security and Cyber Crimes Act 2021, Part V audit obligation) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ZM Cyber.
# Zambia Data Protection Act No. 3 of 2021 (/docs/frameworks/middle-east-and-africa/zambia-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | ZM DPA |
| Region | Middle East & Africa |
| Country or scope | Zambia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers ZM DPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ZM-DPA-SEC` Security of Personal Data | Controllers and processors must secure personal data with appropriate technical and organisational measures against loss, unauthorised access and alteration, evidenced by integrity hashes on processing-system components (Data Protection Act No. 3 of 2021, security-of-processing obligations) | Scan |
| `ZM-DPA-REG` Registration and Processing Records | Data controllers and processors must register with the Data Protection Commissioner, which presupposes an accurate inventory of the software systems used for processing (Data Protection Act No. 3 of 2021, registration provisions) | Scan |
| `ZM-DPA-PROC` Processor Engagement Controls | Processing on a controller's behalf must occur under contract with sufficient security guarantees, so third-party software components must carry named suppliers (Data Protection Act No. 3 of 2021, controller-processor provisions) | Scan |
| `ZM-DPA-BRN` Breach Notification Readiness | Personal data breaches must be notified to the Commissioner, which requires the components of affected systems to be identifiable so impact can be assessed (Data Protection Act No. 3 of 2021, breach-notification duty) | Scan |
| `ZM-DPA-DOC` Demonstrable Documentation | Accountability to the Commissioner requires software records to be identifiable, timestamped documents whose creator is recorded (Data Protection Act No. 3 of 2021, accountability duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ZM DPA.
# Zimbabwe Cyber and Data Protection Act 2021 (/docs/frameworks/middle-east-and-africa/zimbabwe-cdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | ZW CDPA |
| Region | Middle East & Africa |
| Country or scope | Zimbabwe |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers ZW CDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ZW-CDPA-SEC` Security of Processing | Data controllers must take appropriate technical and organisational measures to protect data against accidental or unauthorised destruction, loss, access or alteration, evidenced by integrity hashes on processing components (Cyber and Data Protection Act 2021, security obligations, Part IV) | Scan |
| `ZW-CDPA-BRN` 24-Hour Breach Notification Readiness | Security breaches must be notified to the Data Protection Authority within 24 hours, a deadline that requires affected components to be immediately identifiable (Cyber and Data Protection Act 2021, breach-notification duty) | Scan |
| `ZW-CDPA-PROC` Processor Oversight | Controllers must ensure persons processing on their behalf act under contract and with sufficient security guarantees, so third-party software components must have named suppliers (Cyber and Data Protection Act 2021, controller-processor provisions) | Scan |
| `ZW-CDPA-INT` Tamper Detection for Computer Systems | Unauthorised interference with data and computer systems is criminalised, so operators should keep exact component versions to detect and investigate tampering (Cyber and Data Protection Act 2021, cybercrime offences, Part III) | Scan |
| `ZW-CDPA-INV` Processing System Inventory | Accountability to POTRAZ for all processing operations presupposes an inventory of the software systems that process personal data (Cyber and Data Protection Act 2021, accountability and licensing provisions) | Scan |
| `ZW-CDPA-DOC` Traceable Documentation | Demonstrating compliance to the Authority requires software records to be identifiable, timestamped documents (Cyber and Data Protection Act 2021, compliance-demonstration duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ZW CDPA.
# Integrations (/docs/esscm/integrations)
import { Check } from 'lucide-react';
# Integrations
Safeguard supports multiple integration types to generate SBOMs from various sources. Navigate to **Integrations** from the sidebar to connect your tools.
## Integrations Page Overview
The Integrations page includes tabs for different functions:
* **Add Project/Product** - Connect new integrations and add projects
* **Deployment** - Manage deployment configurations
* **Configure Scanner** - Set up scanner settings
* **Notification** - Configure alerts and notifications
You can filter integrations by type using the filter buttons: **All**, **Source Code (SCM)**, **Container Image**, **AI Model**, **Upload**, or **Reset**.
## Integration Types
### Source Code Management (SCM)
Generate SBOMs directly from your source code repositories. Supports both public and private repositories.
| Integration | Description | Public | Private |
| ----------------------------------------------------------- | ------------------------------ | --------------------------------------------------- | --------------------------------------------------- |
| [GitHub](/docs/esscm/integrations/source-code/github) | Connect GitHub repositories | | |
| [Bitbucket](/docs/esscm/integrations/source-code/bitbucket) | Connect Bitbucket repositories | | |
| [GitLab](/docs/esscm/integrations/source-code/gitlab) | Self-hosted or cloud GitLab | | |
| [Git](/docs/esscm/integrations/source-code/git) | Generic Git URL | | |
### Container Images
Scan container images from popular registries.
| Integration | Description | Public | Private |
| ------------------------------------------------------------------------------ | ------------------------------------ | --------------------------------------------------- | --------------------------------------------------- |
| [Amazon ECR](/docs/esscm/integrations/container-images/amazon-ecr) | AWS Elastic Container Registry | | |
| [Docker Hub](/docs/esscm/integrations/container-images/docker-hub) | Docker Hub repositories | | |
| [GCP Cloud Source](/docs/esscm/integrations/container-images/gcp-cloud-source) | Google Cloud container sources | | |
| [OCI Registry](/docs/esscm/integrations/container-images/oci-registry) | Open Container Initiative registries | | |
### AI Models
Scan AI and machine learning models for dependencies and vulnerabilities.
| Integration | Description |
| --------------------------------------------------------------- | -------------------------- |
| [Hugging Face](/docs/esscm/integrations/ai-models/hugging-face) | Connect and scan AI models |
### File Uploads
Upload files directly for SBOM generation.
| Integration | Description |
| --------------------------------------------------------------- | ----------------------------- |
| [CSAF/VEX](/docs/esscm/integrations/file-uploads/csaf-vex) | Upload CSAF or VEX files |
| [APK](/docs/esscm/integrations/file-uploads/apk) | Upload Android APK files |
| [Manifest File](/docs/esscm/integrations/file-uploads/manifest) | Upload package manifest files |
### VAPT Scans (CLI)
Run vulnerability assessment and penetration-testing scans from the Safeguard CLI
on infrastructure you own. Results upload to your console as projects.
| Scan | Description |
| -------------------------------------------------------------- | ---------------------------------------------------------------- |
| [Network Scan](/docs/esscm/integrations/vapt/network-scan) | Ports, services, versions, and known CVEs across a host or range |
| [Device Scan](/docs/esscm/integrations/vapt/device-scan) | LAN / IoT device discovery and exposure |
| [Wi-Fi Scan](/docs/esscm/integrations/vapt/wifi-scan) | Wireless posture — open, weak-encryption, rogue networks |
| [Active Directory Scan](/docs/esscm/integrations/vapt/ad-scan) | Read-only AD / LDAP identity posture |
| [OSINT](/docs/esscm/integrations/vapt/osint) | Public footprint and data-leak / breach exposure |
| [Cloud Scan](/docs/esscm/integrations/vapt/cloud-scan) | Cloud configuration posture (CSPM) for AWS / Azure / GCP |
## General Workflow
All integrations follow a similar workflow:
1. **Navigate to Integrations** - Access from the sidebar
2. **Select Integration Type** - Choose from SCM, Container Image, AI Model, or Upload
3. **Click Connect** - On the integration card
4. **Configure Access** - Enter credentials (for private) or URL (for public)
5. **Review & Connect** - Select repositories/images and configure project settings
6. **View in Projects** - Your connected projects appear in the Projects page
***
## Example: Adding a Bitbucket Repository
This example demonstrates how to connect a Bitbucket repository. The process differs slightly for public vs private repositories.
### Adding a Public Repository
#### Step 1: Click Connect on Bitbucket
From the Integrations page, click the **Connect** button on the Bitbucket card.
#### Step 2: Enter Repository Details
1. Select **Public** tab
2. Enter a **Name** for this configuration
3. Optionally add a **Description**
4. Enter the **public URL** of the repository (e.g., `https://bitbucket.org/atlassian/aui`)
5. The system will validate the URL and show "Repository URL is valid"
6. Click **Add** to add the URL to the list
#### Step 3: Review Added URLs
Your added repository URLs will appear in the **Added URLs** table showing the Repository URL and when it was added.
Click **Next** to proceed to the review step.
#### Step 4: Review & Configure Repositories
Review and configure the repositories to be connected:
* Select which repositories to include using checkboxes
* Configure **Branch/Tag** for each repository
* Set the **Project Name** (defaults to repository name)
* Set the **Version** (defaults to 1.0.0)
Click **Connect** to complete the integration.
#### Step 5: View Configuration
After connecting, your configuration appears in the **Project Configurations** table at the bottom of the Integrations page.
***
### Adding a Private Repository
For private repositories, you'll need to provide authentication credentials.
#### Step 1: Click Connect on Bitbucket
From the Integrations page, click the **Connect** button on the Bitbucket card.
#### Step 2: Enter Credentials
1. Select **Private** tab
2. Enter a **Name** for this configuration
3. Optionally add a **Description**
4. Enter your **Bitbucket Credentials**:
* **Username** - Your Bitbucket username
* **Access Token / App Password** - Your Bitbucket app password or access token
5. Click **Verify Credentials**
#### Step 3: Credentials Verified
Once credentials are verified successfully, you'll see "Credentials verified successfully!" message. Click **Next** to proceed.
#### Step 4: Select Workspace and Repositories
1. **Select Workspace** - Choose the Bitbucket workspace to access repositories from
2. **Review & Configure Repositories** - Select repositories, configure branch/tag, project name, and version
Click **Connect** to complete the integration.
#### Step 5: View All Configurations
Your new configuration will appear alongside any existing configurations in the **Project Configurations** table.
***
## Generation Options
| Option | Description |
| ---------------------------- | ----------------------------------------- |
| **Project Name** | Identifier for this SBOM |
| **Version** | Version tag (auto-detected from git tags) |
| **Branch/Tag** | Specific branch or tag to scan |
| **Include Dev Dependencies** | Include development dependencies |
| **Deep Analysis** | Enable Griffin AI deep analysis |
## Generation Times
| Project Size | Approximate Time |
| ------------------------------ | ---------------- |
| Small (under 100 dependencies) | Under 1 minute |
| Medium (100-500 dependencies) | 2-5 minutes |
| Large (500+ dependencies) | 5-15 minutes |
## Project Configurations
After connecting integrations, your configurations are saved in the **Project Configurations** table at the bottom of the Integrations page. This allows you to:
* View all connected integrations
* See provider type and connection details
* Track when configurations were created and updated
* Manage and edit existing connections
## Viewing Your Projects
After adding integrations, navigate to **Projects** from the sidebar to see all your added projects. The Projects table displays:
| Column | Description |
| ------------------- | ------------------------------------------- |
| **Project Name** | Name of the project (click to view details) |
| **Version** | Version tag or branch |
| **Status** | Active or inactive status |
| **Organizations** | Organization assignment |
| **Findings** | Summary counts (E, C, H, M, L) |
| **Vulnerabilities** | Vulnerability count |
## Continuous Scanning
Safeguard performs daily continuous scanning of all your projects to detect new vulnerabilities as they are disclosed.
Enable additional scanning triggers:
* **On Push** - Scan on every commit to monitored branches
* **Scheduled** - Daily, weekly, or custom schedule
* **On Release** - Scan when new tags are created
## CLI Usage
```bash
# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash
# Open the terminal, then type /login and /scan .
safeguard
# Or scan from the command line, writing results under ./output
safeguard scan --dir .
```
A scan from the interactive terminal while signed in uploads the SBOM and
findings to the platform; your source never leaves the machine.
[Full CLI documentation](/docs/cli/usage)
# Aland Finnish Data Protection Act (/docs/frameworks/europe/aland-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AX DP Act |
| Region | Europe |
| Country or scope | Aland |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AX DP Act
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AX-GDPR-32` Security of Processing | Controllers and processors must implement technical measures ensuring ongoing integrity of processing systems, including the ability to verify components against tampering via integrity hashes (GDPR Art. 32; Data Protection Act 1050/2018). | Scan |
| `AX-GDPR-30` Records of Processing Activities | Maintaining records of processing activities presupposes an inventory of the software components that carry out the processing (GDPR Art. 30). | Scan |
| `AX-GDPR-28` Processor Guarantees | Processing may only be entrusted to processors providing sufficient guarantees, so third-party components must have named, accountable suppliers (GDPR Art. 28). | Scan |
| `AX-GDPR-5F` Integrity and Confidentiality Principle | The integrity-and-confidentiality principle requires knowing precisely which components handle personal data, so components should carry standard identifiers such as PURL or CPE (GDPR Art. 5(1)(f)). | Scan |
| `AX-GDPR-33` Breach-Notification Readiness | Notifying the supervisory authority within 72 hours of a breach presupposes knowing the exact versions of the software processing personal data so impact can be assessed quickly (GDPR Arts. 33-34). | Scan |
| `AX-GDPR-5-2` Demonstrable Accountability | The accountability principle requires being able to demonstrate compliance, which calls for dated, identifiable documentation of the systems used to process personal data (GDPR Art. 5(2)). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AX DP Act.
# Albania Law No. 9887 on Protection of Personal Data (/docs/frameworks/europe/albania-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AL L9887 |
| Region | Europe |
| Country or scope | Albania |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AL L9887
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AL-9887-27` Security of Personal Data | Controllers must take organizational and technical measures to protect personal data from accidental or unlawful destruction, loss and unauthorized access or alteration; component integrity hashes evidence protection against tampering (Law 9887 Art. 27) | Scan |
| `AL-9887-PROC` Processing by Processors | Processing carried out on the controller's behalf must rest on a contract obliging the processor to equivalent security, requiring the controller to know the suppliers behind its processing software (Law 9887 processor provisions) | Scan |
| `AL-9887-NOT` Notification of Processing | Controllers must notify the Commissioner of the processing they perform, which presupposes maintaining an inventory of the software systems and components that process personal data (Law 9887 notification provisions) | Scan |
| `AL-9887-VER` Maintained Security Level | The required security level must be maintained against evolving risks, which requires knowing exact versions of deployed components so weaknesses can be assessed and remediated (Law 9887 Art. 27 ongoing-security duty) | Scan |
| `AL-9887-DOC` Documented Safeguards | Controllers must be able to document the protective measures applied to processing systems, supported by a formally identified, timestamped software record (Law 9887 documentation duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AL L9887.
# Andorra Qualified Law 29/2021 on Personal Data Protection (/docs/frameworks/europe/andorra-lqpd)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AD LQPD |
| Region | Europe |
| Country or scope | Andorra |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AD LQPD
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AD-LQPD-SEC` Security of Processing | Controllers and processors must implement technical measures appropriate to the risk, ensuring confidentiality, integrity and resilience of processing systems; integrity hashes on software components evidence this control (Law 29/2021 GDPR Art. 32-equivalent security obligation) | Scan |
| `AD-LQPD-ROP` Records of Processing Activities | Controllers and processors must maintain records of their processing activities, which presupposes an inventory of the software systems and components performing the processing (Law 29/2021 GDPR Art. 30-equivalent records obligation) | Scan |
| `AD-LQPD-PROC` Processor Guarantees | Processing may be entrusted only to processors offering sufficient guarantees of appropriate safeguards, requiring visibility into who supplies the software components used for processing (Law 29/2021 GDPR Art. 28-equivalent processor obligation) | Scan |
| `AD-LQPD-BRE` Breach Notification Readiness | Personal data breaches must be notified to the APDA within 72 hours, requiring the ability to identify precisely which software components were affected (Law 29/2021 GDPR Art. 33-equivalent breach obligation) | Scan |
| `AD-LQPD-DOC` Demonstrable Accountability | Controllers must be able to demonstrate compliance with their protection duties, supported by a formally identified, timestamped record of the software processing personal data (Law 29/2021 accountability principle) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AD LQPD.
# Armenia Law on Protection of Personal Data (/docs/frameworks/europe/armenia-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AM PDPL |
| Region | Europe |
| Country or scope | Armenia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AM PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AM-PDPL-19` Ensuring Security of Personal Data | Processors must use encryption and other technical measures to protect personal data against unlawful access, destruction and alteration; cryptographic integrity hashes on software components evidence this safeguard (HO-49-N Art. 19 security obligation) | Scan |
| `AM-PDPL-AUTH` Processing by Authorized Persons | Entrusting processing to another person requires an agreement obliging equivalent protection measures, which requires knowing the suppliers behind the software performing processing (HO-49-N authorized-person provisions) | Scan |
| `AM-PDPL-INV` Knowledge of Processing Systems | The duty to organize and control lawful processing presupposes an inventory of the software systems and components that process personal data (HO-49-N processor obligations) | Scan |
| `AM-PDPL-VER` Maintained Security Level | Security measures must remain effective against current threats, which requires knowing the exact versions of deployed components so weaknesses can be assessed and fixed (HO-49-N Art. 19 ongoing-security duty) | Scan |
| `AM-PDPL-DOC` Documented Protection Measures | Processors must be able to demonstrate the protective measures applied to processing systems, supported by a formally identified, timestamped software record (HO-49-N accountability duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AM PDPL.
# Austria Data Protection Act (DSG) (/docs/frameworks/europe/austria-dsg)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AT DSG |
| Region | Europe |
| Country or scope | Austria |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AT DSG
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AT-DSG-54` Data Security Measures | Controllers and processors must take technical and organisational data-security measures proportionate to the protection needs of the data; verifiable integrity hashes on deployed software components evidence this control (DSG § 54 (law-enforcement chapter); GDPR Art. 32 for general processing). | Scan |
| `AT-DSG-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Datenschutzgesetz (DSG)). | Scan |
| `AT-DSG-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Datenschutzgesetz (DSG)). | Scan |
| `AT-DSG-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Datenschutzgesetz (DSG)). | Scan |
| `AT-DSG-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Datenschutzgesetz (DSG)). | Scan |
| `AT-DSG-A24` Accountability of the Controller | Responsibility for processing operations must be demonstrable, which includes documented provenance of who produced the record of the software estate that processes personal data (GDPR Art. 24 and Art. 5(2); the Datenschutzgesetz (DSG)). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AT DSG.
# Azerbaijan Law on Personal Data (/docs/frameworks/europe/azerbaijan-pdl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AZ PDL |
| Region | Europe |
| Country or scope | Azerbaijan |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AZ PDL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AZ-PDL-SEC` Protection of Personal Data | Owners and operators of personal data information systems must take organizational and technical measures to protect data from unlawful access, alteration and destruction; component integrity hashes evidence tamper protection (Law 998-IIIQ protection obligations) | Scan |
| `AZ-PDL-REG` Registration of Information Systems | Personal data information systems are subject to state registration, which presupposes that the system is named and its software composition enumerated (Law 998-IIIQ state-registration provisions) | Scan |
| `AZ-PDL-INV` Information System Composition | Operating a compliant personal data information system requires knowing the software components it comprises so that protection duties can be applied to each of them (Law 998-IIIQ operator obligations) | Scan |
| `AZ-PDL-THIRD` Third-Party Processing Accountability | Where third parties participate in processing or supply system elements, the operator remains responsible for protection, requiring visibility into the suppliers behind the software in use (Law 998-IIIQ third-party provisions) | Scan |
| `AZ-PDL-VER` Maintained System Security | Protection measures must remain adequate throughout the system's operation, which requires knowing exact versions of deployed components so weaknesses can be assessed (Law 998-IIIQ ongoing-protection duty) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AZ PDL.
# Belarus Law No. 99-Z on Personal Data Protection (/docs/frameworks/europe/belarus-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BY 99-Z |
| Region | Europe |
| Country or scope | Belarus |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BY 99-Z
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BY-99Z-17` Technical and Cryptographic Protection Measures | Operators must apply technical and cryptographic measures to protect personal data against unauthorized access and modification; cryptographic integrity hashes on software components evidence this safeguard (Law 99-Z Art. 17) | Scan |
| `BY-99Z-17-DOC` Documented Processing Policies | Operators must adopt and publish documents defining their personal data processing policy; a formally identified, timestamped software inventory supports documented processing (Law 99-Z Art. 17 documentation duties) | Scan |
| `BY-99Z-7` Authorized Person Processing | Processing performed by an authorized person on the operator's behalf must be governed by an agreement ensuring equivalent protection, requiring the operator to know the suppliers of the software it relies on (Law 99-Z authorized-person provisions) | Scan |
| `BY-99Z-INV` Processing System Inventory | The operator's duty to organize and control processing presupposes knowing which software systems and components process personal data (Law 99-Z operator obligations) | Scan |
| `BY-99Z-BREACH` Breach Notification Readiness | Operators must notify the National Personal Data Protection Center of data protection breaches within three working days, which requires rapidly identifying the affected components and their versions (Law 99-Z breach-notification obligation) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BY 99-Z.
# Belgium Data Protection Act 2018 (/docs/frameworks/europe/belgium-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BE DPA |
| Region | Europe |
| Country or scope | Belgium |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BE DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BE-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Belgium by the Law of 30 July 2018). | Scan |
| `BE-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Law of 30 July 2018). | Scan |
| `BE-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Law of 30 July 2018). | Scan |
| `BE-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Law of 30 July 2018). | Scan |
| `BE-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Law of 30 July 2018). | Scan |
| `BE-DPA-A25` Data Protection by Design | Data-protection safeguards must be built into processing systems at design time; pinning components to specific, unambiguous versions rather than floating ranges is a baseline design-time control (GDPR Art. 25; the Law of 30 July 2018). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BE DPA.
# Bosnia and Herzegovina Law on Protection of Personal Data (/docs/frameworks/europe/bosnia-lpdp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BA LPDP |
| Region | Europe |
| Country or scope | Bosnia and Herzegovina |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BA LPDP
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BA-LPDP-11` Data Security Measures | Controllers and processors must undertake measures against accidental or unauthorized destruction, alteration and access to personal data; verifiable integrity hashes on processing components evidence tamper protection (BiH LPDP Art. 11 data-security obligation) | Scan |
| `BA-LPDP-PLAN` Data Security Plan | Controllers must adopt a security plan describing the technical measures protecting personal data, supported by a formally identified, timestamped record of the software in scope (BiH LPDP security-plan obligation) | Scan |
| `BA-LPDP-REC` Records of Data Filing Systems | Controllers must establish and maintain records of the personal data filing systems they keep, which presupposes an inventory of the software components operating those systems (BiH LPDP records provisions) | Scan |
| `BA-LPDP-PROC` Processing on Behalf of Controllers | Entrusting processing to a processor requires a contract guaranteeing equivalent protection measures, which requires knowing the suppliers behind the processing software (BiH LPDP processor provisions) | Scan |
| `BA-LPDP-VER` Maintained Protection Level | Security measures must remain adequate over time, which requires knowing exact component versions so that weaknesses in deployed software can be assessed (BiH LPDP Art. 11 ongoing-security duty) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BA LPDP.
# BSI IT-Grundschutz (/docs/frameworks/europe/bsi-grundschutz)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
BSI Standard 200-1/2/3 + Compendium - baseline, standard, high protection requirements.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Grundschutz |
| Region | Europe |
| Country or scope | Germany |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Grundschutz
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for Grundschutz.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for Grundschutz and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `DE-BSI-200-2-SA` Structure Analysis Inventory | The Grundschutz methodology begins with a structure analysis capturing all applications, IT systems and their dependencies, so every software component must be inventoried (BSI-Standard 200-2, structure analysis phase) | Scan |
| `DE-BSI-200-3-ID` Risk Analysis Target Objects | Risk analysis requires unambiguously identified target objects so threats can be mapped to them, which means components need machine-resolvable identifiers (BSI-Standard 200-3) | Scan |
| `DE-BSI-OPS113` Patch and Change Management | Patch and change management requires knowing the exact version of every deployed software component so updates and security patches can be planned and verified (IT-Grundschutz Compendium module OPS.1.1.3 Patch- und Änderungsmanagement) | Scan |
| `DE-BSI-CON8` Secure Software Development Sourcing | Secure development requires that third-party and open-source components are obtained from trustworthy sources and their integrity verified, evidenced by cryptographic hashes (IT-Grundschutz Compendium module CON.8 Software-Entwicklung) | Scan |
| `DE-BSI-APP6` Software Approval and Documentation | General software use requires an approval process and documented software inventory, so components must be fully described with both name and version (IT-Grundschutz Compendium module APP.6 Allgemeine Software) | Scan |
| `DE-BSI-OPS2-OUT` Outsourcing and Supplier Control | When IT operation or development is outsourced, the responsible organisation must retain oversight of suppliers, which requires the supplier of each software component to be named (IT-Grundschutz Compendium outsourcing modules, OPS.2.x) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------------ | ------------------------------------------------------- |
| `BSI-200-1-ISMS` | Information Security Management System (Standard 200-1) |
| `BSI-200-2-Methodology` | IT-Grundschutz Methodology (Standard 200-2) |
| `BSI-200-3-RiskAnalysis` | Risk Analysis (Standard 200-3) |
| `BSI-ISMS-Module` | ISMS Compendium Module |
| `BSI-ORP-Module` | Organisation and Personnel (ORP Module) |
| `BSI-CON-Module` | Concepts and Procedures (CON Module) |
| `BSI-OPS-Module` | Operations (OPS Module) |
| `BSI-NET-Module` | Networks and Communications (NET Module) |
| `BSI-SYS-Module` | IT Systems (SYS Module) |
| `BSI-APP-Module` | Applications (APP Module) |
| `BSI-IND-Module` | Industrial IT (IND Module) |
| `BSI-ProtectionNeeds` | Protection Needs Assessment |
## Policy templates
Written for Grundschutz:
* BSI Grundschutz Information Security Manual
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Grundschutz.
# BSI TR-03183-2 (/docs/frameworks/europe/bsi-tr)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
German Federal Office for Information Security SBOM requirements.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | BSI TR |
| Region | Europe |
| Country or scope | Germany |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers BSI TR
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for BSI TR.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for BSI TR and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `DE-TR03183-FMT` Machine-Readable SBOM Format | The SBOM must be provided in a standardised, machine-processable format such as SPDX or CycloneDX (BSI TR-03183-2, format requirements) | Scan |
| `DE-TR03183-DOC` SBOM Document Metadata | Each SBOM must carry document-level data including a timestamp of creation, enabling versioning and audit of the SBOM itself (BSI TR-03183-2, SBOM-level required fields) | Scan |
| `DE-TR03183-CRE` SBOM Creator Recorded | The creator of the SBOM (tool and/or organisation) must be recorded as a required document field (BSI TR-03183-2, SBOM creator field) | Scan |
| `DE-TR03183-VER` Component Version Required | Every component entry must state the exact version of the component (BSI TR-03183-2, per-component required fields) | Scan |
| `DE-TR03183-HASH` Component Integrity Hash | Components must carry a cryptographic hash of their executable/distributed form so integrity can be verified (BSI TR-03183-2, hash value field) | Scan |
| `DE-TR03183-LIC` Component Licence Information | Licence information must be provided for components so legal obligations attached to the software can be assessed (BSI TR-03183-2, licence field) | Scan |
| `DE-TR03183-DEP` Dependency Relationships | The SBOM must express the dependency relationships between components, not just a flat list (BSI TR-03183-2, dependency documentation) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | -------------------------------------------------------- |
| `BSI-TR2-1` | Include Minimum SBOM Data Fields Per TR-03183-2 §3 |
| `BSI-TR2-2` | Provide Complete Dependency Relationships in SBOM §3.2 |
| `BSI-TR2-3` | Ensure SBOM Integrity with Cryptographic Signatures §3.3 |
| `BSI-TR2-4` | Achieve SBOM Completeness as Per §3.4 |
| `BSI-TR2-5` | Maintain Transparency of Third-Party Components §4 |
| `BSI-TR2-6` | Correlate SBOM with CVE/NVD and BSI Advisories §5 |
| `BSI-TR2-7` | Implement SBOM Lifecycle Management §6 |
| `BSI-TR2-8` | Produce SBOM in CycloneDX or SPDX Format |
| `BSI-TR2-9` | Provide SBOM to BSI on Request |
| `BSI-TR2-10` | Define SBOM Roles and Responsibilities |
## Policy templates
Written for BSI TR:
* BSI TR-03183-2 SBOM Compliance Policy
* BSI TR-03183-2 Third-Party Component Transparency Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BSI TR.
# Bulgaria Personal Data Protection Act (/docs/frameworks/europe/bulgaria-pdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BG PDPA |
| Region | Europe |
| Country or scope | Bulgaria |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BG PDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BG-PDPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Bulgaria by the Personal Data Protection Act (as amended SG No. 17/2019)). | Scan |
| `BG-PDPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Personal Data Protection Act (as amended SG No. 17/2019)). | Scan |
| `BG-PDPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Personal Data Protection Act (as amended SG No. 17/2019)). | Scan |
| `BG-PDPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Personal Data Protection Act (as amended SG No. 17/2019)). | Scan |
| `BG-PDPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Personal Data Protection Act (as amended SG No. 17/2019)). | Scan |
| `BG-PDPA-A24` Accountability of the Controller | Responsibility for processing operations must be demonstrable, which includes documented provenance of who produced the record of the software estate that processes personal data (GDPR Art. 24 and Art. 5(2); the Personal Data Protection Act (as amended SG No. 17/2019)). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BG PDPA.
# Croatia Act on Implementation of the GDPR 2018 (/docs/frameworks/europe/croatia-gdpr-act)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | HR GDPR |
| Region | Europe |
| Country or scope | Croatia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers HR GDPR
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `HR-GDPR-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Croatia by the Act on the Implementation of the GDPR (OG 42/2018)). | Scan |
| `HR-GDPR-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Act on the Implementation of the GDPR (OG 42/2018)). | Scan |
| `HR-GDPR-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Act on the Implementation of the GDPR (OG 42/2018)). | Scan |
| `HR-GDPR-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Act on the Implementation of the GDPR (OG 42/2018)). | Scan |
| `HR-GDPR-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Act on the Implementation of the GDPR (OG 42/2018)). | Scan |
| `HR-GDPR-A25` Data Protection by Design | Data-protection safeguards must be built into processing systems at design time; pinning components to specific, unambiguous versions rather than floating ranges is a baseline design-time control (GDPR Art. 25; the Act on the Implementation of the GDPR (OG 42/2018)). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to HR GDPR.
# Cyprus Law 125(I)/2018 (/docs/frameworks/europe/cyprus-law125)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CY L125 |
| Region | Europe |
| Country or scope | Cyprus |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CY L125
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CY-L125-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Cyprus by Law 125(I)/2018). | Scan |
| `CY-L125-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside Law 125(I)/2018). | Scan |
| `CY-L125-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; Law 125(I)/2018). | Scan |
| `CY-L125-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; Law 125(I)/2018). | Scan |
| `CY-L125-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; Law 125(I)/2018). | Scan |
| `CY-L125-A25` Data Protection by Design | Data-protection safeguards must be built into processing systems at design time; pinning components to specific, unambiguous versions rather than floating ranges is a baseline design-time control (GDPR Art. 25; Law 125(I)/2018). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CY L125.
# Czechia Act No. 110/2019 on Personal Data Processing (/docs/frameworks/europe/czechia-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | CZ DPA |
| Region | Europe |
| Country or scope | Czechia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers CZ DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `CZ-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Czechia by Act No. 110/2019 Coll.). | Scan |
| `CZ-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside Act No. 110/2019 Coll.). | Scan |
| `CZ-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; Act No. 110/2019 Coll.). | Scan |
| `CZ-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; Act No. 110/2019 Coll.). | Scan |
| `CZ-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; Act No. 110/2019 Coll.). | Scan |
| `CZ-DPA-A24` Demonstrable Compliance | The controller is responsible for, and must be able to demonstrate, compliance of its processing; a machine-readable software inventory (SPDX or CycloneDX) supports demonstrable accountability (GDPR Art. 24 and Art. 5(2); Act No. 110/2019 Coll.). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CZ DPA.
# Denmark Data Protection Act 2018 (/docs/frameworks/europe/denmark-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | DK DPA |
| Region | Europe |
| Country or scope | Denmark |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers DK DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `DK-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Denmark by the Data Protection Act (Act No. 502 of 23 May 2018)). | Scan |
| `DK-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Data Protection Act (Act No. 502 of 23 May 2018)). | Scan |
| `DK-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Data Protection Act (Act No. 502 of 23 May 2018)). | Scan |
| `DK-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Data Protection Act (Act No. 502 of 23 May 2018)). | Scan |
| `DK-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Data Protection Act (Act No. 502 of 23 May 2018)). | Scan |
| `DK-DPA-A25` Data Protection by Design | Data-protection safeguards must be built into processing systems at design time; pinning components to specific, unambiguous versions rather than floating ranges is a baseline design-time control (GDPR Art. 25; the Data Protection Act (Act No. 502 of 23 May 2018)). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DK DPA.
# EU DORA (/docs/frameworks/europe/dora)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Digital Operational Resilience Act: ICT third-party risk, supply chain resilience, operational continuity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | DORA |
| Region | Europe |
| Country or scope | European Union |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers DORA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 13 controls from Safeguard's control catalog for DORA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for DORA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `EU-DORA-8` ICT Asset Identification | Financial entities must identify, classify and document all ICT-supported business functions and the ICT assets underpinning them, which includes the software components of critical systems (DORA Art. 8) | Scan |
| `EU-DORA-8V` Asset Records with Versions | Identification of ICT assets must be kept up to date and support risk assessment, requiring recorded versions for the software components in scope (DORA Art. 8(1),(4)) | Scan |
| `EU-DORA-9` Protection and Integrity of ICT Systems | Entities must protect the integrity and security of ICT systems with sound policies and tools, including means to verify that deployed software components are authentic and unmodified (DORA Art. 9) | Scan |
| `EU-DORA-28` Third-Party Provider Register | Entities must manage ICT third-party risk and maintain a register of information on all contractual arrangements with ICT providers, requiring supplier attribution for the software they depend on (DORA Art. 28) | Scan |
| `EU-DORA-17` Incident Classification Readiness | ICT-related incidents must be detected, managed and classified for reporting, which requires the ability to pinpoint affected software components against advisories (DORA Arts. 17-19) | Scan |
| `EU-DORA-DOC` Auditable Resilience Documentation | The ICT risk management framework must be documented and reviewed, with evidence artefacts that are identifiable and dated (DORA Art. 6, documentation and review of the framework) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ------------------------------------------------------ |
| `DORA-ART5` | Establish ICT Risk Management Framework |
| `DORA-ART6` | Maintain ICT Asset Register |
| `DORA-ART8` | Implement ICT Security Policies and Procedures |
| `DORA-ART9` | Implement ICT Business Continuity Management |
| `DORA-ART10` | Conduct ICT Testing and Vulnerability Assessments |
| `DORA-ART11` | Implement ICT-Related Incident Management Process |
| `DORA-ART12` | Classify and Report Major ICT-Related Incidents |
| `DORA-ART17` | Establish Major Incident Notification Procedure |
| `DORA-ART28` | Implement ICT Third-Party Risk Management Policy |
| `DORA-ART29` | Conduct Pre-Contractual Due Diligence on ICT Providers |
| `DORA-ART30` | Include Mandatory Provisions in ICT Provider Contracts |
| `DORA-ART18` | Perform Threat-Led Penetration Testing (TLPT) |
| `DORA-REGISTER` | Maintain Register of ICT Third-Party Service Providers |
## Policy templates
Written for DORA:
* DORA ICT Risk Management Policy
* DORA ICT Third-Party Risk Management Policy
* DORA ICT Incident Management and Reporting Policy
* DORA Digital Operational Resilience Testing Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DORA.
# ENISA Good Practices (/docs/frameworks/europe/enisa-guidelines)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
EU Agency for Cybersecurity SBOM practices: machine-readable SBOM, component inventory.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ENISA |
| Region | Europe |
| Country or scope | European Union |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ENISA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for ENISA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for ENISA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ENISA-GP-SBOM` Machine-Readable SBOM | Organisations should produce and consume SBOMs in standard machine-readable formats to enable automated supply-chain risk analysis (ENISA Good Practices for Supply Chain Cybersecurity - SBOM recommendations) | Scan |
| `ENISA-GP-INV` Component Inventory | Suppliers and customers should maintain an inventory of the software components in their products and estates as the foundation of supply-chain risk management (ENISA supply chain guidance - asset and component inventory) | Scan |
| `ENISA-GP-DEP` Dependency Visibility | Understanding transitive exposure requires documenting the dependency relationships between components, not only listing them (ENISA supply chain guidance - dependency transparency) | Scan |
| `ENISA-GP-SUP` Supplier Identification | Supply-chain risk assessment requires knowing which supplier stands behind each component so supplier assurance practices can be applied (ENISA Good Practices - supplier relationship management) | Scan |
| `ENISA-GP-VULN` Vulnerability Correlation Data | SBOM-driven vulnerability management requires component versions and standard identifiers so advisories can be matched automatically (ENISA guidance on SBOM-based vulnerability management) | Scan |
| `ENISA-GP-PROV` SBOM Provenance | SBOMs used as assurance evidence should record who generated them and when, so consumers can judge freshness and trustworthiness (ENISA supply chain guidance - SBOM quality attributes) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ---------------------------------------------------- |
| `ENISA-SBOM-1` | Produce Machine-Readable SBOM in Approved Format |
| `ENISA-SBOM-2` | Achieve SBOM Completeness for All Components |
| `ENISA-SBOM-3` | Include Package URLs (PURLs) in SBOM |
| `ENISA-SBOM-4` | Include Cryptographic Hashes for SBOM Integrity |
| `ENISA-SBOM-5` | Correlate SBOM with Vulnerability Databases |
| `ENISA-SBOM-6` | Include Licence Information for All Components |
| `ENISA-SBOM-7` | Maintain SBOM Provenance and Authorship Metadata |
| `ENISA-SBOM-8` | Integrate SBOM into CI/CD Pipeline |
| `ENISA-SBOM-9` | Share SBOMs with Downstream Customers and Regulators |
| `ENISA-SBOM-10` | Define SBOM Governance and Ownership |
| `ENISA-SBOM-11` | Produce VEX Statements for Known Vulnerabilities |
| `ENISA-SBOM-12` | Implement SBOM-Driven Patch Prioritisation |
## Policy templates
Written for ENISA:
* ENISA SBOM Governance and Management Policy
* ENISA SBOM-Driven Vulnerability Management Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ENISA.
# Estonia EISA / ISKE (/docs/frameworks/europe/estonia-eisa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Estonian Information System Authority guidelines - ISKE framework for public sector systems.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | EISA EE |
| Region | Europe |
| Country or scope | Estonia |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers EISA EE
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for EISA EE.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for EISA EE and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `EE-EITS-INV` Baseline Asset Inventory | The baseline security methodology requires a structure analysis inventorying all applications and systems within scope, so every software component must be recorded (E-ITS/ISKE baseline methodology, inherited from IT-Grundschutz structure analysis) | Scan |
| `EE-CSA-SEC` Duty to Apply Security Measures | System operators covered by the Cybersecurity Act must apply organisational and technical measures proportionate to risk to keep systems secure, including maintaining software at known, patchable versions (Cybersecurity Act 2018, security-measures obligation) | Scan |
| `EE-EITS-PATCH` Patch Management Precision | Baseline patch and change management modules require software to run at precisely determined versions rather than vague or floating version specifications (E-ITS operational security modules) | Scan |
| `EE-CSA-INC` Incident Notification Readiness | Significant cyber incidents must be reported promptly to the national CSIRT (CERT-EE), which requires the ability to quickly match affected components against published vulnerability identifiers (Cybersecurity Act 2018, incident-notification obligation) | Scan |
| `EE-EITS-DOC` Documented Security Records | Implementation of baseline measures must be documented and auditable, so machine-readable security records need a document identity and creation timestamp (E-ITS documentation requirements) | Scan |
| `EE-CSA-SUP` Responsibility for Outsourced Services | Service providers remain responsible for security when relying on third parties, requiring the supplier of software components underpinning the service to be identified (Cybersecurity Act 2018, service-provider responsibility) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------- | ---------------------------------------------------- |
| `ISKE-M1` | Security Policy and Management (M1) |
| `ISKE-M2` | Organisation of Information Security (M2) |
| `ISKE-M3` | Human Resource Security (M3) |
| `ISKE-M4` | Physical and Environmental Security (M4) |
| `ISKE-M5` | Communications and Operations Management (M5) |
| `ISKE-M6` | Access Control (M6) |
| `ISKE-M7` | Information Systems Acquisition and Development (M7) |
| `ISKE-M8` | Supplier Relationships (M8) |
| `ISKE-M9` | Incident Management (M9) |
| `ISKE-M10` | Business Continuity Management (M10) |
| `ISKE-M11` | Compliance (M11) |
| `ISKE-L1` | Baseline Protection Level (L1) |
| `ISKE-L2` | Standard Protection Level (L2) |
| `ISKE-L3` | High Protection Level (L3) |
## Policy templates
Written for EISA EE:
* Estonia ISKE Implementation Policy
* Estonia EISA Incident Reporting Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to EISA EE.
# ETSI EN 303 645 (/docs/frameworks/europe/etsi-en303645)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
IoT Security Standard: software update management, supply chain security for IoT devices.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ETSI IoT |
| Region | Europe |
| Country or scope | European Union |
| Sector | IoT |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ETSI IoT
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for ETSI IoT.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for ETSI IoT and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ETSI-645-5.2-1` Vulnerability Disclosure Contact | Manufacturers must publish a vulnerability disclosure policy including a contact point for reporting issues, so the SBOM/creator metadata must include reachable contact details (ETSI EN 303 645, provision 5.2-1) | Scan |
| `ETSI-645-5.3-UPD` Update Management Visibility | Keeping software updated requires the manufacturer to know each software component and its version on the device to determine update needs (ETSI EN 303 645, provisions 5.3 series - keep software updated) | Scan |
| `ETSI-645-5.3-INV` Device Software Inventory | Managing updates across all software components on a consumer IoT device presupposes an inventory of those components (ETSI EN 303 645, provision 5.3 - software update management scope) | Scan |
| `ETSI-645-5.7` Software Integrity Verification | Devices should verify their software using secure boot or equivalent mechanisms, supported by cryptographic hashes for the software components shipped (ETSI EN 303 645, provision 5.7 - ensure software integrity) | Scan |
| `ETSI-645-SUPP` Third-Party Component Accountability | The manufacturer remains responsible for security of third-party software in the device, requiring supplier attribution for included components (ETSI EN 303 645, supply chain considerations in 5.3/vulnerability handling) | Scan |
| `ETSI-645-DEFPUB` Defined Support Documentation | Manufacturers must publish the defined support period and update information transparently, supported by identifiable, dated composition documentation (ETSI EN 303 645, provision 5.3 - published support period) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ------------------------------------------------------ |
| `ETSI-4.1` | Eliminate Universal Default Passwords |
| `ETSI-4.2` | Implement Vulnerability Disclosure Policy |
| `ETSI-4.3` | Keep Software Updated |
| `ETSI-5.1` | Securely Store Credentials and Security-Sensitive Data |
| `ETSI-5.2` | Communicate Securely |
| `ETSI-5.3` | Minimise Exposed Attack Surfaces |
| `ETSI-5.4` | Ensure Software Integrity |
| `ETSI-5.5` | Protect Personal Data |
| `ETSI-5.6` | Ensure Device Resilience to Outages |
| `ETSI-5.7` | Examine System Telemetry Data |
| `ETSI-5.8` | Make It Easy for Users to Delete Personal Data |
| `ETSI-SUPPORT` | Disclose Defined Support Period |
## Policy templates
Written for ETSI IoT:
* ETSI EN 303 645 IoT Device Security Policy
* ETSI EN 303 645 Vulnerability Disclosure Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ETSI IoT.
# EU AI Act (/docs/frameworks/europe/eu-ai-act)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
AI system component documentation, supply chain transparency, version traceability.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | EU AI |
| Region | Europe |
| Country or scope | European Union |
| Sector | AI |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers EU AI
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for EU AI.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for EU AI and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `EU-AIA-11` Technical Documentation of System Elements | Providers of high-risk AI systems must draw up technical documentation describing the system's development and its elements, which for the software stack means an enumerated component inventory (AI Act Art. 11 and Annex IV) | Scan |
| `EU-AIA-11V` Version Traceability of the Stack | Technical documentation must cover the versions of relevant software and how they interact, so components must record versions to keep documentation faithful across releases (AI Act Annex IV documentation content) | Scan |
| `EU-AIA-15` Cybersecurity and Integrity | High-risk AI systems must achieve appropriate cybersecurity and resilience against attempts to alter their use or behaviour, including assurance that deployed components are unmodified (AI Act Art. 15) | Scan |
| `EU-AIA-25` Value Chain Responsibilities | Obligations along the AI value chain require providers to know which third parties supply tools, components and services integrated into the system (AI Act Art. 25, responsibilities along the AI value chain) | Scan |
| `EU-AIA-12` Record-Keeping Foundations | High-risk systems must support automatic recording of events, and documentation must be identifiable and dated for authorities across the retention period (AI Act Arts. 12 and 18) | Scan |
| `EU-AIA-13` Transparency to Deployers | Systems must be accompanied by instructions and information enabling deployers to understand and use them, supported by machine-readable composition data that downstream tooling can consume (AI Act Art. 13) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ---------------------------------------------------------- |
| `EUAI-ART9` | Establish Risk Management System for High-Risk AI |
| `EUAI-ART10` | Implement Data and Data Governance Practices |
| `EUAI-ART11` | Maintain Technical Documentation |
| `EUAI-ART12` | Implement Automatic Logging of AI System Events |
| `EUAI-ART13` | Ensure Transparency and Provision of Information to Users |
| `EUAI-ART14` | Enable Effective Human Oversight |
| `EUAI-ART15` | Ensure Accuracy, Robustness, and Cybersecurity |
| `EUAI-ART16` | Register High-Risk AI Systems in EU Database |
| `EUAI-ART17` | Implement Quality Management System |
| `EUAI-ART50` | Label AI-Generated Content (GPAI Transparency) |
| `EUAI-ART53` | Comply with GPAI Model Obligations |
| `EUAI-ART55` | Meet Systemic Risk Obligations for High-Impact GPAI Models |
| `EUAI-SBOM` | Document AI Model and Component Supply Chain |
| `EUAI-ART4` | Ensure AI Literacy of Staff |
## Policy templates
Written for EU AI:
* EU AI Act High-Risk AI System Risk Management Policy
* EU AI Act Technical Documentation Policy
* EU AI Act GPAI Model Transparency and Obligations Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to EU AI.
# EU Cyber Resilience Act (/docs/frameworks/europe/eu-cra)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Mandatory cybersecurity requirements for products with digital elements sold in the EU.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | EU CRA |
| Region | Europe |
| Country or scope | European Union |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers EU CRA
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 15 controls from Safeguard's control catalog for EU CRA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 26: 4 written for EU CRA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `EU-CRA-II1` SBOM of Top-Level Dependencies | Manufacturers must identify and document vulnerabilities and components in the product, including by drawing up an SBOM in a commonly used machine-readable format (CRA Annex I Part II(1)) | Scan |
| `EU-CRA-II1B` Documented Component Set | The vulnerability-handling SBOM must actually enumerate the product's components, at minimum its dependencies (CRA Annex I Part II(1)) | Scan |
| `EU-CRA-II2` Vulnerability Remediation Without Delay | Vulnerabilities must be addressed and remediated without delay, including via security updates, which requires exact component versions to match advisories and target fixes (CRA Annex I Part II(2)) | Scan |
| `EU-CRA-II8` Coordinated Disclosure Contact | Manufacturers must have a coordinated vulnerability disclosure policy and provide a contact address for reporting vulnerabilities, so composition documents must carry reachable creator contact details (CRA Annex I Part II and Annex II information requirements) | Scan |
| `EU-CRA-I-INT` Integrity Protection | Products must protect the integrity of stored, transmitted or processed data, commands and configuration, including corruption of the software itself, supported by component integrity hashes (CRA Annex I Part I essential requirements on integrity) | Scan |
| `EU-CRA-13SC` Due Diligence on Third-Party Components | Manufacturers must exercise due diligence when integrating third-party components so they do not compromise the product's security, requiring supplier attribution per component (CRA Art. 13, manufacturer obligations on third-party components) | Scan |
| `EU-CRA-TDOC` Technical Documentation Identity | Technical documentation, including the SBOM, must be drawn up before market placement and kept for at least ten years, requiring identifiable, timestamped documents (CRA Art. 31 and Annex VII) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ---------------------------------------------------------- |
| `CRA-AX1-1` | Deliver Products Without Known Exploitable Vulnerabilities |
| `CRA-AX1-2` | Implement Secure-by-Default Configuration |
| `CRA-AX1-3` | Protect Against Unauthorised Access |
| `CRA-AX1-4` | Ensure Data Confidentiality and Integrity |
| `CRA-AX1-5` | Minimise Attack Surface |
| `CRA-AX1-6` | Mitigate Effects of Security Incidents |
| `CRA-AX2` | Provide SBOM for Third-Party Components |
| `CRA-ART10-1` | Exercise Due Diligence on Third-Party Components |
| `CRA-ART11` | Report Actively Exploited Vulnerabilities to ENISA |
| `CRA-ART14` | Implement Coordinated Vulnerability Disclosure |
| `CRA-ART18` | Perform EU Declaration of Conformity |
| `CRA-ART21` | Affix CE Marking and Maintain Technical Documentation |
| `CRA-ART27` | Ensure Importers and Distributors Comply with CRA |
| `CRA-UPDATE` | Provide Security Updates Throughout Support Period |
| `CRA-VULN-MGMT` | Maintain Vulnerability Management Process |
## Policy templates
Written for EU CRA:
* EU CRA Product Security Policy
* EU CRA Coordinated Vulnerability Disclosure Policy
* EU CRA SBOM Management Policy
* EU CRA Security Incident Reporting Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to EU CRA.
# EU Cybersecurity Act (/docs/frameworks/europe/eu-cybersecurity-act)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Regulation (EU) 2019/881 - ENISA permanent mandate, European cybersecurity certification scheme.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | EU CSA |
| Region | Europe |
| Country or scope | European Union |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers EU CSA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for EU CSA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for EU CSA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `EU-CSA-51-DEP` Documented Dependencies | Certification security objectives require that ICT products identify and document their known dependencies, which an SBOM satisfies through explicit dependency relationships (Regulation (EU) 2019/881 Art. 51(1)) | Scan |
| `EU-CSA-51-INV` Component Enumeration | Documenting a product's dependencies and vulnerabilities presupposes an enumerated inventory of the software components it is built from (Regulation (EU) 2019/881 Art. 51(1)) | Scan |
| `EU-CSA-51-VULN` Known-Vulnerability Traceability | The certification objective of identifying and documenting known vulnerabilities requires components to carry standard identifiers (PURL/CPE) so they can be matched against vulnerability databases (Regulation (EU) 2019/881 Art. 51(1)) | Scan |
| `EU-CSA-51-UPD` Up-to-Date Software | Security objectives include products being provided with up-to-date software free of publicly known vulnerabilities, which requires each component's version to be recorded and assessable (Regulation (EU) 2019/881 Art. 51(1)) | Scan |
| `EU-CSA-52-INTEG` Assurance-Level Integrity Evidence | Assurance levels substantial and high require evaluation that minimises known cyberattack risks, including assurance that delivered software is authentic and unmodified, supported by integrity hashes (Regulation (EU) 2019/881 Art. 52) | Scan |
| `EU-CSA-55-INFO` Supplementary Supplier Information | Manufacturers and providers must publish supplementary cybersecurity information such as support and vulnerability-handling details, which presumes the supplier of each component is identified (Regulation (EU) 2019/881 Art. 55) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | ---------------------------------------------------------- |
| `CSA-Art46` | European Cybersecurity Certification Scheme: Establishment |
| `CSA-Art47` | Scheme Content Requirements |
| `CSA-Art48` | Assurance Levels |
| `CSA-Art49` | Self-Assessment of Conformity |
| `CSA-Art51` | Security Requirements for Certified Products |
| `CSA-Art52` | European Cybersecurity Certificate |
| `CSA-Art53` | Obligations of Holders |
| `CSA-Art54` | Accreditation of Conformity Assessment Bodies |
| `CSA-Art56` | ENISA Mandate: Cybersecurity Certification |
| `CSA-Art57` | ENISA Peer Reviews and Assistance |
## Policy templates
Written for EU CSA:
* EU Cybersecurity Act Certification Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to EU CSA.
# EU Data Act (/docs/frameworks/europe/eu-data-act)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
EU Regulation on fair access to and use of data - IoT data sharing, cloud switching, B2B/B2G.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | Data Act |
| Region | Europe |
| Country or scope | European Union |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers Data Act
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for Data Act.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for Data Act and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `EU-DA-3` Access by Design Documentation | Connected products and related services must be designed so that data is accessible to users, which presupposes the maker can name the system and enumerate the software components handling that data (Regulation (EU) 2023/2854 Chapter II, Art. 3 access-by-design obligation) | Scan |
| `EU-DA-SWITCH` Cloud Switching Completeness | Providers of data processing services must remove obstacles to switching and ensure exportable data and digital assets are fully described, which requires component records complete with both name and version (Regulation (EU) 2023/2854 Chapter VI switching provisions) | Scan |
| `EU-DA-INTEROP` Interoperability Essential Requirements | Participants in data spaces and data processing services must meet essential interoperability requirements including openly documented, machine-readable structures and formats (Regulation (EU) 2023/2854 interoperability provisions, Chapter VIII) | Scan |
| `EU-DA-INTL` Safeguards Against Unlawful Access | Providers must take reasonable technical measures to prevent unlawful third-country governmental access to non-personal data, including assurance of the integrity of the software stack holding that data (Regulation (EU) 2023/2854 international access safeguards, Chapter VII) | Scan |
| `EU-DA-SC` Smart Contract Robustness | Smart contracts used for executing data sharing agreements must meet essential requirements for robustness and access control, which excludes building on vaguely versioned or unpinned components (Regulation (EU) 2023/2854 smart-contract essential requirements) | Scan |
| `EU-DA-HOLDER` Data Holder Accountability | Data holders making data available under the regulation must be identifiable and accountable for the systems that serve it, requiring the creator or operating organisation of technical records to be documented (Regulation (EU) 2023/2854 data-holder obligations, Chapter II) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------------------ | ------------------------------------------------------- |
| `DA-Art3` | Right of Access to Product Data |
| `DA-Art4` | Obligations of Data Holders to Users |
| `DA-Art5` | Obligations When Making Data Available to Third Parties |
| `DA-Art13` | Cloud Switching |
| `DA-Art23` | Business-to-Government Data Sharing |
| `DA-DataContracts` | Contractual Protections for SMEs |
| `DA-InteroperabilityStandards` | Interoperability Standards for Data Spaces |
## Policy templates
Written for Data Act:
* EU Data Act Cloud Switching Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to Data Act.
# EU Digital Markets Act (/docs/frameworks/europe/eu-dma)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
EU Regulation 2022/1925 - gatekeeper obligations, interoperability, prohibited self-preferencing.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | DMA |
| Region | Europe |
| Country or scope | European Union |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers DMA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for DMA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for DMA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `EU-DMA-6-INTEG` Integrity-Protection Measures | Gatekeepers permitting third-party software and app stores may apply only measures strictly necessary to protect the integrity of their hardware, operating system and software, which presupposes verifiable integrity evidence such as component hashes (Regulation (EU) 2022/1925 Art. 6(4)) | Scan |
| `EU-DMA-6-INTEROP` Interoperability Through Standard Formats | Gatekeepers must provide effective interoperability with the same hardware and software features they use themselves, which favours documenting systems in standard machine-readable formats (Regulation (EU) 2022/1925 Art. 6(7)) | Scan |
| `EU-DMA-8` Demonstrable Compliance | Gatekeepers must ensure and be able to demonstrate compliance with their obligations, which requires a documented inventory of the software making up each core platform service (Regulation (EU) 2022/1925 Art. 8(1)) | Scan |
| `EU-DMA-11` Compliance Reporting Records | Gatekeepers must submit reports describing measures taken to comply with the regulation, requiring dated, identifiable technical documentation to substantiate them (Regulation (EU) 2022/1925 Art. 11) | Scan |
| `EU-DMA-28` Compliance Function Provenance | Gatekeepers must maintain an independent compliance function, and technical artefacts supporting compliance must record which tool or organisation created them (Regulation (EU) 2022/1925 Art. 28) | Scan |
| `EU-DMA-VER` Maintained Core Platform Software | Ongoing compliance with security and interoperability duties across gatekeeper services requires knowing the version of each deployed software component (Regulation (EU) 2022/1925 gatekeeper obligations, Arts. 5-7) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------------- | -------------------------------------------------------------------- |
| `DMA-Art5` | Gatekeeper Core Platform Obligations |
| `DMA-Art6` | Additional Gatekeeper Obligations |
| `DMA-Art7` | Interoperability for Number-Independent Interpersonal Communications |
| `DMA-Art14` | Gatekeeper Designation Notification |
| `DMA-Art15` | Compliance Audit for Gatekeepers |
| `DMA-Remedies` | Structural and Behavioural Remedies |
| `DMA-DataPortability` | Data Portability for Business and End Users |
| `DMA-Transparency` | Transparency and Reporting to Commission |
## Policy templates
Written for DMA:
* DMA Compliance Programme
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DMA.
# EU Digital Services Act (/docs/frameworks/europe/eu-dsa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
EU Regulation 2022/2065 - intermediary liability, transparency, risk assessment for VLOPs/VLOSEs.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | DSA |
| Region | Europe |
| Country or scope | European Union |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers DSA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for DSA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for DSA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `EU-DSA-34` Systemic Risk Assessment Basis | Very large platforms must diligently assess systemic risks stemming from the design and functioning of their services, which requires an inventory of the software components those services are built from (Regulation (EU) 2022/2065 Art. 34) | Scan |
| `EU-DSA-35` Risk Mitigation Through Maintained Software | Providers must put in place reasonable and proportionate mitigation measures, including adapting and testing their systems, which requires knowing the versions of deployed components so weaknesses can be remediated (Regulation (EU) 2022/2065 Art. 35) | Scan |
| `EU-DSA-35-INTEG` Integrity of Platform Systems | Mitigation of systemic risks includes safeguarding the integrity of the platform's systems against manipulation, supported by integrity hashes for the software supply chain (Regulation (EU) 2022/2065 Art. 35) | Scan |
| `EU-DSA-37` Independent Audit Evidence | Very large platforms are subject to annual independent audits of their compliance, which requires auditable machine-readable records bearing a document identity and creation timestamp (Regulation (EU) 2022/2065 Art. 37) | Scan |
| `EU-DSA-15` Machine-Readable Transparency | The DSA requires transparency reports to be published in machine-readable formats, and technical compliance documentation should equally use a standard machine-readable SBOM format (Regulation (EU) 2022/2065 Art. 15 and Art. 42) | Scan |
| `EU-DSA-41` Compliance Function Accountability | Very large platforms must establish an independent compliance function, and accountability for technical artefacts requires that the tool or organisation producing them is recorded (Regulation (EU) 2022/2065 Art. 41) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | -------------------------------------------------- |
| `DSA-Art11` | Single Points of Contact |
| `DSA-Art12` | Legal Representatives |
| `DSA-Art13` | Intermediary Service Provider Transparency Reports |
| `DSA-Art14` | Terms and Conditions |
| `DSA-Art15` | Transparency Reporting Obligations for Hosting |
| `DSA-Art16` | Notice-and-Action Mechanisms |
| `DSA-Art25` | Online Interfaces: Prohibition of Dark Patterns |
| `DSA-Art27` | Recommender System Transparency |
| `DSA-Art28` | Online Protection of Minors |
| `DSA-Art33` | Risk Assessment: Very Large Online Platforms |
| `DSA-Art34` | Risk Mitigation Measures |
| `DSA-Art37` | Independent Audit for VLOPs |
## Policy templates
Written for DSA:
* DSA Transparency Reporting Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DSA.
# EU eIDAS Regulation (/docs/frameworks/europe/eu-eidas)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Electronic Identification, Authentication and Trust Services - qualified eSignatures, seals, timestamps.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | eIDAS |
| Region | Europe |
| Country or scope | European Union |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers eIDAS
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for eIDAS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for eIDAS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `EU-EIDAS-19-SEC` Security of Trust Service Systems | Trust service providers must take appropriate technical and organisational measures to manage risks to the security of their services, including assurance that deployed software is authentic and untampered via integrity hashes (Regulation (EU) 910/2014 Art. 19(1)) | Scan |
| `EU-EIDAS-19-BREACH` Breach Notification Readiness | Providers must notify security breaches with significant impact within 24 hours, which requires the ability to rapidly determine whether affected software components match a disclosed vulnerability (Regulation (EU) 910/2014 Art. 19(2)) | Scan |
| `EU-EIDAS-24-TRUST` Trustworthy Systems and Products | Qualified trust service providers must use trustworthy systems and products protected against modification, which excludes running software at vague or unpinned versions (Regulation (EU) 910/2014 Art. 24(2)) | Scan |
| `EU-EIDAS-24-REC` Record Keeping | Qualified providers must record and keep accessible relevant information concerning their services, so machine-readable records must carry a document identity and creation timestamp (Regulation (EU) 910/2014 Art. 24(2)) | Scan |
| `EU-EIDAS-SUP` Component Source Accountability | Reliance on trustworthy products implies knowing the origin of the software components a trust service is built from, so suppliers should be named for the majority of components (Regulation (EU) 910/2014 Art. 24-style trustworthiness obligation) | Scan |
| `EU-EIDAS-FMT` Standardised Machine-Readable Formats | eIDAS interoperability rests on standardised, machine-processable formats defined in implementing acts, and security documentation should likewise use a standard machine-readable SBOM format (Regulation (EU) 910/2014 implementing standards framework) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------------- | ------------------------------------------------------- |
| `EIDAS-Art24` | Qualified Trust Service Providers: Requirements |
| `EIDAS-Art26` | Advanced Electronic Signatures: Requirements |
| `EIDAS-Art28` | Qualified Certificates for Electronic Signatures |
| `EIDAS-Art32` | Qualified Validation of Qualified Electronic Signatures |
| `EIDAS-Art41` | Qualified Electronic Seals |
| `EIDAS-Art42` | Qualified Electronic Time Stamps |
| `EIDAS-Art45` | Qualified Website Authentication Certificates |
| `EIDAS-Supervisory` | TSP Supervisory Notification and Audit |
| `EIDAS-TrustedList` | Trusted Lists Maintenance |
| `EIDAS-MutualRecognition` | Cross-Border Mutual Recognition |
## Policy templates
Written for eIDAS:
* eIDAS Trust Service Provider Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to eIDAS.
# EU PSD2 (/docs/frameworks/europe/eu-psd2)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Payment Services Directive 2 - Strong Customer Authentication, third-party access, open banking APIs.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | PSD2 |
| Region | Europe |
| Country or scope | European Union |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers PSD2
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for PSD2.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for PSD2 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `EU-PSD2-95-RISK` Operational and Security Risk Framework | Payment service providers must establish a framework to manage operational and security risks of the services they provide, which starts with an inventory of the software their payment systems comprise (Directive (EU) 2015/2366 Art. 95(1)) | Scan |
| `EU-PSD2-95-MIT` Mitigation Measures and Control Mechanisms | The risk framework must include effective mitigation measures and control mechanisms, which for software means tracking component versions so weaknesses can be remediated (Directive (EU) 2015/2366 Art. 95(1)) | Scan |
| `EU-PSD2-96-INC` Incident Reporting Readiness | Major operational or security incidents must be reported to the competent authority without undue delay, requiring rapid identification of which deployed components are implicated in an incident (Directive (EU) 2015/2366 Art. 96) | Scan |
| `EU-PSD2-97-SCA` Integrity of Authentication Software | Strong customer authentication must protect the confidentiality and integrity of authentication elements, so the software implementing SCA should carry verifiable integrity hashes (Directive (EU) 2015/2366 Art. 97) | Scan |
| `EU-PSD2-98-CSC` Common and Secure Standards | The regulatory technical standards on strong customer authentication and secure communication require open, common and secure standards between providers, and security documentation should likewise be in a standard machine-readable format (Directive (EU) 2015/2366 Art. 98 and RTS (EU) 2018/389) | Scan |
| `EU-PSD2-OUT` Outsourcing and Third-Party Accountability | Providers relying on agents or outsourced operational functions remain responsible for them, which requires knowing the supplier behind the software components used in payment services (Directive (EU) 2015/2366 outsourcing provisions, Art. 19-20; EBA outsourcing guidelines) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------- | ----------------------------------------------- |
| `PSD2-Art65` | Third-Party Provider Access to Payment Accounts |
| `PSD2-Art66` | Payment Initiation Service Providers |
| `PSD2-Art67` | Account Information Service Providers |
| `PSD2-Art73` | Liability for Unauthorised Transactions |
| `PSD2-Art74` | Refund Rights for Authorised Transactions |
| `PSD2-Art95` | Operational and Security Risk Management |
| `PSD2-Art96` | Major Incident Reporting |
| `PSD2-Art97` | Strong Customer Authentication (SCA) |
| `PSD2-Art98` | RTS on SCA and Secure Communication |
| `PSD2-Licensing` | PSP Authorisation and Registration |
| `PSD2-Safeguarding` | Safeguarding of Customer Funds |
## Policy templates
Written for PSD2:
* PSD2 Strong Customer Authentication (SCA) Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PSD2.
# Faroe Islands Data Protection Act (/docs/frameworks/europe/faroe-islands-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | FO DP Act |
| Region | Europe |
| Country or scope | Faroe Islands |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers FO DP Act
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FO-DPA-SEC` Security of Processing | Entities must implement technical and organisational measures appropriate to processing risk, including the ability to verify the integrity of processing software (Act No. 80 of 7 June 2020, GDPR Art. 32-style security obligation) | Scan |
| `FO-DPA-PRIN` Integrity and Confidentiality Principle | Personal data must be processed securely and kept accurate, presupposing fully described processing components with name and version (Act No. 80 of 7 June 2020, data-protection principles) | Scan |
| `FO-DPA-REC` Records of Processing | Controllers and processors must maintain records of their processing activities, including a named, populated inventory of processing systems (Act No. 80 of 7 June 2020, GDPR Art. 30-style record duty) | Scan |
| `FO-DPA-PROC` Processor Guarantees | Controllers may only engage processors giving sufficient guarantees of compliant processing, requiring supplier visibility for third-party components (Act No. 80 of 7 June 2020, GDPR Art. 28-style processor obligation) | Scan |
| `FO-DPA-BRE` Breach Notification Readiness | Breach-notification duties to the Data Protection Authority require identifying exactly which software components an incident affected (Act No. 80 of 7 June 2020, GDPR Art. 33-style breach notification) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FO DP Act.
# Finland Data Protection Act (1050/2018) (/docs/frameworks/europe/finland-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | FI DPA |
| Region | Europe |
| Country or scope | Finland |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers FI DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FI-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Finland by the Data Protection Act (1050/2018)). | Scan |
| `FI-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Data Protection Act (1050/2018)). | Scan |
| `FI-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Data Protection Act (1050/2018)). | Scan |
| `FI-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Data Protection Act (1050/2018)). | Scan |
| `FI-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Data Protection Act (1050/2018)). | Scan |
| `FI-DPA-A24` Accountability of the Controller | Responsibility for processing operations must be demonstrable, which includes documented provenance of who produced the record of the software estate that processes personal data (GDPR Art. 24 and Art. 5(2); the Data Protection Act (1050/2018)). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FI DPA.
# France ANSSI RGS (/docs/frameworks/europe/france-anssi-rgs)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Referentiel General de Securite - French government security baseline, crypto, IAM, audit.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ANSSI RGS |
| Region | Europe |
| Country or scope | France |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ANSSI RGS
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for ANSSI RGS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ANSSI RGS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FR-RGS-B1` Cryptographic Integrity Mechanisms | Systems must employ ANSSI-approved cryptographic mechanisms to guarantee integrity and authenticity; cryptographic hashes over the deployed software components are the SBOM-level expression of this control (RGS v2.0 Annex B1) | Scan |
| `FR-RGS-RISK` Risk Analysis Asset Identification | Security accreditation rests on a risk analysis (EBIOS-style) that must identify the assets composing the system; an enumerated software component inventory is the entry condition for that analysis (RGS v2.0, risk-analysis requirement) | Scan |
| `FR-RGS-HOMOLOG` Homologation Dossier | Information systems must undergo formal security accreditation supported by a documented dossier describing the system; an identified, timestamped SBOM is a core artifact of such a dossier (RGS v2.0, homologation requirement) | Scan |
| `FR-RGS-QUALIF` Qualified Products and Providers | The RGS establishes qualification of security products and trust service providers, presupposing that the origin and creator of deployed software artifacts is recorded and verifiable (RGS v2.0, qualification scheme) | Scan |
| `FR-RGS-MCS` Maintaining Security Over Time | Accredited systems must be kept in a secure condition throughout their life, including applying security updates; that maintenance is only auditable when component versions are recorded (RGS v2.0, maintien en condition de sécurité) | Scan |
| `FR-RGS-AUDIT` Auditability of Components | Periodic security audits of accredited systems require that the audited components be unambiguously identifiable via standard identifiers (RGS v2.0, audit requirement) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ------------------------------------------------- |
| `RGS-A1-1` | Cryptographic Algorithm Approval (Annex A1) |
| `RGS-A1-2` | Cryptographic Key Management |
| `RGS-A2-1` | Authentication Mechanism Qualification (Annex A2) |
| `RGS-A2-2` | Electronic Signature Qualification (Annex A2) |
| `RGS-A3-1` | Audit Log Integrity (Annex A3) |
| `RGS-A3-2` | Timestamping and Non-Repudiation (Annex A3) |
| `RGS-A4-1` | Software Integrity Verification (Annex A4) |
| `RGS-A4-2` | Secure Software Distribution |
| `RGS-PSSI-1` | Information System Security Policy (PSSI) |
| `RGS-HOMO-1` | ANSSI Security Product Homologation |
## Policy templates
Written for ANSSI RGS:
* ANSSI RGS: Privacy Notice (French Public Services)
* ANSSI RGS: Data Subject Rights Procedure
* ANSSI RGS: Information Security Policy (PSSI)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ANSSI RGS.
# GDPR Article 25 (/docs/frameworks/europe/gdpr-art25)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Privacy by Design: data minimisation, third-party processors, privacy by default documentation.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | GDPR Art.25 |
| Region | Europe |
| Country or scope | European Union |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers GDPR Art.25
* **Scan requirements:** 4, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for GDPR Art.25.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for GDPR Art.25 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 4 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------- | -------------------------------------------------- | ---------- |
| `GDPR-Art25-1` Privacy by Design Components | GDPR Art 25 requires privacy-preserving components | Scan |
| `GDPR-Art25-2` Data Minimization Assessment | GDPR Art 25(2) requires data minimization | Scan |
| `GDPR-Art25-3` Pseudonymization Components | GDPR Art 25 requires pseudonymization techniques | Scan |
| `GDPR-Art25-4` Controller Accountability | GDPR Art 25 requires controller accountability | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------------- | -------------------------------------------------------------------- |
| `ART25-PBD-1` | Embed Data Minimisation at Design Stage |
| `ART25-PBD-2` | Implement Pseudonymisation and Anonymisation Controls |
| `ART25-PBD-3` | Conduct Privacy Impact Review Before System Changes |
| `ART25-PBD-4` | Integrate Privacy Controls into the Software Development Lifecycle |
| `ART25-PBDF-1` | Configure Privacy-Preserving Defaults for User-Facing Products |
| `ART25-PBDF-2` | Enforce Retention Limits by Default |
| `ART25-PBDF-3` | Restrict Internal Access to Personal Data by Default |
| `ART25-CERT` | Consider Approved Certification Mechanisms for Article 25 Compliance |
| `ART25-SCOPE` | Define Scope of Personal Data Processing for Each System |
| `ART25-PROCESSOR` | Ensure Processor Systems Implement Privacy by Design |
## Policy templates
Written for GDPR Art.25:
* Privacy by Design and by Default Policy
* Data Protection Impact Assessment Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GDPR Art.25.
# GDPR (/docs/frameworks/europe/gdpr)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Privacy by design, integrity & confidentiality, data protection impact assessment.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Europe |
| Country or scope | European Union |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers GDPR
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for GDPR.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for GDPR and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `EU-GDPR-32` Security of Processing | Controllers and processors must implement technical measures ensuring ongoing integrity and resilience of processing systems, including the ability to verify that processing software is authentic and unmodified (GDPR Art. 32(1)(b)) | Scan |
| `EU-GDPR-30` Records of Processing Activities | Controllers must maintain records of processing activities including a general description of security measures, which presupposes an inventory of the software performing the processing (GDPR Art. 30) | Scan |
| `EU-GDPR-28` Processor Chain Control | Processing may only be entrusted to processors providing sufficient guarantees, and sub-processors require authorisation, so the suppliers behind processing components must be identified (GDPR Art. 28) | Scan |
| `EU-GDPR-25` Data Protection by Design | Data protection must be built in at the time of determining the means of processing, requiring documented, identifiable and dated records of the system's composition (GDPR Art. 25) | Scan |
| `EU-GDPR-33` Breach Notification Readiness | Personal data breaches must be notified to the supervisory authority within 72 hours where feasible, which requires the ability to determine quickly which software components and versions were affected (GDPR Art. 33) | Scan |
| `EU-GDPR-5-2` Accountability Evidence | Controllers must be able to demonstrate compliance with the processing principles, supported by composition evidence whose creator and provenance are recorded (GDPR Art. 5(2)) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ---------------------------------------------------------------------- |
| `GDPR-ART5` | Ensure Lawfulness, Fairness, and Transparency of Processing |
| `GDPR-ART6` | Establish Lawful Basis for Processing |
| `GDPR-ART7` | Manage Consent Effectively |
| `GDPR-ART13-14` | Provide Data Subject Information at Collection |
| `GDPR-ART15-22` | Implement Data Subject Rights Fulfilment Process |
| `GDPR-ART25` | Implement Privacy by Design and by Default |
| `GDPR-ART30` | Maintain Records of Processing Activities |
| `GDPR-ART32` | Implement Appropriate Technical and Organisational Security Measures |
| `GDPR-ART33` | Report Personal Data Breaches to Supervisory Authority Within 72 Hours |
| `GDPR-ART34` | Notify Data Subjects of High-Risk Breaches |
| `GDPR-ART35` | Conduct Data Protection Impact Assessments |
| `GDPR-ART28` | Execute Data Processing Agreements with Processors |
## Policy templates
Written for GDPR:
* GDPR Data Protection Policy
* GDPR Personal Data Breach Response Policy
* GDPR Processor Management Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GDPR.
# Georgia Law on Information Security (/docs/frameworks/europe/georgia-infosec)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GE InfoSec |
| Region | Europe |
| Country or scope | Georgia |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GE InfoSec
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GE-IS-INV` Critical Information System Inventory | Critical information system subjects must manage the security of their information assets, which presupposes an inventory of the software components composing those systems (GE Information Security Law asset-management obligations) | Scan |
| `GE-IS-INT` Integrity Protection | Minimum information security requirements include protecting the integrity of systems and data against unauthorized modification; verifiable integrity hashes on components evidence this control (GE Information Security Law minimum security requirements) | Scan |
| `GE-IS-VULN` Vulnerability and Update Management | Subjects must manage vulnerabilities in their critical systems and respond to incidents, which requires knowing the exact version of every deployed component (GE Information Security Law security-management and incident duties) | Scan |
| `GE-IS-SUP` Third-Party and Supplier Control | Information security management extends to services and technology obtained from third parties, requiring visibility into the suppliers behind deployed software components (GE Information Security Law third-party provisions) | Scan |
| `GE-IS-DOC` Documented ISMS Evidence | Subjects must adopt internal information security rules and undergo security audits, supported by formally identified, timestamped records of system composition (GE Information Security Law ISMS and audit provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GE InfoSec.
# Georgia Law on Personal Data Protection 2023 (/docs/frameworks/europe/georgia-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GE PDPL |
| Region | Europe |
| Country or scope | Georgia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GE PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GE-PDPL-SEC` Data Security | Controllers and processors must take organizational and technical measures ensuring protection of data against accidental or unlawful destruction, alteration and unauthorized access; component integrity hashes evidence tamper protection (Georgia PDPL 2023 data-security obligation) | Scan |
| `GE-PDPL-REC` Records of Processing | Controllers and processors must document and record their processing activities, which presupposes an inventory of the software systems and components performing the processing (Georgia PDPL 2023 records obligation) | Scan |
| `GE-PDPL-PROC` Processor Engagement | Processing may be assigned only to processors providing adequate guarantees, on the basis of a written contract, requiring visibility into who supplies the software used for processing (Georgia PDPL 2023 processor provisions) | Scan |
| `GE-PDPL-BRE` Breach Notification Readiness | Data breaches must be notified to the Personal Data Protection Service within 72 hours, which requires being able to identify precisely which software components were affected (Georgia PDPL 2023 breach-notification obligation) | Scan |
| `GE-PDPL-VER` State-of-the-Art Safeguards | Safeguards must reflect the state of the art and the risks of processing, which requires knowing the exact versions of deployed components so their weaknesses can be assessed (Georgia PDPL 2023 by-design/security provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GE PDPL.
# Gibraltar Data Protection Act 2004 (/docs/frameworks/europe/gibraltar-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GI DPA 2004 |
| Region | Europe |
| Country or scope | Gibraltar |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GI DPA 2004
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GI-GDPR-32` Security of Processing | Controllers and processors must implement technical and organisational measures ensuring integrity and confidentiality of processing systems, including the ability to verify software integrity (Gibraltar GDPR Art. 32) | Scan |
| `GI-GDPR-5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring appropriate security, which requires knowing the exact version of every processing component so security state can be assessed (Gibraltar GDPR Art. 5(1)(f)) | Scan |
| `GI-GDPR-30` Records of Processing Activities | Controllers and processors must maintain records of processing activities, including a named, populated inventory of the software systems involved (Gibraltar GDPR Art. 30) | Scan |
| `GI-GDPR-28` Processor Guarantees | Controllers may only engage processors providing sufficient guarantees, requiring visibility into the suppliers of third-party components handling personal data (Gibraltar GDPR Art. 28) | Scan |
| `GI-GDPR-33` Breach Notification Readiness | Breach notification within 72 hours requires the ability to identify precisely which components were affected by an incident (Gibraltar GDPR Arts. 33-34) | Scan |
| `GI-DPA-DOC` Documented Accountability | The national act supplementing the Gibraltar GDPR expects controllers to be able to demonstrate compliance through identifiable, timestamped system documentation (Data Protection Act 2004, national accountability provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GI DPA 2004.
# Greece Law 4624/2019 (/docs/frameworks/europe/greece-law4624)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GR L4624 |
| Region | Europe |
| Country or scope | Greece |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GR L4624
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GR-L4624-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Greece by Law 4624/2019). | Scan |
| `GR-L4624-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside Law 4624/2019). | Scan |
| `GR-L4624-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; Law 4624/2019). | Scan |
| `GR-L4624-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; Law 4624/2019). | Scan |
| `GR-L4624-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; Law 4624/2019). | Scan |
| `GR-L4624-A24` Accountability of the Controller | Responsibility for processing operations must be demonstrable, which includes documented provenance of who produced the record of the software estate that processes personal data (GDPR Art. 24 and Art. 5(2); Law 4624/2019). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GR L4624.
# Guernsey Data Protection Law 2017 (/docs/frameworks/europe/guernsey-dpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GG DPL 2017 |
| Region | Europe |
| Country or scope | Guernsey |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GG DPL 2017
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `GG-DPL-SEC` Duty to Ensure Security | Controllers and processors must take reasonable steps to ensure the security of personal data against unauthorised or unlawful processing, loss or damage, including integrity verification of processing software (Data Protection (Bailiwick of Guernsey) Law 2017, duty to ensure security) | Scan |
| `GG-DPL-37` Prescribed Records | Controllers and processors must keep prescribed records and produce them for inspection by the Data Protection Authority on request, requiring a named, populated inventory of processing systems (Data Protection (Bailiwick of Guernsey) Law 2017, s. 37) | Scan |
| `GG-DPL-PRIN` Integrity and Confidentiality Principle | Personal data must be processed securely and kept accurate, which presupposes fully described components with name and version (Data Protection (Bailiwick of Guernsey) Law 2017, data-protection principles) | Scan |
| `GG-DPL-PROC` Processor Guarantees | Controllers may only engage processors giving sufficient guarantees of compliant, secure processing, requiring supplier visibility for third-party software (Data Protection (Bailiwick of Guernsey) Law 2017, processor provisions) | Scan |
| `GG-DPL-BRE` Breach Notification and Records | Notification and record duties in case of personal-data breach require identifying exactly which components were affected (Data Protection (Bailiwick of Guernsey) Law 2017, breach notification and records provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GG DPL 2017.
# Hungary Act CXII of 2011 (Infotv) (/docs/frameworks/europe/hungary-infotv)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | HU Infotv |
| Region | Europe |
| Country or scope | Hungary |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers HU Infotv
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `HU-INFOTV-SEC` Data Security Measures | Controllers and processors must implement technical and organisational measures that protect the security of personal data throughout processing; verifiable integrity hashes on deployed software components evidence this control (Infotv data-security provisions, aligned with GDPR Art. 32). | Scan |
| `HU-INFOTV-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Infotv (Act CXII of 2011, as amended)). | Scan |
| `HU-INFOTV-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Infotv (Act CXII of 2011, as amended)). | Scan |
| `HU-INFOTV-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Infotv (Act CXII of 2011, as amended)). | Scan |
| `HU-INFOTV-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Infotv (Act CXII of 2011, as amended)). | Scan |
| `HU-INFOTV-A24` Accountability of the Controller | Responsibility for processing operations must be demonstrable, which includes documented provenance of who produced the record of the software estate that processes personal data (GDPR Art. 24 and Art. 5(2); the Infotv (Act CXII of 2011, as amended)). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to HU Infotv.
# Iceland Act on Data Protection No. 90/2018 (/docs/frameworks/europe/iceland-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | IS DPA |
| Region | Europe |
| Country or scope | Iceland |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers IS DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IS-DPA-27` Security of Personal Data | Controllers and processors must apply appropriate technical and organisational security measures reflecting the state of the art and the risk of the processing; verifiable integrity hashes on deployed software components evidence this control (Act No. 90/2018 Art. 27; GDPR Art. 32). | Scan |
| `IS-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside Act No. 90/2018). | Scan |
| `IS-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; Act No. 90/2018). | Scan |
| `IS-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; Act No. 90/2018). | Scan |
| `IS-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; Act No. 90/2018). | Scan |
| `IS-DPA-A24` Demonstrable Compliance | The controller is responsible for, and must be able to demonstrate, compliance of its processing; a machine-readable software inventory (SPDX or CycloneDX) supports demonstrable accountability (GDPR Art. 24 and Art. 5(2); Act No. 90/2018). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to IS DPA.
# Europe (/docs/frameworks/europe)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
EU regulations and the laws and standards of European countries and territories. Each framework's page lists what a scan checks, its controls, its policy templates and its automated tests. How coverage works: [Compliance frameworks](/docs/frameworks).
| Framework | Country or scope | Sector | Scan requirements | Catalog controls |
| -------------------------------------------------------------------------------------------------------- | ---------------------- | ---------- | ----------------- | ---------------- |
| [Aland Finnish Data Protection Act](/docs/frameworks/europe/aland-dp) | Aland | Privacy | 6 | None |
| [Albania Law No. 9887 on Protection of Personal Data](/docs/frameworks/europe/albania-pdpl) | Albania | Privacy | 5 | None |
| [Andorra Qualified Law 29/2021 on Personal Data Protection](/docs/frameworks/europe/andorra-lqpd) | Andorra | Privacy | 5 | None |
| [Armenia Law on Protection of Personal Data](/docs/frameworks/europe/armenia-pdpl) | Armenia | Privacy | 5 | None |
| [Austria Data Protection Act (DSG)](/docs/frameworks/europe/austria-dsg) | Austria | Privacy | 6 | None |
| [Azerbaijan Law on Personal Data](/docs/frameworks/europe/azerbaijan-pdl) | Azerbaijan | Privacy | 5 | None |
| [Belarus Law No. 99-Z on Personal Data Protection](/docs/frameworks/europe/belarus-pdpl) | Belarus | Privacy | 5 | None |
| [Belgium Data Protection Act 2018](/docs/frameworks/europe/belgium-dpa) | Belgium | Privacy | 6 | None |
| [Bosnia and Herzegovina Law on Protection of Personal Data](/docs/frameworks/europe/bosnia-lpdp) | Bosnia and Herzegovina | Privacy | 5 | None |
| [BSI IT-Grundschutz](/docs/frameworks/europe/bsi-grundschutz) | Germany | Government | 6 | 12 |
| [BSI TR-03183-2](/docs/frameworks/europe/bsi-tr) | Germany | Government | 7 | 10 |
| [Bulgaria Personal Data Protection Act](/docs/frameworks/europe/bulgaria-pdpa) | Bulgaria | Privacy | 6 | None |
| [Croatia Act on Implementation of the GDPR 2018](/docs/frameworks/europe/croatia-gdpr-act) | Croatia | Privacy | 6 | None |
| [Cyprus Law 125(I)/2018](/docs/frameworks/europe/cyprus-law125) | Cyprus | Privacy | 6 | None |
| [Czechia Act No. 110/2019 on Personal Data Processing](/docs/frameworks/europe/czechia-dpa) | Czechia | Privacy | 6 | None |
| [Denmark Data Protection Act 2018](/docs/frameworks/europe/denmark-dpa) | Denmark | Privacy | 6 | None |
| [ENISA Good Practices](/docs/frameworks/europe/enisa-guidelines) | European Union | Government | 6 | 12 |
| [Estonia EISA / ISKE](/docs/frameworks/europe/estonia-eisa) | Estonia | Government | 6 | 14 |
| [ETSI EN 303 645](/docs/frameworks/europe/etsi-en303645) | European Union | IoT | 6 | 12 |
| [EU AI Act](/docs/frameworks/europe/eu-ai-act) | European Union | AI | 6 | 14 |
| [EU Cyber Resilience Act](/docs/frameworks/europe/eu-cra) | European Union | Government | 7 | 15 |
| [EU Cybersecurity Act](/docs/frameworks/europe/eu-cybersecurity-act) | European Union | Government | 6 | 10 |
| [EU Data Act](/docs/frameworks/europe/eu-data-act) | European Union | Privacy | 6 | 7 |
| [EU Digital Markets Act](/docs/frameworks/europe/eu-dma) | European Union | Privacy | 6 | 8 |
| [EU Digital Services Act](/docs/frameworks/europe/eu-dsa) | European Union | Privacy | 6 | 12 |
| [EU DORA](/docs/frameworks/europe/dora) | European Union | Finance | 6 | 13 |
| [EU eIDAS Regulation](/docs/frameworks/europe/eu-eidas) | European Union | Government | 6 | 10 |
| [EU NIS2 Directive](/docs/frameworks/europe/nis2) | European Union | Government | 6 | 13 |
| [EU PSD2](/docs/frameworks/europe/eu-psd2) | European Union | Finance | 6 | 11 |
| [Faroe Islands Data Protection Act](/docs/frameworks/europe/faroe-islands-dp) | Faroe Islands | Privacy | 5 | None |
| [Finland Data Protection Act (1050/2018)](/docs/frameworks/europe/finland-dpa) | Finland | Privacy | 6 | None |
| [France ANSSI RGS](/docs/frameworks/europe/france-anssi-rgs) | France | Government | 6 | 10 |
| [GDPR](/docs/frameworks/europe/gdpr) | European Union | Privacy | 6 | 12 |
| [GDPR Article 25](/docs/frameworks/europe/gdpr-art25) | European Union | Privacy | 4 | 10 |
| [Georgia Law on Information Security](/docs/frameworks/europe/georgia-infosec) | Georgia | Government | 5 | None |
| [Georgia Law on Personal Data Protection 2023](/docs/frameworks/europe/georgia-pdpl) | Georgia | Privacy | 5 | None |
| [Gibraltar Data Protection Act 2004](/docs/frameworks/europe/gibraltar-dpa) | Gibraltar | Privacy | 6 | None |
| [Greece Law 4624/2019](/docs/frameworks/europe/greece-law4624) | Greece | Privacy | 6 | None |
| [Guernsey Data Protection Law 2017](/docs/frameworks/europe/guernsey-dpl) | Guernsey | Privacy | 5 | None |
| [Holy See Data Protection Framework](/docs/frameworks/europe/vatican-dp) | Holy See (Vatican) | Privacy | 5 | None |
| [Hungary Act CXII of 2011 (Infotv)](/docs/frameworks/europe/hungary-infotv) | Hungary | Privacy | 6 | None |
| [Iceland Act on Data Protection No. 90/2018](/docs/frameworks/europe/iceland-dpa) | Iceland | Privacy | 6 | None |
| [Ireland Data Protection Act 2018](/docs/frameworks/europe/ireland-dpa) | Ireland | Privacy | 6 | None |
| [Isle of Man Data Protection Act 2018](/docs/frameworks/europe/isle-of-man-dpa) | Isle of Man | Privacy | 5 | None |
| [Italy ACN Cybersecurity](/docs/frameworks/europe/italy-acn) | Italy | Government | 6 | 8 |
| [Jersey Data Protection Law 2018](/docs/frameworks/europe/jersey-dpl) | Jersey | Privacy | 5 | None |
| [Kosovo Law No. 06/L-082 on Protection of Personal Data](/docs/frameworks/europe/kosovo-lpdp) | Kosovo | Privacy | 5 | None |
| [Latvia Personal Data Processing Law 2018](/docs/frameworks/europe/latvia-dpa) | Latvia | Privacy | 6 | None |
| [Liechtenstein Data Protection Act (DSG) 2018](/docs/frameworks/europe/liechtenstein-dsg) | Liechtenstein | Privacy | 5 | None |
| [Lithuania Law on Legal Protection of Personal Data](/docs/frameworks/europe/lithuania-dpa) | Lithuania | Privacy | 6 | None |
| [Luxembourg Data Protection Law of 1 August 2018](/docs/frameworks/europe/luxembourg-dpa) | Luxembourg | Privacy | 6 | None |
| [Malta Data Protection Act (Cap. 586) 2018](/docs/frameworks/europe/malta-dpa) | Malta | Privacy | 6 | None |
| [Moldova Law No. 133 on Personal Data Protection](/docs/frameworks/europe/moldova-law133) | Moldova | Privacy | 5 | None |
| [Monaco Law No. 1.165 on Personal Data](/docs/frameworks/europe/monaco-law1165) | Monaco | Privacy | 5 | None |
| [Montenegro Law on Personal Data Protection](/docs/frameworks/europe/montenegro-lpdp) | Montenegro | Privacy | 5 | None |
| [Netherlands NEN 7510](/docs/frameworks/europe/netherlands-nen7510) | Netherlands | Healthcare | 6 | 9 |
| [North Macedonia Law on Personal Data Protection 2020](/docs/frameworks/europe/north-macedonia-lpdp) | North Macedonia | Privacy | 5 | None |
| [Norway NSM Basic Principles](/docs/frameworks/europe/norway-nsm) | Norway | Government | 6 | 8 |
| [Poland KSC Act](/docs/frameworks/europe/poland-cyber-act) | Poland | Government | 6 | 14 |
| [Portugal Law No. 58/2019](/docs/frameworks/europe/portugal-lei58) | Portugal | Privacy | 6 | None |
| [Romania Law No. 190/2018](/docs/frameworks/europe/romania-law190) | Romania | Privacy | 6 | None |
| [Russia Federal Law 152-FZ on Personal Data](/docs/frameworks/europe/russia-152fz) | Russia | Privacy | 5 | None |
| [Russia Federal Law 187-FZ on Critical Information Infrastructure](/docs/frameworks/europe/russia-187fz) | Russia | Government | 6 | None |
| [San Marino Law 171/2018 on Data Protection](/docs/frameworks/europe/san-marino-dp) | San Marino | Privacy | 6 | None |
| [Serbia Law on Personal Data Protection 2018](/docs/frameworks/europe/serbia-lpdp) | Serbia | Privacy | 5 | None |
| [Slovakia Act No. 18/2018 on Personal Data Protection](/docs/frameworks/europe/slovakia-dpa) | Slovakia | Privacy | 6 | None |
| [Slovenia Personal Data Protection Act (ZVOP-2)](/docs/frameworks/europe/slovenia-zvop2) | Slovenia | Privacy | 7 | None |
| [Spain ENS (RD 311/2022)](/docs/frameworks/europe/spain-ens) | Spain | Government | 6 | 10 |
| [Sweden Data Protection Act (2018:218)](/docs/frameworks/europe/sweden-dpa) | Sweden | Privacy | 6 | None |
| [Switzerland revFADP](/docs/frameworks/europe/switzerland-revfadp) | Switzerland | Privacy | 6 | 8 |
| [TISAX](/docs/frameworks/europe/tisax) | Germany | Automotive | 6 | 12 |
| [UK Cyber Essentials](/docs/frameworks/europe/uk-cyber-essentials) | United Kingdom | Government | 6 | 12 |
| [UK GDPR / DPA 2018](/docs/frameworks/europe/uk-gdpr-dpa2018) | United Kingdom | Privacy | 6 | 14 |
| [UK NCSC CAF](/docs/frameworks/europe/uk-ncsc-caf) | United Kingdom | Government | 6 | 14 |
| [Ukraine Law on Basic Principles of Cyber Security 2017](/docs/frameworks/europe/ukraine-cybersec) | Ukraine | Government | 6 | None |
| [Ukraine Law on Protection of Personal Data (2297-VI)](/docs/frameworks/europe/ukraine-pdpl) | Ukraine | Privacy | 5 | None |
# Ireland Data Protection Act 2018 (/docs/frameworks/europe/ireland-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | IE DPA |
| Region | Europe |
| Country or scope | Ireland |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers IE DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `IE-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Ireland by the Data Protection Act 2018). | Scan |
| `IE-DPA-71` Integrity and Confidentiality of Processing | Personal data must be processed in a manner that ensures appropriate security, including protection against unauthorised or unlawful processing, which requires processing software to carry known, assessable versions (DPA 2018 s.71(1)(f); GDPR Art. 5(1)(f)). | Scan |
| `IE-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Data Protection Act 2018). | Scan |
| `IE-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Data Protection Act 2018). | Scan |
| `IE-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Data Protection Act 2018). | Scan |
| `IE-DPA-75` Technical and Organisational Measures | Controllers must implement appropriate technical and organisational measures to ensure and demonstrate compliant processing; unambiguous, pinned component versions in processing systems are a baseline such measure (DPA 2018 s.75). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to IE DPA.
# Isle of Man Data Protection Act 2018 (/docs/frameworks/europe/isle-of-man-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | IM DPA 2018 |
| Region | Europe |
| Country or scope | Isle of Man |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers IM DPA 2018
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IM-AGDPR-32` Security of Processing | Controllers and processors must implement technical and organisational measures ensuring confidentiality, integrity, availability and resilience of processing systems, including software integrity verification (Applied GDPR Art. 32) | Scan |
| `IM-AGDPR-5F` Integrity and Confidentiality Principle | Personal data must be processed with appropriate security, requiring known versions of every processing component so security state is assessable (Applied GDPR Art. 5(1)(f)) | Scan |
| `IM-AGDPR-30` Records of Processing Activities | Controllers and processors must maintain records of processing activities, including a named, populated inventory of processing software (Applied GDPR Art. 30) | Scan |
| `IM-AGDPR-28` Processor Guarantees | Controllers may only engage processors providing sufficient guarantees, requiring supplier visibility for third-party components that handle personal data (Applied GDPR Art. 28) | Scan |
| `IM-AGDPR-33` Breach Notification Readiness | 72-hour breach notification requires the ability to identify precisely which software components an incident affected (Applied GDPR Arts. 33-34) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to IM DPA 2018.
# Italy ACN Cybersecurity (/docs/frameworks/europe/italy-acn)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Agenzia per la Cybersicurezza Nazionale guidelines - National Cybersecurity Perimeter, supply chain.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ACN IT |
| Region | Europe |
| Country or scope | Italy |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ACN IT
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for ACN IT.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ACN IT and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IT-ACN-INV` ICT Asset List | Perimeter entities must compile and keep updated a list of the ICT assets supporting their essential functions; a populated software component inventory is the direct SBOM analogue (DL 105/2019 Art. 1(2)(b)) | Scan |
| `IT-ACN-CVCN` Supply-Chain Evaluation (CVCN) | ICT goods and services intended for perimeter networks are subject to national evaluation before procurement, which requires the supplier of each component to be known and recorded (DL 105/2019, CVCN procurement-scrutiny provision) | Scan |
| `IT-ACN-MEAS-INT` Integrity Security Measures | The implementing decree prescribes technical measures protecting the integrity of perimeter systems; integrity hashes across deployed components provide verifiable evidence (DPCM 81/2021, security-measures annex) | Scan |
| `IT-ACN-VULN` Vulnerability and Update Management | Prescribed measures include managing vulnerabilities and keeping systems updated, which is only demonstrable when each component's version is recorded (DPCM 81/2021, vulnerability-management measures) | Scan |
| `IT-ACN-INCIDENT` Incident Notification Readiness | Perimeter entities must notify significant incidents to the Italian CSIRT within short deadlines; scoping an incident that fast requires components to be unambiguously identifiable (DL 105/2019, incident-notification obligation) | Scan |
| `IT-ACN-DOC` Maintained Asset Documentation | Asset lists must be transmitted to the authorities and periodically updated, presupposing dated, identifiable documentation of the software estate (DL 105/2019, asset-list update and transmission duty) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | -------------------------------------------------- |
| `ACN-PSNC-1` | Perimeter Identification and Asset Register |
| `ACN-PSNC-2` | ICT Supply Chain Security Assessment |
| `ACN-PSNC-3` | Notification of Cyber Incidents to CSIRT Italia |
| `ACN-PSNC-4` | Minimum Technical Security Measures |
| `ACN-PSNC-5` | SBOM and Software Component Transparency |
| `ACN-PSNC-6` | Continuity and Recovery Planning |
| `ACN-PSNC-7` | Privileged Access Management for Perimeter Systems |
| `ACN-PSNC-8` | Security Audit and Penetration Testing |
## Policy templates
Written for ACN IT:
* ACN/PSNC: Privacy Notice
* ACN/PSNC: Breach Notification Procedure
* ACN/PSNC: ICT Supply Chain Security Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ACN IT.
# Jersey Data Protection Law 2018 (/docs/frameworks/europe/jersey-dpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | JE DPL 2018 |
| Region | Europe |
| Country or scope | Jersey |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers JE DPL 2018
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `JE-DPL-21` Security of Personal Data | Controllers and processors must implement technical and organisational measures proportionate to risk, ensuring ongoing confidentiality, integrity, availability and resilience of processing systems (Data Protection (Jersey) Law 2018, Art. 21) | Scan |
| `JE-DPL-PRIN` Integrity and Confidentiality Principle | Personal data must be processed in a manner that ensures its appropriate security, requiring known versions of every processing component (Data Protection (Jersey) Law 2018, Art. 8 data-protection principles) | Scan |
| `JE-DPL-REC` Record-Keeping Duty | Controllers and processors must keep records of their processing activities, including a named, populated inventory of processing software (Data Protection (Jersey) Law 2018, record-keeping provisions) | Scan |
| `JE-DPL-PROC` Processor Engagement Guarantees | A controller may only use processors providing sufficient guarantees of compliant processing, requiring supplier visibility for third-party components (Data Protection (Jersey) Law 2018, processor provisions) | Scan |
| `JE-DPL-BRE` Breach Assessment Readiness | Personal-data-breach notification duties require the ability to identify exactly which software components were involved in an incident (Data Protection (Jersey) Law 2018, breach-notification provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to JE DPL 2018.
# Kosovo Law No. 06/L-082 on Protection of Personal Data (/docs/frameworks/europe/kosovo-lpdp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | XK LPDP |
| Region | Europe |
| Country or scope | Kosovo |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers XK LPDP
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `XK-LPDP-SEC` Security of Processing | Controllers and processors must implement appropriate technical measures ensuring confidentiality, integrity and resilience of processing systems; integrity hashes on software components evidence protection against tampering (Law 06/L-082 GDPR Art. 32-equivalent security obligation) | Scan |
| `XK-LPDP-ROP` Records of Processing Activities | Controllers must maintain records of processing activities, which presupposes an inventory of the software systems and components that carry out the processing (Law 06/L-082 GDPR Art. 30-equivalent records obligation) | Scan |
| `XK-LPDP-PROC` Processor Guarantees | Processing may be entrusted only to processors offering sufficient guarantees of appropriate safeguards, requiring visibility into the suppliers of each software component in the chain (Law 06/L-082 GDPR Art. 28-equivalent processor obligation) | Scan |
| `XK-LPDP-BRE` Breach Notification Readiness | Personal data breaches must be notified to the Information and Privacy Agency within 72 hours, requiring the ability to identify exactly which components were affected (Law 06/L-082 GDPR Art. 33-equivalent breach obligation) | Scan |
| `XK-LPDP-DBD` Data Protection by Design | State-of-the-art safeguards must be integrated into processing systems from the design stage, which requires knowing the exact versions of the components in use (Law 06/L-082 GDPR Art. 25-equivalent by-design obligation) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to XK LPDP.
# Latvia Personal Data Processing Law 2018 (/docs/frameworks/europe/latvia-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | LV DPA |
| Region | Europe |
| Country or scope | Latvia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers LV DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LV-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Latvia by the Personal Data Processing Law). | Scan |
| `LV-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Personal Data Processing Law). | Scan |
| `LV-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Personal Data Processing Law). | Scan |
| `LV-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Personal Data Processing Law). | Scan |
| `LV-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Personal Data Processing Law). | Scan |
| `LV-DPA-A24` Demonstrable Compliance | The controller is responsible for, and must be able to demonstrate, compliance of its processing; a machine-readable software inventory (SPDX or CycloneDX) supports demonstrable accountability (GDPR Art. 24 and Art. 5(2); the Personal Data Processing Law). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LV DPA.
# Liechtenstein Data Protection Act (DSG) 2018 (/docs/frameworks/europe/liechtenstein-dsg)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | LI DSG |
| Region | Europe |
| Country or scope | Liechtenstein |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers LI DSG
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LI-DSG-32` Security of Processing | Appropriate technical measures must ensure ongoing confidentiality, integrity, availability and resilience of processing systems; integrity hashes on software components evidence this control (DSG 2018 in conjunction with GDPR Art. 32, applicable via the EEA Agreement) | Scan |
| `LI-DSG-30` Records of Processing Activities | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components carrying out the processing (DSG 2018 in conjunction with GDPR Art. 30) | Scan |
| `LI-DSG-28` Processor Guarantees | Only processors providing sufficient guarantees of appropriate technical and organizational measures may be engaged, requiring visibility into the suppliers of the software components in the processing chain (DSG 2018 in conjunction with GDPR Art. 28) | Scan |
| `LI-DSG-33` Breach Notification Readiness | Personal data breaches must be notified to the Datenschutzstelle within 72 hours, requiring the ability to identify exactly which software components were affected (DSG 2018 in conjunction with GDPR Art. 33) | Scan |
| `LI-DSG-25` Data Protection by Design and by Default | State-of-the-art safeguards must be built into processing systems from the design stage, which requires knowing the exact versions of the components in use (DSG 2018 in conjunction with GDPR Art. 25) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LI DSG.
# Lithuania Law on Legal Protection of Personal Data (/docs/frameworks/europe/lithuania-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | LT DPA |
| Region | Europe |
| Country or scope | Lithuania |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers LT DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `LT-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Lithuania by the Law on Legal Protection of Personal Data). | Scan |
| `LT-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Law on Legal Protection of Personal Data). | Scan |
| `LT-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Law on Legal Protection of Personal Data). | Scan |
| `LT-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Law on Legal Protection of Personal Data). | Scan |
| `LT-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Law on Legal Protection of Personal Data). | Scan |
| `LT-DPA-A24` Accountability of the Controller | Responsibility for processing operations must be demonstrable, which includes documented provenance of who produced the record of the software estate that processes personal data (GDPR Art. 24 and Art. 5(2); the Law on Legal Protection of Personal Data). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LT DPA.
# Luxembourg Data Protection Law of 1 August 2018 (/docs/frameworks/europe/luxembourg-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | LU DPA |
| Region | Europe |
| Country or scope | Luxembourg |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers LU DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LU-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Luxembourg by the Law of 1 August 2018). | Scan |
| `LU-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Law of 1 August 2018). | Scan |
| `LU-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Law of 1 August 2018). | Scan |
| `LU-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Law of 1 August 2018). | Scan |
| `LU-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Law of 1 August 2018). | Scan |
| `LU-DPA-A24` Accountability of the Controller | Responsibility for processing operations must be demonstrable, which includes documented provenance of who produced the record of the software estate that processes personal data (GDPR Art. 24 and Art. 5(2); the Law of 1 August 2018). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LU DPA.
# Malta Data Protection Act (Cap. 586) 2018 (/docs/frameworks/europe/malta-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MT DPA |
| Region | Europe |
| Country or scope | Malta |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MT DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MT-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Malta by the Data Protection Act (Cap. 586)). | Scan |
| `MT-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Data Protection Act (Cap. 586)). | Scan |
| `MT-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Data Protection Act (Cap. 586)). | Scan |
| `MT-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Data Protection Act (Cap. 586)). | Scan |
| `MT-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Data Protection Act (Cap. 586)). | Scan |
| `MT-DPA-A24` Demonstrable Compliance | The controller is responsible for, and must be able to demonstrate, compliance of its processing; a machine-readable software inventory (SPDX or CycloneDX) supports demonstrable accountability (GDPR Art. 24 and Art. 5(2); the Data Protection Act (Cap. 586)). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MT DPA.
# Moldova Law No. 133 on Personal Data Protection (/docs/frameworks/europe/moldova-law133)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MD L133 |
| Region | Europe |
| Country or scope | Moldova |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MD L133
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MD-133-30` Security and Confidentiality of Processing | Controllers must apply organizational and technical measures protecting personal data against destruction, alteration and unauthorized access; verifiable integrity hashes on the software components processing data evidence this control (Law 133 Art. 30) | Scan |
| `MD-133-30-PROC` Processor Guarantees | When processing is carried out on the controller's behalf, the processor must provide sufficient guarantees of technical security measures, requiring knowledge of the suppliers behind the processing software (Law 133 Art. 30 processor provisions) | Scan |
| `MD-133-REG` Registration of Processing Operations | Controllers must notify and register their processing operations with the National Center, which presupposes an inventory of the software systems performing the processing (Law 133 notification/registration provisions) | Scan |
| `MD-133-VER` Currency of Processing Systems | Maintaining adequate security over time requires knowing the exact versions of deployed software components so that weaknesses can be assessed and corrected (Law 133 Art. 30 ongoing-security obligation) | Scan |
| `MD-133-DOC` Documented Accountability | Controllers must be able to demonstrate the measures taken to protect processing, supported by a formally identified and timestamped record of the software in use (Law 133 accountability obligations) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MD L133.
# Monaco Law No. 1.165 on Personal Data (/docs/frameworks/europe/monaco-law1165)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MC L1165 |
| Region | Europe |
| Country or scope | Monaco |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MC L1165
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MC-1165-17` Security Precautions | Anyone processing personal information must take all useful precautions to preserve its security and prevent it from being altered, damaged or accessed by unauthorized third parties; component integrity hashes evidence protection against alteration (Law 1.165 Art. 17) | Scan |
| `MC-1165-DECL` Declaration of Automated Processing | Automated processing of personal information must be declared to or authorized by the CCIN before implementation, which presupposes an enumeration of the systems and software carrying out the processing (Law 1.165 declaration/authorization provisions) | Scan |
| `MC-1165-INV` Processing System Inventory | Fulfilling declaration and security duties requires knowing which software components make up each processing system (Law 1.165 controller obligations) | Scan |
| `MC-1165-SUB` Outsourced Processing Accountability | Where processing is carried out through service providers, the declarant remains responsible for the required security precautions, requiring visibility into the suppliers behind the processing software (Law 1.165 third-party processing provisions) | Scan |
| `MC-1165-VER` Maintained Security of Systems | Security precautions must remain effective over the lifetime of the processing, which requires knowing exact versions of deployed components so weaknesses can be assessed (Law 1.165 Art. 17 ongoing-security duty) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MC L1165.
# Montenegro Law on Personal Data Protection (/docs/frameworks/europe/montenegro-lpdp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | ME LPDP |
| Region | Europe |
| Country or scope | Montenegro |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers ME LPDP
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ME-LPDP-SEC` Protection of Personal Data Filing Systems | Controllers must apply technical and organizational measures protecting personal data against loss, destruction, alteration and unauthorized access; integrity hashes on the software components handling data evidence this control (ME LPDP data-security provisions) | Scan |
| `ME-LPDP-REC` Records of Filing Systems | Controllers must keep records of the personal data filing systems they establish, which presupposes an inventory of the software systems and components that operate them (ME LPDP records provisions) | Scan |
| `ME-LPDP-PROC` Processing by Processors | Processing entrusted to a processor must be governed by a contract ensuring the same level of protection, requiring the controller to know the suppliers behind its processing software (ME LPDP processor provisions) | Scan |
| `ME-LPDP-DOC` Documented Protection Measures | Controllers must be able to demonstrate the protective measures applied, supported by a formally identified and timestamped record of the software processing personal data (ME LPDP accountability duties) | Scan |
| `ME-LPDP-VER` Adequacy of Deployed Software | Keeping protection measures adequate over time requires knowing exact versions of deployed components so weaknesses can be identified and corrected (ME LPDP ongoing-security duty) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ME LPDP.
# Netherlands NEN 7510 (/docs/frameworks/europe/netherlands-nen7510)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Dutch healthcare information security standard - access control, integrity, availability, audit.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NEN 7510 |
| Region | Europe |
| Country or scope | Netherlands |
| Sector | Healthcare |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NEN 7510
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for NEN 7510.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for NEN 7510 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NL-NEN7510-ASSET` Inventory of Assets | Assets associated with information and processing facilities must be identified and inventoried; a populated software component inventory is the SBOM-level expression of this control (NEN 7510-2, asset-inventory control per ISO 27002 lineage) | Scan |
| `NL-NEN7510-VULN` Technical Vulnerability Management | Information about technical vulnerabilities of systems in use must be obtained and exposure evaluated in a timely fashion, which requires each component's version to be known (NEN 7510-2, technical vulnerability management control) | Scan |
| `NL-NEN7510-INT` Integrity of Health Information Systems | Health information systems must protect the integrity of patient data, evidenced at the software level by verifiable integrity hashes over deployed components (NEN 7510-2, integrity controls) | Scan |
| `NL-NEN7510-SUP` Supplier Relationships | Security requirements must be agreed and monitored across supplier relationships touching health information, presupposing that the supplier behind each software component is recorded (NEN 7510-2, supplier relationship controls) | Scan |
| `NL-NEN7510-ID` Unambiguous Asset Identification | Effective access control and auditing of healthcare systems require the software estate to be unambiguously identifiable through standard identifiers (NEN 7510-2, asset management and audit controls) | Scan |
| `NL-NEN7510-DOC` Documented Operating Environment | Operating procedures and system documentation must be maintained and available; an identified, timestamped SBOM document is part of a documented operating environment (NEN 7510-2, documented operating procedures control) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ----------------------------------------------------- |
| `NEN7510-5` | Information Security Policies (Clause 5) |
| `NEN7510-6` | Organisation of Information Security (Clause 6) |
| `NEN7510-8` | Asset Management (Clause 8) |
| `NEN7510-9` | Access Control for Patient Data (Clause 9) |
| `NEN7510-10` | Cryptography for Health Data (Clause 10) |
| `NEN7510-12` | Operations Security (Clause 12) |
| `NEN7510-14` | System Acquisition and Secure Development (Clause 14) |
| `NEN7510-16` | Information Security Incident Management (Clause 16) |
| `NEN7510-18` | Compliance and Privacy Obligations (Clause 18) |
## Policy templates
Written for NEN 7510:
* NEN 7510: Privacy Notice (Healthcare)
* NEN 7510: Information Security Incident & Breach Notification Procedure
* NEN 7510: Access Control Policy for Patient Data
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NEN 7510.
# EU NIS2 Directive (/docs/frameworks/europe/nis2)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Network and information system security: supply chain measures, vulnerability management.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NIS2 |
| Region | Europe |
| Country or scope | European Union |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NIS2
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 13 controls from Safeguard's control catalog for NIS2.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for NIS2 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NIS2-21.2D` Supply Chain Security | Risk-management measures must address supply chain security including the security aspects of relationships with direct suppliers, presupposing known suppliers for software components (NIS2 Art. 21(2)(d)) | Scan |
| `NIS2-21.2E` Vulnerability Handling and Disclosure | Measures must cover security in acquisition, development and maintenance including vulnerability handling, which requires components identifiable against vulnerability data (NIS2 Art. 21(2)(e)) | Scan |
| `NIS2-21.2A` Risk Analysis Foundation | Policies on risk analysis and system security presuppose an inventory of the software components comprising network and information systems (NIS2 Art. 21(2)(a)) | Scan |
| `NIS2-23` Incident Reporting Readiness | Significant incidents must be reported within tight deadlines (24h early warning), which requires knowing the versions of affected software to assess impact quickly (NIS2 Art. 23) | Scan |
| `NIS2-CVD-CONTACT` Coordinated Disclosure Contact | NIS2 promotes coordinated vulnerability disclosure, which requires a reachable contact for the software's producer in its documentation (NIS2 Art. 12 and Art. 21(2)(e), coordinated vulnerability disclosure provisions) | Scan |
| `NIS2-INTEGRITY` System Integrity Measures | Measures protecting the security of network and information systems include verifying the integrity of the software deployed, supported by component hashes (NIS2 Art. 21(2), security measures) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | -------------------------------------------------------------------------------- |
| `NIS2-ART20` | Establish Cybersecurity Governance at Management Level |
| `NIS2-ART21A` | Implement Policies on Risk Analysis and Information System Security |
| `NIS2-ART21B` | Implement Incident Handling Procedures |
| `NIS2-ART21C` | Implement Business Continuity and Disaster Recovery |
| `NIS2-ART21D` | Manage Supply Chain Security |
| `NIS2-ART21E` | Implement Secure Network and Information Systems Acquisition and Development |
| `NIS2-ART21F` | Implement Policies and Procedures to Assess Cybersecurity Measures Effectiveness |
| `NIS2-ART21G` | Implement Cybersecurity Hygiene and Training |
| `NIS2-ART21H` | Implement Cryptographic and Encryption Policies |
| `NIS2-ART21I` | Implement Human Resources Security and Access Control |
| `NIS2-ART21J` | Use Multi-Factor Authentication and Secure Communications |
| `NIS2-ART23` | Report Significant Incidents to CSIRT Within 24/72 Hours |
| `NIS2-ART22` | Establish Vulnerability Coordination and Disclosure |
## Policy templates
Written for NIS2:
* NIS2 Cybersecurity Risk Management Policy
* NIS2 Significant Incident Reporting Policy
* NIS2 Supply Chain Cybersecurity Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NIS2.
# North Macedonia Law on Personal Data Protection 2020 (/docs/frameworks/europe/north-macedonia-lpdp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MK LPDP |
| Region | Europe |
| Country or scope | North Macedonia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MK LPDP
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `MK-LPDP-SEC` Security of Processing | Controllers and processors must implement technical measures ensuring the ongoing confidentiality, integrity and resilience of processing systems; integrity hashes on software components evidence this control (LPDP 2020 GDPR Art. 32-equivalent security obligation) | Scan |
| `MK-LPDP-ROP` Records of Processing Activities | Controllers must keep records of their processing activities, which presupposes an inventory of the software systems and components performing the processing (LPDP 2020 GDPR Art. 30-equivalent records obligation) | Scan |
| `MK-LPDP-PROC` Processor Guarantees | Only processors providing sufficient guarantees of appropriate technical measures may be engaged, requiring visibility into who supplies each component of the processing software (LPDP 2020 GDPR Art. 28-equivalent processor obligation) | Scan |
| `MK-LPDP-BRE` Breach Notification Readiness | Personal data breaches must be notified to the Agency within 72 hours, requiring the ability to identify precisely which software components were affected (LPDP 2020 GDPR Art. 33-equivalent breach obligation) | Scan |
| `MK-LPDP-DBD` Data Protection by Design | State-of-the-art safeguards must be embedded in processing systems from design onward, which requires knowing the exact versions of components in use (LPDP 2020 GDPR Art. 25-equivalent by-design obligation) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MK LPDP.
# Norway NSM Basic Principles (/docs/frameworks/europe/norway-nsm)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Norwegian National Security Authority basic principles for ICT security - identify, protect, detect, respond.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NSM NO |
| Region | Europe |
| Country or scope | Norway |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NSM NO
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for NSM NO.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for NSM NO and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NO-NSM-12` Map Devices and Software | Organizations must map and maintain an overview of the devices and software in use in their ICT environment; a populated software component inventory is the direct SBOM analogue (NSM Basic Principles, Principle 1.2) | Scan |
| `NO-NSM-12V` Versioned Software Overview | The software overview must be precise enough to support security decisions, meaning each mapped component should carry its version (NSM Basic Principles, Principle 1.2) | Scan |
| `NO-NSM-21` Security in Procurement and Development | Security must be addressed in procurement and development processes, which requires knowing which suppliers stand behind the software components brought into the environment (NSM Basic Principles, procurement/development principle in the Protect category) | Scan |
| `NO-NSM-UPD` Keep Software Updated | Software must be kept updated and unmanaged version drift avoided; vague or floating version declarations (latest, wildcards, ranges) defeat controlled update management (NSM Basic Principles, software-update principle in the Protect category) | Scan |
| `NO-NSM-INT` Protect Integrity of the ICT Estate | The Protect function requires safeguarding systems against unauthorized change; cryptographic hashes over deployed components provide verifiable integrity evidence (NSM Basic Principles, Protect-category integrity principles) | Scan |
| `NO-NSM-RESP` Incident Response Readiness | Detection and response require quickly determining which assets are affected by an incident, which presupposes unambiguous component identification (NSM Basic Principles, Detect/Respond categories) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | -------------------------------------------------- |
| `NSM-1.1` | Identify and Categorise Assets (Principle 1.x) |
| `NSM-1.2` | Risk and Vulnerability Assessment (Principle 1.x) |
| `NSM-2.1` | Access Control and Least Privilege (Principle 2.x) |
| `NSM-2.2` | Network Security and Segmentation (Principle 2.x) |
| `NSM-2.3` | Patch and Vulnerability Management (Principle 2.x) |
| `NSM-3.1` | Security Monitoring and Logging (Principle 3.x) |
| `NSM-4.1` | Incident Response and Recovery (Principle 4.x) |
| `NSM-4.2` | Business Continuity and Resilience (Principle 4.x) |
## Policy templates
Written for NSM NO:
* NSM: Personvernerklæring / Privacy Notice
* NSM: Information Security Policy
* NSM: Incident Response and Breach Notification Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NSM NO.
# Poland KSC Act (/docs/frameworks/europe/poland-cyber-act)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Polish Act on the National Cybersecurity System - operators of essential services, CSIRT obligations.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | KSC PL |
| Region | Europe |
| Country or scope | Poland |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers KSC PL
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for KSC PL.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for KSC PL and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `PL-KSC-8-RISK` Systematic Risk Assessment | Operators of essential services must implement a security management system including systematic risk estimation, which requires an inventory of the software components their information systems comprise (KSC Act Art. 8) | Scan |
| `PL-KSC-8-SEC` Proportionate Technical Measures | Operators must apply technical and organisational measures proportionate to the assessed risk, including maintaining information systems with known, updatable software versions (KSC Act Art. 8) | Scan |
| `PL-KSC-8-INTEG` System Integrity Protection | Required security measures include protecting information systems against unauthorised modification, supported by verifiable integrity hashes for deployed software (KSC Act Art. 8 security-measures obligation) | Scan |
| `PL-KSC-DOC` Security Documentation | Operators must produce and maintain documentation of information-system security, so machine-readable records must carry a document identity and creation timestamp (KSC Act documentation obligation, Art. 10) | Scan |
| `PL-KSC-11-INC` Incident Handling and Reporting | Serious incidents must be handled and reported to the competent CSIRT within 24 hours of detection, requiring rapid matching of deployed components against vulnerability identifiers (KSC Act Art. 11) | Scan |
| `PL-KSC-VULN` Vulnerability Information Management | Operators must collect information about cybersecurity threats and vulnerabilities of the systems used to provide the essential service, which requires complete component records with names and versions (KSC Act vulnerability-monitoring obligation) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | ------------------------------------------------ |
| `KSC-Art5` | Essential Service Operator: Identification |
| `KSC-Art6` | OES Cybersecurity System |
| `KSC-Art7` | OES Risk Management |
| `KSC-Art8` | OES Incident Reporting |
| `KSC-Art9` | OES Security Audit |
| `KSC-Art14` | CSIRT Responsibilities |
| `KSC-Art15` | CSIRT Cooperation and Information Exchange |
| `KSC-Art21` | Digital Service Provider: Cybersecurity Measures |
| `KSC-Art22` | Digital Service Provider: Incident Handling |
| `KSC-Art23` | Digital Service Provider: Supervisory Measures |
| `KSC-Art24` | Digital Service Provider: Non-EU Establishment |
| `KSC-Art26` | Sectoral CSIRT Designation |
| `KSC-Art27` | Sectoral CSIRT Tasks |
| `KSC-Art28` | Cooperation Between CSIRTs and Authorities |
## Policy templates
Written for KSC PL:
* Poland KSC Incident Response and Reporting Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KSC PL.
# Portugal Law No. 58/2019 (/docs/frameworks/europe/portugal-lei58)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | PT Lei 58 |
| Region | Europe |
| Country or scope | Portugal |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers PT Lei 58
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `PT-L58-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Portugal by Law No. 58/2019). | Scan |
| `PT-L58-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside Law No. 58/2019). | Scan |
| `PT-L58-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; Law No. 58/2019). | Scan |
| `PT-L58-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; Law No. 58/2019). | Scan |
| `PT-L58-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; Law No. 58/2019). | Scan |
| `PT-L58-A24` Demonstrable Compliance | The controller is responsible for, and must be able to demonstrate, compliance of its processing; a machine-readable software inventory (SPDX or CycloneDX) supports demonstrable accountability (GDPR Art. 24 and Art. 5(2); Law No. 58/2019). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PT Lei 58.
# Romania Law No. 190/2018 (/docs/frameworks/europe/romania-law190)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | RO L190 |
| Region | Europe |
| Country or scope | Romania |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers RO L190
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `RO-L190-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Romania by Law No. 190/2018). | Scan |
| `RO-L190-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside Law No. 190/2018). | Scan |
| `RO-L190-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; Law No. 190/2018). | Scan |
| `RO-L190-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; Law No. 190/2018). | Scan |
| `RO-L190-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; Law No. 190/2018). | Scan |
| `RO-L190-A25` Data Protection by Design | Data-protection safeguards must be built into processing systems at design time; pinning components to specific, unambiguous versions rather than floating ranges is a baseline design-time control (GDPR Art. 25; Law No. 190/2018). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to RO L190.
# Russia Federal Law 152-FZ on Personal Data (/docs/frameworks/europe/russia-152fz)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | RU 152-FZ |
| Region | Europe |
| Country or scope | Russia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers RU 152-FZ
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `RU-152FZ-19` Security of Personal Data | Operators must take technical measures to prevent unauthorized access to, destruction, modification or copying of personal data, including protection against malicious software; integrity hashes on components evidence tamper protection (152-FZ Art. 19) | Scan |
| `RU-152FZ-19-2` Accounting of Information Systems and Carriers | Security measures include keeping account of the machine media and information systems that process personal data, which for software means an inventory of components with known versions (152-FZ Art. 19(2)) | Scan |
| `RU-152FZ-18-1` Internal Accountability Measures | Operators must adopt and document internal measures ensuring compliance, including internal audit and documentation of processing systems; a machine-readable software inventory supports this accountability duty (152-FZ Art. 18.1) | Scan |
| `RU-152FZ-6-3` Entrusted Processing Obligations | Processing may be entrusted to a third party only under an instruction obliging that party to observe data security requirements, requiring visibility into which suppliers stand behind the software in use (152-FZ Art. 6(3)) | Scan |
| `RU-152FZ-21` Incident Notification Readiness | Since the 2022 amendments operators must notify Roskomnadzor of personal data incidents within 24 hours, which requires immediately identifying the affected software components (152-FZ Art. 21, as amended by Law No. 266-FZ of 2022) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to RU 152-FZ.
# Russia Federal Law 187-FZ on Critical Information Infrastructure (/docs/frameworks/europe/russia-187fz)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | RU 187-FZ |
| Region | Europe |
| Country or scope | Russia |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers RU 187-FZ
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `RU-187FZ-9` Duties of CII Subjects | CII subjects must prevent unlawful access to information processed by significant objects and prevent its destruction or modification; verifiable integrity hashes across software components evidence tamper protection (187-FZ Art. 9) | Scan |
| `RU-187FZ-7` Categorization of CII Objects | CII objects must be categorized by significance and entered in the state register, which presupposes that each system is named and its software composition enumerated (187-FZ Art. 7) | Scan |
| `RU-187FZ-10` Security System for Significant Objects | Significant CII objects must operate under a security system whose functions include continuous inventory and monitoring of the object's software assets (187-FZ Art. 10) | Scan |
| `RU-187FZ-11` FSTEC Security Requirements and Update Management | Security requirements established for significant objects include vulnerability analysis and controlled software updates, which requires knowing the exact version of every deployed component (187-FZ Art. 11 with FSTEC Order No. 239) | Scan |
| `RU-187FZ-239-SUP` Trusted Software Acquisition | FSTEC requirements for significant objects address security during acquisition and use of software, favoring components whose origin and supplier are known and verifiable (187-FZ implementing requirements, FSTEC Order No. 239) | Scan |
| `RU-187FZ-INC` Incident Reporting Readiness | CII subjects must immediately inform the GosSOPKA system of computer incidents, which requires machine-usable identification of the affected software components (187-FZ Art. 9 incident-reporting duty) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to RU 187-FZ.
# San Marino Law 171/2018 on Data Protection (/docs/frameworks/europe/san-marino-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SM Law 171 |
| Region | Europe |
| Country or scope | San Marino |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SM Law 171
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SM-171-SEC` Security of Processing | Controllers and processors must adopt appropriate technical and organizational measures ensuring the integrity and confidentiality of processing systems; integrity hashes across processing components evidence those measures (Law 171/2018, GDPR Art. 32-equivalent security obligation) | Scan |
| `SM-171-REC` Records of Processing Activities | Controllers must maintain records of their processing activities, which requires an enumerable, named inventory of the software components performing the processing (Law 171/2018, GDPR Art. 30-equivalent record-keeping duty) | Scan |
| `SM-171-PROC` Processor Guarantees | Processing on behalf of a controller may be entrusted only to processors offering sufficient guarantees, so third-party software components must carry named, accountable suppliers (Law 171/2018, GDPR Art. 28-equivalent processor obligations) | Scan |
| `SM-171-BREACH` Breach Notification Readiness | Personal-data breaches must be notified to the Garante without undue delay, which requires that affected components are identifiable via standard identifiers to assess breach scope quickly (Law 171/2018, GDPR Art. 33-equivalent breach-notification duty) | Scan |
| `SM-171-ACCU` Accuracy Principle | Personal data must be accurate and kept up to date, presuming each processing component is fully identified by both name and a concrete version (Law 171/2018, GDPR Art. 5-equivalent processing principles) | Scan |
| `SM-171-TRANS` Transparent Processing | Controllers owe data subjects transparent information about processing, which presupposes documented, uniquely identified and timestamped records of the processing environment (Law 171/2018, GDPR Art. 12-equivalent transparency duty) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SM Law 171.
# Serbia Law on Personal Data Protection 2018 (/docs/frameworks/europe/serbia-lpdp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | RS LPDP |
| Region | Europe |
| Country or scope | Serbia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers RS LPDP
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `RS-LPDP-50` Security of Processing | Controllers and processors must implement appropriate technical measures ensuring ongoing confidentiality, integrity and resilience of processing systems; verifiable integrity hashes on software components evidence this control (LPDP Art. 50, mirroring GDPR Art. 32) | Scan |
| `RS-LPDP-47` Records of Processing Activities | Controllers must maintain written records of their processing activities, which presupposes an inventory of the software systems and components that perform the processing (LPDP Art. 47, mirroring GDPR Art. 30) | Scan |
| `RS-LPDP-45` Processor and Third-Party Guarantees | Processing may be entrusted only to processors providing sufficient guarantees of appropriate safeguards, requiring knowledge of who supplies each software component in the processing chain (LPDP Art. 45, mirroring GDPR Art. 28) | Scan |
| `RS-LPDP-52` Breach Notification Readiness | Personal data breaches must be notified to the Commissioner within 72 hours, which requires the ability to identify precisely which software components were affected (LPDP Art. 52, mirroring GDPR Art. 33) | Scan |
| `RS-LPDP-42` Data Protection by Design | Safeguards reflecting the state of the art must be built into processing systems from the design stage, which requires knowing the exact versions of the components in use (LPDP Art. 42, mirroring GDPR Art. 25) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to RS LPDP.
# Slovakia Act No. 18/2018 on Personal Data Protection (/docs/frameworks/europe/slovakia-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SK DPA |
| Region | Europe |
| Country or scope | Slovakia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SK DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SK-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Slovakia by Act No. 18/2018 Coll., which restates these duties in Slovak law). | Scan |
| `SK-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside Act No. 18/2018 Coll., which restates these duties in Slovak law). | Scan |
| `SK-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; Act No. 18/2018 Coll., which restates these duties in Slovak law). | Scan |
| `SK-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; Act No. 18/2018 Coll., which restates these duties in Slovak law). | Scan |
| `SK-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; Act No. 18/2018 Coll., which restates these duties in Slovak law). | Scan |
| `SK-DPA-A24` Accountability of the Controller | Responsibility for processing operations must be demonstrable, which includes documented provenance of who produced the record of the software estate that processes personal data (GDPR Art. 24 and Art. 5(2); Act No. 18/2018 Coll., which restates these duties in Slovak law). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SK DPA.
# Slovenia Personal Data Protection Act (ZVOP-2) (/docs/frameworks/europe/slovenia-zvop2)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SI ZVOP-2 |
| Region | Europe |
| Country or scope | Slovenia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SI ZVOP-2
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SI-ZVOP2-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Slovenia by ZVOP-2). | Scan |
| `SI-ZVOP2-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside ZVOP-2). | Scan |
| `SI-ZVOP2-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; ZVOP-2). | Scan |
| `SI-ZVOP2-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; ZVOP-2). | Scan |
| `SI-ZVOP2-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; ZVOP-2). | Scan |
| `SI-ZVOP2-22` Processing Logs and Traceability | For higher-risk automated processing, the law mandates processing logs that record what was done to personal data and when; an SBOM with a document identifier and creation timestamp is the analogous traceability record for the software estate (ZVOP-2 Art. 22). | Scan |
| `SI-ZVOP2-23` Security of Special Processing | Large-scale 'special processing' information systems face heightened security duties linked to the Information Security Act, requiring complete knowledge of the software running in them, with every component named and versioned (ZVOP-2 Art. 23). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SI ZVOP-2.
# Spain ENS (RD 311/2022) (/docs/frameworks/europe/spain-ens)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Esquema Nacional de Seguridad - Spanish national security framework for public-sector systems.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ENS |
| Region | Europe |
| Country or scope | Spain |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ENS
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for ENS.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ENS and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ES-ENS-OPEXP1` Asset Inventory | Systems must maintain an inventory of assets identifying what the system is composed of; a populated software component inventory is the direct SBOM expression (RD 311/2022 Annex II, op.exp.1) | Scan |
| `ES-ENS-MAINT` Maintenance and Security Updates | Operational measures require ongoing maintenance and application of security updates to system components, demonstrable only when component versions are recorded (RD 311/2022 Annex II, maintenance/updates measure op.exp) | Scan |
| `ES-ENS-CONFIG` Security Configuration Management | Systems must apply and manage a controlled security configuration; unpinned or vague component versions (latest, wildcards, ranges) are incompatible with a controlled configuration baseline (RD 311/2022 Annex II, configuration measures op.exp) | Scan |
| `ES-ENS-INTEG` Integrity Protection | Protection measures require safeguarding the integrity of information and system elements; cryptographic hashes over deployed components provide verifiable integrity evidence (RD 311/2022 Annex II, integrity protection measures mp.info/mp.sw) | Scan |
| `ES-ENS-OPEXT` External Services and Supply Chain | Security must be assured when services or products are contracted from third parties, which requires knowing the supplier behind each component in the system (RD 311/2022 Annex II, external resources measures op.ext) | Scan |
| `ES-ENS-DOC` Security Documentation | The organizational framework requires approved, maintained security documentation of the system; an identified, timestamped SBOM document contributes to that documentation set (RD 311/2022 Annex II, organizational framework measures org) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ------------------------------------------------- |
| `ENS-OP.ACC-1` | Access Control Policy (op.acc) |
| `ENS-OP.EXP-1` | Operational Security Procedures (op.exp) |
| `ENS-MP.IF-1` | Physical Security of Facilities (mp.if) |
| `ENS-MP.PER-1` | Personnel Security Measures (mp.per) |
| `ENS-MP.EQ-1` | Equipment Protection (mp.eq) |
| `ENS-MP.COM-1` | Communications Protection (mp.com) |
| `ENS-MP.SI-1` | Secure Storage of Information (mp.si) |
| `ENS-MP.S-1` | Services Security (mp.s) |
| `ENS-MP.SW-1` | Software Security (mp.sw) |
| `ENS-MP.INFO-1` | Information Classification and Handling (mp.info) |
## Policy templates
Written for ENS:
* ENS: Privacy Notice (Spanish Public Administration)
* ENS: Data Subject Rights Procedure
* ENS: Information Security Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ENS.
# Sweden Data Protection Act (2018:218) (/docs/frameworks/europe/sweden-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SE DPA |
| Region | Europe |
| Country or scope | Sweden |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SE DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SE-DPA-A32` Security of Processing | Technical and organisational measures appropriate to the risk must safeguard systems that process personal data; verifiable integrity hashes on deployed software components evidence this control (GDPR Art. 32, as given effect in Sweden by the Data Protection Act (2018:218)). | Scan |
| `SE-DPA-A5F` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its security and integrity, which requires the processing software stack to consist of components with known, assessable versions (GDPR Art. 5(1)(f), applied alongside the Data Protection Act (2018:218)). | Scan |
| `SE-DPA-A30` Records of Processing Systems | Controllers and processors must maintain records of processing activities, which presupposes an inventory of the software systems and components through which personal data flows (GDPR Art. 30; the Data Protection Act (2018:218)). | Scan |
| `SE-DPA-A28` Processor and Vendor Accountability | Processing carried out on behalf of a controller may only use processors offering sufficient guarantees, so third-party software components in the processing chain must have identifiable suppliers (GDPR Art. 28; the Data Protection Act (2018:218)). | Scan |
| `SE-DPA-A33` Breach-Notification Readiness | Personal data breaches must be notified to the supervisory authority without undue delay and where feasible within 72 hours, which requires affected software components to be rapidly and unambiguously identifiable (GDPR Art. 33; the Data Protection Act (2018:218)). | Scan |
| `SE-DPA-A24` Demonstrable Compliance | The controller is responsible for, and must be able to demonstrate, compliance of its processing; a machine-readable software inventory (SPDX or CycloneDX) supports demonstrable accountability (GDPR Art. 24 and Art. 5(2); the Data Protection Act (2018:218)). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SE DPA.
# Switzerland revFADP (/docs/frameworks/europe/switzerland-revfadp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Revised Swiss Federal Act on Data Protection - notification, DPIA, data subject rights, processor duties.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | revFADP |
| Region | Europe |
| Country or scope | Switzerland |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers revFADP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for revFADP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for revFADP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CH-FADP-8` Data Security | Controllers and processors must ensure security of personal data appropriate to the risk through technical and organizational measures; verifiable integrity of the software inventory evidences such measures (revFADP Art. 8) | Scan |
| `CH-FADP-7` Privacy by Design and Default | Processing must be designed from planning onward to respect data protection rules; precisely pinned component versions (no wildcards, ranges or 'latest') reflect the disciplined engineering this design duty demands (revFADP Art. 7) | Scan |
| `CH-FADP-12` Record of Processing Activities | Controllers and processors must maintain a record of their processing activities; an enumerated inventory of the software components performing processing underpins that record (revFADP Art. 12) | Scan |
| `CH-FADP-9` Processing by Processors | Assignment of processing to a processor requires contractual or legal safeguards and controller oversight, which presupposes knowing the suppliers behind the software in the processing chain (revFADP Art. 9) | Scan |
| `CH-FADP-24` Breach Notification Readiness | Data security breaches likely to pose high risk must be reported to the FDPIC as quickly as possible; rapid impact assessment requires the versions of affected software components to be known (revFADP Art. 24) | Scan |
| `CH-FADP-16` Cross-Border Disclosure Readiness | Personal data may only be disclosed abroad when adequate protection is guaranteed; determining which systems disclose what requires components to be precisely identifiable (revFADP Art. 16) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | ------------------------------------------------------------- |
| `FADP-ART5` | Lawfulness, Purpose Limitation and Proportionality (Art. 5-7) |
| `FADP-ART19` | Privacy Notice and Transparency (Art. 19-20) |
| `FADP-ART21` | Data Subject Rights: Access and Rectification (Art. 21-22) |
| `FADP-ART24` | Data Breach Notification (Art. 24) |
| `FADP-ART16` | Cross-Border Data Transfers (Art. 16-18) |
| `FADP-ART30` | Data Protection Impact Assessment (Art. 30-34) |
| `FADP-PROC-1` | Data Processing Agreements with Processors |
| `FADP-SEC-1` | Technical and Organisational Security Measures |
## Policy templates
Written for revFADP:
* revFADP: Datenschutzerklärung / Privacy Notice
* revFADP: Cross-Border Data Transfer Policy
* revFADP: Data Breach Notification Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to revFADP.
# TISAX (/docs/frameworks/europe/tisax)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Automotive industry standard for information security in the supply chain.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Europe |
| Country or scope | Germany |
| Sector | Automotive |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers TISAX
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for TISAX.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for TISAX and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `TISAX-ASSET` Asset Inventory | Information assets, including software in use, must be identified and inventoried with assigned responsibility (VDA ISA catalogue: asset management controls, ISO 27001-aligned) | Scan |
| `TISAX-VULN` Technical Vulnerability Management | Information about technical vulnerabilities of systems in use must be obtained and evaluated in a timely manner, requiring identifiable software components (VDA ISA catalogue: vulnerability management controls) | Scan |
| `TISAX-PATCH` Patch Level Awareness | Managing vulnerabilities across the automotive supply chain requires knowing the version and patch level of software components in scope (VDA ISA catalogue: IT operations / patch management controls) | Scan |
| `TISAX-SUP` Supplier Relationship Security | Information security must be maintained in supplier relationships, requiring each externally sourced software component to be attributable to its supplier (VDA ISA catalogue: supplier relationships controls) | Scan |
| `TISAX-INT` Software Integrity in the Supply Chain | Protecting prototype and production-related information includes assurance that software exchanged along the supply chain is unaltered, supported by component integrity hashes (VDA ISA catalogue: IT security / integrity protection controls) | Scan |
| `TISAX-DOC` Assessment Evidence | TISAX assessments and label exchange require documented, current evidence; a dated, identifiable SBOM evidences the software-asset portion of the ISMS (TISAX assessment / ENX exchange requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------ | --------------------------------------------------------------- |
| `TISAX-1.1.1` | Establish Information Security Policy |
| `TISAX-1.2.1` | Define Information Security Roles and Responsibilities |
| `TISAX-1.6.1` | Conduct Information Security Risk Assessment |
| `TISAX-5.1.1` | Classify and Label Information Assets |
| `TISAX-5.2.1` | Implement Access Control for Classified Information |
| `TISAX-5.2.2` | Protect Classified Information During Transfer |
| `TISAX-PROTO-1` | Establish Prototype Protection Requirements |
| `TISAX-PROTO-2` | Implement Prototype Camouflage and Tracking Controls |
| `TISAX-SUPPLIER-1` | Assess Supplier Information Security Before Engagement |
| `TISAX-SUPPLIER-2` | Include Information Security Requirements in Supplier Contracts |
| `TISAX-IT-1` | Implement Secure Configuration for IT Systems |
| `TISAX-INCIDENT` | Establish Information Security Incident Management |
## Policy templates
Written for TISAX:
* TISAX Information Security Policy
* TISAX Prototype Protection Policy
* TISAX Supplier Information Security Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TISAX.
# UK Cyber Essentials (/docs/frameworks/europe/uk-cyber-essentials)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
UK NCSC: patch management, malware protection, access control, software inventory.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | UK CE |
| Region | Europe |
| Country or scope | United Kingdom |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers UK CE
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for UK CE.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for UK CE and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `UK-CE-INV` In-Scope Software Inventory | Organisations must know all software in scope so it can be kept licensed, supported and updated; an enumerated inventory of installed software components is the prerequisite for every other control (Cyber Essentials Requirements for IT Infrastructure, Security Update Management control) | Scan |
| `UK-CE-PATCH` Security Update Management | All software must be supported and have high/critical security updates applied within 14 days of release, which requires every component's installed version to be recorded and comparable against vendor advisories (Cyber Essentials Requirements for IT Infrastructure, Security Update Management control) | Scan |
| `UK-CE-VERS` Determinable Software Versions | Patch-currency within the 14-day window can only be assessed when versions are concrete; vague or floating version declarations (latest, wildcards, ranges) make update status unverifiable (Cyber Essentials Requirements for IT Infrastructure, Security Update Management control) | Scan |
| `UK-CE-SUPPORT` Supported Software from Identifiable Vendors | Software must be licensed and in vendor support; demonstrating support status requires that each component's supplier or publisher is identified (Cyber Essentials Requirements for IT Infrastructure, Security Update Management control) | Scan |
| `UK-CE-MALWARE` Malware Protection via Trusted Software | The malware protection control permits execution-allow-listing of known, trusted software as an acceptable mechanism, which depends on integrity data (hashes) being available for the deployed components (Cyber Essentials Requirements for IT Infrastructure, Malware Protection control) | Scan |
| `UK-CE-ID` Unambiguous Asset Identification | Scoping and certification require the assessed estate to be unambiguously identified; components should carry standard identifiers (PURL/CPE) so scheme scope and vulnerability exposure can be established (Cyber Essentials Requirements for IT Infrastructure, scope definition) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | -------------------------------------------------------- |
| `CE-BF-1` | Implement Boundary Firewall Controls |
| `CE-BF-2` | Block Inbound Connections on All Unapproved Ports |
| `CE-SC-1` | Apply Secure Configuration to All Devices |
| `CE-SC-2` | Change All Default Administrative Passwords |
| `CE-AC-1` | Implement User Access Control Based on Least Privilege |
| `CE-AC-2` | Authenticate Users Before Granting Administrative Access |
| `CE-AC-3` | Remove or Disable Unused User Accounts |
| `CE-MP-1` | Deploy and Maintain Malware Protection on All Endpoints |
| `CE-MP-2` | Restrict Execution of Unauthorised Applications |
| `CE-PM-1` | Apply Security Patches Within 14 Days of Release |
| `CE-PM-2` | Remove Unsupported Software from In-Scope Systems |
| `CE-PM-3` | Maintain Inventory of In-Scope Software and Versions |
## Policy templates
Written for UK CE:
* UK Cyber Essentials Patch Management Policy
* UK Cyber Essentials Access Control Policy
* UK Cyber Essentials Secure Configuration Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to UK CE.
# UK GDPR / DPA 2018 (/docs/frameworks/europe/uk-gdpr-dpa2018)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
UK General Data Protection Regulation + Data Protection Act 2018 - post-Brexit data protection.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | UK GDPR |
| Region | Europe |
| Country or scope | United Kingdom |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers UK GDPR
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for UK GDPR.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for UK GDPR and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `UK-GDPR-32` Security of Processing | Controllers and processors must implement technical and organisational measures appropriate to the risk, including the ability to ensure ongoing integrity of processing systems, which implies integrity verification of the software performing the processing (UK GDPR Art. 32) | Scan |
| `UK-GDPR-30` Records of Processing Activities | Controllers and processors must maintain records of their processing activities, including descriptions of technical security measures, which presupposes an enumerated account of the systems and software components used for processing (UK GDPR Art. 30) | Scan |
| `UK-GDPR-28` Processor Guarantees | Controllers may engage only processors providing sufficient guarantees to implement appropriate technical and organisational measures, which requires knowing which suppliers stand behind the components of the processing stack (UK GDPR Art. 28) | Scan |
| `UK-GDPR-33` 72-Hour Breach Notification Readiness | Personal data breaches must be notified to the ICO without undue delay and where feasible within 72 hours, including the categories and approximate scope affected; scoping that quickly requires individually identifiable system components (UK GDPR Art. 33) | Scan |
| `UK-GDPR-25` Data Protection by Design and Default | Controllers must build data protection into processing systems at design time and throughout their lifecycle, which requires knowing the exact versions of components in use so protective measures can track the deployed software (UK GDPR Art. 25) | Scan |
| `UK-GDPR-5-2` Accountability Principle | The controller is responsible for, and must be able to demonstrate, compliance with the data protection principles, which is supported by formally identified, timestamped machine-readable documentation of the processing systems (UK GDPR Art. 5(2)) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ------------------------------------------------ |
| `UK-GDPR-Art5` | Principles of Personal Data Processing |
| `UK-GDPR-Art6` | Lawful Basis for Processing |
| `UK-GDPR-Art13` | Privacy Information: Direct Collection |
| `UK-GDPR-Art14` | Privacy Information: Indirect Collection |
| `UK-GDPR-Art25` | Data Protection by Design and by Default |
| `UK-GDPR-Art28` | Processor Contracts and Obligations |
| `UK-GDPR-Art30` | Records of Processing Activities (ROPA) |
| `UK-GDPR-Art32` | Security of Processing |
| `UK-GDPR-Art33` | Personal Data Breach Notification to ICO |
| `UK-GDPR-Art34` | Communication of Breach to Data Subjects |
| `UK-GDPR-Art35` | Data Protection Impact Assessment (DPIA) |
| `DPA2018-Part2` | DPA 2018 Part 2: General Processing |
| `DPA2018-Part3` | DPA 2018 Part 3: Law Enforcement Processing |
| `DPA2018-Sch1` | DPA 2018 Schedule 1: Special Category Conditions |
## Policy templates
Written for UK GDPR:
* UK GDPR Privacy Notice
* Records of Processing Activities (ROPA)
* Data Protection Impact Assessment (DPIA) Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to UK GDPR.
# UK NCSC CAF (/docs/frameworks/europe/uk-ncsc-caf)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
UK NCSC Cyber Assessment Framework - 4 objectives, 14 principles for essential services security.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NCSC CAF |
| Region | Europe |
| Country or scope | United Kingdom |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NCSC CAF
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 14 controls from Safeguard's control catalog for NCSC CAF.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for NCSC CAF and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `UK-CAF-A3` Asset Management | Organisations must maintain a current understanding of all systems and software assets required for the operation of essential functions, so every deployed component must appear in the inventory (CAF Objective A, Principle A3 Asset Management) | Scan |
| `UK-CAF-A3-ID` Asset Identifiability | Knowledge of assets must be detailed enough to support security decision-making, which requires components to carry unambiguous machine-resolvable identifiers (CAF Principle A3 Asset Management) | Scan |
| `UK-CAF-A4` Supply Chain Understanding | Organisations must understand and manage the security risks arising from dependencies on external suppliers, which requires knowing who supplies each software component (CAF Objective A, Principle A4 Supply Chain) | Scan |
| `UK-CAF-B4` System Security and Build Integrity | Network and information systems must be securely built and maintained to resist exploitation, including assurance that deployed software has not been tampered with, evidenced by integrity hashes (CAF Objective B, Principle B4 System Security) | Scan |
| `UK-CAF-C1` Security Monitoring Readiness | Effective security monitoring depends on knowing exactly which software versions are running so that exploitation of known vulnerabilities can be detected and correlated (CAF Objective C, Principle C1 Security Monitoring) | Scan |
| `UK-CAF-D1` Response and Recovery Readiness | Incident response and recovery planning requires complete, well-defined records of what software the essential function runs, so components must be fully described with both name and version (CAF Objective D, Principle D1 Response and Recovery Planning) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | -------------------------------------------------- |
| `CAF-A1` | Governance: Organisational Policy |
| `CAF-A2` | Risk Management |
| `CAF-A3` | Asset Management |
| `CAF-A4` | Supply Chain Security |
| `CAF-B1` | Service Protection: Network Security |
| `CAF-B2` | Service Protection: Identity and Access Management |
| `CAF-B3` | Service Protection: Data Security |
| `CAF-B4` | Service Protection: System Security |
| `CAF-B5` | Service Protection: Resilient Networks and Systems |
| `CAF-B6` | Service Protection: Staff Awareness and Training |
| `CAF-C1` | Detection: Security Monitoring |
| `CAF-C2` | Detection: Anomaly Detection |
| `CAF-D1` | Response and Recovery: Response Planning |
| `CAF-D2` | Response and Recovery: Improvements from Incidents |
## Policy templates
Written for NCSC CAF:
* NCSC CAF Cybersecurity Programme Charter
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NCSC CAF.
# Ukraine Law on Basic Principles of Cyber Security 2017 (/docs/frameworks/europe/ukraine-cybersec)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | UA Cyber |
| Region | Europe |
| Country or scope | Ukraine |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers UA Cyber
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `UA-CYB-CII-INV` Critical Infrastructure Asset Knowledge | Owners and operators of critical infrastructure objects must implement cyber protection over their communication and technological systems, which presupposes an inventory of the software components those systems run (Law 2163-VIII critical-infrastructure protection duties) | Scan |
| `UA-CYB-INT` Integrity of Technological Systems | Cyber protection must guard the integrity of information and of the systems processing it against unauthorized modification; verifiable integrity hashes on software components evidence this control (Law 2163-VIII cyber-protection requirements) | Scan |
| `UA-CYB-VULN` Vulnerability Management Readiness | Operators must detect and respond to cyber threats and incidents affecting their systems, which requires knowing the exact version of each deployed component so vulnerabilities can be matched and remediated (Law 2163-VIII threat-response duties with CERT-UA coordination) | Scan |
| `UA-CYB-SUP` Supply-Chain Trustworthiness | Protection of critical infrastructure extends to the trustworthiness of the technology it relies on, requiring visibility into the suppliers behind deployed software components (Law 2163-VIII critical-infrastructure security requirements) | Scan |
| `UA-CYB-ID` Incident Reporting Identification | Reporting cyber incidents to CERT-UA and state authorities requires machine-usable identification of the affected software components (Law 2163-VIII incident-reporting framework) | Scan |
| `UA-CYB-AUD` Auditable Security Documentation | Critical infrastructure objects are subject to independent information security audits and state review, supported by formally identified, timestamped and machine-readable records of system composition (Law 2163-VIII security-audit provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to UA Cyber.
# Ukraine Law on Protection of Personal Data (2297-VI) (/docs/frameworks/europe/ukraine-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | UA PDPL |
| Region | Europe |
| Country or scope | Ukraine |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers UA PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `UA-PDPL-24` Protection of Personal Data in Processing Systems | Owners, managers, and third parties handling personal data must protect it against accidental loss or destruction and against unlawful processing; integrity hashes on the software components that process the data evidence this safeguard (Law No. 2297-VI Art. 24). | Scan |
| `UA-PDPL-24V` Defence Against Unlawful Alteration | The duty to prevent unlawful destruction or alteration of personal data requires the processing software to be maintained in a known, assessable state, with each component carrying an identified version (Law No. 2297-VI Art. 24). | Scan |
| `UA-PDPL-6` Purpose-Bound, Documented Processing | Personal data may only be processed lawfully and for declared, specific purposes, which presupposes the owner knows and can enumerate the software systems and components through which the data flows (Law No. 2297-VI Art. 6). | Scan |
| `UA-PDPL-DLG` Delegated Processing Accountability | Processing may be entrusted to a manager (processor) only under a written agreement that fixes responsibilities, so third-party software components in the processing chain must have identifiable suppliers (Law No. 2297-VI, delegation-of-processing provisions). | Scan |
| `UA-PDPL-24R` Responsible Data-Protection Unit | Owners and managers processing significant volumes of personal data must designate a responsible unit or officer for data-protection arrangements; an identified, timestamped record of the software estate is core evidence such a function exists and works (Law No. 2297-VI Art. 24). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to UA PDPL.
# Holy See Data Protection Framework (/docs/frameworks/europe/vatican-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | VA DP Frwk |
| Region | Europe |
| Country or scope | Holy See (Vatican) |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers VA DP Frwk
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `VA-GRPD-IC` Integrity and Confidentiality Principle | Personal data must be processed in a manner ensuring its integrity and confidentiality against unauthorized access or alteration; verifiable integrity hashes on processing components evidence this principle (General Regulation 2024, integrity-and-confidentiality principle) | Scan |
| `VA-GRPD-ACC` Accuracy Principle | Processed personal data must be accurate and kept up to date, which presumes the software performing the processing is fully identified by name and concrete version (General Regulation 2024, accuracy principle) | Scan |
| `VA-GRPD-TRANS` Transparency of Processing | Processing must be transparent to data subjects, presupposing documented, uniquely identified and timestamped records of the processing environment (General Regulation 2024, transparency principle) | Scan |
| `VA-GRPD-MIN` Purpose Limitation and Minimisation | Processing requires a legitimate purpose and must be limited and proportionate, which requires knowing precisely which software components take part in the processing (General Regulation 2024, purpose-limitation and data-minimisation principles) | Scan |
| `VA-GRPD-RESP` Accountable Processing Parties | Processing must be attributable to responsible parties operating under the controller's authority, so third-party software components must carry named, accountable suppliers (General Regulation 2024, controller-responsibility provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to VA DP Frwk.
# Afghanistan National Privacy Framework (/docs/frameworks/asia-pacific/afghanistan-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | AF Privacy |
| Region | Asia-Pacific |
| Country or scope | Afghanistan |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers AF Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `AF-C37-SEC` Confidentiality Safeguards for Processing Systems | Systems that handle personal communications and data should be protected against tampering, so components need integrity hashes that let unauthorised alteration be detected (Constitution 2004, Art. 37 confidentiality guarantee). | Scan |
| `AF-C37-INV` Inventory of Data-Handling Software | Honouring a confidentiality guarantee presupposes knowing which software components touch personal communications, so a component inventory must exist (Constitution 2004, Art. 37). | Scan |
| `AF-ICT-SUP` Third-Party Service Accountability | Telecom licensing rules make operators answerable for services delivered through third parties, so third-party components should carry named suppliers (Afghan telecom-sector licensing rules). | Scan |
| `AF-ICT-VER` Version Records for Incident Assessment | Assessing whether confidentiality of communications has been compromised requires knowing the versions of the software in operation (Constitution 2004, Art. 37; sectoral ICT rules). | Scan |
| `AF-ICT-DOC` Documented Software Records | Demonstrating compliance with confidentiality obligations requires dated, identifiable documentation of the systems used to process data (Constitution 2004, Art. 37; sectoral ICT rules). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AF Privacy.
# Australia Essential Eight (/docs/frameworks/asia-pacific/aus-essential8)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Patch applications, application control, software inventory for Australian organisations.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | AUS E8 |
| Region | Asia-Pacific |
| Country or scope | Australia |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers AUS E8
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 18 controls from Safeguard's control catalog for AUS E8.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for AUS E8 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AU-E8-APPCTL` Application Control Baseline | Application control requires an authoritative list of approved software; the organisation must be able to enumerate every software component it runs (Essential Eight - Application Control, Maturity Level 1) | Scan |
| `AU-E8-PATCHAPP` Patch Applications - Version Visibility | Timely patching of applications is only possible when the installed version of each component is known, so components must record their versions (Essential Eight - Patch Applications) | Scan |
| `AU-E8-PATCHSPEC` Deterministic Patch Targets | Vulnerability scanners used to drive the 48-hour/two-week patch timeframes need exact versions, so vague or floating version specifiers must not be used (Essential Eight - Patch Applications, scanning and patch timeframe requirements) | Scan |
| `AU-E8-ASSETID` Scannable Asset Identification | Components should carry standard identifiers (PURL or CPE) so vulnerability scanning across applications and drivers can match them to published advisories (Essential Eight - Patch Applications / Patch Operating Systems, vulnerability scanner use) | Scan |
| `AU-E8-INTEGRITY` Executable Integrity Evidence | Application control at higher maturity levels validates software by cryptographic attributes, so components should ship with integrity hashes (Essential Eight - Application Control, hash/publisher-based rules) | Scan |
| `AU-E8-PLATFORM` Named System Under Management | Mitigation strategies are applied per system, so the software inventory must identify the system it describes and list its constituent components (Essential Eight Maturity Model, scoping of assessed systems) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ------------------------------------------------------ |
| `E8-AC-ML1` | Implement Application Control at Maturity Level 1 |
| `E8-AC-ML2` | Implement Application Control at Maturity Level 2 |
| `E8-AC-ML3` | Implement Application Control at Maturity Level 3 |
| `E8-PA-ML1` | Patch Applications at Maturity Level 1 |
| `E8-PA-ML2` | Patch Applications at Maturity Level 2 |
| `E8-PA-ML3` | Patch Applications at Maturity Level 3 |
| `E8-MO-ML1` | Configure Microsoft Office Macros at Maturity Level 1 |
| `E8-MO-ML2` | Configure Microsoft Office Macros at Maturity Level 2 |
| `E8-MO-ML3` | Configure Microsoft Office Macros at Maturity Level 3 |
| `E8-UAH-ML1` | Apply User Application Hardening at Maturity Level 1 |
| `E8-UAH-ML2` | Apply User Application Hardening at Maturity Level 2 |
| `E8-RAP-ML1` | Restrict Administrative Privileges at Maturity Level 1 |
| `E8-RAP-ML2` | Restrict Administrative Privileges at Maturity Level 2 |
| `E8-RAP-ML3` | Restrict Administrative Privileges at Maturity Level 3 |
| `E8-POS-ML2` | Patch Operating Systems at Maturity Level 2 |
| `E8-MFA-ML2` | Enable Multi-Factor Authentication at Maturity Level 2 |
| `E8-BK-ML1` | Perform Daily Backups at Maturity Level 1 |
| `E8-BK-ML3` | Perform Daily Backups at Maturity Level 3 |
## Policy templates
Written for AUS E8:
* Multi-Factor Authentication and Patch Management Policy
* Application Control and User Application Hardening Policy
* Privileged Access Management and Backup Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AUS E8.
# Australia ACSC ISM (/docs/frameworks/asia-pacific/australia-ism)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Australian Cyber Security Centre Information Security Manual - PROTECTED/SECRET/TOP SECRET controls.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | AU ISM |
| Region | Asia-Pacific |
| Country or scope | Australia |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers AU ISM
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for AU ISM.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for AU ISM and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AU-ISM-DOC-INV` System Documentation and Asset Records | Systems must be documented, including records of their composition, so every software component must appear in the system's inventory (ISM, Guidelines for Security Documentation) | Scan |
| `AU-ISM-PATCH` Patching Applications and Operating Systems | Security vulnerabilities in applications and operating systems must be patched within mandated timeframes (48 hours for exploited critical vulnerabilities), which requires the exact version of every deployed component to be known (ISM, Guidelines for System Management, patching controls; Essential Eight) | Scan |
| `AU-ISM-SUPPLY` Cyber Supply Chain Risk Management | Organisations must identify and manage cyber supply chain risks for applications, ICT equipment and services, including knowing the supplier of each software component (ISM, Guidelines for Procurement and Outsourcing) | Scan |
| `AU-ISM-DEV-INTEG` Secure Development and Component Integrity | Secure software development includes obtaining components from trusted sources and verifying their authenticity and integrity via cryptographic hashes (ISM, Guidelines for Software Development) | Scan |
| `AU-ISM-SBOM` Software Bill of Materials | The ISM directs developers and suppliers of applications to produce and make available a software bill of materials in a standard machine-readable format (ISM, Guidelines for Software Development, SBOM controls) | Scan |
| `AU-ISM-EOL` No Unsupported Software | Unsupported operating systems and applications must be removed or replaced, which excludes components declared at vague or floating versions whose support status cannot be determined (ISM, Guidelines for System Management, obsolescence controls) | Scan |
| `AU-ISM-VULN` Vulnerability Scanning Readiness | Regular vulnerability scanning and monitoring of systems requires components to carry standard identifiers (PURL/CPE) so scan results correlate with published advisories (ISM, Guidelines for System Monitoring) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ---------------------------------- |
| `ISM-INCI` | Cyber Security Incident Management |
| `ISM-PERS` | Personnel Security |
| `ISM-CRYPTO` | Cryptographic Fundamentals |
| `ISM-HARD` | System Hardening |
| `ISM-SYSMON` | System Monitoring |
| `ISM-NETW` | Network Security |
| `ISM-EMAIL` | Email Security |
| `ISM-SOFDEV` | Software Development Security |
| `ISM-PROC` | Procurement & Outsourcing Security |
| `ISM-SSP` | System Security Plan (SSP) |
## Policy templates
Written for AU ISM:
* ACSC ISM System Security Plan (SSP)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AU ISM.
# Australia Privacy Act (/docs/frameworks/asia-pacific/australia-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Australian Privacy Principles: data handling software inventory, processor accountability.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | AUS Privacy |
| Region | Asia-Pacific |
| Country or scope | Australia |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers AUS Privacy
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for AUS Privacy.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for AUS Privacy and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `AU-APP-11` Security of Personal Information | Entities must take reasonable steps to protect personal information from misuse, interference, loss and unauthorised access, which for software systems includes integrity assurance of the processing components (Privacy Act 1988, Schedule 1, APP 11.1) | Scan |
| `AU-APP-1` Open and Transparent Management | Entities must manage personal information in an open and transparent way, implying documented, identifiable records of the systems that process it (Privacy Act 1988, Schedule 1, APP 1.2) | Scan |
| `AU-APP-INV` Processing System Inventory | Reasonable steps to implement practices, procedures and systems that ensure APP compliance require knowing which software components handle personal information (Privacy Act 1988, Schedule 1, APP 1.2) | Scan |
| `AU-APP-8` Cross-Border Disclosure Accountability | Before disclosing personal information to overseas recipients an entity must take reasonable steps to ensure the recipient complies with the APPs, which requires knowing who supplies each software component in the processing chain (Privacy Act 1988, Schedule 1, APP 8.1) | Scan |
| `AU-NDB-26WK` Notifiable Data Breach Readiness | The Notifiable Data Breaches scheme requires rapid assessment of suspected eligible data breaches, which depends on being able to identify affected software and its versions (Privacy Act 1988, Part IIIC, s 26WK) | Scan |
| `AU-APP-11RET` Identifiable Components for Safeguard Review | Ongoing review of security safeguards requires that processing components be unambiguously identifiable against vulnerability and threat information (Privacy Act 1988, Schedule 1, APP 11; OAIC security guidance) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ------------------------------------------------------ |
| `APP-1` | Establish an Open and Transparent Privacy Policy |
| `APP-3` | Limit Collection of Personal Information |
| `APP-5` | Notify Individuals at or Before Collection |
| `APP-6` | Control Use and Disclosure of Personal Information |
| `APP-7` | Manage Direct Marketing Communications |
| `APP-8` | Govern Cross-Border Disclosure of Personal Information |
| `APP-11` | Secure Personal Information Against Misuse and Loss |
| `APP-12` | Provide Access to Personal Information on Request |
| `APP-13` | Correct Personal Information on Request |
| `NDB-ASSESS` | Assess Suspected Eligible Data Breaches Promptly |
| `NDB-NOTIFY` | Notify OAIC and Individuals of Eligible Data Breaches |
| `APP-2` | Anonymity and Pseudonymity Options |
## Policy templates
Written for AUS Privacy:
* Privacy Collection Notice and Transparency Policy
* Notifiable Data Breaches Response Policy
* Cross-Border Disclosure of Personal Information Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to AUS Privacy.
# Australia SOCI Act (/docs/frameworks/asia-pacific/australia-soci)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Security of Critical Infrastructure Act - 11 sectors, risk management program, mandatory IR reporting.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SOCI |
| Region | Asia-Pacific |
| Country or scope | Australia |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SOCI
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 6 controls from Safeguard's control catalog for SOCI.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for SOCI and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `AU-SOCI-P2-REG` Register of Critical Infrastructure Assets | Responsible entities must provide and keep current operational and interest information about their critical infrastructure assets for the national register, which presumes knowing what systems and software constitute the asset (SOCI Act Part 2) | Scan |
| `AU-SOCI-P2A-RMP` Critical Infrastructure Risk Management Program | Responsible entities must adopt and maintain a written risk management program that identifies material risks to the asset, which requires an inventory of the software components the asset depends on (SOCI Act Part 2A) | Scan |
| `AU-SOCI-CIRMP-SC` Supply Chain Hazard Management | The risk management program must minimise material risks arising from supply chain hazards, including reliance on third-party vendors and suppliers, so component origins must be documented (SOCI Act Part 2A and CIRMP Rules 2023 supply chain hazard provisions) | Scan |
| `AU-SOCI-30BC` Critical Incident Reporting Readiness (12 hours) | Cyber security incidents with a significant impact must be reported within 12 hours, demanding the ability to rapidly identify which precise components are affected (SOCI Act s 30BC) | Scan |
| `AU-SOCI-30BD` Other Incident Reporting Readiness (72 hours) | Other relevant cyber security incidents must be reported within 72 hours, requiring version-level knowledge of deployed software to assess whether an incident is relevant to the asset (SOCI Act s 30BD) | Scan |
| `AU-SOCI-P2A-CYBER` Cyber and Information Hazard Controls | The risk management program must minimise cyber and information security hazards, which for software assets includes protecting the integrity of code and artifacts against tampering (SOCI Act Part 2A cyber hazard obligations, CIRMP Rules 2023) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ------------------------------------------------- |
| `SOCI-2A` | Critical Infrastructure Risk Management Programme |
| `SOCI-2B` | Cyber Incident Reporting |
| `SOCI-2C` | Enhanced Cyber Security Obligations |
| `SOCI-3` | Critical Infrastructure Asset Register |
| `SOCI-POSOWN` | Positive Security Obligations |
| `SOCI-GOVCOORD` | Government Coordination & Assistance |
## Policy templates
Written for SOCI:
* SOCI Act Critical Infrastructure Risk Management Programme
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SOCI.
# Bangladesh Cyber Security Act 2023 (/docs/frameworks/asia-pacific/bangladesh-csa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BD CSA |
| Region | Asia-Pacific |
| Country or scope | Bangladesh |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BD CSA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BD-CSA-CII` Critical Infrastructure Asset Knowledge | Operators of declared Critical Information Infrastructure must protect those systems, which starts with an enumerated, named inventory of the software platforms they run (Cyber Security Act 2023, CII declaration and protection provisions) | Scan |
| `BD-CSA-INT` System Integrity Verification | Unauthorised access to and alteration of computer systems and CII are offences, so operators should be able to verify component integrity via cryptographic hashes (Cyber Security Act 2023, offences against computer systems and CII) | Scan |
| `BD-CSA-VULN` Vulnerability Assessment Readiness | Emergency response and threat mitigation coordinated by the national agency require operators to know exact software versions so vulnerabilities can be matched and patched (Cyber Security Act 2023, National CERT and emergency-response powers) | Scan |
| `BD-CSA-SUP` Supply-Chain Verification | Safeguarding CII against compromise includes knowing the provenance of the software supply chain, so components must have named suppliers (Cyber Security Act 2023, CII protection duties) | Scan |
| `BD-CSA-ID` Component Identifiability | Incident investigation and digital forensics under the Act require system components to carry unique identifiers (PURL or CPE) (Cyber Security Act 2023, investigation and forensic provisions) | Scan |
| `BD-CSA-FMT` Machine-Readable Asset Records | Cooperation with the National Cyber Security Agency is practical only if software asset records are exchanged in standard machine-readable formats (Cyber Security Act 2023, agency cooperation and reporting duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BD CSA.
# Bhutan ICM Act 2018 (Data Protection) (/docs/frameworks/asia-pacific/bhutan-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BT ICM 2018 |
| Region | Asia-Pacific |
| Country or scope | Bhutan |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BT ICM 2018
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BT-ICM-SEC` Security of Personal Information Systems | Service providers must safeguard the personal information they process against unauthorised alteration or disclosure, which integrity hashes on software components make verifiable (ICM Act 2018, data-protection and privacy provisions). | Scan |
| `BT-ICM-REC` Records of Data-Handling Software | Regulated providers must be able to account for the systems through which they collect and process personal information, requiring a maintained component inventory (ICM Act 2018, data-protection and privacy provisions). | Scan |
| `BT-ICM-3P` Third-Party Provider Accountability | Duties owed to users are not discharged by outsourcing, so components sourced from third parties must have named, accountable suppliers (ICM Act 2018, service-provider obligations). | Scan |
| `BT-ICM-ID` Identifiable Processing Components | Protecting personal information requires knowing precisely which software handles it, so components should carry standard identifiers such as PURL or CPE (ICM Act 2018, data-protection and privacy provisions). | Scan |
| `BT-ICM-VER` Version Records for Risk Assessment | Judging exposure of systems that hold personal information requires recorded versions for the components in operation (ICM Act 2018, data-protection and privacy provisions). | Scan |
| `BT-ICM-DOC` Auditable System Documentation | BICMA's supervisory powers presuppose dated, identifiable documentation of the systems a provider operates (ICM Act 2018, regulatory oversight provisions). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BT ICM 2018.
# Brunei Personal Data Protection Order 2025 (/docs/frameworks/asia-pacific/brunei-pdpo)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | BN PDPO |
| Region | Asia-Pacific |
| Country or scope | Brunei |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers BN PDPO
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `BN-PDPO-PROT` Protection Obligation | Organisations must make reasonable security arrangements to protect personal data against unauthorised access, modification or disposal, evidenced by integrity hashes across processing-system components (PDPO 2025, protection obligation) | Scan |
| `BN-PDPO-ACC` Accountability Obligation | Organisations must develop policies and practices to meet their PDPO obligations, which requires an accurate inventory of the software that processes personal data (PDPO 2025, accountability obligation and DPO designation) | Scan |
| `BN-PDPO-INT` Data Intermediary Oversight | Data intermediaries processing on behalf of an organisation must be engaged under contract and remain the organisation's responsibility, so third-party components must have identifiable suppliers (PDPO 2025, data intermediary provisions) | Scan |
| `BN-PDPO-BRN` Data Breach Notification Readiness | Notifiable data breaches must be reported to the authority, which requires affected components to be quickly identifiable via PURL or CPE identifiers (PDPO 2025, data breach notification obligation) | Scan |
| `BN-PDPO-DOC` Demonstrable Policies and Records | Organisations must be able to demonstrate their data-protection practices on request, so software records must be machine-readable, dated and identifiable documents (PDPO 2025, openness and accountability duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to BN PDPO.
# Cambodia E-Commerce Law 2019 (Data Protection) (/docs/frameworks/asia-pacific/cambodia-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | KH ECom 2019 |
| Region | Asia-Pacific |
| Country or scope | Cambodia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers KH ECom 2019
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `KH-ECL-SEC` Protection of Stored Consumer Data | Persons storing consumers' private data must maintain secure systems and prevent loss or unauthorised alteration, which integrity hashes on software components make verifiable (E-Commerce Law 2019, data-security obligations, Art. 32). | Scan |
| `KH-ECL-CONF` Disclosure Prevention via Identifiable Components | Preventing unauthorised disclosure of stored private information requires knowing precisely which components handle it, so components should carry standard identifiers such as PURL or CPE (E-Commerce Law 2019, confidentiality obligations). | Scan |
| `KH-ECL-REC` Records of Electronic-Commerce Systems | Record-keeping duties on e-commerce service providers presuppose an inventory of the software components that operate their electronic systems (E-Commerce Law 2019, record-keeping provisions). | Scan |
| `KH-ECL-3P` Intermediary and Service-Provider Accountability | Duties and liability rules for electronic-commerce intermediaries mean components supplied by third parties must have named, accountable suppliers (E-Commerce Law 2019, intermediary and service-provider provisions). | Scan |
| `KH-ECL-VER` Version Records for Breach Assessment | Assessing whether stored consumer data has been compromised requires knowing the versions of the software in operation (E-Commerce Law 2019, data-security obligations). | Scan |
| `KH-ECL-DOC` Auditable System Documentation | Demonstrating compliance with e-commerce security and record duties requires dated, identifiable documentation of the systems used (E-Commerce Law 2019, record-keeping provisions). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KH ECom 2019.
# China Cybersecurity Law (/docs/frameworks/asia-pacific/china-csl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
PRC Cybersecurity Law - network operator obligations, CII protection, cross-border data.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CSL CN |
| Region | Asia-Pacific |
| Country or scope | China |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CSL CN
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for CSL CN.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for CSL CN and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CN-CSL-21-MLPS` Multi-Level Protection Duties | Network operators must fulfil multi-level protection obligations including internal security management systems and technical measures against attacks and intrusions, which starts with an inventory of the software their networks run (Cybersecurity Law Art. 21) | Scan |
| `CN-CSL-21-RESP` Security Responsible Persons | Operators must determine persons responsible for cybersecurity, so technical security documentation must record an accountable creator contact (Cybersecurity Law Art. 21) | Scan |
| `CN-CSL-22` Product Security Maintenance and Vulnerability Disclosure | Network products and services must be free of malicious programs, and providers must inform users of discovered security defects and vulnerabilities and provide ongoing security maintenance, which requires tracked component versions (Cybersecurity Law Art. 22) | Scan |
| `CN-CSL-22-INTEG` Malicious-Program Prevention | The prohibition on shipping malicious programs implies verifiable integrity of distributed software, evidenced by cryptographic hashes on components (Cybersecurity Law Art. 22) | Scan |
| `CN-CSL-25` Emergency Response and Remediation | Network operators must formulate emergency response plans and promptly address system vulnerabilities and security risks, which requires matching deployed components against vulnerability identifiers (Cybersecurity Law Art. 25) | Scan |
| `CN-CSL-35` CII Procurement Security Review | Critical information infrastructure operators procuring network products or services that may affect national security must pass a security review, which presupposes knowing the supplier of the components used (Cybersecurity Law Art. 35) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ---------------------------------------------------- |
| `CSL-21` | Network Operator Security Obligations |
| `CSL-24` | Real-Name Registration |
| `CSL-31-39` | Critical Information Infrastructure (CII) Protection |
| `CSL-37` | Data Localisation |
| `CSL-40-44` | Personal Information Protection (CSL) |
| `CSL-48` | Cybersecurity Incident Reporting |
| `CSL-CII-ISAC` | CII Information Sharing |
## Policy templates
Written for CSL CN:
* Critical Information Infrastructure (CII) Protection Plan
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CSL CN.
# China Data Security Law (/docs/frameworks/asia-pacific/china-dsl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
PRC Data Security Law - data classification, important data, security review for cross-border transfer.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | DSL CN |
| Region | Asia-Pacific |
| Country or scope | China |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers DSL CN
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for DSL CN.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for DSL CN and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `CN-DSL-21` Data Classification Foundation | The state implements classified and graded data protection, and classifying data by system requires an enumerated inventory of the software components that process it (Data Security Law Art. 21) | Scan |
| `CN-DSL-27-SEC` Whole-Process Security Measures | Data processors must establish a sound data security management system across the full workflow and adopt corresponding technical measures, including integrity assurance for the software stack handling data (Data Security Law Art. 27) | Scan |
| `CN-DSL-27-RESP` Designated Security Responsibility | Processors of important data must designate a data security responsible person and management body, so security documentation must record an accountable contact (Data Security Law Art. 27) | Scan |
| `CN-DSL-29` Risk Monitoring and Flaw Remediation | Data processors must strengthen risk monitoring and immediately remediate discovered security flaws and vulnerabilities, which requires knowing the exact version of every deployed component (Data Security Law Art. 29) | Scan |
| `CN-DSL-30` Periodic Risk Assessment Reports | Processors of important data must conduct periodic risk assessments and submit reports to the competent authority, requiring dated, identifiable machine-readable records as evidence (Data Security Law Art. 30) | Scan |
| `CN-DSL-29-ID` Vulnerability Traceability | Effective risk monitoring depends on matching deployed components against published vulnerability advisories, which requires standard component identifiers such as PURL or CPE (Data Security Law Art. 29) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | -------------------------------------- |
| `DSL-21` | Data Classification System |
| `DSL-27` | Data Security Management System |
| `DSL-28` | Third-Party Risk Management |
| `DSL-31` | Cross-Border Data Transfer Controls |
| `DSL-32` | National Core Data Protection |
| `DSL-34` | Data Security Review |
| `DSL-35` | Government Data Opening Standards |
| `DSL-36-39` | Government Data Management Obligations |
## Policy templates
Written for DSL CN:
* PRC Data Classification & Grading Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DSL CN.
# China MLPS 2.0 (/docs/frameworks/asia-pacific/china-mlps-2)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
PRC Multi-Level Protection Scheme 2.0 - 5 levels of system grading and protection requirements.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | MLPS 2.0 |
| Region | Asia-Pacific |
| Country or scope | China |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers MLPS 2.0
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for MLPS 2.0.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for MLPS 2.0 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CN-MLPS-GRADE` System Grading and Identification | Every network/system must be graded and filed, which requires the system to be named and its constituent software components enumerated (GB/T 22239-2019 grading and filing framework) | Scan |
| `CN-MLPS-ASSET` Asset Management in the Computing Environment | Secure computing environment requirements include managing and cataloguing system assets, so all software components must appear in the inventory (GB/T 22239-2019 secure computing environment / asset management requirements) | Scan |
| `CN-MLPS-TRUST` Trusted Verification of Software | MLPS 2.0 introduces trusted verification of system programs and applications at boot and runtime, which requires cryptographic integrity hashes for deployed components (GB/T 22239-2019 trusted verification requirements) | Scan |
| `CN-MLPS-VULN` Vulnerability and Patch Management | Security management requirements include identifying and remediating vulnerabilities in a timely manner, which requires every component's version to be recorded and current (GB/T 22239-2019 security operations and maintenance requirements) | Scan |
| `CN-MLPS-SUPPLY` Procurement and Outsourced Development Control | Product procurement must use qualified suppliers and outsourced software development is subject to security checks, so the supplier of each software component must be identified (GB/T 22239-2019 product procurement and outsourced development requirements) | Scan |
| `CN-MLPS-DOC` Security Management Documentation | Graded systems must maintain security management documentation and records for assessment, so machine-readable records must carry a document identity and creation timestamp (GB/T 22239-2019 security management requirements) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ------------------------------ |
| `MLPS-A` | Physical Security (Class A) |
| `MLPS-B` | Network Security (Class B) |
| `MLPS-C` | Host Security (Class C) |
| `MLPS-D` | Application Security (Class D) |
| `MLPS-E` | Data Security (Class E) |
| `MLPS-F` | Security Management (Class F) |
| `MLPS-EVAL` | Comprehensive MLPS Evaluation |
| `MLPS-L3-ANNUAL` | Level 3+ Annual Assessment |
## Policy templates
Written for MLPS 2.0:
* MLPS 2.0 Assessment Standard Operating Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MLPS 2.0.
# China PIPL (/docs/frameworks/asia-pacific/china-pipl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Personal Information Protection Law: cross-border data transfer, processor inventory, security measures.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | PIPL |
| Region | Asia-Pacific |
| Country or scope | China |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers PIPL
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for PIPL.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for PIPL and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `CN-PIPL-51` Security Measures for Processing | Personal information handlers must adopt corresponding technical security measures such as encryption and take steps to prevent unauthorised access, leakage, tampering or loss, which includes verifying the integrity of processing software (PIPL Art. 51) | Scan |
| `CN-PIPL-51INV` Classified Processing Inventory | Handlers must formulate internal management systems and operating procedures and implement categorised management of personal information, requiring an inventory of the software components involved in processing (PIPL Art. 51(1)-(2)) | Scan |
| `CN-PIPL-21` Entrusted Party Supervision | Where processing is entrusted to another party, the handler must agree on purpose and method and supervise the entrusted party's processing, requiring knowledge of who supplies each processing component (PIPL Art. 21) | Scan |
| `CN-PIPL-55` Impact Assessment Documentation | Personal information protection impact assessments must be conducted for high-risk processing and the reports retained for at least three years, requiring identifiable, timestamped system documentation (PIPL Arts. 55-56) | Scan |
| `CN-PIPL-57` Incident Notification Readiness | On a leak, tampering or loss of personal information, handlers must immediately take remedial measures and notify authorities and individuals, which depends on rapidly identifying affected components and versions (PIPL Art. 57) | Scan |
| `CN-PIPL-38` Cross-Border Chain Traceability | Cross-border provision of personal information requires security assessments and contractual controls, which presuppose that the software chain handling the data is identifiable end to end (PIPL Arts. 38-40) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | ------------------------------------------------------------ |
| `PIPL-A13` | Establish a Lawful Basis for Processing Personal Information |
| `PIPL-A17` | Provide Individuals with a Clear Privacy Notice |
| `PIPL-A21` | Govern Third-Party Entrusted Processing by Contract |
| `PIPL-A23` | Obtain Separate Consent for Third-Party Provision |
| `PIPL-A28` | Apply Strict Controls to Sensitive Personal Information |
| `PIPL-A38` | Satisfy Legal Conditions for Cross-Border Transfers |
| `PIPL-A40` | Obtain Separate Consent for Overseas Transfers |
| `PIPL-A44` | Fulfil Individual Rights Requests |
| `PIPL-A51` | Implement PI Protection Measures Proportionate to Risk |
| `PIPL-A55` | Conduct Personal Information Protection Impact Assessments |
| `PIPL-A58` | Comply with Large Platform Obligations |
| `PIPL-BREACH` | Notify Regulators and Individuals of PI Incidents |
## Policy templates
Written for PIPL:
* Cross-Border Personal Information Transfer Policy (PIPL)
* Personal Information Consent and Data Subject Rights Policy (PIPL)
* Important Internet Platform Obligations Policy (PIPL Article 58)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PIPL.
# Fiji Cybercrime Act 2021 (/docs/frameworks/asia-pacific/fiji-cyber)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | FJ Cyber 21 |
| Region | Asia-Pacific |
| Country or scope | Fiji |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers FJ Cyber 21
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FJ-CYB-INV` Software Asset Inventory | Detecting and prosecuting illegal access or interference with computer systems presupposes a named system with a complete inventory of its software components (Cybercrime Act 2021, offences against computer data and systems). | Scan |
| `FJ-CYB-INT` Data Integrity Verification | The data-interference offence protects the integrity of computer data, so components should carry integrity hashes that let unauthorised alteration be detected and evidenced (Cybercrime Act 2021, data-interference offence). | Scan |
| `FJ-CYB-VER` Version Records for System-Interference Response | Responding to system interference and assessing exploited weaknesses requires knowing the exact versions of the software in operation (Cybercrime Act 2021, system-interference offence). | Scan |
| `FJ-CYB-SUP` Supply-Chain Origin Verification | Guarding against misuse of devices and malicious tooling entering systems requires that components have named, verifiable suppliers (Cybercrime Act 2021, misuse-of-devices offence). | Scan |
| `FJ-CYB-DEP` Documented Dependency Relationships | Tracing how an intrusion propagates through a system requires documented dependency relationships between its components (Cybercrime Act 2021, offences against computer systems). | Scan |
| `FJ-CYB-DOC` Preservation-Ready Documentation | Expedited-preservation powers presuppose dated, identifiable records of the systems and data concerned (Cybercrime Act 2021, procedural powers on preservation of stored data). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FJ Cyber 21.
# Fiji National ICT / Privacy Framework (/docs/frameworks/asia-pacific/fiji-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | FJ Privacy |
| Region | Asia-Pacific |
| Country or scope | Fiji |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers FJ Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FJ-C24-CONF` Confidentiality of Personal Information | The express guarantee of confidentiality of personal information requires knowing precisely which software components handle it, so components should carry standard identifiers such as PURL or CPE (Constitution 2013, s. 24). | Scan |
| `FJ-C24-SEC` Integrity of Personal-Data Systems | Keeping personal information and communications confidential requires protecting the systems that carry them from tampering, which integrity hashes on components make verifiable (Constitution 2013, s. 24). | Scan |
| `FJ-C24-REC` Inventory of Data-Handling Software | Honouring the constitutional confidentiality guarantee presupposes a maintained record of the software components that process personal information (Constitution 2013, s. 24). | Scan |
| `FJ-C24-SUP` Third-Party Handling Accountability | Confidentiality of personal information extends to handling by third parties, so third-party components must have named, accountable suppliers (Constitution 2013, s. 24). | Scan |
| `FJ-OSA-DOC` Documented Online Systems | Sectoral duties around online services presuppose dated, identifiable documentation of the systems operated (Online Safety Act 2018; Constitution 2013, s. 24). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FJ Privacy.
# French Polynesia Loi Informatique et Libertes (/docs/frameworks/asia-pacific/french-polynesia-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | PF LIL |
| Region | Asia-Pacific |
| Country or scope | French Polynesia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers PF LIL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `PF-LIL-121` Security of Processing | The controller must take all necessary precautions, given the nature of the data and processing risks, to preserve data security and prevent alteration or access by unauthorized third parties, including integrity verification of processing software (Loi 78-17, art. 121) | Scan |
| `PF-LIL-4` Data Quality and Integrity Principles | Personal data must be accurate, kept up to date and processed in a manner guaranteeing appropriate security, requiring known versions for every processing component (Loi 78-17, art. 4 principles) | Scan |
| `PF-LIL-REC` Records of Processing | GDPR-standard record-keeping obligations extended to French Polynesia require a named, populated inventory of processing systems (Loi 78-17, GDPR Art. 30-standard record duty as extended overseas) | Scan |
| `PF-LIL-PROC` Processor Guarantees | Controllers may only engage processors presenting sufficient guarantees, requiring supplier visibility for third-party components handling personal data (Loi 78-17, GDPR Art. 28-standard processor rules as extended overseas) | Scan |
| `PF-LIL-BRE` Breach Notification Readiness | Breach-notification duties to the CNIL require identifying exactly which software components an incident affected (Loi 78-17, GDPR Art. 33-standard breach notification as extended overseas) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PF LIL.
# Guam Data Breach Law / US Frameworks (/docs/frameworks/asia-pacific/guam-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | GU Data Law |
| Region | Asia-Pacific |
| Country or scope | Guam |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers GU Data Law
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `GU-GCA-48-NOTIF` Breach Notification Readiness | Covered entities must notify affected parties without unreasonable delay after a breach, which requires identifying precisely which systems and components were compromised (9 G.C.A. § 48.10 et seq.) | Scan |
| `GU-GCA-48-SCOPE` Scope and Severity Determination | Notices must describe the steps taken to determine the scope and severity of the breach, presupposing version-tracked knowledge of the affected software environment (9 G.C.A. ch. 48, notice-content requirements) | Scan |
| `GU-GCA-48-CAT` Disclosed-Category Reporting | Notices must state the categories of personal information disclosed, requiring fully described data-handling components with both name and version (9 G.C.A. ch. 48, notice-content requirements) | Scan |
| `GU-GCA-48-INV` Personal-Information System Inventory | Agencies, businesses and organizations responsible for breach response must be able to account for the systems and software holding protected personal information (9 G.C.A. § 48.10 et seq., covered-entity responsibilities) | Scan |
| `GU-GCA-48-SAFE` Protection of Stored Personal Data | The law's protection of financial credentials and identifiers rewards verifiable integrity controls on the components that store and transmit them (9 G.C.A. ch. 48, protected personal-information definitions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to GU Data Law.
# Hong Kong PDPO (/docs/frameworks/asia-pacific/hong-kong-pdpo)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Personal Data (Privacy) Ordinance - 6 Data Protection Principles, doxxing prohibition (2021 amendment).
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | HK PDPO |
| Region | Asia-Pacific |
| Country or scope | Hong Kong |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers HK PDPO
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for HK PDPO.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for HK PDPO and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `HK-PDPO-DPP4` Security of Personal Data | Data users must take all reasonably practicable steps to protect personal data against unauthorised or accidental access, processing, erasure, loss or use, including integrity assurance for the software systems holding it (PDPO Schedule 1, DPP4(1)) | Scan |
| `HK-PDPO-DPP4-INV` Knowing the Systems Holding Data | Reasonably practicable security steps presuppose knowing which software components store or process personal data, so those components must be inventoried (PDPO Schedule 1, DPP4) | Scan |
| `HK-PDPO-DPP4-2` Data Processor Safeguards | When a data processor is engaged, the data user must adopt contractual or other means to prevent unauthorised access to the data, which requires knowing the suppliers behind processing software (PDPO Schedule 1, DPP4(2)) | Scan |
| `HK-PDPO-DPP2` Accuracy of Records | Data users must take reasonably practicable steps to ensure data held is accurate, and the same discipline applied to system records requires components documented with both name and version (PDPO Schedule 1, DPP2(1)) | Scan |
| `HK-PDPO-DPP5` Openness of Policies and Practices | Data users must make their personal data policies and practices generally available, and supporting technical documentation should be identifiable and timestamped (PDPO Schedule 1, DPP5) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | --------------------------------------- |
| `DPP1` | Data Collection Purpose & Adequacy |
| `DPP2` | Accuracy & Retention |
| `DPP3` | Use Limitation |
| `DPP4` | Data Security |
| `DPP5` | Transparency & Privacy Policy Notice |
| `DPP6` | Access & Correction Rights |
| `PDPO-DOXX` | Doxxing Prevention & Response (Part 6A) |
| `PDPO-DPO` | Data Protection Officer Designation |
## Policy templates
Written for HK PDPO:
* Hong Kong PDPO Data Protection Policy & Doxxing Response Plan
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to HK PDPO.
# Asia-Pacific (/docs/frameworks/asia-pacific)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Laws, regulations and standards of Asia and the Pacific. Each framework's page lists what a scan checks, its controls, its policy templates and its automated tests. How coverage works: [Compliance frameworks](/docs/frameworks).
| Framework | Country or scope | Sector | Scan requirements | Catalog controls |
| ------------------------------------------------------------------------------------------------------------- | ---------------- | ---------- | ----------------- | ---------------- |
| [Afghanistan National Privacy Framework](/docs/frameworks/asia-pacific/afghanistan-dp) | Afghanistan | Privacy | 5 | None |
| [Australia ACSC ISM](/docs/frameworks/asia-pacific/australia-ism) | Australia | Government | 7 | 10 |
| [Australia Essential Eight](/docs/frameworks/asia-pacific/aus-essential8) | Australia | Government | 6 | 18 |
| [Australia Privacy Act](/docs/frameworks/asia-pacific/australia-privacy) | Australia | Privacy | 6 | 12 |
| [Australia SOCI Act](/docs/frameworks/asia-pacific/australia-soci) | Australia | Government | 6 | 6 |
| [Bangladesh Cyber Security Act 2023](/docs/frameworks/asia-pacific/bangladesh-csa) | Bangladesh | Government | 6 | None |
| [Bhutan ICM Act 2018 (Data Protection)](/docs/frameworks/asia-pacific/bhutan-dp) | Bhutan | Privacy | 6 | None |
| [Brunei Personal Data Protection Order 2025](/docs/frameworks/asia-pacific/brunei-pdpo) | Brunei | Privacy | 5 | None |
| [Cambodia E-Commerce Law 2019 (Data Protection)](/docs/frameworks/asia-pacific/cambodia-dp) | Cambodia | Privacy | 6 | None |
| [China Cybersecurity Law](/docs/frameworks/asia-pacific/china-csl) | China | Government | 6 | 7 |
| [China Data Security Law](/docs/frameworks/asia-pacific/china-dsl) | China | Privacy | 6 | 8 |
| [China MLPS 2.0](/docs/frameworks/asia-pacific/china-mlps-2) | China | Government | 6 | 8 |
| [China PIPL](/docs/frameworks/asia-pacific/china-pipl) | China | Privacy | 6 | 12 |
| [DPRK National Data Framework](/docs/frameworks/asia-pacific/north-korea-dp) | North Korea | Privacy | 5 | None |
| [Fiji Cybercrime Act 2021](/docs/frameworks/asia-pacific/fiji-cyber) | Fiji | Government | 6 | None |
| [Fiji National ICT / Privacy Framework](/docs/frameworks/asia-pacific/fiji-privacy) | Fiji | Privacy | 5 | None |
| [French Polynesia Loi Informatique et Libertes](/docs/frameworks/asia-pacific/french-polynesia-dp) | French Polynesia | Privacy | 5 | None |
| [Guam Data Breach Law / US Frameworks](/docs/frameworks/asia-pacific/guam-dp) | Guam | Privacy | 5 | None |
| [Hong Kong PDPO](/docs/frameworks/asia-pacific/hong-kong-pdpo) | Hong Kong | Privacy | 5 | 8 |
| [India CERT-In](/docs/frameworks/asia-pacific/india-certin) | India | Government | 7 | 11 |
| [India DPDP Act](/docs/frameworks/asia-pacific/india-dpdp) | India | Privacy | 4 | 12 |
| [Indonesia PDP Law](/docs/frameworks/asia-pacific/indonesia-pdp) | Indonesia | Privacy | 6 | 7 |
| [Japan APPI](/docs/frameworks/asia-pacific/japan-appi) | Japan | Privacy | 6 | 8 |
| [Japan ISMAP](/docs/frameworks/asia-pacific/japan-ismap) | Japan | Cloud | 6 | 7 |
| [Japan METI SBOM Guidelines](/docs/frameworks/asia-pacific/japan-meti) | Japan | Government | 7 | 11 |
| [Kazakhstan Law on Personal Data and its Protection](/docs/frameworks/asia-pacific/kazakhstan-pdpl) | Kazakhstan | Privacy | 5 | None |
| [Kiribati National ICT / Privacy Framework](/docs/frameworks/asia-pacific/kiribati-privacy) | Kiribati | Privacy | 5 | None |
| [Korea ISMS-P](/docs/frameworks/asia-pacific/korea-isms-p) | South Korea | Privacy | 6 | 9 |
| [Kyrgyzstan Law on Personal Information](/docs/frameworks/asia-pacific/kyrgyzstan-pil) | Kyrgyzstan | Privacy | 5 | None |
| [Laos Law on Electronic Data Protection 2017](/docs/frameworks/asia-pacific/laos-edpl) | Laos | Privacy | 5 | None |
| [Macau PDPA](/docs/frameworks/asia-pacific/macau-pdpa) | Macau | Privacy | 5 | 8 |
| [Malaysia PDPA](/docs/frameworks/asia-pacific/malaysia-pdpa) | Malaysia | Privacy | 6 | 9 |
| [Maldives National Privacy Framework](/docs/frameworks/asia-pacific/maldives-dp) | Maldives | Privacy | 5 | None |
| [Marshall Islands National ICT / Privacy Framework](/docs/frameworks/asia-pacific/marshall-islands-privacy) | Marshall Islands | Privacy | 5 | None |
| [MAS TRMG](/docs/frameworks/asia-pacific/singapore-mas-trmg) | Singapore | Finance | 6 | 9 |
| [Micronesia National ICT / Privacy Framework](/docs/frameworks/asia-pacific/micronesia-privacy) | Micronesia | Privacy | 5 | None |
| [Mongolia Law on Personal Data Protection 2021](/docs/frameworks/asia-pacific/mongolia-pdpl) | Mongolia | Privacy | 5 | None |
| [Myanmar Law Protecting Privacy and Security of Citizens 2017](/docs/frameworks/asia-pacific/myanmar-privacy) | Myanmar | Privacy | 4 | None |
| [Nauru National ICT / Privacy Framework](/docs/frameworks/asia-pacific/nauru-privacy) | Nauru | Privacy | 5 | None |
| [Nepal Individual Privacy Act 2018](/docs/frameworks/asia-pacific/nepal-privacy-act) | Nepal | Privacy | 5 | None |
| [New Caledonia Loi Informatique et Libertes](/docs/frameworks/asia-pacific/new-caledonia-dp) | New Caledonia | Privacy | 6 | None |
| [New Zealand NZISM](/docs/frameworks/asia-pacific/new-zealand-nzism) | New Zealand | Government | 6 | 12 |
| [Pakistan PDPB](/docs/frameworks/asia-pacific/pakistan-pdpb) | Pakistan | Privacy | 6 | 6 |
| [Palau National ICT / Privacy Framework](/docs/frameworks/asia-pacific/palau-privacy) | Palau | Privacy | 5 | None |
| [Papua New Guinea Cybercrime Code Act 2016](/docs/frameworks/asia-pacific/png-cybercrime) | Papua New Guinea | Government | 5 | None |
| [Philippines Data Privacy Act](/docs/frameworks/asia-pacific/philippines-dpa) | Philippines | Privacy | 6 | 9 |
| [Samoa National ICT / Privacy Framework](/docs/frameworks/asia-pacific/samoa-privacy) | Samoa | Privacy | 5 | None |
| [Singapore Cybersecurity Act](/docs/frameworks/asia-pacific/singapore-cyber) | Singapore | Government | 6 | 11 |
| [Singapore PDPA](/docs/frameworks/asia-pacific/singapore-pdpa) | Singapore | Privacy | 6 | 10 |
| [Solomon Islands National ICT / Privacy Framework](/docs/frameworks/asia-pacific/solomon-islands-privacy) | Solomon Islands | Privacy | 5 | None |
| [South Korea PIPA](/docs/frameworks/asia-pacific/korea-pipa) | South Korea | Privacy | 6 | 12 |
| [Sri Lanka Personal Data Protection Act No. 9 of 2022](/docs/frameworks/asia-pacific/sri-lanka-pdpa) | Sri Lanka | Privacy | 5 | None |
| [Taiwan PDPA](/docs/frameworks/asia-pacific/taiwan-pdpa) | Taiwan | Privacy | 6 | 7 |
| [Tajikistan Law on Protection of Personal Data](/docs/frameworks/asia-pacific/tajikistan-pdpl) | Tajikistan | Privacy | 5 | None |
| [Thailand PDPA](/docs/frameworks/asia-pacific/thailand-pdpa) | Thailand | Privacy | 6 | 13 |
| [Timor-Leste National Privacy Framework](/docs/frameworks/asia-pacific/timor-leste-dp) | Timor-Leste | Privacy | 5 | None |
| [Tonga National ICT / Privacy Framework](/docs/frameworks/asia-pacific/tonga-privacy) | Tonga | Privacy | 5 | None |
| [Turkmenistan Law on Information about Private Life](/docs/frameworks/asia-pacific/turkmenistan-pdpl) | Turkmenistan | Privacy | 5 | None |
| [Tuvalu National ICT / Privacy Framework](/docs/frameworks/asia-pacific/tuvalu-privacy) | Tuvalu | Privacy | 5 | None |
| [Uzbekistan Law on Personal Data](/docs/frameworks/asia-pacific/uzbekistan-pdl) | Uzbekistan | Privacy | 5 | None |
| [Vanuatu National ICT / Privacy Framework](/docs/frameworks/asia-pacific/vanuatu-privacy) | Vanuatu | Privacy | 5 | None |
| [Vietnam Decree 13/2023](/docs/frameworks/asia-pacific/vietnam-decree13) | Vietnam | Privacy | 6 | 11 |
# India CERT-In (/docs/frameworks/asia-pacific/india-certin)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Software inventory, patch management, and supply chain security requirements.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | CERT-In |
| Region | Asia-Pacific |
| Country or scope | India |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers CERT-In
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for CERT-In.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for CERT-In and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `IN-CERT-INV` Software Component Inventory | Entities must maintain an inventory of the software components comprising their systems as the basis for incident response and SBOM production (CERT-In SBOM Technical Guidelines, minimum elements; CERT-In Directions 2022) | Scan |
| `IN-CERT-VER` Component Version Element | Each SBOM component entry must include the component's version string (CERT-In SBOM Technical Guidelines, minimum data fields) | Scan |
| `IN-CERT-SUP` Supplier Name Element | Each SBOM component entry must name the supplier or originator of the component (CERT-In SBOM Technical Guidelines, minimum data fields) | Scan |
| `IN-CERT-UID` Unique Component Identifiers | Components should carry unique identifiers such as package URLs to enable correlation with vulnerability advisories (CERT-In SBOM Technical Guidelines, unique identifier field) | Scan |
| `IN-CERT-HASH` Component Checksums | Cryptographic hashes of components should be included to support integrity verification of delivered software (CERT-In SBOM Technical Guidelines, checksum/hash field) | Scan |
| `IN-CERT-DEP` Dependency Relationships | The SBOM must document the dependency relationships between components (CERT-In SBOM Technical Guidelines, dependency relationship field) | Scan |
| `IN-CERT-META` SBOM Author and Timestamp | The SBOM must record who authored it and when it was created (CERT-In SBOM Technical Guidelines, author and timestamp fields) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------- | -------------------------------------------------------- |
| `CERTIN-LOG-1` | Retain ICT System Logs for Six Months |
| `CERTIN-LOG-2` | Synchronise ICT Clocks to NTP |
| `CERTIN-IR-1` | Report Cyber Incidents to CERT-In Within Six Hours |
| `CERTIN-IR-2` | Maintain a Documented Incident Response Plan |
| `CERTIN-KYC-VPN` | Maintain KYC Records for VPN Users |
| `CERTIN-KYC-CRYPTO` | Maintain KYC Records for Virtual Asset Transactions |
| `CERTIN-VULN-1` | Conduct Regular Vulnerability Assessments |
| `CERTIN-ACCESS-1` | Enforce Multi-Factor Authentication for Critical Systems |
| `CERTIN-PATCH-1` | Patch Critical Vulnerabilities Promptly |
| `CERTIN-DRP-1` | Maintain and Test Disaster Recovery Capability |
| `CERTIN-AUDIT-1` | Conduct Annual Information Security Audits |
## Policy templates
Written for CERT-In:
* Cyber Incident Reporting to CERT-In Policy
* Vulnerability Management and Security Audit Policy (CERT-In)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to CERT-In.
# India DPDP Act (/docs/frameworks/asia-pacific/india-dpdp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Digital Personal Data Protection Act 2023: data processor inventory, third-party controls.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | DPDP |
| Region | Asia-Pacific |
| Country or scope | India |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers DPDP
* **Scan requirements:** 4, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for DPDP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for DPDP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 4 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------- | -------------------------------------------------------------------------------- | ---------- |
| `DPDP-S8` Data Fiduciary Identification | India DPDP requires data fiduciary identification for personal data processing | Scan |
| `DPDP-S9` Data Principal Rights Components | DPDP requires capability for data principal rights (access, correction, erasure) | Scan |
| `DPDP-S10` Consent Manager Documentation | India DPDP allows consent managers: document consent management components | Scan |
| `DPDP-S16` Significant Data Fiduciary Controls | Significant data fiduciaries require additional security and data localization | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ------------------------------------------------------------- |
| `DPDP-S4` | Process Personal Data Only for Lawful Purposes |
| `DPDP-S5` | Provide Clear and Accessible Notice of Data Processing |
| `DPDP-S6` | Obtain Free, Specific, and Informed Consent |
| `DPDP-S6-W` | Honour Consent Withdrawal Without Detriment |
| `DPDP-BREACH` | Notify Data Principals and DPBI of Personal Data Breaches |
| `DPDP-SDF` | Apply Heightened Obligations for Significant Data Fiduciaries |
| `DPDP-CHILD` | Protect Children's Personal Data |
| `DPDP-PROCESSOR` | Govern Data Processors by Written Contract |
| `DPDP-XBORDER` | Restrict Cross-Border Data Transfers to Permitted Countries |
## Policy templates
Written for DPDP:
* Consent and Notice Management Policy (DPDP Act 2023)
* Data Principal Rights and Grievance Redressal Policy (DPDP Act 2023)
* Cross-Border Personal Data Transfer Policy (DPDP Act 2023)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to DPDP.
# Indonesia PDP Law (/docs/frameworks/asia-pacific/indonesia-pdp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Indonesia Personal Data Protection Law (UU PDP) - data subject rights, DPO, breach notification, transfers.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ID PDP |
| Region | Asia-Pacific |
| Country or scope | Indonesia |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ID PDP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for ID PDP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for ID PDP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `ID-PDP-35` Security of Personal Data Processing | Controllers must protect and ensure the security of personal data they process, including preventing unlawful access and unauthorized alteration, which presupposes verifiable integrity of the processing software (UU PDP, Art. 35) | Scan |
| `ID-PDP-46` Breach Notification Within 3x24 Hours | A controller must notify data subjects and the supervisory institution of a personal data protection failure within 3x24 hours; scoping a breach that quickly requires each deployed component to be individually identifiable (UU PDP, Art. 46) | Scan |
| `ID-PDP-DPO` Data Protection Officer Contact | Controllers whose core activities involve large-scale or systematic processing must appoint an officer responsible for personal data protection, meaning an accountable named contact must exist for the processing systems (UU PDP, DPO appointment provisions, Arts. 53-54) | Scan |
| `ID-PDP-PROC` Processor Obligations | Personal data processors must process only on the controller's instruction and share responsibility for protection, so controllers must know which suppliers stand behind the components of their processing systems (UU PDP, processor obligation provisions) | Scan |
| `ID-PDP-ACC` Demonstrable Accountability for Processing | Controllers must be able to demonstrate that processing is carried out responsibly and in accordance with the law, which requires an enumerated record of the systems and software components performing that processing (UU PDP, controller responsibility provisions) | Scan |
| `ID-PDP-XBDR` Cross-Border Transfer Documentation | Transfers of personal data outside Indonesia are permitted only where the receiving jurisdiction or recipient ensures equivalent protection, requiring identified, timestamped documentation of the transferring systems for demonstration (UU PDP, cross-border transfer provisions, Art. 56) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------------- | ----------------------------------- |
| `ID-PDP-ART4-8` | Personal Data Protection Principles |
| `ID-PDP-ART9-15` | Data Subject Rights Implementation |
| `ID-PDP-ART16-17` | Consent Requirements |
| `ID-PDP-ART18-21` | Lawful Processing without Consent |
| `ID-PDP-ART35-36` | Data Protection Officer |
| `ID-PDP-ART46` | Personal Data Breach Notification |
| `ID-PDP-ART56` | Cross-Border Data Transfer |
## Policy templates
Written for ID PDP:
* Data Protection Officer Charter (Indonesia UU 27/2022)
* Personal Data Breach Notification Procedure (Indonesia UU 27/2022 Article 46)
* Consent Management Policy (Indonesia UU 27/2022 Articles 16-21)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ID PDP.
# Japan APPI (/docs/frameworks/asia-pacific/japan-appi)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Act on the Protection of Personal Information - PPC oversight, opt-out for sale, cross-border transfer.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | APPI |
| Region | Asia-Pacific |
| Country or scope | Japan |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers APPI
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for APPI.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for APPI and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `JP-APPI-23` Security Control Measures | Business operators must take necessary and appropriate measures for the security control of personal data, including assurance of the integrity of the software systems processing it (APPI Art. 23) | Scan |
| `JP-APPI-23-INV` Knowing the Processing Systems | Security control measures presuppose that the operator knows which software components handle personal data, so those components must be inventoried (APPI Art. 23; PPC security control guidelines) | Scan |
| `JP-APPI-25` Supervision of Trustees | When entrusting personal data handling to third parties, operators must exercise necessary and appropriate supervision over the trustee, which requires knowing the suppliers behind processing software (APPI Art. 25) | Scan |
| `JP-APPI-26` Breach Reporting Readiness | Leakage incidents likely to harm individuals' rights must be reported to the PPC and affected data subjects notified, which requires quickly determining whether deployed components match a disclosed vulnerability (APPI Art. 26) | Scan |
| `JP-APPI-ACC` Accuracy and Currency of Processing Records | Operators must keep personal data accurate and up to date and delete it when no longer needed, and equivalent discipline applies to records of the processing systems, requiring components documented with name and version (APPI data-accuracy obligation) | Scan |
| `JP-APPI-TRANS` Transparency of Handling | Operators must make information about their personal data handling publicly accessible, and supporting technical documentation should be identifiable and timestamped (APPI transparency/public-disclosure obligations) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | --------------------------------------------- |
| `APPI-15-17` | Purpose Specification & Acquisition |
| `APPI-20-22` | Security Management Measures |
| `APPI-23-24` | Third-Party Provision & Cross-Border Transfer |
| `APPI-27-30` | Data Subject Rights |
| `APPI-56-61` | Anonymously Processed Information |
| `APPI-76` | Breach Notification & Reporting |
| `APPI-SPD` | Sensitive Personal Data Handling |
| `APPI-PPC-REG` | PPC Registration & Compliance Programme |
## Policy templates
Written for APPI:
* APPI Cross-Border Personal Data Transfer Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to APPI.
# Japan ISMAP (/docs/frameworks/asia-pacific/japan-ismap)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Information system Security Management and Assessment Program - cloud service registration for government.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISMAP |
| Region | Asia-Pacific |
| Country or scope | Japan |
| Sector | Cloud |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISMAP
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for ISMAP.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for ISMAP and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `JP-ISMAP-ASSET` Cloud Asset Inventory | Registered cloud services must maintain an inventory of information assets, including the software components the service is built from (ISMAP control standards, asset-management controls derived from ISO/IEC 27002) | Scan |
| `JP-ISMAP-CONF` Configuration and Change Management | Changes to systems must be controlled and configurations documented, which requires the version of every deployed component to be recorded (ISMAP control standards, change/configuration management controls) | Scan |
| `JP-ISMAP-VULN` Technical Vulnerability Management | Service providers must obtain and act on information about technical vulnerabilities of systems in use, which requires standard component identifiers to match vulnerability advisories (ISMAP control standards, technical vulnerability management controls) | Scan |
| `JP-ISMAP-INTEG` Software Integrity Controls | Controls against malware and unauthorised software require verification that deployed software is authentic, evidenced by cryptographic hashes on components (ISMAP control standards, malware-protection and software-installation controls) | Scan |
| `JP-ISMAP-SUP` Supplier Relationship Security | Security requirements must be managed across supplier relationships and the cloud supply chain, which requires the supplier of each software component to be named (ISMAP control standards, supplier-relationship controls derived from ISO/IEC 27017) | Scan |
| `JP-ISMAP-DOC` Assessment Evidence Records | ISMAP registration and annual reassessment depend on documented, auditable evidence, so machine-readable records must carry a document identity and creation timestamp (ISMAP registration and assessment rules) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------------- | -------------------------------------------- |
| `ISMAP-GOV` | Information Security Governance |
| `ISMAP-A5-A8` | Organisational & Asset Controls |
| `ISMAP-A9-A12` | Access, Cryptography & Operations Controls |
| `ISMAP-A13-A14` | Communications & System Acquisition Security |
| `ISMAP-A16-A18` | Incident Management, BCM & Compliance |
| `ISMAP-NIST-AC` | NIST 800-53 Access Control Overlay |
| `ISMAP-CLOUD-OPS` | Cloud Provider Operational Obligations |
## Policy templates
Written for ISMAP:
* ISMAP Cloud Service Onboarding Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISMAP.
# Japan METI SBOM Guidelines (/docs/frameworks/asia-pacific/japan-meti)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Software component transparency and vulnerability management requirements.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | METI |
| Region | Asia-Pacific |
| Country or scope | Japan |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers METI
* **Scan requirements:** 7, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for METI.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for METI and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 7 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `JP-METI-NAMEVER` Component Name and Version | SBOM entries must record each component's name together with its version, per the NTIA-aligned minimum elements adopted by the guide (METI SBOM Guide, minimum element data fields) | Scan |
| `JP-METI-SUP` Supplier Name | Each component must name its supplier so responsibility in the supply chain can be traced (METI SBOM Guide, supplier name minimum element) | Scan |
| `JP-METI-UID` Unique Identifiers | Components should carry other unique identifiers such as package URLs to enable automated lookup (METI SBOM Guide, unique identifier minimum element) | Scan |
| `JP-METI-DEP` Dependency Relationships | The SBOM must express the dependency relationships between components (METI SBOM Guide, dependency relationship minimum element) | Scan |
| `JP-METI-META` SBOM Author and Timestamp | The SBOM must record its author and the timestamp of its creation (METI SBOM Guide, author and timestamp minimum elements) | Scan |
| `JP-METI-TOOL` Creating Tool Provenance | The tool or organization producing the SBOM should be recorded to support trust in the document (METI SBOM Guide, SBOM creation process guidance) | Scan |
| `JP-METI-VULN` Vulnerability Management Use | SBOMs are to be used for vulnerability management, which requires components identifiable against vulnerability databases (METI SBOM Guide, vulnerability management use case) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------------- | --------------------------------------------------- |
| `METI-SBOM-VIS-1` | Maintain Complete Software Component Inventory |
| `METI-SBOM-VIS-2` | Use a Machine-Readable SBOM Format |
| `METI-SBOM-VULN-1` | Monitor Components for Known Vulnerabilities |
| `METI-SBOM-VULN-2` | Communicate Vulnerabilities to Downstream Customers |
| `METI-SBOM-LIC-1` | Track and Comply with Open Source Licenses |
| `METI-SBOM-LIC-2` | Identify Copyleft Obligations in the Supply Chain |
| `METI-SBOM-SHARE-1` | Provide SBOMs to Customers on Request |
| `METI-SBOM-SHARE-2` | Receive and Ingest Supplier SBOMs |
| `METI-SBOM-PROC-1` | Integrate SBOM Generation into the Build Pipeline |
| `METI-SBOM-PROC-2` | Maintain SBOM Accuracy Across the Product Lifecycle |
| `METI-SBOM-RISK-1` | Assess Supply Chain Risk Using SBOM Data |
## Policy templates
Written for METI:
* SBOM Lifecycle Management Policy
* Open Source License Compliance Policy
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to METI.
# Kazakhstan Law on Personal Data and its Protection (/docs/frameworks/asia-pacific/kazakhstan-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | KZ PDPL |
| Region | Asia-Pacific |
| Country or scope | Kazakhstan |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers KZ PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `KZ-PDPL-SEC` Protection of Personal Data | Owners and operators must take organizational and technical measures protecting personal data against unlawful access, alteration and destruction; component integrity hashes evidence tamper protection (Law 94-V data-protection obligations) | Scan |
| `KZ-PDPL-INV` Database and System Inventory | Duties attach to databases containing personal data and the systems operating them, which presupposes an inventory of the software components those systems comprise (Law 94-V owner/operator obligations) | Scan |
| `KZ-PDPL-THIRD` Third-Party Processing Accountability | Transfer of processing to third persons does not relieve the owner or operator of protection duties, requiring visibility into the suppliers behind the software used for processing (Law 94-V third-party provisions) | Scan |
| `KZ-PDPL-VER` Currency of Protection Systems | Protection measures must remain effective against current threats, which requires knowing the exact versions of deployed components so weaknesses can be assessed and remediated (Law 94-V ongoing-protection duty) | Scan |
| `KZ-PDPL-DOC` Documented Protection Measures | Owners and operators must be able to demonstrate the measures adopted for data protection, supported by a formally identified, timestamped record of the software in use (Law 94-V accountability duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KZ PDPL.
# Kiribati National ICT / Privacy Framework (/docs/frameworks/asia-pacific/kiribati-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | KI Privacy |
| Region | Asia-Pacific |
| Country or scope | Kiribati |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers KI Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `KI-TEL-SEC` Integrity of Communications Systems | Confidentiality duties on communications providers imply protecting the systems carrying customer communications from tampering, which integrity hashes on components make verifiable (Kiribati telecommunications legislation, confidentiality duties). | Scan |
| `KI-ICT-REC` Inventory of Data-Handling Software | Meeting confidentiality obligations presupposes an inventory of the software components that process customer data (Kiribati telecommunications legislation; national ICT policy). | Scan |
| `KI-ICT-3P` Third-Party Service Accountability | Licensed operators remain answerable for services delivered through third parties, so third-party components should have named suppliers (Kiribati telecommunications licensing rules). | Scan |
| `KI-CON-ID` Identifiable Data-Handling Components | Protecting persons from arbitrary intrusion into their information requires knowing which components handle it, so components should carry standard identifiers such as PURL or CPE (Constitution 1979, fundamental-rights privacy protections). | Scan |
| `KI-ICT-DOC` Documented System Records | Demonstrating compliance with confidentiality duties requires dated, identifiable documentation of the systems operated (Kiribati telecommunications legislation). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KI Privacy.
# Korea ISMS-P (/docs/frameworks/asia-pacific/korea-isms-p)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Personal Information and Information Security Management System - KISA certification (80 base + 22 PII controls).
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | ISMS-P |
| Region | Asia-Pacific |
| Country or scope | South Korea |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers ISMS-P
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for ISMS-P.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for ISMS-P and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `KR-ISMSP-ASSET` Asset Identification and Classification | Certification requires identifying and classifying the information assets within the management-system scope, so all software components must be inventoried (ISMS-P certification criteria, asset-management area) | Scan |
| `KR-ISMSP-DEV` Secure Acquisition and Development | Security must be applied when introducing and developing information systems, including verifying the integrity of acquired and third-party software via hashes (ISMS-P certification criteria, system acquisition and development security area) | Scan |
| `KR-ISMSP-OPS` Operational Patch and Change Control | System and service operation criteria require controlled changes and timely patching, which depends on recording the version of every deployed component (ISMS-P certification criteria, system and service operations management area) | Scan |
| `KR-ISMSP-VULN` Vulnerability Inspection and Response | Organisations must periodically inspect for and remediate technical vulnerabilities, requiring standard component identifiers to match published advisories (ISMS-P certification criteria, vulnerability-management controls) | Scan |
| `KR-ISMSP-OUT` Outsourcing and External-Party Security | Security must be managed for outsourced services and external parties, which requires knowing the supplier of the software components in use (ISMS-P certification criteria, external-party security area) | Scan |
| `KR-ISMSP-DOC` Management-System Records | The management system must maintain documented policies and operational records for certification audit, so machine-readable records must carry a document identity and creation timestamp (ISMS-P certification criteria, management-system operation and documentation area; Network Act Art. 47) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------- | --------------------------------------- |
| `1.1.1` | Information Security Governance |
| `1.2.1` | Risk Management |
| `2.4.1` | Access Management |
| `2.10.1` | Breach Response & Notification |
| `3.1.1` | PII Collection Lawfulness |
| `3.2.1` | Minimum Collection & Purpose Limitation |
| `3.3.1` | Data Subject Rights |
| `2.1.1` | Security Policy & Procedures |
| `2.6.1` | Cryptography & Key Management |
## Policy templates
Written for ISMS-P:
* ISMS-P Implementation & Certification Plan
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to ISMS-P.
# South Korea PIPA (/docs/frameworks/asia-pacific/korea-pipa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Personal Information Protection Act: technical safeguards, data inventory, access control.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | PIPA |
| Region | Asia-Pacific |
| Country or scope | South Korea |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers PIPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for PIPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for PIPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `KR-PIPA-29` Duty to Ensure Safety | Controllers must take technical measures to ensure personal information is not lost, altered or damaged, supported by the ability to verify the integrity of processing software (PIPA Art. 29) | Scan |
| `KR-PIPA-29-INV` Knowledge of Processing Systems | Applying required safeguards presupposes that the controller knows what software components make up its processing systems (PIPA Art. 29 and Enforcement Decree safety measures) | Scan |
| `KR-PIPA-26` Outsourced Processing Oversight | Entrusting processing to third parties requires documented oversight of those parties, mapping to named suppliers for the software components in use (PIPA Art. 26) | Scan |
| `KR-PIPA-34` Breach Notification Readiness | Controllers must notify data subjects and authorities of breaches, which requires knowing the versions of affected software to assess scope and cause (PIPA Art. 34) | Scan |
| `KR-PIPA-33` Privacy Impact Assessment Inputs | Privacy impact assessments of processing systems require identifying the system's components and their known risk exposure (PIPA Art. 33) | Scan |
| `KR-PIPA-30` Processing Transparency | Controllers must publish a privacy policy describing their processing, supported by dated, identifiable documentation of the processing environment (PIPA Art. 30) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | ------------------------------------------------------------- |
| `PIPA-A15` | Obtain Consent for Collection and Use of Personal Information |
| `PIPA-A17` | Obtain Separate Consent for Third-Party Provision |
| `PIPA-A18` | Limit Use to Collected Purpose |
| `PIPA-A22` | Ensure Validity and Distinctness of Consents |
| `PIPA-A23` | Restrict Processing of Sensitive Information |
| `PIPA-A24` | Protect Resident Registration Numbers |
| `PIPA-A28` | Govern Personal Information Processing Entrustment |
| `PIPA-A29` | Implement Security Measures for Personal Information |
| `PIPA-A34` | Notify Data Subjects and PIPC of Breaches |
| `PIPA-RIGHTS` | Fulfil Data Subject Access and Correction Rights |
| `PIPA-XBORDER` | Disclose and Govern Cross-Border Transfers |
| `PIPA-DPO` | Appoint a Personal Information Protection Manager |
## Policy templates
Written for PIPA:
* Consent and Sensitive Information Processing Policy (PIPA)
* Personal Data Breach Notification Policy (PIPA)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PIPA.
# Kyrgyzstan Law on Personal Information (/docs/frameworks/asia-pacific/kyrgyzstan-pil)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | KG PIL |
| Region | Asia-Pacific |
| Country or scope | Kyrgyzstan |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers KG PIL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `KG-PIL-SEC` Protection of Personal Data Arrays | Holders of personal data must take organizational and technical measures protecting data arrays against unauthorized access, alteration and destruction; component integrity hashes evidence protection against alteration (Law No. 58 data-protection obligations) | Scan |
| `KG-PIL-REG` Registration of Data Arrays | Personal data arrays and their holders are subject to registration, which presupposes that each processing system is named and its software composition enumerated (Law No. 58 registration provisions) | Scan |
| `KG-PIL-INV` Processing System Inventory | Applying protection duties to personal data arrays requires knowing the software components that make up the systems processing them (Law No. 58 holder obligations) | Scan |
| `KG-PIL-THIRD` Entrusted Processing Accountability | Entrusting processing to another person requires an agreement preserving protection requirements, and the holder remains responsible, requiring visibility into the suppliers behind the processing software (Law No. 58 entrusted-processing provisions) | Scan |
| `KG-PIL-VER` Maintained Protection Level | Protection measures must remain adequate throughout processing, which requires knowing exact versions of deployed components so weaknesses can be assessed (Law No. 58 ongoing-protection duty) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KG PIL.
# Laos Law on Electronic Data Protection 2017 (/docs/frameworks/asia-pacific/laos-edpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | LA EDPL |
| Region | Asia-Pacific |
| Country or scope | Laos |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers LA EDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LA-EDPL-SEC` Electronic Data Security Measures | Data managers must apply technical measures to keep electronic data safe from unauthorised access, alteration or destruction, evidenced by integrity hashes on system components (Law No. 25/NA on Electronic Data Protection 2017, data-security obligations) | Scan |
| `LA-EDPL-CLS` Data and System Classification | Classifying electronic data as general or specific and managing it accordingly requires an inventory of the software components that store and process it (Law No. 25/NA 2017, data classification and management provisions) | Scan |
| `LA-EDPL-ACC` Accuracy and Completeness of Data Records | Electronic data must be kept accurate and complete, which extends to system records where every component carries both a name and a version (Law No. 25/NA 2017, data accuracy and storage duties) | Scan |
| `LA-EDPL-3P` Third-Party Data Handling | Disclosure of electronic data to third parties is restricted and third-party handlers bear duties, so third-party software components should have named suppliers (Law No. 25/NA 2017, obligations of data users and third parties) | Scan |
| `LA-EDPL-DOC` Traceable System Documentation | Managing electronic data under state supervision requires system documentation that is itself identifiable, with a document ID and creation timestamp (Law No. 25/NA 2017, data-management and reporting duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LA EDPL.
# Macau PDPA (/docs/frameworks/asia-pacific/macau-pdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Macau Personal Data Protection Act (Law 8/2005) - consent, notification, GPDP oversight.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | MO PDPA |
| Region | Asia-Pacific |
| Country or scope | Macau |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers MO PDPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below, plus 8 controls from Safeguard's control catalog for MO PDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for MO PDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MO-PDPA-SEC` Security of Processing | Controllers must implement appropriate technical and organisational measures to protect personal data against accidental or unlawful destruction, alteration and unauthorised access, which includes verifiable integrity of processing software (Law 8/2005 security-of-processing obligation, Art. 15-style) | Scan |
| `MO-PDPA-SPSEC` Special Security Measures | Processing of sensitive categories requires reinforced security measures, implying maintained, up-to-date knowledge of the exact software versions handling such data (Law 8/2005 special security measures provision) | Scan |
| `MO-PDPA-NOTIF` Notification to GPDP | Automated processing operations must be notified to the GPDP with a description of the processing and the systems used, requiring identifiable, timestamped documentation of the processing platform (Law 8/2005 notification obligation) | Scan |
| `MO-PDPA-QUAL` Data Quality Principle | Personal data must be adequate, accurate and kept up to date; a processing environment can only demonstrate this discipline if its own software inventory is complete and versioned (Law 8/2005 data quality principles, Art. 5-style) | Scan |
| `MO-PDPA-PROC` Processing on Behalf of the Controller | Controllers must choose processors providing sufficient guarantees regarding security measures, which extends to knowing who supplies the software components used in processing (Law 8/2005 processor obligations) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ----------- | ------------------------------------ |
| `MAC-5` | Data Processing Principles |
| `MAC-6` | Lawful Basis for Processing |
| `MAC-8` | Sensitive Data Processing |
| `MAC-10-11` | Data Subject Rights |
| `MAC-15` | Security of Processing |
| `MAC-19-20` | Cross-Border Transfer Controls |
| `MAC-22` | Notification to GPDP |
| `MAC-DPO` | Data Protection Officer & Governance |
## Policy templates
Written for MO PDPA:
* Macau PDPA Privacy Notice
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MO PDPA.
# Malaysia PDPA (/docs/frameworks/asia-pacific/malaysia-pdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Malaysia Personal Data Protection Act - data subject rights, processor obligations, consent, transfers.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | MY PDPA |
| Region | Asia-Pacific |
| Country or scope | Malaysia |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers MY PDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for MY PDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for MY PDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `MY-PDPA-9` Security Principle | A data user must take practical steps to protect personal data from loss, misuse, modification, or unauthorized access, having regard to the technical measures available, which implies integrity verification for the software processing the data (Act 709, s.9) | Scan |
| `MY-PDPA-9-2` Data Processor Guarantees | Where processing is carried out by a data processor, the data user must ensure the processor provides sufficient guarantees of security measures and takes reasonable steps to ensure compliance, which requires knowing the suppliers behind the processing stack (Act 709, s.9(2)) | Scan |
| `MY-PDPA-11` Data Integrity Principle | Personal data and the records surrounding it must be accurate, complete, not misleading, and kept up to date; applied to processing-system records this means each software component entry carries both a name and a version (Act 709, s.11) | Scan |
| `MY-PDPA-7` Notice and Documentation Duty | The Notice and Choice Principle obliges the data user to inform data subjects about the processing being carried out, which is supported by formally identified, timestamped documentation of the processing systems (Act 709, s.7) | Scan |
| `MY-PDPA-12` Access-Readiness of Processing Systems | The Access Principle entitles data subjects to access and correct their personal data, which requires the data user to be able to locate where data lives across identifiable system components (Act 709, s.12) | Scan |
| `MY-PDPA-129` Cross-Border Transfer Control | Personal data may not be transferred outside Malaysia except to permitted jurisdictions or under specified conditions; controlling this requires knowing the provenance and operator of each component that moves data (Act 709, s.129) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ---------------- | ------------------------------------------ |
| `MY-PDPA-S6` | General Principle |
| `MY-PDPA-S7` | Notice and Choice Principle |
| `MY-PDPA-S8` | Disclosure Principle |
| `MY-PDPA-S9` | Security Principle |
| `MY-PDPA-S10` | Retention Principle |
| `MY-PDPA-S11` | Data Integrity Principle |
| `MY-PDPA-S12` | Access Principle |
| `MY-PDPA-S38-42` | Data Subject Rights: Access and Correction |
| `MY-PDPA-S129` | Cross-Border Transfer Restriction |
## Policy templates
Written for MY PDPA:
* Personal Data Protection Principles Procedure (Malaysia Act 709)
* Cross-Border Personal Data Transfer Policy (Malaysia Act 709 Section 129)
* Personal Data Security Procedure (Malaysia Act 709 Section 9)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MY PDPA.
# Maldives National Privacy Framework (/docs/frameworks/asia-pacific/maldives-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MV Privacy |
| Region | Asia-Pacific |
| Country or scope | Maldives |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MV Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MV-CONST-SEC` Safeguards for Private Communications Systems | Respecting the constitutional privacy of private communications requires protecting the systems that carry them from tampering, which integrity hashes on components make verifiable (Constitution 2008, right-to-privacy guarantee). | Scan |
| `MV-CONST-INV` Inventory of Personal-Data Software | Honouring privacy guarantees presupposes knowing which software components process personal information, so a component inventory must exist (Constitution 2008, right-to-privacy guarantee). | Scan |
| `MV-ICT-3P` Third-Party Service Accountability | Telecom-sector rules keep licensed operators answerable for services provided through third parties, so third-party components should carry named suppliers (Maldivian telecom-sector rules). | Scan |
| `MV-ICT-VER` Version Records for Incident Assessment | Assessing whether private data has been exposed after an incident requires knowing the versions of the software in operation (Constitution 2008 privacy guarantee; sectoral ICT rules). | Scan |
| `MV-ICT-DOC` Documented Software Records | Demonstrating that privacy obligations are met requires dated, identifiable documentation of the data-handling systems used (Constitution 2008 privacy guarantee; pending Personal Data Protection Bill accountability model). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MV Privacy.
# Marshall Islands National ICT / Privacy Framework (/docs/frameworks/asia-pacific/marshall-islands-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MH Privacy |
| Region | Asia-Pacific |
| Country or scope | Marshall Islands |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MH Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `MH-PDPA-SEC` Safeguards for Personal Data | Ministries and agencies processing personal data must apply protective measures so stored and processed data cannot be tampered with undetected (Personal Data Protection Act 2025, data-protection principles) | Scan |
| `MH-PDPA-PRIN` Data Protection Principles | Processing must follow the Act's personal-data-protection principles, which presuppose accurate, fully described processing components (Personal Data Protection Act 2025, personal data protection principles) | Scan |
| `MH-PDPA-CONF` Confidentiality of Engaged Persons | Directors, employees, consultants and other persons engaged in processing owe confidentiality duties, requiring visibility into who supplies each software component handling personal data (Personal Data Protection Act 2025, confidentiality provisions) | Scan |
| `MH-PDPA-AUTH` Accountability to Competent Authority | The Act establishes a competent authority with administrative and oversight powers, requiring covered bodies to account for the systems and software processing personal data (Personal Data Protection Act 2025, competent authority provisions) | Scan |
| `MH-PDPA-DOC` Documented Processing Systems | Government processing of personal data must be transparent and auditable, which requires identifiable, timestamped documentation of processing software (Personal Data Protection Act 2025, transparency and administration provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MH Privacy.
# Micronesia National ICT / Privacy Framework (/docs/frameworks/asia-pacific/micronesia-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | FM Privacy |
| Region | Asia-Pacific |
| Country or scope | Micronesia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers FM Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `FM-FSMC-349` Security Safeguards for Customer Information | Customer information may not be collected, used or disclosed without consent and must be protected by appropriate security safeguards, including integrity protection of the systems that hold it (21 F.S.M.C. § 349) | Scan |
| `FM-FSMC-350` Confidentiality of Communications | Providers must ensure the confidentiality of communications, which requires accountability for the third-party software components in the communications path (21 F.S.M.C. § 350) | Scan |
| `FM-PDPA-INV` Processing Inventory Readiness | The pending national data-protection framework for government departments presumes each covered body can inventory the software processing personal data (Personal Data Protection Act of 2025, bill pending before FSM Congress) | Scan |
| `FM-CONST-PRIV` Identifiable Data-Handling Components | Constitutional protection against unreasonable intrusion presumes operators can identify precisely which software handles personal information (FSM Constitution, Article IV declaration of rights) | Scan |
| `FM-FSMC-VER` Maintained Communications Software | Appropriate security safeguards for customer data imply that the software applying them is version-tracked and maintainable (21 F.S.M.C. § 349, security-safeguard mandate) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to FM Privacy.
# Mongolia Law on Personal Data Protection 2021 (/docs/frameworks/asia-pacific/mongolia-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MN PDPL |
| Region | Asia-Pacific |
| Country or scope | Mongolia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MN PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `MN-PDPL-SEC` Security of Personal Data Processing | Data controllers must take technical and organisational measures to protect personal data from loss, unauthorised access and alteration, evidenced by integrity hashes on processing-system components (Law on Personal Data Protection 2021, controller security obligations) | Scan |
| `MN-PDPL-INV` Processing System Inventory | Controllers are accountable for all collection and processing of personal data, which presupposes an inventory of the software systems performing that processing (Law on Personal Data Protection 2021, controller accountability duties) | Scan |
| `MN-PDPL-3P` Authorised Processor Oversight | Processing performed by other persons on the controller's behalf must be authorised and supervised, so third-party software components must have named suppliers (Law on Personal Data Protection 2021, provisions on processing by third parties) | Scan |
| `MN-PDPL-BRN` Breach Response Readiness | Controllers must respond to and report violations of data security, which requires components to be identifiable so breach impact can be scoped (Law on Personal Data Protection 2021, breach response and notification duties) | Scan |
| `MN-PDPL-VER` Known Software Versions | Keeping personal data accurate and secure over time requires knowing the exact versions of the software components in use (Law on Personal Data Protection 2021, data quality and security provisions) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MN PDPL.
# Myanmar Law Protecting Privacy and Security of Citizens 2017 (/docs/frameworks/asia-pacific/myanmar-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | MM Privacy |
| Region | Asia-Pacific |
| Country or scope | Myanmar |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers MM Privacy
* **Scan requirements:** 4, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 4 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `MM-LPPS-8` Non-Interference with Personal Data | Unlawful interference with a citizen's personal data and communications is prohibited, so operators should be able to detect unauthorised modification via integrity hashes on system components (Law No. 5/2017, s. 8 prohibitions) | Scan |
| `MM-LPPS-INV` Knowledge of Data-Holding Systems | Protecting citizens' personal data from unlawful access requires the holder to know which software systems store or process that data (Law No. 5/2017, protection of privacy and security of citizens) | Scan |
| `MM-LPPS-ID` Identifiable Components | Investigating and remedying unlawful access to personal data requires the components of processing systems to be uniquely identifiable (Law No. 5/2017, enforcement and penalty provisions) | Scan |
| `MM-LPPS-DOC` Traceable System Records | Demonstrating lawful handling of citizens' data requires system documentation to carry a document identity and creation timestamp (Law No. 5/2017, safeguarding duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MM Privacy.
# Nauru National ICT / Privacy Framework (/docs/frameworks/asia-pacific/nauru-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | NR Privacy |
| Region | Asia-Pacific |
| Country or scope | Nauru |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers NR Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `NR-CYB-INTEG` Data Integrity Protection | Systems handling personal data must be safeguarded against unauthorised alteration or corruption of data, the conduct criminalised as data interference (Cybercrime Act 2015, data-interference offences) | Scan |
| `NR-CYB-ACCESS` Unauthorised Access Prevention | Operators must know and maintain the software they run so that unauthorised access and interception offences can be prevented and investigated (Cybercrime Act 2015, illegal access and interception offences) | Scan |
| `NR-COMM-CONF` Subscriber Confidentiality Accountability | Communications providers owe confidentiality duties for subscriber information, requiring accountability for the third-party software components that touch such data (Communications and Broadcasting Act 2018, confidentiality provisions) | Scan |
| `NR-CONST-PRIV` Processing System Inventory | Constitutional privacy protection presumes an entity can account for the systems and software through which personal information is processed (Constitution of Nauru, fundamental rights and freedoms provisions) | Scan |
| `NR-DTS-DOC` Documented Auditable Systems | The national commitment to data-protection legislative reform expects government and private systems to be documented in an identifiable, auditable form (National Digital Transformation Strategy 2025-2030, data-protection reform commitment) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NR Privacy.
# Nepal Individual Privacy Act 2018 (/docs/frameworks/asia-pacific/nepal-privacy-act)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | NP Privacy |
| Region | Asia-Pacific |
| Country or scope | Nepal |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers NP Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NP-IPA-PROT` Protection of Stored Personal Information | Bodies holding personal information must keep it secure and prevent unauthorised access or alteration, evidenced by integrity hashes on data-processing software components (Individual Privacy Act 2018, protection-of-personal-information duty, Chapter on personal information) | Scan |
| `NP-IPA-INV` Records of Information Systems | Responsible collection and safe storage of personal information presupposes that the organisation maintains an inventory of the software systems in which such information resides (Individual Privacy Act 2018, collection and storage obligations) | Scan |
| `NP-IPA-3P` Third-Party Disclosure Control | Personal information may not be provided to or used by third parties without consent, so third-party software handling such data must have identifiable, named suppliers (Individual Privacy Act 2018, restrictions on disclosure to third parties) | Scan |
| `NP-IPA-VER` Misuse-Response Readiness | Liability for unauthorised use or leakage of personal information requires operators to know exactly which software versions they run so incidents can be traced and remedied (Individual Privacy Act 2018, offences and compensation provisions) | Scan |
| `NP-IPA-DOC` Traceable Records | Accountable handling of personal information requires records about processing systems to be identifiable documents with a creation timestamp (Individual Privacy Act 2018, record-keeping duties of public bodies) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NP Privacy.
# New Caledonia Loi Informatique et Libertes (/docs/frameworks/asia-pacific/new-caledonia-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | NC LIL |
| Region | Asia-Pacific |
| Country or scope | New Caledonia |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers NC LIL
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `NC-LIL-34` Security of Processing | Controllers must take all useful precautions to preserve the security of personal data and prevent its alteration or access by unauthorised parties; integrity hashes on components let tampering be detected (Law 78-17, security-of-processing obligation, Art. 34 in the pre-2018 numbering). | Scan |
| `NC-LIL-REC` Records of Processing Systems | The GDPR-equivalent accountability regime extended by the Act requires maintained records of processing, which presuppose an inventory of the software components performing it (Law 78-17, records-of-processing obligations as extended to New Caledonia). | Scan |
| `NC-LIL-ST` Processor Guarantees | Processing may only be entrusted to processors presenting sufficient guarantees, so third-party components must have named, accountable suppliers (Law 78-17, processor obligations). | Scan |
| `NC-LIL-VER` Breach-Notification Readiness | Notifying the CNIL of a breach within the required timeframe presupposes knowing the exact versions of the software processing personal data so impact can be assessed quickly (Law 78-17, breach-notification obligations). | Scan |
| `NC-LIL-DOC` Demonstrable Compliance Documentation | Demonstrating compliance to the CNIL requires dated, identifiable documentation of the systems used to process personal data (Law 78-17, accountability obligations). | Scan |
| `NC-LIL-FMT` Machine-Readable Processing Records | Records supporting supervisory review are most useful in standard machine-readable form, so the software inventory should be an SPDX or CycloneDX SBOM (Law 78-17, records and supervisory-cooperation obligations). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NC LIL.
# New Zealand NZISM (/docs/frameworks/asia-pacific/new-zealand-nzism)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
NZ Information Security Manual: software asset register, supplier management, software integrity.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | NZISM |
| Region | Asia-Pacific |
| Country or scope | New Zealand |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers NZISM
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 12 controls from Safeguard's control catalog for NZISM.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for NZISM and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `NZISM-ASSET-REG` Software Asset Register | Agencies must maintain registers of their systems and software assets, i.e. an inventory of components in use (NZISM asset management and documentation controls) | Scan |
| `NZISM-PATCH` Product Patching and Updating | Software must be kept patched and up to date, which requires knowing the installed version of each component (NZISM product patching and updating chapter) | Scan |
| `NZISM-SUPPLIER` Supplier and Outsourcing Management | Risks from suppliers and outsourced services must be identified and managed, presupposing named suppliers for software components (NZISM supplier relationships and outsourcing controls) | Scan |
| `NZISM-INTEGRITY` Software Integrity Assurance | Software acquired and installed must be verifiable as authentic and unmodified, supported by integrity hashes (NZISM software security and integrity controls) | Scan |
| `NZISM-VULN` Vulnerability Identification | Agencies must identify vulnerabilities affecting their systems, requiring components identifiable against vulnerability sources via PURL or CPE (NZISM vulnerability management controls) | Scan |
| `NZISM-DOC` System Documentation | System security documentation must be maintained and current, satisfied by dated, identifiable SBOM documentation (NZISM information security documentation chapter) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ---------------------------------------------------------- |
| `NZISM-CH5-1` | Establish an Information Security Policy Framework |
| `NZISM-CH5-2` | Classify Government Information Assets |
| `NZISM-CH6-1` | Screen Personnel with Access to Sensitive Information |
| `NZISM-CH14-1` | Encrypt Data in Transit Using Approved Algorithms |
| `NZISM-CH14-2` | Encrypt Data at Rest for Sensitive Classifications |
| `NZISM-CH17-1` | Implement Perimeter and Internal Network Security Controls |
| `NZISM-CH17-2` | Monitor Network Traffic for Threats |
| `NZISM-CH19-1` | Control Access to Systems Based on Least Privilege |
| `NZISM-CH20-1` | Manage Vulnerabilities in Government Systems |
| `NZISM-CH21-1` | Respond to Information Security Incidents |
| `NZISM-CH22-1` | Conduct Business Continuity Planning |
| `NZISM-CLOUD-1` | Assess Cloud Services Against NZISM Requirements |
## Policy templates
Written for NZISM:
* Government Information Security Policy Framework (NZISM)
* Cryptography and Network Security Policy (NZISM)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to NZISM.
# DPRK National Data Framework (/docs/frameworks/asia-pacific/north-korea-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | KP Data Frwk |
| Region | Asia-Pacific |
| Country or scope | North Korea |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers KP Data Frwk
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `KP-CONST-SEC` Integrity of Correspondence-Handling Systems | The constitutional guarantee of privacy of correspondence implies that systems carrying communications be protected from tampering, which integrity hashes on components make verifiable (Socialist Constitution, privacy-of-correspondence guarantee). | Scan |
| `KP-SIL-INV` State Software Inventory | State direction of software production presupposes a complete inventory of the software components in use (Software Industry Law 2004). | Scan |
| `KP-NET-VER` Version Records for Network Management | Administering computer networks under state rules requires knowing the versions of the software operating on them (Computer Network Management Law). | Scan |
| `KP-NET-SUP` Accountable Software Origins | State control over network software implies that each component's producer or supplier be recorded and answerable (Software Industry Law 2004; Computer Network Management Law). | Scan |
| `KP-SIL-DOC` Documented Software Records | State registration and oversight of software presuppose dated, identifiable documentation of the systems deployed (Software Industry Law 2004). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to KP Data Frwk.
# Pakistan PDPB (/docs/frameworks/asia-pacific/pakistan-pdpb)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Pakistan Personal Data Protection Bill - data subject rights, consent, cross-border transfers, DPC.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | PK PDPB |
| Region | Asia-Pacific |
| Country or scope | Pakistan |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers PK PDPB
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 6 controls from Safeguard's control catalog for PK PDPB.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for PK PDPB and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `PK-PDPB-SEC` Security Safeguards | Data controllers would be required to take practical technical and organisational steps to protect personal data from loss, misuse, or unauthorized alteration, implying integrity assurance for the software performing the processing (Pakistan PDPB draft, security-requirements clause) | Scan |
| `PK-PDPB-PROC` Processor Guarantees | A controller engaging a data processor would need to ensure the processor provides sufficient guarantees of security and compliance, requiring visibility into which suppliers stand behind the processing stack (Pakistan PDPB draft, processor obligations clause) | Scan |
| `PK-PDPB-BREACH` Breach Notification Readiness | Personal data breaches would have to be notified to the Commission within a short statutory window; assessing impact quickly requires deployed components to be individually identifiable with known versions (Pakistan PDPB draft, breach notification clause) | Scan |
| `PK-PDPB-ACC` Accountability Records | Controllers would be accountable for demonstrating compliance with the data protection principles, which requires an enumerated, documented record of the systems and software components that process personal data (Pakistan PDPB draft, accountability principle) | Scan |
| `PK-PDPB-XBDR` Cross-Border Transfer Documentation | Cross-border transfers of personal data (and localization of critical personal data) would be conditioned on adequate protection and Commission oversight, requiring identified, timestamped documentation of transferring systems (Pakistan PDPB draft, cross-border transfer clause) | Scan |
| `PK-PDPB-INTG` Data and Record Integrity | Personal data would have to be accurate, complete, and kept up to date; applied to processing-system records this means component entries carry both a name and a version (Pakistan PDPB draft, data quality principle) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------------- | ------------------------------------- |
| `PK-PDPB-CONSENT` | Consent and Lawful Basis |
| `PK-PDPB-PRINCIPLES` | Core Data Protection Principles |
| `PK-PDPB-RIGHTS` | Data Subject Rights |
| `PK-PDPB-SENSITIVE` | Sensitive Personal Data Processing |
| `PK-PDPB-CROSSBORDER` | Cross-Border Transfer Controls |
| `PK-PDPB-DPC` | Data Protection Commission Compliance |
## Policy templates
Written for PK PDPB:
* Pakistan PDPB Privacy Notice
* Pakistan PDPB Cross-Border Transfer Policy
* Pakistan PDPB Data Subject Rights Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PK PDPB.
# Palau National ICT / Privacy Framework (/docs/frameworks/asia-pacific/palau-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | PW Privacy |
| Region | Asia-Pacific |
| Country or scope | Palau |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers PW Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `PW-PRIV-SEC` Protection Against Unauthorized Modification | Agencies maintaining personal information must protect it from loss, unauthorized access, modification, disclosure or misuse, implying integrity verification of the systems that hold it (Palau Privacy Act, security-of-records obligation) | Scan |
| `PW-PRIV-PURP` Purpose-Bound, Accurate Records | Personal information may be kept only as long as necessary and used only for its original purpose, which presupposes accurate, fully described data-handling components (Palau Privacy Act, retention and purpose-limitation provisions) | Scan |
| `PW-PRIV-REC` Inventory of Personal-Information Systems | Entities must be able to account for the systems and software through which personal information is collected, stored and shared (Palau Privacy Act, agency record-keeping obligations) | Scan |
| `PW-CYB-VER` Maintained Digital Infrastructure | The national cybersecurity framework expects operators to run known, version-tracked software so vulnerabilities can be managed (Cybersecurity Act, Bill 12-9, national digital-security framework) | Scan |
| `PW-PRIV-TRANS` Transparency of Data Use | Entities must inform individuals how their data is used, which requires identifiable, timestamped documentation of the processing software (Palau Privacy Act, transparency obligations) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PW Privacy.
# Philippines Data Privacy Act (/docs/frameworks/asia-pacific/philippines-dpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Philippines DPA 2012 - NPC registration, DPO, breach notification, data subject rights.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | PH DPA |
| Region | Asia-Pacific |
| Country or scope | Philippines |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers PH DPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for PH DPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for PH DPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `PH-DPA-20` Security of Personal Information | Controllers must implement reasonable and appropriate organizational, physical, and technical measures to protect personal information against unlawful destruction, alteration, and disclosure, which requires integrity assurance over the software performing the processing (RA 10173, s.20) | Scan |
| `PH-DPA-20C` Safeguards Against Software Vulnerabilities | The required security measures include protecting the computer network against accidental, unlawful or unauthorized use and interference; knowing the exact versions of deployed components is a precondition to guarding them against known vulnerabilities (RA 10173, s.20(c)) | Scan |
| `PH-DPA-21` Accountability for Transfers to Third Parties | A controller remains accountable for personal information transferred to third parties for processing and must use contractual or other reasonable means to ensure comparable protection, which requires knowing who supplies each processing component (RA 10173, s.21) | Scan |
| `PH-DPA-11` Transparency of Processing | Processing must adhere to the principles of transparency, legitimate purpose, and proportionality; a machine-readable, standard-format account of the processing software supports demonstrable transparency (RA 10173, s.11) | Scan |
| `PH-DPA-20F` Breach Notification Readiness | The NPC and affected data subjects must be notified when sensitive personal information that may enable identity fraud has been acquired by an unauthorized person; timely scoping of such a breach requires individually identifiable system components (RA 10173, s.20(f)) | Scan |
| `PH-DPA-INV` Records of Processing Systems | Compliance with the NPC's registration and accountability regime presupposes a documented inventory of the data processing systems in use, including the software components composing them (RA 10173 and NPC implementing rules, registration of data processing systems) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | ------------------------------------------------ |
| `PH-DPA-S12` | Lawful Basis for Processing |
| `PH-DPA-S16` | Right to Be Informed |
| `PH-DPA-S17-18` | Right to Access and Rectification |
| `PH-DPA-S19` | Right to Erasure and Blocking |
| `PH-DPA-S20` | Security Measures for Personal Information |
| `PH-DPA-S21` | Subcontractor and Third-Party Processor Security |
| `PH-DPA-S22-24` | Data Protection Officer Designation |
| `PH-DPA-S25-26` | NPC Registration |
| `PH-DPA-IRR` | Implementing Rules Compliance |
## Policy templates
Written for PH DPA:
* Data Protection Officer Charter (Philippines RA 10173)
* Personal Information Security Policy (Philippines RA 10173 Section 20)
* Data Subject Rights Procedure (Philippines RA 10173 Sections 16-19)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PH DPA.
# Papua New Guinea Cybercrime Code Act 2016 (/docs/frameworks/asia-pacific/png-cybercrime)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National cybersecurity framework: software asset inventory, component integrity, supply-chain verification, and vulnerability management.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | PG Cyber |
| Region | Asia-Pacific |
| Country or scope | Papua New Guinea |
| Sector | Government |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers PG Cyber
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `PG-CCA-ACC` Unauthorised-Access Detection Readiness | Illegal access to computer systems is an offence, and detecting or investigating it requires system components to be uniquely identifiable (Cybercrime Code Act 2016, illegal-access offences, Part on offences against computer data and systems) | Scan |
| `PG-CCA-INT` Data Interference Detection | Unauthorised damaging, deletion or alteration of computer data is criminalised, so operators should be able to detect tampering via integrity hashes on software components (Cybercrime Code Act 2016, data-interference offences) | Scan |
| `PG-CCA-SYS` System Inventory | Protecting systems from serious hindering (system interference) presupposes an inventory of the software components that make up those systems (Cybercrime Code Act 2016, system-interference offences) | Scan |
| `PG-CCA-VER` Version Knowledge for Incident Response | Responding to and prosecuting cyber offences requires knowing exactly which software versions were running when an incident occurred (Cybercrime Code Act 2016, investigation provisions) | Scan |
| `PG-CCA-PRES` Forensic Record Preservation | Expedited preservation of stored computer data during investigations requires system records to be identifiable, timestamped documents (Cybercrime Code Act 2016, data-preservation and procedural powers) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PG Cyber.
# Samoa National ICT / Privacy Framework (/docs/frameworks/asia-pacific/samoa-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | WS Privacy |
| Region | Asia-Pacific |
| Country or scope | Samoa |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers WS Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `WS-TEL-SEC` Integrity of Communications Systems | Confidentiality duties on telecom providers imply protecting the systems that carry customer communications from tampering, which integrity hashes on components make verifiable (Telecommunications Act 2005, confidentiality duties). | Scan |
| `WS-CRM-VER` Version Records for Computer-Misuse Response | Detecting and responding to unauthorised access or data interference requires knowing the versions of the software in operation (Crimes Act 2013, computer-offence provisions). | Scan |
| `WS-TEL-3P` Third-Party Service Accountability | Licensed operators remain answerable for services delivered through third parties, so third-party components should have named suppliers (Telecommunications Act 2005, licensing obligations). | Scan |
| `WS-ICT-REC` Inventory of Data-Handling Software | Meeting confidentiality obligations presupposes knowing which software components handle customer data, so a component inventory must exist (Telecommunications Act 2005; national ICT policy). | Scan |
| `WS-ICT-DOC` Documented System Records | Demonstrating compliance with confidentiality and computer-security duties requires dated, identifiable documentation of the systems operated (Telecommunications Act 2005; Crimes Act 2013). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to WS Privacy.
# Singapore Cybersecurity Act (/docs/frameworks/asia-pacific/singapore-cyber)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
CII cybersecurity requirements: software inventory, patch management, vulnerability reporting.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SG Cyber |
| Region | Asia-Pacific |
| Country or scope | Singapore |
| Sector | Government |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SG Cyber
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for SG Cyber.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for SG Cyber and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SG-CSA-10` Code of Practice Compliance: Asset Inventory | CII owners must comply with applicable codes of practice, which require maintaining an inventory of hardware and software assets supporting the CII (Cybersecurity Act 2018 s.10; CCoP asset management requirements) | Scan |
| `SG-CSA-PATCH` Patch Management Readiness | The Cybersecurity Code of Practice requires timely patching of CII systems, which presupposes known versions for the software components in scope (CCoP under Cybersecurity Act 2018 s.10) | Scan |
| `SG-CSA-14` Incident Assessment Readiness | CII owners must report prescribed cybersecurity incidents, and assessing whether a disclosed vulnerability or incident affects the CII requires identifiable software components (Cybersecurity Act 2018 s.14 incident reporting duty) | Scan |
| `SG-CSA-RISK` Risk Assessment of CII Software | CII owners must conduct regular cybersecurity risk assessments of the CII, requiring complete records (name and version) of the software composing it (Cybersecurity Act 2018 s.15 audits and risk assessments) | Scan |
| `SG-CSA-VENDOR` Supply Chain Visibility | The 2024 amendments and CCoP place expectations on managing supply chain risk to CII, requiring the supplier of software components to be known (Cybersecurity (Amendment) Act 2024; CCoP supply chain provisions) | Scan |
| `SG-CSA-INTEG` System Integrity Safeguards | Codes of practice require measures to protect the integrity of CII systems and detect unauthorized modification, supported by integrity hashes on software components (CCoP system integrity requirements under Cybersecurity Act 2018 s.10) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| -------------- | -------------------------------------------------------------- |
| `SCA-CII-1` | Designate and Register Critical Information Infrastructure |
| `SCA-CCOP-2` | Conduct Cybersecurity Risk Assessments of CII |
| `SCA-CCOP-3` | Audit CII Cybersecurity Posture Annually |
| `SCA-CCOP-4` | Conduct Penetration Testing of CII |
| `SCA-IR-1` | Report Cybersecurity Incidents to CSA Within Prescribed Period |
| `SCA-IR-2` | Maintain and Test a Cybersecurity Incident Response Plan |
| `SCA-ACCESS-1` | Enforce Least Privilege and Multi-Factor Authentication |
| `SCA-SUPPLY-1` | Assess Cybersecurity Risks in the ICT Supply Chain |
| `SCA-PATCH-1` | Apply Security Patches to CII Systems Promptly |
| `SCA-LOG-1` | Maintain Audit Logs for CII Systems |
| `SCA-NETW-1` | Segment CII from Non-Critical Networks |
## Policy templates
Written for SG Cyber:
* Operator of Critical Information Infrastructure Cybersecurity Policy
* ICT Supply Chain Cybersecurity Policy (Singapore)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SG Cyber.
# MAS TRMG (/docs/frameworks/asia-pacific/singapore-mas-trmg)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Singapore MAS Technology Risk Management Guidelines - governance, risk, security, IT operations.
| | |
| ----------------- | ------------------------------------------------------- |
| Region | Asia-Pacific |
| Country or scope | Singapore |
| Sector | Finance |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers MAS TRMG
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 9 controls from Safeguard's control catalog for MAS TRMG.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for MAS TRMG and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SG-TRMG-INV` IT Asset Inventory | Financial institutions should maintain an up-to-date inventory of their information system assets throughout the asset life cycle, so all software components must be enumerated (MAS TRMG 2021, IT asset-management expectations) | Scan |
| `SG-TRMG-OSS` Open-Source and Third-Party Software Risk | Institutions should assess and manage the risks of using third-party and open-source software in their applications, which requires the supplier or origin of each component to be identified (MAS TRMG 2021, software application development and management chapter) | Scan |
| `SG-TRMG-PATCH` Patch and Vulnerability Management | Institutions should establish processes to identify, categorise and remediate vulnerabilities and apply security patches timely, which requires every component's version to be recorded (MAS TRMG 2021, vulnerability and patch management expectations) | Scan |
| `SG-TRMG-INTEG` Software Integrity in the Delivery Pipeline | Secure development and deployment practices should verify the integrity and authenticity of software throughout the delivery pipeline, evidenced by cryptographic hashes on components (MAS TRMG 2021, secure software development expectations) | Scan |
| `SG-TRMG-VA` Cyber Security Assessment Readiness | Institutions should conduct regular vulnerability assessments and penetration tests of their systems, which requires standard component identifiers to correlate findings with known vulnerabilities (MAS TRMG 2021, cyber security assessment chapter) | Scan |
| `SG-TRMG-EOL` No Unsupported or Indeterminate Software | Institutions should manage the risk of outdated or unsupported systems, which excludes running components at vague or floating version specifications that prevent support-status determination (MAS TRMG 2021, IT asset life-cycle and obsolescence expectations) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------- | ------------------------------------ |
| `TRMG-4` | Board & Senior Management Oversight |
| `TRMG-5` | Technology Risk Management Framework |
| `TRMG-6` | IT Project & Procurement Management |
| `TRMG-7` | System Reliability & Availability |
| `TRMG-8` | System Lifecycle Management |
| `TRMG-9` | Cyber Resilience |
| `TRMG-10` | Online Financial Services Security |
| `TRMG-11` | Data Centre Security & Operations |
| `TRMG-13` | Cryptography Controls |
## Policy templates
Written for MAS TRMG:
* MAS TRMG Technology & Cyber Incident Response Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to MAS TRMG.
# Singapore PDPA (/docs/frameworks/asia-pacific/singapore-pdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Personal Data Protection Act - consent, purpose limitation, notification, access/correction, accountability.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | SG PDPA |
| Region | Asia-Pacific |
| Country or scope | Singapore |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers SG PDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 10 controls from Safeguard's control catalog for SG PDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 23: 1 written for SG PDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `SG-PDPA-24` Protection Obligation | Organisations must protect personal data in their possession or control by making reasonable security arrangements against unauthorised access, modification or disposal, including integrity assurance for processing software (PDPA 2012 s. 24) | Scan |
| `SG-PDPA-24-PATCH` Reasonable ICT Security Upkeep | Reasonable security arrangements for electronic personal data include keeping software patched and updated, which requires the version of each deployed component to be recorded (PDPA 2012 s. 24; PDPC guidance on ICT security arrangements) | Scan |
| `SG-PDPA-11` Accountability and DPO Designation | Organisations are responsible for the personal data they handle and must designate at least one individual (the data protection officer) responsible for compliance, so documentation must record an accountable contact (PDPA 2012 s. 11) | Scan |
| `SG-PDPA-12` Documented Policies and Practices | Organisations must develop and implement policies and practices necessary to meet their PDPA obligations and make information about them available, so supporting technical records must be identifiable and timestamped (PDPA 2012 s. 12) | Scan |
| `SG-PDPA-26` Data Breach Assessment Readiness | Organisations must assess suspected data breaches and notify the PDPC of notifiable breaches, which requires quickly determining whether deployed components match a disclosed vulnerability (PDPA 2012 Part 6A, ss. 26A-26D, introduced by the 2020 amendment) | Scan |
| `SG-PDPA-4` Data Intermediary Accountability | An organisation engaging a data intermediary to process data on its behalf remains responsible as if it processed the data itself, which requires knowing the suppliers behind the processing software (PDPA 2012 s. 4(2)-(3)) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------------- | ----------------------------------- |
| `PDPA-CONSENT` | Consent Obligation |
| `PDPA-PURPOSE` | Purpose Limitation Obligation |
| `PDPA-NOTIFICATION` | Notification Obligation |
| `PDPA-ACCESS` | Access & Correction Obligation |
| `PDPA-ACCURACY` | Accuracy Obligation |
| `PDPA-PROTECTION` | Protection Obligation |
| `PDPA-RETENTION` | Retention Limitation Obligation |
| `PDPA-TRANSFER` | Transfer Limitation Obligation |
| `PDPA-ACCOUNTABILITY` | Accountability Obligation |
| `PDPA-DBN` | Data Breach Notification Obligation |
## Policy templates
Written for SG PDPA:
* Singapore PDPA Data Breach Notification Form & Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SG PDPA.
# Solomon Islands National ICT / Privacy Framework (/docs/frameworks/asia-pacific/solomon-islands-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | SB Privacy |
| Region | Asia-Pacific |
| Country or scope | Solomon Islands |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers SB Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `SB-TEL-SEC` Integrity of Communications Systems | Confidentiality duties on telecommunications providers imply protecting the systems carrying customer communications from tampering, which integrity hashes on components make verifiable (Telecommunications Act 2009, confidentiality duties). | Scan |
| `SB-TEL-3P` Third-Party Service Accountability | Licensed operators remain answerable for services delivered through third parties, so third-party components should have named suppliers (Telecommunications Act 2009, licensing obligations). | Scan |
| `SB-CON-ID` Identifiable Data-Handling Components | Protecting persons from arbitrary intrusion into their information requires knowing which components handle it, so components should carry standard identifiers such as PURL or CPE (Constitution 1978, fundamental-rights privacy protections). | Scan |
| `SB-ICT-REC` Inventory of Data-Handling Software | Meeting confidentiality obligations presupposes an inventory of the software components that process customer data (Telecommunications Act 2009; national ICT policy). | Scan |
| `SB-ICT-DOC` Documented System Records | Demonstrating compliance with confidentiality duties requires dated, identifiable documentation of the systems operated (Telecommunications Act 2009). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to SB Privacy.
# Sri Lanka Personal Data Protection Act No. 9 of 2022 (/docs/frameworks/asia-pacific/sri-lanka-pdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | LK PDPA |
| Region | Asia-Pacific |
| Country or scope | Sri Lanka |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers LK PDPA
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `LK-PDPA-12` Data Protection Management Programme | Controllers must implement internal controls and a data protection management programme, which presupposes an accurate inventory of the software systems that process personal data (PDPA No. 9 of 2022, s. 12) | Scan |
| `LK-PDPA-SEC` Security of Processing | Appropriate technical and organisational measures must safeguard the integrity and confidentiality of personal data, evidenced by integrity hashes on the components of processing systems (PDPA No. 9 of 2022, s. 12(1) security safeguards) | Scan |
| `LK-PDPA-PROC` Processor Accountability | Controllers may only engage processors that give sufficient guarantees under a binding agreement, so third-party software components must have identifiable suppliers (PDPA No. 9 of 2022, processor-engagement obligations, Part II) | Scan |
| `LK-PDPA-BRN` Breach Notification Readiness | Controllers must notify the Data Protection Authority of personal data breaches, which requires components to be identifiable (PURL/CPE) so breach impact can be assessed quickly (PDPA No. 9 of 2022, personal data breach notification duty, Part II) | Scan |
| `LK-PDPA-DOC` Demonstrable Documentation | The accountability principle requires controllers to be able to demonstrate compliance, so software records must be traceable documents with an identity and creation timestamp (PDPA No. 9 of 2022, s. 12 accountability duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to LK PDPA.
# Taiwan PDPA (/docs/frameworks/asia-pacific/taiwan-pdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Taiwan Personal Data Protection Act - rights, consent, cross-border transfer, sensitive data.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | TW PDPA |
| Region | Asia-Pacific |
| Country or scope | Taiwan |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers TW PDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 7 controls from Safeguard's control catalog for TW PDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for TW PDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `TW-PDPA-27` Proper Security Measures | Non-government agencies holding personal data must adopt proper security measures to prevent the data from being stolen, altered, damaged, destroyed or disclosed, including integrity assurance for the processing software (PDPA Art. 27(1)) | Scan |
| `TW-PDPA-27-PLAN` Security and Maintenance Plan | The competent authority may require a security and maintenance plan for personal data files, and the enforcement rules enumerate technical measures such as data-security and equipment-security management, which require tracked component versions (PDPA Art. 27(2) and Enforcement Rules security-measure catalogue) | Scan |
| `TW-PDPA-18` Dedicated Security Personnel | Government agencies keeping personal data files must assign dedicated personnel to handle security and maintenance, so security documentation must record an accountable contact (PDPA Art. 18) | Scan |
| `TW-PDPA-12` Breach Notification Readiness | When personal data is stolen, disclosed, altered or otherwise infringed, the agency must notify the affected data subjects after investigation, which requires quickly determining whether deployed components match a disclosed vulnerability (PDPA Art. 12) | Scan |
| `TW-PDPA-OUT` Supervision of Commissioned Processing | Agencies commissioning third parties to collect or process personal data must properly supervise the commissioned party, which requires knowing the suppliers behind the processing software (PDPA commissioning provisions and Enforcement Rules supervision requirements) | Scan |
| `TW-PDPA-INV` Inventory of Processing Systems | Proper security measures presuppose that the agency knows which software components process personal data, so those components must be inventoried (PDPA Art. 27 security-measures obligation) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------ | ----------------------------------- |
| `PDPA-5` | Lawful Collection Principles |
| `PDPA-6` | Sensitive Personal Data |
| `PDPA-8` | Notice to Data Subject |
| `PDPA-19-20` | Indirect Collection & Secondary Use |
| `PDPA-27-28` | Security Safeguards |
| `PDPA-41` | Cross-Border Transfer Restrictions |
| `PDPA-DSR` | Data Subject Rights Management |
## Policy templates
Written for TW PDPA:
* Taiwan PDPA Privacy Notice
* Taiwan PDPA Breach Notification Procedure
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TW PDPA.
# Tajikistan Law on Protection of Personal Data (/docs/frameworks/asia-pacific/tajikistan-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TJ PDPL |
| Region | Asia-Pacific |
| Country or scope | Tajikistan |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TJ PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TJ-PDPL-SEC` Protection of Personal Data | Owners and operators must take measures preventing unlawful access to, destruction, modification, blocking or copying of personal data; verifiable integrity hashes on software components evidence protection against modification (Law No. 1537 protection obligations) | Scan |
| `TJ-PDPL-INV` Database and System Inventory | Protection duties attach to personal data databases and the systems operating them, which presupposes an inventory of the software components those systems comprise (Law No. 1537 owner/operator obligations) | Scan |
| `TJ-PDPL-THIRD` Delegated Processing Accountability | Delegating processing to third persons does not relieve the owner of protection responsibility, requiring visibility into the suppliers behind the software used for processing (Law No. 1537 delegated-processing provisions) | Scan |
| `TJ-PDPL-VER` Maintained Security of Systems | Protection measures must remain effective throughout processing, which requires knowing exact versions of deployed components so weaknesses can be assessed and corrected (Law No. 1537 ongoing-protection duty) | Scan |
| `TJ-PDPL-DOC` Documented Protection Measures | Owners and operators must be able to demonstrate the protective measures adopted, supported by a formally identified, timestamped record of the software in use (Law No. 1537 accountability duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TJ PDPL.
# Thailand PDPA (/docs/frameworks/asia-pacific/thailand-pdpa)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Personal Data Protection Act: data processing software inventory, controller accountability.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | PDPA |
| Region | Asia-Pacific |
| Country or scope | Thailand |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers PDPA
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 13 controls from Safeguard's control catalog for PDPA.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 24: 2 written for PDPA and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TH-PDPA-37-1` Security Measures | Controllers must provide appropriate security measures to prevent unauthorized loss, access, use, alteration, or disclosure of personal data, which for processing software implies integrity assurance of its components (PDPA B.E. 2562 s.37(1)) | Scan |
| `TH-PDPA-39` Records of Processing | Controllers must maintain records of processing activities for inspection, which extends to knowing the software components performing that processing (PDPA B.E. 2562 s.39) | Scan |
| `TH-PDPA-40` Processor Obligations | Data processors act under controller instructions and must implement security measures, so third-party software suppliers involved in processing must be identifiable (PDPA B.E. 2562 s.40) | Scan |
| `TH-PDPA-37-4` Breach Notification Readiness | Controllers must notify the PDPC of breaches within 72 hours of becoming aware; assessing whether a disclosed vulnerability affects processing systems requires versioned, identifiable components (PDPA B.E. 2562 s.37(4)) | Scan |
| `TH-PDPA-37-ID` Vulnerability Exposure Assessment | Maintaining appropriate security over time requires matching processing software against known vulnerabilities, which needs standard identifiers on components (PDPA B.E. 2562 s.37 security duty, ongoing review) | Scan |
| `TH-PDPA-39-DOC` Inspectable Documentation | Records kept for PDPC inspection should be dated and identifiable documents; a timestamped SBOM with a document ID evidences the software-inventory portion of those records (PDPA B.E. 2562 s.39 record-keeping duty) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| ------------- | ------------------------------------------------------- |
| `PDPA-S19` | Collect Personal Data Under a Lawful Basis |
| `PDPA-S20` | Provide Data Subjects with Comprehensive Notice |
| `PDPA-S22` | Obtain Explicit Consent in Clear and Plain Language |
| `PDPA-S23` | Provide Parental Consent Mechanism for Minors |
| `PDPA-S26` | Restrict Processing of Sensitive Personal Data |
| `PDPA-S27` | Implement Security Measures Appropriate to Risk |
| `PDPA-S28` | Govern Data Processors by Written Agreement |
| `PDPA-S30` | Retain Personal Data Only as Long as Necessary |
| `PDPA-S37` | Notify PDPC and Data Subjects of Personal Data Breaches |
| `PDPA-S39` | Process Cross-Border Transfers Lawfully |
| `PDPA-S40` | Appoint a Data Protection Officer Where Required |
| `PDPA-S41` | Maintain Records of Processing Activities |
| `PDPA-RIGHTS` | Fulfil Data Subject Rights Requests |
## Policy templates
Written for PDPA:
* Consent Management and Data Subject Rights Policy (PDPA Thailand)
* Data Breach Notification and Cross-Border Transfer Policy (PDPA Thailand)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to PDPA.
# Timor-Leste National Privacy Framework (/docs/frameworks/asia-pacific/timor-leste-dp)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TL Privacy |
| Region | Asia-Pacific |
| Country or scope | Timor-Leste |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TL Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TL-C38-REC` Accurate Records of Data-Processing Software | The constitutional right to know and correct data held about oneself presupposes an accurate, maintained record of the software components that store and process personal records (Constitution 2002, s. 38). | Scan |
| `TL-C38-ACC` Identifiable Data-Holding Components | Giving effect to access and rectification rights requires knowing precisely which components hold personal data, so components should carry standard identifiers such as PURL or CPE (Constitution 2002, s. 38). | Scan |
| `TL-C36-SEC` Integrity of Personal-Data Systems | Protecting personal data and private life from interference requires that data-handling components be verifiable against tampering via integrity hashes (Constitution 2002, ss. 36 and 38 privacy and data-protection guarantees). | Scan |
| `TL-C38-VER` Version Records for Exposure Assessment | Assessing whether personal records have been exposed or misused requires knowing the versions of the software in operation (Constitution 2002, s. 38-derived safeguard duty). | Scan |
| `TL-ICT-DOC` Documented Processing Systems | Demonstrating that constitutional data-protection duties are met requires dated, identifiable documentation of the systems used to process personal records (Constitution 2002, s. 38; state ICT policy). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TL Privacy.
# Tonga National ICT / Privacy Framework (/docs/frameworks/asia-pacific/tonga-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TO Privacy |
| Region | Asia-Pacific |
| Country or scope | Tonga |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TO Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------- |
| `TO-CCA-INT` Protection Against Data Interference | The computer-crime regime protects data and systems from unauthorised alteration or damage, so components should carry integrity hashes that let tampering be detected (Computer Crimes Act 2003, data- and system-interference offences). | Scan |
| `TO-CCA-VER` Version Records for Intrusion Response | Investigating unauthorised access to computer systems requires knowing the versions of the software in operation (Computer Crimes Act 2003, illegal-access offence). | Scan |
| `TO-COM-3P` Third-Party Service Accountability | Licensed communications operators remain answerable for services delivered through third parties, so third-party components should have named suppliers (Communications Act 2015, licensing and confidentiality duties). | Scan |
| `TO-ICT-REC` Inventory of Communications Software | Meeting confidentiality duties over customer communications presupposes an inventory of the software components handling them (Communications Act 2015; national ICT policy). | Scan |
| `TO-ICT-DOC` Documented System Records | Demonstrating compliance with computer-security and confidentiality duties requires dated, identifiable documentation of the systems operated (Computer Crimes Act 2003; Communications Act 2015). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TO Privacy.
# Turkmenistan Law on Information about Private Life (/docs/frameworks/asia-pacific/turkmenistan-pdpl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TM PDPL |
| Region | Asia-Pacific |
| Country or scope | Turkmenistan |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TM PDPL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TM-PDPL-SEC` Protection of Private-Life Information | Operators must take organizational and technical measures preventing unlawful access to, modification or destruction of personal data; component integrity hashes evidence protection against modification (Law on Information about Private Life protection obligations) | Scan |
| `TM-PDPL-INV` Processing System Inventory | Applying protection duties to systems processing personal data requires knowing the software components those systems comprise (Law on Information about Private Life operator obligations) | Scan |
| `TM-PDPL-THIRD` Third-Party Processing Accountability | Where processing involves third persons, the operator remains responsible for protecting the data, requiring visibility into the suppliers behind the processing software (Law on Information about Private Life third-party provisions) | Scan |
| `TM-PDPL-VER` Maintained Protection of Systems | Protection measures must remain adequate throughout processing, which requires knowing exact versions of deployed components so weaknesses can be assessed (Law on Information about Private Life ongoing-protection duty) | Scan |
| `TM-PDPL-DOC` Documented Safeguards | Operators should be able to evidence the safeguards applied to systems handling private-life information, supported by a formally identified, timestamped record of the software in use (Law on Information about Private Life accountability duties) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TM PDPL.
# Tuvalu National ICT / Privacy Framework (/docs/frameworks/asia-pacific/tuvalu-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | TV Privacy |
| Region | Asia-Pacific |
| Country or scope | Tuvalu |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers TV Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `TV-TEL-SEC` Integrity of Communications Systems | Confidentiality duties on communications providers imply protecting the systems carrying customer communications from tampering, which integrity hashes on components make verifiable (Tuvalu telecommunications legislation, confidentiality duties). | Scan |
| `TV-ICT-REC` Inventory of Data-Handling Software | Meeting confidentiality obligations presupposes an inventory of the software components that process customer data (Tuvalu telecommunications legislation; national ICT policy). | Scan |
| `TV-ICT-3P` Third-Party Service Accountability | Operators remain answerable for services delivered through third parties, so third-party components should have named suppliers (Tuvalu telecommunications licensing rules). | Scan |
| `TV-CON-ID` Identifiable Data-Handling Components | Protecting persons from arbitrary interference with their privacy requires knowing which components handle their information, so components should carry standard identifiers such as PURL or CPE (Constitution of Tuvalu 1986, bill-of-rights privacy protections). | Scan |
| `TV-ICT-DOC` Documented System Records | Demonstrating compliance with confidentiality duties requires dated, identifiable documentation of the systems operated (Tuvalu telecommunications legislation). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to TV Privacy.
# Uzbekistan Law on Personal Data (/docs/frameworks/asia-pacific/uzbekistan-pdl)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | UZ PDL |
| Region | Asia-Pacific |
| Country or scope | Uzbekistan |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers UZ PDL
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `UZ-PDL-SEC` Protection of Personal Data | Owners and operators must take measures preventing unlawful access to, destruction, modification or copying of personal data; verifiable integrity hashes on software components evidence protection against modification (Law ZRU-547 protection obligations) | Scan |
| `UZ-PDL-REG` Database Registration | Personal data databases must be registered in the state register, which presupposes that each system is named and its software composition enumerated (Law ZRU-547 registration provisions) | Scan |
| `UZ-PDL-INV` Processing System Inventory | Applying protection duties to personal data databases requires knowing the software components that make up the systems processing the data (Law ZRU-547 owner/operator obligations) | Scan |
| `UZ-PDL-THIRD` Third-Party Processing Accountability | Where processing is carried out by third persons on the owner's instruction, protection duties persist, requiring visibility into the suppliers behind the processing software (Law ZRU-547 third-party provisions) | Scan |
| `UZ-PDL-VER` Maintained Security of Databases | Protection measures must remain adequate over the database's operation, which requires knowing exact versions of deployed components so weaknesses can be assessed (Law ZRU-547 ongoing-protection duty) | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to UZ PDL.
# Vanuatu National ICT / Privacy Framework (/docs/frameworks/asia-pacific/vanuatu-privacy)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
National data-protection law: technical safeguards, records of processing software, third-party/processor accountability, and integrity controls.
| | |
| ----------------- | ------------------------------------------------------ |
| Short name | VU Privacy |
| Region | Asia-Pacific |
| Country or scope | Vanuatu |
| Sector | Privacy |
| In your workspace | Off until you switch it on in **Compliance › Manage**. |
## How Safeguard covers VU Privacy
* **Scan requirements:** 5, all decided by a scan.
* **Controls:** the scan requirements below.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 5 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `VU-CYB-INT` Protection Against Data and System Interference | Cybercrime offences protect computer data and systems from unauthorised alteration, so components should carry integrity hashes that let tampering be detected (Cybercrime Act 2021, data- and system-interference offences). | Scan |
| `VU-CYB-VER` Version Records for Incident Response | Investigating illegal access and assessing exploited weaknesses requires knowing the versions of the software in operation (Cybercrime Act 2021, illegal-access offence). | Scan |
| `VU-ETA-DOC` Reliable Electronic Records | The e-transactions regime depends on trustworthy electronic records, so the software record should carry a document identifier and creation timestamp (Electronic Transactions Act 2000, record-integrity provisions). | Scan |
| `VU-ICT-REC` Inventory of Data-Handling Software | National cybersecurity arrangements presuppose knowing which software components process data, so a component inventory must exist (national cybersecurity framework; Cybercrime Act 2021). | Scan |
| `VU-ICT-3P` Third-Party Service Accountability | Operators remain answerable for services and software supplied by third parties, so third-party components should have named suppliers (telecommunications licensing rules; national cybersecurity framework). | Scan |
## Policy templates
All 22 from the [standard set](/docs/frameworks#policy-templates), adapted to VU Privacy.
# Vietnam Decree 13/2023 (/docs/frameworks/asia-pacific/vietnam-decree13)
{/* AUTO-GENERATED by scripts/gen-framework-pages.mjs from sg-ui-app lib/compliance, data/scan-requirements.json and data/framework-coverage.json. Do not edit by hand: change the sources, then run the script. */}
Vietnam personal data protection decree - cross-border transfer DPIA, consent, data subject rights.
| | |
| ----------------- | ------------------------------------------------------- |
| Short name | VN D13 |
| Region | Asia-Pacific |
| Country or scope | Vietnam |
| Sector | Privacy |
| In your workspace | On unless you switch it off in **Compliance › Manage**. |
## How Safeguard covers VN D13
* **Scan requirements:** 6, all decided by a scan.
* **Controls:** the scan requirements below, plus 11 controls from Safeguard's control catalog for VN D13.
* **Automated tests:** none map to it directly. You can link any automated test to its controls yourself ([how](/docs/framework-connectors#every-other-framework)).
* **Policy templates:** 25: 3 written for VN D13 and 22 from the [standard set](/docs/frameworks#policy-templates).
How each kind of coverage works, and what the readiness score counts: [Compliance frameworks](/docs/frameworks).
## What a scan checks
Each scan of a product checks these 6 requirements against what the scan found, including the product's software inventory (SBOM).
| Requirement | What Safeguard checks | Decided by |
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- |
| `VN-D13-26` Personal Data Protection Measures | Regulated entities must apply management and technical measures to protect personal data throughout processing, implying verifiable integrity of the software systems that handle the data (Decree 13/2023/ND-CP, Art. 26) | Scan |
| `VN-D13-24` Impact Assessment Dossier | Controllers and processors must prepare and maintain a personal data processing impact assessment dossier from the start of processing, which requires an enumerated account of the processing systems and their software components (Decree 13/2023/ND-CP, Art. 24) | Scan |
| `VN-D13-25` Cross-Border Transfer Assessment Documentation | Transferring Vietnamese citizens' personal data abroad requires a transfer impact assessment dossier kept available for inspection, demanding formally identified, timestamped technical documentation of the transferring systems (Decree 13/2023/ND-CP, Art. 25) | Scan |
| `VN-D13-23` Breach Notification Readiness | Violations of personal data protection regulations must be notified to the Ministry of Public Security (A05) within 72 hours; assessing scope and cause that quickly requires each deployed component to be individually identifiable (Decree 13/2023/ND-CP, Art. 23) | Scan |
| `VN-D13-PROC` Processor and Third-Party Responsibility | Personal data processors and third parties bear defined protection responsibilities to the controller, so the controller must know which suppliers stand behind the components of its processing stack (Decree 13/2023/ND-CP, controller/processor responsibility articles) | Scan |
| `VN-D13-VER` Version Knowledge for Incident Assessment | The 72-hour breach reporting duty and impact-assessment obligations jointly require knowing the exact versions of software in use to evaluate exposure to a given vulnerability (Decree 13/2023/ND-CP, Arts. 23-24) | Scan |
## More controls in the catalog
The framework's **Controls** tab lists its scan requirements and these controls from Safeguard's control catalog. Evidence them with automated tests, uploaded evidence, policies or an attestation.
| Control | Name |
| --------------- | -------------------------------------------------- |
| `VD13-ART2` | Definitions and Scope |
| `VD13-ART3` | Personal Data Protection Principles |
| `VD13-ART11` | Right to Know |
| `VD13-ART12` | Right to Consent |
| `VD13-ART13` | Right to Access and Correction |
| `VD13-ART14` | Right to Erasure and Restriction |
| `VD13-ART17-19` | Controller Obligations: Notice and Consent Capture |
| `VD13-ART20-22` | Processor Obligations and Sub-Processing |
| `VD13-ART23-24` | Cross-Border Transfer DPIA: Assessment |
| `VD13-ART25-26` | Cross-Border Transfer: Regulatory Approval |
| `VD13-ART38` | Sensitive Personal Data Handling |
## Policy templates
Written for VN D13:
* Cross-Border Personal Data Transfer Policy (Vietnam Decree 13)
* Sensitive Personal Data Handling Policy (Vietnam Decree 13 Article 38)
* Data Controller Obligations Policy (Vietnam Decree 13 Articles 17-22)
And 22 from the [standard set](/docs/frameworks#policy-templates), adapted to VN D13.
# AD FS (/docs/sso-authentication/saml/ad-fs)
# AD FS
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In AD FS — the Relying Party Trust (you enter these at the IdP):**
| Field | Example value |
| --------------------------------------------- | ---------------------------------------------------------------------------- |
| SAML 2.0 WebSSO URL (ACS URL) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/adfs/endpoint` |
| Relying party trust identifier (SP Entity ID) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | LDAP `E-Mail-Addresses`, sent via a second outgoing claim rule named `email` |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | ---------------------------------------- |
| Alias | `adfs` |
| Display Name | `Sign in with AD FS` |
| SSO Service URL | `https:///adfs/ls/` |
| Entity ID | `http:///adfs/services/trust` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. On the AD FS server, open **AD FS Management → Relying Party Trusts → Add Relying Party Trust → Claims aware**, and enter data manually.
2. Set the **Relying party trust identifier** to the **SP Entity ID** Safeguard shows after Save (this is the Entity ID).
3. Enable **SAML 2.0 WebSSO** and set its URL to the **ACS URL** Safeguard shows after Save.
4. Add an **Issuance Transform Rule** mapping `E-Mail-Addresses` to the **Name ID** outgoing claim, format **Email**.
5. Add a second **Issuance Transform Rule** mapping `E-Mail-Addresses` to an outgoing claim type named exactly `email` — AD FS's default claim types are full URIs, not this short name, and Safeguard needs the literal `email` attribute separate from the Name ID rule.
6. Export the token-signing certificate under **Service → Certificates**, and note the SAML 2.0/WS-Federation endpoint under **Endpoints** (or the federation metadata URL).
7. In Safeguard, click **Add Provider → SAML 2.0 → AD FS**, and enter the endpoint, Entity ID, and certificate.
8. Grant access under the relying party trust's **Access Control Policy**.
9. Click **Test** in Safeguard to confirm.
**Common errors:** an "MSIS7042: claims required by relying party trust were not present" error means the Issuance Transform Rule mapping E-Mail-Addresses → Name ID is missing, or the signed-in AD account has no email attribute set.
# Auth0 (/docs/sso-authentication/saml/auth0)
# Auth0
Auth0 can act as either an OIDC provider (see [OpenID Connect](/docs/sso-authentication/oidc)) or a SAML IdP via its SAML Web App addon.
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In Auth0 — the SAML app / SP details (you enter these at the IdP):**
| Field | Example value |
| ------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- |
| ACS URL (Auth0 calls this the Application Callback URL) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/auth0/endpoint` |
| SP Entity ID / Audience | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | the signed-in user's email (Auth0's user profile email, via the addon's `"mappings": {"email": "email"}` setting) |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | ------------------------------------------------- |
| Alias | `auth0` |
| Display Name | `Sign in with Auth0` |
| SSO Service URL | `https://.us.auth0.com/samlp/` |
| Entity ID | `urn:.us.auth0.com` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In the Auth0 dashboard, open (or create) a Regular Web Application, then enable the **SAML2 Web App** addon under its **Addons** tab.
2. In the addon settings, set **Application Callback URL** to the **ACS URL** Safeguard shows after Save.
3. Optionally set `audience` to the **SP Entity ID** Safeguard shows after Save — this sets an audience restriction on the assertion, separate from Auth0's own Issuer.
4. In the addon's **Settings (JSON)**, ensure `"mappings"` includes `"email": "email"` so an attribute literally named `email` is sent — separate from the Login URL/NameID Auth0 derives from the user profile.
5. On the addon's **Usage** tab, copy the **Identity Provider Login URL** and the **Issuer** (Auth0's own Entity ID, typically `urn:.us.auth0.com`), and download the **Identity Provider Certificate**.
6. In Safeguard, click **Add Provider → SAML 2.0 → Auth0**, and enter the Login URL, Issuer (Entity ID), and Certificate.
7. Ensure the connections you want (Database, Google, etc.) are enabled for this specific application.
8. Click **Test** in Safeguard to confirm.
**Common errors:** "wrong tenant" issues after saving usually mean the SAML addon was enabled on a different Application than the one you're editing — double-check the addon's **Usage** tab shows the app you configured.
# Authentik (/docs/sso-authentication/saml/authentik)
# Authentik
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In Authentik — the SAML app / SP details (you enter these at the IdP):**
| Field | Example value |
| ----------------------- | ------------------------------------------------------------------------------------------------ |
| ACS URL | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/authentik/endpoint` |
| SP Entity ID / Audience | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | the signed-in user's email (via a Property mapping that sends `email` as an assertion attribute) |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | -------------------------------------------------------------------------------------------------------- |
| Alias | `authentik` |
| Display Name | `Sign in with Authentik` |
| SSO Service URL | `https:///application/saml//sso/binding/redirect/` |
| Entity ID | `https:///application/saml//sso/binding/redirect/` (or your configured issuer) |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In Authentik, go to **Applications → Providers → Create → SAML Provider**.
2. Set **ACS URL** to the **ACS URL** Safeguard shows after Save, **Issuer** to the **SP Entity ID** Safeguard shows after Save, and **Service Provider Binding** to **Post**.
3. Under **Advanced protocol settings**, set **NameID Property Mapping** to `email`.
4. Under **Property mappings**, ensure a mapping sending `email` as an assertion attribute is selected — separate from the NameID Property Mapping above.
5. Save, then copy the **SSO URL (Post)** and download the **Signing Certificate** from the provider detail page.
6. In Safeguard, click **Add Provider → SAML 2.0 → Authentik**, and enter the SSO URL, Issuer (Entity ID), and Certificate.
7. Create an **Application** that uses this provider, and assign it to the group(s) allowed to sign in.
8. Click **Test** in Safeguard to confirm.
**Common errors:** an assertion that's signed but rejected by Safeguard usually means Service Provider Binding is set to "Redirect" instead of "Post" — Safeguard's ACS only accepts HTTP-POST bindings.
# CyberArk Identity (/docs/sso-authentication/saml/cyberark)
# CyberArk Identity
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In CyberArk Identity — the SAML app / Trust details (you enter these at the IdP):**
| Field | Example value |
| ------------------------------ | ------------------------------------------------------------------------------ |
| Assertion Consumer Service URL | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/cyberark/endpoint` |
| SP Entity ID | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| NameID Format | `Email Address` |
| `email` attribute | attribute mapped to LoginUser.email |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | -------------------------------------------------- |
| Alias | `cyberark` |
| Display Name | `Sign in with CyberArk Identity` |
| SSO Service URL | `https://.id.cyberark.cloud/saml2/idp/sso` |
| Entity ID | `https://.id.cyberark.cloud/` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In the CyberArk Identity Admin Portal, go to **Apps & Widgets → Web Apps → Add Web Apps → Custom → SAML**.
2. Under **Trust**, set **SP Entity ID** to the **SP Entity ID** Safeguard shows after Save, and **Assertion Consumer Service URL** to the **ACS URL** Safeguard shows after Save.
3. Set **NameID Format** to **Email Address**, with the NameID value resolving to the user's email.
4. Under **SAML Response → Attributes**, add an attribute named `email` resolving to the user's email — separate from the NameID Format/value setting above.
5. Copy the **IdP Issuer URL** and **SSO endpoint**, and download the **IdP Certificate**, from the app's **Trust** tab.
6. In Safeguard, click **Add Provider → SAML 2.0 → CyberArk Identity**, and enter those three values.
7. Assign the application to the appropriate **Roles** under the app's **Permissions** tab.
8. Click **Test** in Safeguard to confirm.
**Common errors:** sign-in looping back to CyberArk usually means the NameID value variable is misconfigured (it must resolve to an actual email, not a bare username).
# Duo Security (/docs/sso-authentication/saml/duo)
# Duo Security
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In Duo Security — the SAML app / SP details (you enter these at the IdP):**
| Field | Example value |
| ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| ACS URL (Duo calls this the Assertion Consumer Service (ACS) URL) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/duo/endpoint` |
| SP Entity ID / Audience | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | the signed-in user's email (Duo's Email address field, sent as a SAML Response attribute named `email`) |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | -------------------------------------------------------------------------- |
| Alias | `duo` |
| Display Name | `Sign in with Duo Security` |
| SSO Service URL | `https://sso-.sso.duosecurity.com/saml2/sp//sso` |
| Entity ID | `https://sso-.sso.duosecurity.com/saml2/sp//metadata` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In the Duo Admin Panel, go to **Applications → Protect an Application**, and protect **Generic SAML Service Provider** (via Duo Single Sign-On).
2. Under **SAML Response**, set **Entity ID** to the **SP Entity ID** Safeguard shows after Save, and **Assertion Consumer Service (ACS) URL** to the **ACS URL** Safeguard shows after Save.
3. Set **NameID format** to **Email Address** and **NameID value** to **Email address**.
4. Under **SAML Response → Attributes**, add an attribute named `email` mapped to Email address — separate from the NameID setting above.
5. Copy the **Single Sign-On URL**, **Entity ID**, and **Certificate** from the **Metadata** section.
6. In Safeguard, click **Add Provider → SAML 2.0 → Duo Security**, and enter those three values.
7. Confirm an **Authentication Source** (your upstream directory — AD, Azure, Google, etc.) is linked to this Duo SSO application.
8. Click **Test** in Safeguard to confirm.
**Common errors:** an "AuthSource error" at Duo means the Duo SSO Authentication Source isn't linked to this application yet — link it under the application's settings before testing.
# Microsoft Entra ID (/docs/sso-authentication/saml/entra-id)
# Microsoft Entra ID
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In Microsoft Entra ID — the SAML app / SP details (you enter these at the IdP):**
| Field | Example value |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------- |
| ACS URL (Reply URL / Assertion Consumer Service URL) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/entra/endpoint` |
| SP Entity ID / Audience | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | the signed-in user's email (`user.mail`, not the default `user.userprincipalname`) |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | ------------------------------------------------------- |
| Alias | `entra` |
| Display Name | `Sign in with Microsoft Entra ID` |
| SSO Service URL | `https://login.microsoftonline.com//saml2` |
| Entity ID | `https://sts.windows.net//` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In the **Microsoft Entra admin center**, go to **Enterprise applications → New application → Create your own application**, choose "Integrate any other application you don't find in the gallery," and create it.
2. Open the app, go to **Single sign-on → SAML**.
3. Edit **Basic SAML Configuration**:
* **Identifier (Entity ID)**: the **SP Entity ID** Safeguard shows after Save
* **Reply URL (ACS URL)**: the **ACS URL** Safeguard shows after Save
4. Set the **Unique User Identifier (Name ID)** to `user.mail` — Entra's out-of-box default is `user.userprincipalname`, which isn't always the same as the user's email address.
5. Under **Attributes & Claims**, also add or rename a claim so its Name is exactly `email`, mapped to `user.mail` (required) — Entra's default claim set uses full claim-type URIs, not this short name, and Safeguard needs the literal `email` attribute separate from the Name ID above.
6. Under **SAML Certificates**, copy the **Login URL**, **Microsoft Entra Identifier** (Entity ID), and download the **Certificate (Base64)**, or copy the **App Federation Metadata URL** if you'd rather import metadata directly.
7. In Safeguard, click **Add Provider → SAML 2.0 → Microsoft Entra ID**, and enter the Login URL, Entra Identifier, and certificate contents from step 6.
8. Back in Entra, go to **Users and groups** and assign the users/groups who should have access.
9. Click **Test** in Safeguard to confirm.
**Common errors:** an `AADSTS50105` "user not assigned to a role" error means you skipped assigning users/groups in step 8. An `AADSTS75011` reply URL mismatch means the Reply URL doesn't exactly match the Callback URL (check for a trailing slash). If you pasted individual values instead of importing the metadata URL, Entra's signing certificate rotates periodically — re-sync it in Safeguard when Entra warns about upcoming rotation.
# Google Workspace (/docs/sso-authentication/saml/google-workspace)
# Google Workspace
Use this when you want Google Workspace itself to be the SAML identity provider (distinct from the "Sign in with Google" OAuth button — see [Social login](/docs/sso-authentication/social) for that).
## Example values
The tenant-specific values below (the `sg_ab12cde` parts) are examples that show the *shape* of each value — Safeguard displays your real ones in the **Add Provider** dialog after you click **Save**. The point of this table is to make it unambiguous which value goes on which side.
**In Google — Service provider details:**
| Field | Example value |
| -------------- | -------------------------------------------------------------------------------------- |
| ACS URL | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/google-workspace/endpoint` |
| Entity ID | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EMAIL` |
| Name ID | `Basic Information → Primary email` |
**In Google — Attribute mapping:**
| Google directory attribute | App attribute |
| ----------------------------------- | ------------- |
| `Basic Information → Primary email` | `email` |
| `Basic Information → First name` | `firstName` |
| `Basic Information → Last name` | `lastName` |
**In Safeguard — Add Provider → SAML 2.0:**
| Field | Example value |
| ----------------- | --------------------------------------------------------- |
| Alias | `google-workspace` |
| Display Name | `Sign in with Google Workspace` |
| SSO Service URL | `https://accounts.google.com/o/saml2/idp?idpid=C0abc1def` |
| Entity ID | `https://accounts.google.com/o/saml2?idpid=C0abc1def` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
> **Two different "Entity ID" values — don't mix them up.** SAML involves two separate fields, both usually labelled "Entity ID", and they must hold *different* values:
>
> * The **IdP Entity ID** identifies the identity provider (Google): `https://accounts.google.com/o/saml2?idpid=C0abc1def`. This goes **into Safeguard** — it's the **Entity ID** field of the Add-Provider form.
> * The **SP Entity ID** identifies Safeguard as the service provider: `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde`. This goes **into Google** — Google's **Entity ID** field on the *Service provider details* screen, alongside the ACS URL.
>
> Putting Google's own entity ID into Google's Entity ID field (echoing Google's value back to Google) makes Google reject the request. They must be the two distinct values above.
> **Both sign-in directions work.** Start at `https://app.safeguard.sh` and click the Google Workspace button (SP-initiated), **or** launch from Google's app-launcher tile or Google Admin's **Test SAML login** button (IdP-initiated) — both log you straight into Safeguard. Because you're already signed in to Google, the IdP-initiated route completes with no second prompt: Safeguard detects the unsolicited SAML response and transparently restarts it as an SP-initiated login.
1. In **Google Admin Console**, go to **Apps → Web and mobile apps → Add app → Add custom SAML app**.
2. Name the app (e.g. "Safeguard") and click **Continue**.
3. On the **Google IdP information** screen, note the **SSO URL**, **Entity ID**, and download the **Certificate**. Click **Continue**.
4. On **Service provider details**, enter:
* **ACS URL**: the **ACS URL** Safeguard shows in the dialog after Save, copy-pasted exactly — `https://api.safeguard.sh/auth/idp/realms//broker/google-workspace/endpoint`. Typing this by hand is a common source of errors (wrong domain, missing path segment); if login fails outright with no error reaching Safeguard at all, re-check this field character-by-character against what Safeguard's dialog shows.
* **Entity ID**: the **SP Entity ID** Safeguard shows after Save — `https://api.safeguard.sh/auth/idp/realms/`
* **Name ID format**: `EMAIL`
* **Name ID**: `Basic Information → Primary email`
5. On **Attribute mapping**, Google's form has two columns: **Google directory attributes** (pick from a dropdown) on the left, **App attributes** (you type the name) on the right. Add these rows:
| Google directory attributes | App attributes |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Basic Information → Primary email | `email` (required — do this even though you already set the Name ID to the same field in step 4; Safeguard reads email from this named attribute, not from the Name ID) |
| Basic Information → First name | `firstName` (optional — only if you want it synced) |
| Basic Information → Last name | `lastName` (optional — only if you want it synced) |
**Do not leave a half-filled row** (a Google directory attribute selected with no App attribute name typed, or vice versa) — Google's admin console will reject the whole form with a generic `400 internal_error` referencing `schemaKey` if you do. Delete any empty/incomplete row before saving.
6. Click **Finish**.
7. Back in Safeguard, click **Add Provider → SAML 2.0 → Google Workspace**, and enter the SSO URL, Entity ID, and Certificate from step 3, plus an alias/display name. Save.
8. In Google Admin Console, turn the app **ON for everyone** (or the specific org units you want), under **User access**.
9. Confirm by signing in. Either start **from Safeguard** — go to `https://app.safeguard.sh`, enter your email, and click the Google Workspace SSO button — or use Google Admin's **Test SAML login** button (or the Gmail app-launcher tile). All three log you directly into Safeguard.
**What "User access: ON for everyone" actually controls:** this only decides which Google Workspace users are *allowed to attempt* SAML sign-in through this app — it does not by itself grant them access into Safeguard. A user still needs a Safeguard account: either they already exist in the tenant (they'll be signed into their existing account), or your tenant's [provisioning policy](/docs/sso-authentication/provisioning-policy) allows just-in-time creation on first login. If you restrict this to specific org units, only users in those org units can even reach the SAML redirect; everyone else sees a Google-side "you don't have access to this app" message before Safeguard is ever involved.
**Common errors:** Google Admin shows `400. Error: internal_error` mentioning `schemaKey` on the Attribute mapping step — see step 5 above (delete any half-filled attribute-mapping row). Users don't see the option to sign in via Google Workspace even after saving the provider in Safeguard — the app hasn't been turned **ON** for their org unit yet under **User access** (step 8). Login fails immediately with no request ever reaching Safeguard (blank page, browser can't resolve/connect, or an unrelated 404) — the ACS URL in step 4 has a typo; re-copy it exactly from Safeguard's dialog rather than retyping it.
# IBM Security Verify (/docs/sso-authentication/saml/ibm-security-verify)
# IBM Security Verify
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In IBM Security Verify — the custom SAML application (you enter these at the IdP):**
| Field | Example value |
| ------------------------------ | -------------------------------------------------------------------------------- |
| Assertion consumer service URL | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/ibm-verify/endpoint` |
| Entity ID (SP Entity ID) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `Email` |
| `email` attribute | mapped from the user's work email attribute |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | ----------------------------------------------------------------- |
| Alias | `ibm-verify` |
| Display Name | `Sign in with IBM Security Verify` |
| SSO Service URL | `https://.verify.ibm.com/saml/sps/saml20idp/saml20/login` |
| Entity ID | `https://.verify.ibm.com/saml/sps/saml20idp/saml20` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In the IBM Security Verify admin console, go to **Applications → Add application → Custom Application → SAML 2.0**.
2. Under **Sign-on**, set **Assertion consumer service URL** to the **ACS URL** Safeguard shows after Save and **Entity ID** to the **SP Entity ID** Safeguard shows after Save.
3. Set **Name ID format** to **Email**, mapped from the user's email attribute.
4. Under **Attribute mapping**, add an attribute named `email` mapped from the user's email attribute — separate from the Name ID format setting above.
5. Copy the **SSO URL** and **Issuer**, and download the signing certificate, from the app's **Sign-on** tab.
6. In Safeguard, click **Add Provider → SAML 2.0 → IBM Security Verify**, and enter those three values.
7. Assign the application to the entitled users/groups under the app's **Access** tab.
8. Click **Test** in Safeguard to confirm.
**Common errors:** a "SAML response validation failed" error at Safeguard usually means the Entity ID entered in Safeguard doesn't exactly match the Issuer IBM Security Verify sends (this comparison is case-sensitive).
# SAML 2.0 (/docs/sso-authentication/saml)
# SAML 2.0
Use this when your IdP is not Google, Microsoft, or GitHub, or when you specifically want a SAML (rather than OAuth) integration with one of those.
> **Every IdP below needs an explicit `email` attribute, not just the Name ID.** Safeguard reads the signed-in user's email from a SAML attribute literally named `email` in the assertion's Attribute Statement — this is a different thing from the Name ID you also configure. Setting the Name ID format to Email is necessary but on its own may not be sufficient. Whatever your IdP calls this section ("Attribute Statements," "Attribute Mapping," "Attributes & Claims"), add or rename an entry so its attribute name is exactly `email`, mapped to the user's email address. Skipping this is the most common reason a SAML login looks fully configured on both sides but still fails.
> **Two different "Entity ID" values — don't mix them up.** SAML involves two separate fields, both usually labelled "Entity ID", and they must hold *different* values:
>
> * The **IdP Entity ID** identifies the identity provider (e.g. Google): `https://accounts.google.com/o/saml2?idpid=C0abc1def`. This goes **into Safeguard** — it's the **Entity ID** field of the Add-Provider form.
> * The **SP Entity ID** identifies Safeguard as the service provider: `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde`. This goes **into the IdP** — the IdP's **Entity ID** / **Audience** field, alongside the ACS URL.
>
> Putting the IdP's own entity ID into the IdP's Entity ID field (echoing the IdP's value back to itself) makes the IdP reject the request. They must be the two distinct values above.
> **Both sign-in directions work.** The usual path is SP-initiated: start at `https://app.safeguard.sh`, enter your email, and pick the SSO button. IdP-initiated login also works — launching from the IdP's app launcher/dashboard or a "Test SAML login" button signs you straight into Safeguard. Safeguard detects the unsolicited SAML response landing on the broker endpoint and transparently restarts it as an SP-initiated login; since you're already authenticated at the IdP, it completes with no second prompt. (This requires the provider to be configured and enabled in Safeguard first.)
## Generic steps (any SAML IdP)
1. In your IdP, create a new SAML application/integration.
2. Set the IdP's **ACS URL** (sometimes called *Reply URL* or *Single Sign-On URL*) to the **ACS URL** Safeguard shows in the dialog after Save (the `.../auth/idp/realms/.../broker//endpoint` value).
3. Set the IdP's **Entity ID / Audience (SP Entity ID)** to the **SP Entity ID** Safeguard shows (the `.../auth/idp/realms/` value). You'll enter the *IdP's* entity ID (not this one) into Safeguard in a later step.
4. Set **Name ID format** to `Email` / `EmailAddress`, and map the Name ID to the user's email attribute.
5. **Also add an explicit attribute statement/mapping** (separate from the Name ID) with the attribute name `email`, mapped to the user's email address. Safeguard reads email from this named attribute, not from the Name ID directly — most IdPs let you add this in an "Attribute Statements" or "Attribute Mapping" section of the same app config. Skipping this is the most common reason a SAML login otherwise appears fully configured but fails with a claim/email error.
6. From the IdP, collect three values: the **SSO/Login URL**, the **Entity ID / Issuer**, and the **X.509 signing certificate** (PEM format).
7. In Safeguard, click **Add Provider → SAML 2.0** and fill in:
| Field | Value |
| --------------------- | ----------------------------------------------------------------------------------------------------- |
| **Alias** | A short, URL-safe id, e.g. `okta`, `entra`, `acme-sso` (lowercase letters, numbers, hyphens only) |
| **Display Name** | What users see on the login screen, e.g. "Sign in with Okta" |
| **SSO Service URL** | The IdP's SSO/Login URL from step 6 |
| **Entity ID** | The IdP's Entity ID / Issuer from step 6 |
| **X.509 Certificate** | Paste the full PEM certificate, including `-----BEGIN CERTIFICATE-----` / `-----END CERTIFICATE-----` |
8. Click **Save**. Copy the **ACS URL**, **SP Entity ID**, and Metadata URL shown, and paste the ACS URL and SP Entity ID back into your IdP's app configuration if you hadn't already (some IdPs let you finish setup before these values exist — that's fine, just go back and update them now).
9. Assign users/groups to the app in your IdP.
10. Back in Safeguard, click **Test** next to the new provider.
### Example values (any SAML IdP)
Illustrative values for an Okta integration. The tenant-specific `sg_ab12cde` values show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**.
**In Safeguard — Add Provider → SAML 2.0:**
| Field | Example value |
| ----------------- | --------------------------------------------- |
| Alias | `okta` |
| Display Name | `Sign in with Okta` |
| SSO Service URL | `https://example.okta.com/app/xxxxx/sso/saml` |
| Entity ID | `http://www.okta.com/exkxxxxxxx` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
**In your IdP — the values you paste back from Safeguard:**
| Field | Example value |
| ---------------------------------------- | -------------------------------------------------------------------------- |
| ACS URL (Reply URL / Single Sign-On URL) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/okta/endpoint` |
| SP Entity ID (Audience) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
The `broker/` segment of the ACS URL matches the **Alias** you chose above (here, `okta`).
## In this section
* [Okta](/docs/sso-authentication/saml/okta)
* [Microsoft Entra ID](/docs/sso-authentication/saml/entra-id)
* [Google Workspace](/docs/sso-authentication/saml/google-workspace)
* [OneLogin](/docs/sso-authentication/saml/onelogin)
* [Ping Identity](/docs/sso-authentication/saml/ping-identity)
* [Duo Security](/docs/sso-authentication/saml/duo)
* [JumpCloud](/docs/sso-authentication/saml/jumpcloud)
* [Auth0](/docs/sso-authentication/saml/auth0)
* [Keycloak](/docs/sso-authentication/saml/keycloak)
* [Authentik](/docs/sso-authentication/saml/authentik)
* [AD FS](/docs/sso-authentication/saml/ad-fs)
* [Shibboleth](/docs/sso-authentication/saml/shibboleth)
* [SailPoint IdentityNow](/docs/sso-authentication/saml/sailpoint)
* [CyberArk Identity](/docs/sso-authentication/saml/cyberark)
* [IBM Security Verify](/docs/sso-authentication/saml/ibm-security-verify)
# JumpCloud (/docs/sso-authentication/saml/jumpcloud)
# JumpCloud
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In JumpCloud — the SAML app / SP details (you enter these at the IdP):**
| Field | Example value |
| ----------------------- | ---------------------------------------------------------------------------------------------------- |
| ACS URL | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/jumpcloud/endpoint` |
| SP Entity ID / Audience | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | the signed-in user's email (JumpCloud's user email, sent as a constant SAML attribute named `email`) |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | ------------------------------------------ |
| Alias | `jumpcloud` |
| Display Name | `Sign in with JumpCloud` |
| SSO Service URL | `https://sso.jumpcloud.com/saml2/` |
| Entity ID | `https://sso.jumpcloud.com/` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In the JumpCloud Admin Console, go to **SSO Applications → + Add New Application → Custom SAML App**.
2. Set **SP Entity ID** to the **SP Entity ID** Safeguard shows after Save, and **ACS URL** to the **ACS URL** Safeguard shows after Save.
3. Set the **SAML Subject NameID** to `email` with format **EmailAddress**.
4. Under **SAML Attributes**, also add a constant attribute named `email` mapped to the user's email — separate from the Subject NameID above.
5. Save, then reopen the app and copy the **IdP URL** and **IdP Entity ID**, and download the **Certificate** from the **Export Metadata** tab.
6. In Safeguard, click **Add Provider → SAML 2.0 → JumpCloud**, and enter those three values.
7. Assign **User Groups** to the application under the app's **User Groups** tab.
8. Click **Test** in Safeguard to confirm.
**Common errors:** users see "Access Denied" at JumpCloud — they exist in JumpCloud but haven't been added to a User Group bound to this SSO app.
# Keycloak (/docs/sso-authentication/saml/keycloak)
# Keycloak
Use this to connect your own, separately-hosted Keycloak instance as an external IdP — distinct from the internal Keycloak Safeguard's auth service uses as its broker.
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In Keycloak — the SAML app / SP details (you enter these at the IdP):**
| Field | Example value |
| ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| ACS URL (Keycloak calls this the Assertion Consumer Service POST Binding URL) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/keycloak/endpoint` |
| SP Entity ID / Audience | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | the signed-in user's email (via a SAML Attribute mapper named `email` on the client) |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | ------------------------------------------------------ |
| Alias | `keycloak` |
| Display Name | `Sign in with Keycloak` |
| SSO Service URL | `https:///realms//protocol/saml` |
| Entity ID | `https:///realms/` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In your organization's Keycloak admin console, select your realm, then go to **Clients → Create client → SAML**.
2. Set **Client ID** to the **SP Entity ID** Safeguard shows after Save (this is the SP Entity ID), and set the **Assertion Consumer Service POST Binding URL** to the **ACS URL** Safeguard shows after Save.
3. Under **Realm Settings → General**, copy the realm's SAML 2.0 endpoint and issuer, and export the realm's signing certificate.
4. Set **Name ID format** to **Email** under the client's **Advanced** settings.
5. Add a SAML **Attribute mapper** on the client with SAML attribute name `email` mapped to the user's email attribute — separate from the Name ID mapper above.
6. In Safeguard, click **Add Provider → SAML 2.0 → Keycloak**, and enter the endpoint, issuer (Entity ID), and certificate.
7. Assign the client's role/group mappers to the users who should have access.
8. Click **Test** in Safeguard to confirm.
**Common errors:** an "invalid\_redirect\_uri" error from Keycloak means the Callback URL wasn't added to the client's **Valid Redirect URIs** exactly as shown.
# Okta (/docs/sso-authentication/saml/okta)
# Okta
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In Okta — the SAML app / SP details (you enter these at the IdP):**
| Field | Example value |
| ---------------------------- | -------------------------------------------------------------------------- |
| ACS URL (Single sign on URL) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/okta/endpoint` |
| SP Entity ID / Audience | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | the signed-in user's email (`user.email`) |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | --------------------------------------------------- |
| Alias | `okta` |
| Display Name | `Sign in with Okta` |
| SSO Service URL | `https://.okta.com/app//sso/saml` |
| Entity ID | `http://www.okta.com/` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In the Okta admin console, go to **Applications → Create App Integration → SAML 2.0**.
2. Name the app and continue to **Configure SAML**:
* **Single sign on URL**: the **ACS URL** Safeguard shows after Save
* **Audience URI (SP Entity ID)**: the **SP Entity ID** Safeguard shows after Save
* **Name ID format**: `EmailAddress`
* **Application username**: `Email`
3. Under **Attribute Statements** (Okta labels this section "optional," but this row is required for Safeguard), add: Name `email`, Name format `Unspecified`, Value `user.email`. Okta's "Application username" setting above controls the Name ID, not this — Safeguard needs both.
4. Click **Next**, then **Finish**.
5. On the app's **Sign On** tab, click **View SAML setup instructions** (or download the **Identity Provider metadata**) to get the **Identity Provider Single Sign-On URL**, **Identity Provider Issuer**, and **X.509 Certificate**.
6. In Safeguard, click **Add Provider → SAML 2.0 → Okta**, and enter those three values.
7. Back in Okta, go to the **Assignments** tab and assign people or groups.
8. Click **Test** in Safeguard to confirm.
**Common errors:** users can authenticate at Okta but never appear correctly in Safeguard — check that **Application username** is set to **Email**, not a bare username. Sign-in works for you but not teammates — they haven't been added under the app's **Assignments** tab yet.
# OneLogin (/docs/sso-authentication/saml/onelogin)
# OneLogin
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In OneLogin — the SAML app / SP details (you enter these at the IdP):**
| Field | Example value |
| ---------------------------- | ------------------------------------------------------------------------------ |
| ACS URL (ACS (Consumer) URL) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/onelogin/endpoint` |
| SP Entity ID / Audience | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | the signed-in user's email (mapped from the `Email` field) |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | ----------------------------------------------------------------- |
| Alias | `onelogin` |
| Display Name | `Sign in with OneLogin` |
| SSO Service URL | `https://.onelogin.com/trust/saml2/http-post/sso/` |
| Entity ID | `https://app.onelogin.com/saml/metadata/` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In OneLogin, go to **Applications → Add App**, search for "SAML Custom Connector," and add it.
2. Under **Configuration**, set:
* **ACS (Consumer) URL**: the **ACS URL** Safeguard shows after Save
* **Audience**: the **SP Entity ID** Safeguard shows after Save
3. Under **Parameters**, add a custom parameter named `email` mapped to the Email field — separate from the NameID policy OneLogin applies by default.
4. Under **SSO**, copy the **SAML 2.0 Endpoint (HTTP)**, **Issuer URL**, and the **X.509 Certificate**.
5. In Safeguard, click **Add Provider → SAML 2.0 → OneLogin**, and enter those three values.
6. In OneLogin, assign users under the app's **Users** tab.
7. Click **Test** in Safeguard to confirm.
**Common errors:** an "Invalid Login" error at OneLogin usually means the Audience field doesn't match what Safeguard expects, or the app isn't assigned to the signed-in user under **Users**.
# Ping Identity (/docs/sso-authentication/saml/ping-identity)
# Ping Identity
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In Ping Identity — the SAML app / SP details (you enter these at the IdP):**
| Field | Example value |
| ----------------------- | -------------------------------------------------------------------------- |
| ACS URL (ACS URLs) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/ping/endpoint` |
| SP Entity ID / Audience | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | the signed-in user's email (mapped from the `Email Address` attribute) |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | -------------------------------------------------- |
| Alias | `ping` |
| Display Name | `Sign in with Ping Identity` |
| SSO Service URL | `https://auth.pingone.com//saml20/idp/sso` |
| Entity ID | `https://auth.pingone.com/` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In PingOne, go to **Connections → Applications → +**, and choose **SAML**.
2. Set **ACS URL** to the **ACS URL** Safeguard shows after Save and **SP Entity ID** to the **SP Entity ID** Safeguard shows after Save.
3. Set the **Subject NameID** format to **Email Address**, mapped to the user's Email Address attribute.
4. Under **Attribute Mappings**, add an outgoing attribute named `email` sourced from the user's Email Address — separate from the Subject NameID mapping above.
5. On the **Configuration** tab, download the **Signing Certificate** and copy the **Issuer ID** and **SSO endpoint URL**.
6. In Safeguard, click **Add Provider → SAML 2.0 → Ping Identity**, and enter those three values.
7. Assign the groups/users who should have access under the app's **Access** tab, then enable the connection.
8. Click **Test** in Safeguard to confirm.
**Common errors:** sign-on succeeds at PingOne but the user is rejected at Safeguard — check that the Subject NameID mapping is set to **Email Address**, not Username, in the SAML assertion configuration.
# SailPoint IdentityNow (/docs/sso-authentication/saml/sailpoint)
# SailPoint IdentityNow
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In SailPoint IdentityNow — the SAML app / SP details (you enter these at the IdP):**
| Field | Example value |
| ------------------------------------ | ------------------------------------------------------------------------------- |
| ACS URL | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/sailpoint/endpoint` |
| Audience / SP Entity ID | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Application username / NameID format | `Email` |
| `email` attribute | outgoing attribute mapped from the identity's email |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | ---------------------------------------------------- |
| Alias | `sailpoint` |
| Display Name | `Sign in with SailPoint IdentityNow` |
| SSO Service URL | `https://.identitynow.com/saml/sso/` |
| Entity ID | `https://.identitynow.com` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. In SailPoint IdentityNow, go to **Admin → Connections → Applications → Add Web App → "Connect a SAML app you've already set up."**
2. Under **Sign-On**, set **ACS URL** to the **ACS URL** Safeguard shows after Save and **Audience/SP Entity ID** to the **SP Entity ID** Safeguard shows after Save.
3. Set **Application username / NameID format** to **Email**.
4. Under **Attribute Mapping**, add an outgoing attribute named `email` sourced from the identity's email — separate from the Application username/NameID setting above.
5. Copy the **IdP SSO URL**, **Issuer**, and download the certificate from the app's **Sign-On** tab.
6. In Safeguard, click **Add Provider → SAML 2.0 → SailPoint IdentityNow**, and enter those three values.
7. Provision the application to the identities/roles that need access.
8. Click **Test** in Safeguard to confirm.
**Common errors:** "Access Denied" at IdentityNow means the app was created but never provisioned to the identity/role attempting to sign in.
# Shibboleth (/docs/sso-authentication/saml/shibboleth)
# Shibboleth
## Example values
The tenant-specific values (the `sg_ab12cde` parts) show the *shape* only — Safeguard displays your real ACS URL and SP Entity ID in the **Add Provider** dialog after you click **Save**. This table makes it unambiguous which value goes on which side.
**In Shibboleth — the relying party / attribute-filter config (you enter these at the IdP):**
| Field | Example value |
| ------------------------------------------------------------------ | -------------------------------------------------------------------------------- |
| ACS URL (Safeguard's SP endpoint, registered as the relying party) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde/broker/shibboleth/endpoint` |
| SP Entity ID (relying party ID) | `https://api.safeguard.sh/auth/idp/realms/sg_ab12cde` |
| Name ID format | `EmailAddress` |
| `email` attribute | released `mail` attribute, aliased to `email` |
**In Safeguard — Add Provider → SAML 2.0 (you copy these from the IdP):**
| Field | Example value |
| ----------------- | ----------------------------------------------- |
| Alias | `shibboleth` |
| Display Name | `Sign in with Shibboleth` |
| SSO Service URL | `https:///idp/profile/SAML2/POST/SSO` |
| Entity ID | `https:///idp/shibboleth` |
| X.509 Certificate | the PEM block below |
```
-----BEGIN CERTIFICATE-----
MIIDdDCCAlygAwIBAgIGAX...(full cert from your IdP)...P3B/k0SolrFYPo
-----END CERTIFICATE-----
```
1. Add a relying party entry for Safeguard's SP metadata on your Shibboleth Identity Provider (`metadata-providers.xml`, or publish Safeguard's Metadata URL where your IdP can fetch it).
2. Configure an attribute-filter policy releasing the `mail` attribute to Safeguard's entity ID as the NameID.
3. Ensure the released attribute's SAML attribute name (or an attribute-resolver alias for it) is exactly `email` — separate from the NameID transform above; Safeguard reads this named attribute.
4. Note your IdP's SSO endpoint (typically `/idp/profile/SAML2/POST/SSO`) and Entity ID (typically `/idp/shibboleth`), and export the IdP signing certificate.
5. In Safeguard, click **Add Provider → SAML 2.0 → Shibboleth**, and enter the SSO endpoint, Entity ID, and certificate.
6. Reload the Shibboleth IdP service so the new relying party takes effect.
7. Click **Test** in Safeguard to confirm.
**Common errors:** an assertion that arrives with no email attribute means the attribute-filter policy isn't releasing `mail` to Safeguard's entity ID — check `attribute-filter.xml`.
# GitHub (/docs/sso-authentication/social/github)
# GitHub
1. In GitHub, go to **Settings → Developer settings → OAuth Apps → New OAuth App** (for a GitHub organization, use the organization's own Developer settings instead).
2. Set **Authorization callback URL** to the Callback URL.
3. Click **Register application**, then **Generate a new client secret**.
4. In Safeguard, click **Add Provider → GitHub**, paste in the **Client ID** and generated **Client Secret**, and **Save**.
## Example values
Dummy values illustrating the shape — use the real ones from your GitHub OAuth App.
| Field | Example value |
| ----------------------------------------------- | --------------------------------------------------- |
| Authorization callback URL (register in GitHub) | `https://api.safeguard.sh/auth/api/v1/sso/callback` |
| Client ID (paste into Safeguard) | `Iv1.abcdef1234567890` |
| Client Secret (paste into Safeguard) | `ghs_xxxxxxxxxxxx` |
# Google (/docs/sso-authentication/social/google)
# Google
1. In **Google Cloud Console**, go to **APIs & Services → Credentials → Create Credentials → OAuth client ID**.
2. Application type: **Web application**.
3. Under **Authorized redirect URIs**, add the Callback URL (`https://api.safeguard.sh/auth/api/v1/sso/callback`).
4. Create the client and copy the **Client ID** and **Client Secret**.
5. In Safeguard, click **Add Provider → Google**, paste in the Client ID and Client Secret, and **Save**.
## Example values
Dummy values illustrating the shape — use the real ones from Google Cloud Console.
| Field | Example value |
| -------------------------------------------- | --------------------------------------------------- |
| Authorized redirect URI (register in Google) | `https://api.safeguard.sh/auth/api/v1/sso/callback` |
| Client ID (paste into Safeguard) | `1234567890-abcdefg.apps.googleusercontent.com` |
| Client Secret (paste into Safeguard) | `GOCSPX-xxxxxxxxxxxx` |
# Social Login (/docs/sso-authentication/social)
# Social Login
These use each provider's own OAuth flow (a "Sign in with Google/Microsoft/GitHub" button) rather than SAML. They're simpler to set up but give you less control over attribute mapping than SAML.
> Google and Microsoft can each be connected **either** as a social OAuth login (this section) **or** as a full [SAML IdP](/docs/sso-authentication/saml) — pick one per provider based on whether you need SAML-specific features like Entra/Workspace group-based attribute mapping.
## In this section
* [Google](/docs/sso-authentication/social/google)
* [Microsoft](/docs/sso-authentication/social/microsoft)
* [GitHub](/docs/sso-authentication/social/github)
# Microsoft (/docs/sso-authentication/social/microsoft)
# Microsoft
1. In the **Microsoft Entra admin center**, go to **App registrations → New registration**.
2. Set **Redirect URI** (type **Web**) to the Callback URL.
3. Under **Certificates & secrets**, create a new **client secret** and copy its value immediately (it's only shown once).
4. Copy the **Application (client) ID**.
5. In Safeguard, click **Add Provider → Microsoft**, and enter:
* **Client ID**
* **Client Secret**
* **Azure Tenant** (optional) — use `common` to allow any Microsoft account, `organizations` for any work/school account, or a specific tenant ID/domain to restrict sign-in to one organization.
6. Click **Save**.
## Example values
Dummy values illustrating the shape — use the real ones from the Microsoft Entra admin center.
| Field | Example value |
| --------------------------------------------------------------------- | --------------------------------------------------- |
| Redirect URI (register in Entra) | `https://api.safeguard.sh/auth/api/v1/sso/callback` |
| Application (client) ID (paste into Safeguard) | `11111111-2222-3333-4444-555555555555` |
| Client Secret — the secret *value*, not its ID (paste into Safeguard) | `Abc8Q~dummy.secret.value.xxxxxxxxxxxxxxxxx` |
| Azure Tenant (optional) | `common` |
# Accurate (/docs/compliance-connectors/setup/background-check-providers/accurate)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Accurate connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Accurate:
1. Sign in to the Accurate developer portal at **developer.accuratebackground.com** (a free developer account gives sandbox access; production access follows Accurate's online contracting process).
Accurate keeps the full instructions behind sign-in; this is what its public pages say.
Accurate's public announcement confirms the developer portal and free sandbox developer account, but the credential-creation steps, labels and base URLs are not visible without signing in to the portal (the docs pages returned errors). No read-only role is documented.
Source: [accurate.com](https://www.accurate.com/about-us/news/accurate-backgrounds-new-version-of-their-background-check-api-delivers-superior-developer-experience/), [developer.accuratebackground.com](https://developer.accuratebackground.com/), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Accurate**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Accurate yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Certn (/docs/compliance-connectors/setup/background-check-providers/certn)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Certn connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Certn:
1. Sign in to the Certn Client Portal and open the **Integrations** area.
2. Create a new API key there and copy it.
Where to find the other values:
* **Base URL (optional)**: Certn's API reference gives the sandbox base URL as **[https://api.sandbox.certn.co/api/public/](https://api.sandbox.certn.co/api/public/)**; use your production API host for live accounts.
Certn's public documentation does not cover every step.
Certn's API docs say keys are created and managed in the Integrations area of the Client Portal but do not give button labels. API keys expire after 1 year (365 days); admins get expiry notices 30, 14, 7 and 1 day(s) before. More than one active key can exist, so rotation needs no downtime. No read-only key type is documented. Certn's help-center article on API keys (help.certn.co) blocked automated access, so the exact button labels are unverified.
Source: [centric-api-docs.certn.co](https://centric-api-docs.certn.co/reference/authentication.md), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Certn**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Certn yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Checkr (/docs/compliance-connectors/setup/background-check-providers/checkr)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Checkr connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Checkr:
1. In the Checkr Dashboard, go to **Account Settings › Developer Settings**.
2. Click **Create Key** and choose the **Secret** key type (a publishable key will not work for server-side API calls).
3. Copy the secret key and store it securely.
Where to find the other values:
* **Base URL (optional)**: Checkr's API docs give **[https://api.checkr.com/v1](https://api.checkr.com/v1)** for production and **[https://api.checkr-staging.com/v1](https://api.checkr-staging.com/v1)** for staging.
Source: [docs.checkr.com](https://docs.checkr.com/), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Checkr**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Checkr yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Cisive (/docs/compliance-connectors/setup/background-check-providers/cisive)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Cisive connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Cisive:
1. Sign up or sign in at the Cisive API portal, **apiportal.cisive.com** (**Sign up** / **Sign In**).
Cisive keeps the full instructions behind sign-in; this is what its public pages say.
Cisive's public API portal lists its APIs (Order Management, Sanction Check, License Manager Pro) but does not explain publicly how credentials are issued; the details are behind portal sign-in. No read-only option is documented.
Source: [apiportal.cisive.com](https://apiportal.cisive.com/), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Cisive**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Cisive yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# ClearChecks (/docs/compliance-connectors/setup/background-check-providers/clearchecks)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your ClearChecks connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In ClearChecks:
1. Sign in to your ClearChecks account (you must be an existing customer) and open the **Developers** section.
2. Enter a **Token Name** and generate the token, then copy it.
ClearChecks's public documentation does not cover every step.
Source is the ClearChecks (formerly BackgroundChecks.com) support center. It names the Developers section and the Token Name field but not the exact button label, and does not say whether the token is shown only once. Developer docs live at app.backgroundchecks.com/developers/docs (sign-in). No read-only token type is documented; the base URL and account fields are not documented publicly.
Source: [support.backgroundchecks.com](https://support.backgroundchecks.com/en/articles/9438018-how-do-i-get-an-api-key), checked 2026-10-07.
2. On **Compliance › Connectors**, open **ClearChecks**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads ClearChecks yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# GoodHire (/docs/compliance-connectors/setup/background-check-providers/goodhire)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your GoodHire connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In GoodHire:
1. Sign in to GoodHire and open the developer dashboard, where GoodHire says API keys, webhooks and logging are managed.
GoodHire keeps the full instructions behind sign-in; this is what its public pages say.
GoodHire's public API page only says a "Developer dashboard for API keys, webhooks, and logging" exists and offers **Talk to Sales** for API access. Its API documentation link (help.goodhire.com/docs/api-documentation) now redirects to a Checkr help page that returns 404, so the click path and any read-only option are unverified.
Source: [goodhire.com](https://goodhire.com/api), checked 2026-10-07.
2. On **Compliance › Connectors**, open **GoodHire**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads GoodHire yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# HireRight (/docs/compliance-connectors/setup/background-check-providers/hireright)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your HireRight connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In HireRight, create the credential for **API token / Personal access token**, read-only where it offers that. HireRight does not publish these steps; its support team can confirm them.
2. On **Compliance › Connectors**, open **HireRight**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads HireRight yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# IDenfy (/docs/compliance-connectors/setup/background-check-providers/idenfy)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your IDenfy connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In IDenfy:
1. In the iDenfy Dashboard, go to **Settings › API keys**.
2. Click **Create** to generate a new API key and secret.
3. Copy the API key and the API secret right away; the secret is shown only once.
IDenfy shows the secret only once, so copy it before you leave the page.
Source: [documentation.idenfy.com](https://documentation.idenfy.com/guides/dashboard/settings/api-keys), [documentation.idenfy.com](https://documentation.idenfy.com/authentication.md), checked 2026-10-07.
2. On **Compliance › Connectors**, open **IDenfy**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads IDenfy yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Background Check Providers connectors (/docs/compliance-connectors/setup/background-check-providers)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Pre-employment screening (HR).
Each connector has its own page: the credential to create at the vendor, the permissions it needs, what to enter on **Compliance › Connectors**, and the frameworks it provides evidence for. How connecting works, card statuses and multiple accounts: [Compliance connectors](/docs/compliance-connectors). Every connector in one table: [setup reference](/docs/compliance-connectors/reference).
## Accurate
Record your Accurate connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Accurate](/docs/compliance-connectors/setup/background-check-providers/accurate)
## Certn
Record your Certn connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Certn](/docs/compliance-connectors/setup/background-check-providers/certn)
## Checkr
Record your Checkr connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Checkr](/docs/compliance-connectors/setup/background-check-providers/checkr)
## Cisive
Record your Cisive connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Cisive](/docs/compliance-connectors/setup/background-check-providers/cisive)
## ClearChecks
Record your ClearChecks connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect ClearChecks](/docs/compliance-connectors/setup/background-check-providers/clearchecks)
## GoodHire
Record your GoodHire connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect GoodHire](/docs/compliance-connectors/setup/background-check-providers/goodhire)
## HireRight
Record your HireRight connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect HireRight](/docs/compliance-connectors/setup/background-check-providers/hireright)
## IDenfy
Record your IDenfy connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect IDenfy](/docs/compliance-connectors/setup/background-check-providers/idenfy)
## Jumio
Record your Jumio connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Jumio](/docs/compliance-connectors/setup/background-check-providers/jumio)
## Onfido
Record your Onfido connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Onfido](/docs/compliance-connectors/setup/background-check-providers/onfido)
## Persona
Record your Persona connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Persona](/docs/compliance-connectors/setup/background-check-providers/persona)
## Socure
Record your Socure connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Socure](/docs/compliance-connectors/setup/background-check-providers/socure)
## Sterling
Record your Sterling connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Sterling](/docs/compliance-connectors/setup/background-check-providers/sterling)
## Truework
Record your Truework connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Truework](/docs/compliance-connectors/setup/background-check-providers/truework)
## Universal Background Screening
Record your Universal Background Screening connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Universal Background Screening](/docs/compliance-connectors/setup/background-check-providers/universal-background-screening)
## Veremark
Record your Veremark connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Veremark](/docs/compliance-connectors/setup/background-check-providers/veremark)
## Vetty
Record your Vetty connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Vetty](/docs/compliance-connectors/setup/background-check-providers/vetty)
## Yardstik
Connect Yardstik to collect background check providers evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token. [How to connect Yardstik](/docs/compliance-connectors/setup/background-check-providers/yardstik)
## Zinc
Record your Zinc connection as background check providers evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Zinc](/docs/compliance-connectors/setup/background-check-providers/zinc)
# Jumio (/docs/compliance-connectors/setup/background-check-providers/jumio)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Jumio connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Jumio, create the credential for **API token / Personal access token**, read-only where it offers that. Jumio does not publish these steps; its support team can confirm them.
2. On **Compliance › Connectors**, open **Jumio**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Jumio yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Onfido (/docs/compliance-connectors/setup/background-check-providers/onfido)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Onfido connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Onfido:
1. In the Onfido Dashboard, go to **Developers › API authentication** and open the **Tokens** tab.
2. Click **Generate API token**.
3. In the popup, choose **Live** (or **Sandbox** for testing) and click **Generate**.
4. Copy the token from the popup.
Where to find the other values:
* **Base URL (optional)**: Use your account's region: **[https://api.eu.onfido.com/](https://api.eu.onfido.com/)** (EU, tokens start api\_live.), **[https://api.us.onfido.com/](https://api.us.onfido.com/)** (US, api\_live\_us.) or **[https://api.ca.onfido.com/](https://api.ca.onfido.com/)** (CA, api\_live\_ca.).
Source: [documentation.identity.entrust.com](https://documentation.identity.entrust.com/api/latest/), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Onfido**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Onfido yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Persona (/docs/compliance-connectors/setup/background-check-providers/persona)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Persona connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Persona:
1. In the Persona Dashboard, switch to the production environment and go to **API › API Keys**.
2. Create a new API key (needs a role with API key administration privileges) and copy it; production keys start with persona\_production\_.
3. On the key, choose **Edit › Permissions** and keep only read permissions (for example **account.read**), clearing any write permissions.
Persona's public documentation does not cover every step.
Source: [docs.withpersona.com](https://docs.withpersona.com/api-keys), [docs.withpersona.com](https://docs.withpersona.com/reference/api-keys), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Persona**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Persona yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Socure (/docs/compliance-connectors/setup/background-check-providers/socure)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Socure connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Socure:
1. Sign in to the RiskOS Dashboard (production: riskos.socure.com).
2. Go to **Developer Workbench › API Keys**.
3. Copy the API key for the environment you are connecting.
Where to find the other values:
* **Base URL (optional)**: Socure documents separate Sandbox (riskos.sandbox.socure.com) and Production (riskos.socure.com) environments, each with its own API key.
Source: [help.socure.com](https://help.socure.com/riskos/reference/authentication), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Socure**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Socure yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Sterling (/docs/compliance-connectors/setup/background-check-providers/sterling)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Sterling connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Sterling:
1. Obtain API credentials from First Advantage (Sterling is a First Advantage company); they are not provided through the API or a self-service screen. You receive a **client\_id** and **client\_secret**, and the credentials differ by region and environment.
2. Integration credentials and Production credentials differ, so obtain a separate set from First Advantage for Production when you go live.
3. To get a bearer token, POST to the region's oauth endpoint (for example [https://api.us.sterlingcheck.app/v2/oauth](https://api.us.sterlingcheck.app/v2/oauth)) with **Authorization: Basic** base64(client\_id:client\_secret) and grant\_type=client\_credentials. The returned token expires (expires\_in 3600 seconds) and is sent as **Authorization: Bearer**.
Where to find the other values:
* **Base URL (optional)**: The regional API host from the Sterling API docs: US [https://api.us.sterlingcheck.app](https://api.us.sterlingcheck.app) (Integration: [https://api.us.int.sterlingcheck.app](https://api.us.int.sterlingcheck.app)), EMEA [https://api.eu.sterlingcheck.app](https://api.eu.sterlingcheck.app), Canada [https://api.ca.sterlingcheck.app](https://api.ca.sterlingcheck.app), APAC [https://api.au.sterlingcheck.app](https://api.au.sterlingcheck.app).
Sterling issues this credential through its API or its support team, not through its admin screens.
Sterling is now a First Advantage company. The API docs portal is script-rendered; its content was read from the portal's own collection JSON on apidocs.sterlingcheck.app. The docs say the credentials 'are not provided through the API and must be obtained through First Advantage'. EMEA, Canada and APAC are supported only in Production. The client secret changes only at your request. The docs define no read-only scope: the credential gives access to the packages and screenings on the client account. Prospects can use the 'Request a Developer Key' form on the Sterling API page instead.
Source: [sterlingcheck.com](https://www.sterlingcheck.com/services/api/), [apidocs.sterlingcheck.app](https://apidocs.sterlingcheck.app/), [apidocs.sterlingcheck.app](https://apidocs.sterlingcheck.app/api/collections/7075989/TVRkZ7pA?environment=7075989-7339d01d-891d-4ab0-9cbc-89b5efc93475\&segregateAuth=true\&versionTag=latest), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Sterling**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Sterling yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Truework (/docs/compliance-connectors/setup/background-check-providers/truework)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Truework connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Truework, create the credential for **API token / Personal access token**, read-only where it offers that. Truework does not publish these steps; its support team can confirm them.
2. On **Compliance › Connectors**, open **Truework**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Truework yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Universal Background Screening (/docs/compliance-connectors/setup/background-check-providers/universal-background-screening)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Universal Background Screening connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Universal Background Screening, create the credential for **API token / Personal access token**, read-only where it offers that. Universal Background Screening does not publish these steps; its support team can confirm them.
2. On **Compliance › Connectors**, open **Universal Background Screening**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Universal Background Screening yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Veremark (/docs/compliance-connectors/setup/background-check-providers/veremark)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Veremark connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Veremark, create the credential for **API token / Personal access token**, read-only where it offers that.
2. On **Compliance › Connectors**, open **Veremark**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Veremark yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Vetty (/docs/compliance-connectors/setup/background-check-providers/vetty)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Vetty connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Vetty:
1. In Vetty, go to **Settings** and open the **API Management** tab.
2. Click **Add New User Key**.
3. Choose a **Client User**, enter the **IP Address** the integration will call from, and set an **Expiration Date** (Vetty suggests 24 months).
4. Click **Add**.
5. In the **API Management System** table, single-click the new key to copy it.
Source: [info.vetty.co](https://info.vetty.co/creating-an-api-key-for-an-integration), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Vetty**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Vetty yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Yardstik (/docs/compliance-connectors/setup/background-check-providers/yardstik)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Yardstik to collect background check providers evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Yardstik's guide | [developer.yardstik.com](https://developer.yardstik.com/) |
## Connect with an API token
1. In Yardstik:
1. In the Yardstik dashboard, go to **Developer Tools › API Keys** (app.yardstik.com/developer/api-keys).
2. Enter a descriptive key name and click **Create**.
3. Copy the full key from the popup now; Yardstik says this is the only time you will see the complete API key.
Yardstik shows the secret only once, so copy it before you leave the page.
Source: [developer.yardstik.com](https://developer.yardstik.com/), checked 2026-10-07.
The permissions Safeguard needs: `reports and candidates: read`.
2. On **Compliance › Connectors**, open **Yardstik**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------- | ------------------------------------------------- |
| API key | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Yardstik and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | --------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC1.4` | 1 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.6.1` | 1 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)` | 1 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `12.7.1` | 1 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `GV.RR-04` | 1 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Zinc (/docs/compliance-connectors/setup/background-check-providers/zinc)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Zinc connection as background check providers evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------ |
| Category | [Background Check Providers](/docs/compliance-connectors/setup/background-check-providers) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Zinc, create the credential for **API token / Personal access token**, read-only where it offers that. Zinc does not publish these steps; its support team can confirm them.
2. On **Compliance › Connectors**, open **Zinc**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Zinc yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Background Check Providers connectors](/docs/compliance-connectors/setup/background-check-providers)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Amazon S3 (/docs/compliance-connectors/setup/cloud-storage-provider/amazon-s3)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Amazon S3 to collect cloud storage provider evidence automatically.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated evidence collection |
## Connect with an API token
1. In Amazon S3:
1. Sign in to the AWS Management Console and open the IAM console at [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
2. In the navigation pane, choose **Users**, then choose the user name (a dedicated user that has the **AmazonS3ReadOnlyAccess** AWS managed policy attached).
3. On the **Security credentials** tab, in the **Access keys** section, choose **Create access key**.
4. On the **Access key best practices & alternatives** page, choose **Other**, then choose **Next**.
5. Optionally add a description tag on the **Set description tag** page, then select **Create access key**.
6. On the **Retrieve access key** page, choose **Show** to reveal the secret access key, or choose **Download .csv file**. This is your only time to view or download it.
7. Attach the AWS managed policy **AmazonS3ReadOnlyAccess** (s3:Get\*, s3:List\*, s3:Describe\*) to the user, or to a group the user belongs to.
Where to find the other values:
* **AWS Access Key ID**: IAM console › **Users** › the user › **Security credentials** tab › **Access keys** lists the access key ID.
Amazon S3 shows the secret only once, so copy it before you leave the page.
Each IAM user can have two access keys. AmazonS3ReadOnlyAccess provides read-only access to all buckets. The policy-attach dialog itself (Add permissions) was not quoted from a fetched page; the managed policy reference page says it can be attached to users, groups and roles.
Source: [docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-keys-admin-managed.html), [docs.aws.amazon.com](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonS3ReadOnlyAccess.html), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Amazon S3**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------ | ------------------------------------------------- |
| AWS Access Key ID | Required. Stored encrypted and never shown again. |
| AWS Secret Access Key | Required. Stored encrypted and never shown again. |
| Region | Optional. |
| Session token (optional) | Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Amazon S3 and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.1`, `A1.2`, `A1.3`, `C1.1`, `CC2.3`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1`, `CC7.2`, `CC7.3`, `CC7.4`, `CC8.1` | 148 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.12`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.24`, `A.5.25`, `A.8.2`, `A.8.3`, `A.8.5`, `A.8.6`, `A.8.8`, `A.8.9`, `A.8.11`, `A.8.12`, `A.8.13`, `A.8.14`, `A.8.15`, `A.8.16`, `A.8.20`, `A.8.24`, `A.8.32` | 148 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(1)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 81 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `3.5.1`, `3.7.4`, `4.2.1`, `6.3.1`, `6.3.3`, `6.4.2`, `6.5.1`, `7.2.1`, `7.2.2`, `8.2.6`, `8.3.6`, `8.4.1`, `8.4.2`, `8.6.3`, `10.2.1`, `10.3.2`, `10.5.1`, `11.3.1`, `11.5.1`, `11.5.2` | 81 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.AE-02`, `DE.CM-01`, `DE.CM-09`, `ID.AM-07`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.IR-03`, `PR.PS-01`, `PR.PS-02`, `PR.PS-04`, `RS.CO-02`, `RS.MA-01` | 148 |
| [CIS AWS Foundations Benchmark](/docs/framework-connectors/cis-aws) | Automated tests | `1.1`, `1.2`, `1.6`, `1.7`, `1.11`, `1.13`, `1.15`, `1.16`, `1.17`, `1.18`, `1.19`, `1.20`, `1.21`, `1.22`, `2.1.1`, `2.1.2`, `2.1.3`, `2.3.2`, `2.4.1`, `3.4`, `3.8`, `3.9`, `4.1`, `4.2`, `4.3`, `4.4`, `4.5`, `4.6`, `4.7`, `4.8`, `4.9`, `4.10`, `4.11`, `4.12`, `4.13`, `4.14`, `4.15`, `4.16`, `5.1`, `5.4`, `5.6` | 41 |
For a CIS benchmark, the numbers are its recommendations.
These tests are switched on per workspace by the Safeguard team.
[Amazon CloudWatch](/docs/compliance-connectors/setup/observability/amazon-cloudwatch), [Amazon Web Services](/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services), [AWS CodeCommit](/docs/compliance-connectors/setup/version-control/aws-codecommit), [AWS GovCloud](/docs/compliance-connectors/setup/cloud-infrastructure/aws-govcloud), [AWS Inspector](/docs/compliance-connectors/setup/vulnerability-scanning/aws-inspector), [AWS Security Hub](/docs/compliance-connectors/setup/cspm/aws-security-hub) connect to the same provider as Amazon S3, and these tests run for a connection made through any of them.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Azure Blob Storage (/docs/compliance-connectors/setup/cloud-storage-provider/azure-blob-storage)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Azure Blob Storage connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Azure Blob Storage:
1. In the Azure portal (portal.azure.com), go to your storage account.
2. From the resource menu under **Security + networking**, select **Access keys**.
3. Select **Show keys** to reveal the access keys and connection strings.
4. Under **key1**, find the **Key** value and select the **Copy** button. Paste it into Safeguard as the token.
5. To view the keys, your Azure user needs a role that includes **Microsoft.Storage/storageAccounts/listkeys/action**: the built-in **Owner**, **Contributor** or **Storage Account Key Operator Service Role**.
Where to find the other values:
* **Account / Org / Workspace (optional)**: The storage account name is the resource you open in the Azure portal; it also appears in the **Connection string** under **Security + networking › Access keys**.
* **Base URL (optional)**: Not stated on the fetched page.
Azure Blob Storage's public documentation does not cover every step.
Storage account access keys give full access to the account's data; Microsoft documents no read-only access key. Microsoft recommends Microsoft Entra ID or a user delegation SAS instead of Shared Key where possible. The keys can be shown again at any time from the Access keys page. The exact location of the blob endpoint URL in the portal was not confirmed from a fetched page; Shared Key authorization may also be disabled on the account, in which case the key will not work.
Source: [learn.microsoft.com](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-keys-manage), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Azure Blob Storage**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Azure Blob Storage yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Backblaze (/docs/compliance-connectors/setup/cloud-storage-provider/backblaze)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Backblaze to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Backblaze's guide | [backblaze.com](https://www.backblaze.com/docs/cloud-storage-buckets) |
## Connect with an API token
1. In Backblaze:
1. In the Backblaze web console, go to **Application Keys** under B2 Cloud Storage.
2. Click **Add a New Application Key** and enter a name.
3. For bucket access choose **All** (Safeguard lists buckets), and set the type of access to **Read Only**.
4. Click **Create New Key**.
5. Copy the **keyID** and the **applicationKey**: the applicationKey appears only once.
Where to find the other values:
* **Key ID**: The **keyID** shown for the key on the **Application Keys** page.
Backblaze shows the secret only once, so copy it before you leave the page.
Backblaze's public documentation does not cover every step.
Backblaze's docs list listBuckets, readBucketEncryption and readBucketRetentions as key capabilities, but do not say which capabilities a Read Only key from the web console receives. To set exactly those capabilities, create the key with the Native API b2\_create\_key operation; the CLI syntax was not sourced.
Source: [backblaze.com](https://www.backblaze.com/docs/cloud-storage-create-and-manage-app-keys), [backblaze.com](https://www.backblaze.com/docs/cloud-storage-application-keys), checked 2026-10-07.
The permissions Safeguard needs: `listBuckets`, `readBucketEncryption`, `readBucketRetentions`.
2. On **Compliance › Connectors**, open **Backblaze**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| --------------- | ------------------------------------------------- |
| Key ID | Required. |
| Application key | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Backblaze and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.2`, `CC6.1`, `CC6.6` | 3 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.8.13`, `A.8.20`, `A.8.24` | 3 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(7)`, `164.312(a)(1)`, `164.312(e)(1)` | 3 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `3.5.1` | 2 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.DS-01`, `PR.DS-11`, `PR.IR-01` | 3 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Box (/docs/compliance-connectors/setup/cloud-storage-provider/box)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Box to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token, MCP server |
| What a connection produces | Automated compliance tests |
| Box's guide | [developer.box.com](https://developer.box.com/reference/get-users/) |
## Connect with an API token
1. In Box:
1. In the Box Developer Console, select **New App**, select **Server** as the app type, leave **Client Credentials Grant** selected under **Select Method**, and select **Create**.
2. On the **Configuration** tab, set **App Access Level** to **App + Enterprise Access**.
3. Under the application scopes, check **Manage users** (manage\_managed\_users).
4. Copy the **Client ID** and **Client Secret** from the **Configuration** tab (the secret is only shown once multi-factor authentication is enabled on your Box account).
5. After a Box admin authorizes the app (see the admin step), request an access token from the **/oauth2/token** endpoint with the client credentials and **box\_subject\_type=enterprise** plus your Enterprise ID, and paste that access token into Safeguard.
6. A Box admin opens the Admin Console, selects the **Platform** tab, then the **Platform Apps** tab, clicks **Add** and enters the app's Client ID to authorize it.
Box's public documentation does not cover every step.
Source: [developer.box.com](https://developer.box.com/guides/authentication/client-credentials/client-credentials-setup/), [developer.box.com](https://developer.box.com/guides/authorization/platform-app-approval/), [developer.box.com](https://developer.box.com/guides/api-calls/permissions-and-errors/scopes/), [developer.box.com](https://developer.box.com/reference/get-users/), checked 2026-10-07.
The permissions Safeguard needs: `manage_managed_users`, `App + Enterprise access`. Box has no narrower grant for these reads. Safeguard only reads with it.
2. On **Compliance › Connectors**, open **Box**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------ | ------------------------------------------------- |
| Access token | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Connect with the MCP server
Choose **MCP server**: the address `https://mcp.box.com` is filled in. Sign in to Box when asked. It lets Griffin AI search Box; the compliance evidence comes from the API token connection.
## Frameworks
Safeguard's automated tests read Box and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ------------------------------------ | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.2`, `CC6.3` | 3 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-05` | 3 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Citrix ShareFile (/docs/compliance-connectors/setup/cloud-storage-provider/citrix-sharefile)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Citrix ShareFile to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Citrix ShareFile's guide | [api.sharefile.com](https://api.sharefile.com/docs/resource?name=Users) |
## Connect with an API token
1. In Citrix ShareFile:
1. Request a ShareFile OAuth2 client ID and secret by completing and submitting the request form on ShareFile's API keys page ([https://secure.sharefile.com/apikeys](https://secure.sharefile.com/apikeys)).
2. Obtain an access token from https\://\{subdomain}.\{apicp}/oauth/token, using the authorization code flow or the password grant for console and non-web clients.
3. Copy the **access\_token** from the response. It expires after **expires\_in** seconds; refresh it at the same endpoint with grant\_type=refresh\_token.
Where to find the other values:
* **Subdomain**: Your ShareFile subdomain, for example mycompany in [https://mycompany.sharefile.com](https://mycompany.sharefile.com); the token response also returns it as **subdomain**.
* **Region (optional)**: The **apicp** value in the token response: your ShareFile API control plane, for example sharefile.com or securevdr.com.
Citrix ShareFile issues this credential through its API or its support team, not through its admin screens.
ShareFile issues API client credentials through a request form, and access tokens through its OAuth2 API, not a self-service UI. Tokens expire, so a pasted access token stops working after expires\_in seconds. Which ShareFile permissions are needed to list all users was not sourced (the Users reference page read was only an index).
Source: [api.sharefile.com](https://api.sharefile.com/gettingstarted/oauth2), [api.sharefile.com](https://api.sharefile.com/docs/resource?name=Users), checked 2026-10-07.
The permissions Safeguard needs: `AdminManageEmployees`. Citrix ShareFile shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
2. On **Compliance › Connectors**, open **Citrix ShareFile**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ----------------- | --------------------------------------------------------- |
| Subdomain | Required. The part before .sharefile.com in your address. |
| Access token | Required. Stored encrypted and never shown again. |
| Region (optional) | — |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Citrix ShareFile and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ------------------------------------ | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.2`, `CC6.3` | 3 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-05` | 3 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Dropbox Sign (/docs/compliance-connectors/setup/cloud-storage-provider/dropbox-sign)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Dropbox Sign to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | --------------------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Dropbox Sign's guide | [developers.hellosign.com](https://developers.hellosign.com/api/reference/operation/teamGet/) |
## Connect with an API token
1. In Dropbox Sign:
1. Sign in to Dropbox Sign.
2. Go to your **API Settings** page.
3. Click **Generate key** and copy the API key.
Dropbox Sign's public documentation does not cover every step.
Dropbox Sign API key permissions cannot be restricted; Dropbox Sign says to use OAuth (team\_access scope) for scoped access. The OAuth app and access-token steps for the alternative Access token field were not sourced. The fetched docs do not say which role is needed to list the whole team, whether the key is shown only once, or how to reach the API Settings page from the menus (the docs link to it directly).
Source: [developers.hellosign.com](https://developers.hellosign.com/api/reference/authentication/), [developers.hellosign.com](https://developers.hellosign.com/api/reference/operation/teamGet/), checked 2026-10-07.
The permissions Safeguard needs: `team_access`. Dropbox Sign shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
2. On **Compliance › Connectors**, open **Dropbox Sign**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------- | ------------------------------------------------- |
| API key | Optional. Stored encrypted and never shown again. |
Or, instead: Access token (optional).
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Dropbox Sign and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ------------------------------------ | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.2`, `CC6.3` | 3 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-05` | 3 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Dropbox (/docs/compliance-connectors/setup/cloud-storage-provider/dropbox)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Dropbox to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Dropbox's guide | [developers.dropbox.com](https://developers.dropbox.com/business) |
## Connect with an API token
1. In Dropbox:
1. Sign in as a Dropbox team admin and open the App Console ([https://www.dropbox.com/developers/apps](https://www.dropbox.com/developers/apps)) to register an app.
2. On the app's **Permissions** tab, select the team scopes the app needs.
3. On the app's settings page, in the OAuth 2 section, press **Generate** to create an access token for your own account, and copy it.
Dropbox's public documentation does not cover every step.
Source: [docs.dropboxapi.com](https://docs.dropboxapi.com/dropbox-api/docs/oauth), [developers.dropbox.com](https://developers.dropbox.com/business), checked 2026-10-07.
The permissions Safeguard needs: `members.read`.
2. On **Compliance › Connectors**, open **Dropbox**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------ | ------------------------------------------------- |
| Access token | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Dropbox and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ------------------------------------ | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.2`, `CC6.3` | 3 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-05` | 3 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Egnyte (/docs/compliance-connectors/setup/cloud-storage-provider/egnyte)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Egnyte to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | -------------------------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token, MCP server |
| What a connection produces | Automated compliance tests |
| Egnyte's guide | [developers.egnyte.com](https://developers.egnyte.com/docs/read/User_Management_API_Documentation) |
## Connect with an API token
1. In Egnyte:
1. Using the email address of an active Egnyte domain administrator (not a service account), register for a developer account on the Egnyte Developer Portal (developers.egnyte.com) and click the confirmation link in the email.
2. Sign in to the developer portal, click the drop-down arrow next to your email and click **Apps**.
3. Click **New APP**.
4. Fill in **App Name**, **Description** and **Egnyte Domain** (only the part before .egnyte.com). For **Type**, select **Internal Application** (for your own company's internal use).
5. Under **APIs**, click **Request** next to **Prod Collaborate**, then click **Save**.
6. Open the app to see the **API Key** and **Secret**. The key starts as **Pending Approval** and becomes **Active** after Egnyte verifies the request.
7. Exchange the key for an access token with the Resource Owner Password Credentials flow: send POST https\://\{domain}.egnyte.com/puboauth/token (form-encoded) with client\_id = the API key, client\_secret = the secret, username and password of the domain administrator, grant\_type=password and scope=Egnyte.user.
8. Copy access\_token from the response. It is valid for 30 days and is revoked immediately if the user changes their password.
9. Scope the token to **Egnyte.user** (User Management API) by passing scope=Egnyte.user in the token request. Without a scope parameter the token has global access to all APIs.
Where to find the other values:
* **Domain**: Your Egnyte web address is yourdomain.egnyte.com; the Domain is the yourdomain part (the same value entered in **Egnyte Domain** when creating the app).
API keys are only issued to Egnyte domain administrators on eligible plans; Trial, Legacy Office and Team plans are not supported. Keys are reviewed by Egnyte (Pending Approval, then Active). The access token comes from an OAuth API call, not from the UI; it expires after 30 days (a refresh token is returned alongside it). The developer portal (developers.egnyte.com) serves its docs from us-partner-integrations.egnyte.com/integration/cfs/api-docs/. Egnyte migrated from Mashery to Apigee on 1 Oct 2025; old Mashery accounts must re-register with the same email. Verification 2026-10-07: Egnyte's Getting Started page shows the API key and secret on the app page after saving but does not say whether they can be viewed again later, so one\_time\_display is unknown.
Source: [us-partner-integrations.egnyte.com](https://us-partner-integrations.egnyte.com/integration/cfs/api-docs/getting-started), [us-partner-integrations.egnyte.com](https://us-partner-integrations.egnyte.com/integration/cfs/api-docs/public-api-authentication), [developers.egnyte.com](https://developers.egnyte.com/sitemap.xml), checked 2026-10-07.
The permissions Safeguard needs: `Egnyte.user`. Egnyte shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it. Safeguard's compliance tests for Egnyte need the credential on the API token tab: an OAuth connection cannot read everything they check.
2. On **Compliance › Connectors**, open **Egnyte**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------ | ------------------------------------------------------ |
| Domain | Required. The part before .egnyte.com in your address. |
| Access token | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Connect with the MCP server
Choose **MCP server**: the address `https://mcp-server.egnyte.com/sse` is filled in. Sign in to Egnyte when asked. It lets Griffin AI search Egnyte; the compliance evidence comes from the API token connection.
## Frameworks
Safeguard's automated tests read Egnyte and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ------------------------------------ | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.2`, `CC6.3` | 3 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-05` | 3 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Google Cloud Storage (/docs/compliance-connectors/setup/cloud-storage-provider/google-cloud-storage)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Google Cloud Storage to collect cloud storage provider evidence automatically.
Step-by-step guide: [Connect Google Cloud Storage](/docs/compliance-connectors/google-cloud).
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | OAuth, API token |
| What a connection produces | Automated evidence collection |
## Connect with OAuth
Before you start, an administrator of Google Cloud Storage must allow third-party apps:
* If your organization uses Google Workspace app access control: in the Google Admin console go to **Menu › Security › Access and data control › API controls**, click **Manage App Access**, then **Configure new app**.
* Enter Safeguard's app name or client ID and click **Search**, select it, choose the organizational units, and set access to **Trusted** or **Specific Google data**; click **Continue** and **Finish**. Changes can take up to 24 hours.
1. On **Compliance › Connectors**, open **Google Cloud Storage**, click **Connect** and choose **OAuth**.
2. Sign in to Google Cloud Storage and approve Safeguard on its consent screen. Use an account that can approve apps for your organization, usually an administrator. Safeguard asks for `https://www.googleapis.com/auth/devstorage.read_only`.
3. You return to Safeguard, and the card shows **Verified** once the first check succeeds.
## Connect with an API token
1. In Google Cloud Storage:
1. In the Google Cloud console, go to the **Service accounts** page and select your project.
2. Click the email address of the service account Safeguard will use.
3. Click the **Keys** tab, click the **Add key** drop-down menu and select **Create new key**.
4. Select **JSON** as the **Key type** and click **Create**. The key file downloads; you cannot download it again.
5. In the Google Cloud console, go to the **IAM** page and select the project.
6. Click **Grant Access**, enter the service account's email as the principal, click **Select a role** and choose **Storage Bucket Viewer** (roles/storage.bucketViewer), which views buckets and their metadata, excluding IAM policies. Click **Save**.
Google Cloud Storage shows the secret only once, so copy it before you leave the page.
Source: [docs.cloud.google.com](https://docs.cloud.google.com/iam/docs/keys-create-delete), [docs.cloud.google.com](https://docs.cloud.google.com/iam/docs/granting-changing-revoking-access), [docs.cloud.google.com](https://docs.cloud.google.com/storage/docs/access-control/iam-roles), [knowledge.workspace.google.com](https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Google Cloud Storage**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Service account key (JSON) | Required. Paste the full service-account JSON key. Needs roles/viewer (cloud-platform.read-only). Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Google Cloud Storage yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Google Drive (/docs/compliance-connectors/setup/cloud-storage-provider/google-drive)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Google Drive to collect cloud storage provider evidence automatically.
Step-by-step guide: [Connect Google Drive](/docs/compliance-connectors/google-workspace).
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | OAuth, API token, MCP server |
| What a connection produces | Automated evidence collection |
| Google Drive's guide | [support.google.com](https://support.google.com/a/answer/60781) |
## Connect with OAuth
Before you start, an administrator of Google Drive must allow third-party apps:
* If your organization restricts third-party apps: in the Google Admin console go to **Menu › Security › Access and data control › API controls**, click **Manage App Access**, then **Configure new app**.
* Enter Safeguard's app name or client ID, click **Search**, select it, choose the organizational units, and set access to **Trusted** or **Specific Google data**; click **Continue** and **Finish**. Changes can take up to 24 hours.
1. On **Compliance › Connectors**, open **Google Drive**, click **Connect** and choose **OAuth**.
2. Sign in to Google Drive and approve Safeguard on its consent screen. Use an account that can approve apps for your organization, usually an administrator. Safeguard asks for `https://www.googleapis.com/auth/drive.readonly`.
3. You return to Safeguard, and the card shows **Verified** once the first check succeeds.
## Connect with an API token
1. In Google Drive:
1. In the Google Cloud console, go to the **Service accounts** page, select your project, and click the email address of the service account Safeguard will use.
2. Click the **Keys** tab, click **Add key** and select **Create new key**.
3. Select **JSON** as the **Key type** and click **Create**. The key file downloads; you cannot download it again.
4. Find the service account's client ID: as a super administrator in Google Cloud, click **IAM & Admin › Service accounts ›** the service account, and expand **Advanced settings** to copy the **Client ID**.
5. In the Google Admin console, go to **Menu › Security › Access and data control › API controls › Manage Domain Wide Delegation**.
6. Click **Add new**, enter the **Client ID**, add the OAuth scope [https://www.googleapis.com/auth/drive.readonly](https://www.googleapis.com/auth/drive.readonly) under **OAuth Scopes**, and click **Authorize**.
Where to find the other values:
* **Admin email to impersonate**: The email address of a Google Workspace administrator in your domain; the service account acts as this user through domain-wide delegation.
Google Drive shows the secret only once, so copy it before you leave the page.
Key creation can be blocked by the organization policy iam.disableServiceAccountKeyCreation (enforced by default for organizations created on or after May 3, 2024). Setting up domain-wide delegation and app access control needs a super administrator or the Service Settings administrator privilege.
Source: [docs.cloud.google.com](https://docs.cloud.google.com/iam/docs/keys-create-delete), [knowledge.workspace.google.com](https://knowledge.workspace.google.com/admin/apps/control-api-access-with-domain-wide-delegation), [knowledge.workspace.google.com](https://knowledge.workspace.google.com/admin/apps/control-which-apps-access-google-workspace-data), [support.google.com](https://support.google.com/a/answer/60781), checked 2026-10-07.
The permissions Safeguard needs: `drive.readonly`.
2. On **Compliance › Connectors**, open **Google Drive**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| Service account key (JSON) | Optional. Domain-wide delegation service account with Admin SDK Directory read-only scopes. Stored encrypted and never shown again. |
| Admin email to impersonate | Optional. |
| OAuth access token (optional) | Alternative: paste a short-lived OAuth token with Admin SDK Directory scopes. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Connect with the MCP server
Choose **MCP server**: the address `https://drivemcp.googleapis.com/mcp/v1` is filled in. Sign in to Google Drive when asked. It lets Griffin AI search Google Drive; the compliance evidence comes from the OAuth or API token connection.
## Frameworks
Safeguard's automated tests read Google Drive and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ----------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.1`, `CC6.7` | 1 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.14`, `A.8.3` | 1 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.312(a)(1)` | 1 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.DS-01` | 1 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Hack The Box (/docs/compliance-connectors/setup/cloud-storage-provider/hack-the-box)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Hack The Box connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Hack The Box:
1. Sign in to the HTB Enterprise Platform with the account the key will belong to (use a Member account for read-only, content-limited access; Admin accounts can call every endpoint, including user and space management).
2. Click **My Profile** and select **Settings**.
3. Scroll to the API Key section and click **+ Create API Key**.
4. In the modal, enter a name for the key (optional but recommended) and click **Create API Key**.
5. Copy the key from the new modal with the copy icon. This is the only time the full API key is shown.
Where to find the other values:
* **Base URL (optional)**: HTB documents the Enterprise Public API in its Developer Portal at [https://enterprise.hackthebox.com/developers/portal#overview](https://enterprise.hackthebox.com/developers/portal#overview); the help articles do not state the API base URL.
Hack The Box shows the secret only once, so copy it before you leave the page.
Applies to the HTB Enterprise Platform (business); the key must belong to a user provisioned on that platform. There is no scope choice at creation: the key carries its owner's role. Members can reach read-only or limited content endpoints; User Management endpoints are Admins only. Keys expire automatically two years after creation, at most 10 keys can be active at once, rate limits are shared across all of an account's keys, and deleting a key invalidates it immediately. The separate HTB CTF platform issues an MCP token under Profile Settings › MCP Access › Generate Token (also shown once). Where the organization identifier is shown is not documented.
Source: [enterprise-help.hackthebox.com](https://enterprise-help.hackthebox.com/en/articles/13375829-creating-an-api-key), [enterprise-help.hackthebox.com](https://enterprise-help.hackthebox.com/en/articles/13375637-introduction-to-enterprise-public-api), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Hack The Box**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Hack The Box yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# iCloud (/docs/compliance-connectors/setup/cloud-storage-provider/icloud)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your iCloud connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In iCloud:
1. Make sure the Apple Account is protected with two-factor authentication.
2. Sign in to your Apple Account at account.apple.com.
3. In the **Sign-In and Security** section, select **App-Specific Passwords**.
4. Select **Generate an app-specific password**, follow the steps on screen, and copy the password.
iCloud's public documentation does not cover every step.
Source: [support.apple.com](https://support.apple.com/en-us/102654), checked 2026-10-07.
2. On **Compliance › Connectors**, open **iCloud**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads iCloud yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# IDrive (/docs/compliance-connectors/setup/cloud-storage-provider/idrive)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your IDrive connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In IDrive:
1. In IDrive e2, open the **Access Key** tab and click **Create Access Key**.
2. Enter a name, select a region from your enabled regions, and set an expiry date and time.
3. Choose the **Read only** access permission and enable **Allow Listing**.
4. Assign the buckets Safeguard may read (all buckets are selected by default).
5. Click **Create Access Key**, then download or copy and save the generated **Access Key ID** and **Secret Access Key**.
Where to find the other values:
* **Base URL (optional)**: The endpoint URL for each enabled region is shown in the **Enabled regions** section of the **Dashboard** tab.
IDrive's public documentation does not cover every step.
Source: [idrive.com](https://www.idrive.com/s3-storage-e2/faq-access-keys), [idrive.com](https://www.idrive.com/s3-storage-e2/faq), checked 2026-10-07.
2. On **Compliance › Connectors**, open **IDrive**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
IDrive publishes no API for what these tests check, so its evidence is an attestation: connect it to record the connection, then attest the result. An accepted attestation counts toward each control below.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | ----------- | --------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Attestation | `A1.2` | 1 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Attestation | `A.8.13` | 1 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Attestation | `164.308(a)(7)` | 1 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Attestation | `PR.DS-11` | 1 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Cloud Storage Provider connectors (/docs/compliance-connectors/setup/cloud-storage-provider)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Confidentiality of stored data (C1).
Each connector has its own page: the credential to create at the vendor, the permissions it needs, what to enter on **Compliance › Connectors**, and the frameworks it provides evidence for. How connecting works, card statuses and multiple accounts: [Compliance connectors](/docs/compliance-connectors). Every connector in one table: [setup reference](/docs/compliance-connectors/reference).
## Amazon S3
Connect Amazon S3 to collect cloud storage provider evidence automatically.
**Connect with:** API token. [How to connect Amazon S3](/docs/compliance-connectors/setup/cloud-storage-provider/amazon-s3)
## Azure Blob Storage
Record your Azure Blob Storage connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Azure Blob Storage](/docs/compliance-connectors/setup/cloud-storage-provider/azure-blob-storage)
## Backblaze
Connect Backblaze to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token. [How to connect Backblaze](/docs/compliance-connectors/setup/cloud-storage-provider/backblaze)
## Box
Connect Box to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token, MCP server. [How to connect Box](/docs/compliance-connectors/setup/cloud-storage-provider/box)
## Citrix ShareFile
Connect Citrix ShareFile to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token. [How to connect Citrix ShareFile](/docs/compliance-connectors/setup/cloud-storage-provider/citrix-sharefile)
## Dropbox
Connect Dropbox to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token. [How to connect Dropbox](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox)
## Dropbox Sign
Connect Dropbox Sign to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token. [How to connect Dropbox Sign](/docs/compliance-connectors/setup/cloud-storage-provider/dropbox-sign)
## Egnyte
Connect Egnyte to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token, MCP server. [How to connect Egnyte](/docs/compliance-connectors/setup/cloud-storage-provider/egnyte)
## Google Cloud Storage
Connect Google Cloud Storage to collect cloud storage provider evidence automatically.
**Connect with:** OAuth, API token. [How to connect Google Cloud Storage](/docs/compliance-connectors/setup/cloud-storage-provider/google-cloud-storage)
## Google Drive
Connect Google Drive to collect cloud storage provider evidence automatically.
**Connect with:** OAuth, API token, MCP server. [How to connect Google Drive](/docs/compliance-connectors/setup/cloud-storage-provider/google-drive)
## Hack The Box
Record your Hack The Box connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Hack The Box](/docs/compliance-connectors/setup/cloud-storage-provider/hack-the-box)
## iCloud
Record your iCloud connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect iCloud](/docs/compliance-connectors/setup/cloud-storage-provider/icloud)
## IDrive
Record your IDrive connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect IDrive](/docs/compliance-connectors/setup/cloud-storage-provider/idrive)
## MinIO
Connect MinIO to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token. [How to connect MinIO](/docs/compliance-connectors/setup/cloud-storage-provider/minio)
## Nextcloud
Connect Nextcloud to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token. [How to connect Nextcloud](/docs/compliance-connectors/setup/cloud-storage-provider/nextcloud)
## OneDrive
Connect OneDrive to collect cloud storage provider evidence automatically.
**Connect with:** API token. [How to connect OneDrive](/docs/compliance-connectors/setup/cloud-storage-provider/onedrive)
## ownCloud
Connect ownCloud to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token. [How to connect ownCloud](/docs/compliance-connectors/setup/cloud-storage-provider/owncloud)
## pCloud
Record your pCloud connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect pCloud](/docs/compliance-connectors/setup/cloud-storage-provider/pcloud)
## SharePoint
Connect SharePoint to collect cloud storage provider evidence automatically.
**Connect with:** API token. [How to connect SharePoint](/docs/compliance-connectors/setup/cloud-storage-provider/sharepoint)
## Storj
Record your Storj connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
**Connect with:** API token. [How to connect Storj](/docs/compliance-connectors/setup/cloud-storage-provider/storj)
## Wasabi
Connect Wasabi to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
**Connect with:** API token. [How to connect Wasabi](/docs/compliance-connectors/setup/cloud-storage-provider/wasabi)
# MinIO (/docs/compliance-connectors/setup/cloud-storage-provider/minio)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect MinIO to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| MinIO's guide | [min.io](https://min.io/docs/minio/linux/administration/identity-access-management/policy-based-access-control.html) |
## Connect with an API token
1. In MinIO:
1. Write a policy file that allows only the bucket-listing actions Safeguard needs (MinIO policies use AWS IAM syntax).
2. Create the policy: `mc admin policy create ALIAS safeguard-read policy.json`.
3. Create a dedicated user: `mc admin user add ALIAS USERNAME PASSWORD`, and attach the policy: `mc admin policy attach ALIAS safeguard-read --user USERNAME`.
4. Generate an access key for that user: `mc admin accesskey create ALIAS USERNAME` (add `--policy policy.json` to restrict the key further, and `--expiry-duration` if you want it to expire).
5. Copy the access key and secret key from the command output.
Where to find the other values:
* **Server URL**: The https endpoint of your MinIO deployment (the URL your `mc` alias points to).
MinIO's public documentation does not cover every step.
MinIO's docs now redirect to the AIStor documentation; the mc commands are the same. The built-in readonly policy only reads a specific object without listing, so a custom policy is needed for bucket listing. MinIO Console steps were not sourced. The docs do not say whether the secret key is shown only once. Verification removed the action names s3:ListAllMyBuckets and s3:GetBucket\* because the fetched pages do not list them.
Source: [min.io](https://min.io/docs/minio/linux/administration/identity-access-management/policy-based-access-control.html), [docs.min.io](https://docs.min.io/enterprise/aistor-object-store/administration/iam/access/), [docs.min.io](https://docs.min.io/enterprise/aistor-object-store/reference/cli/admin/mc-admin-accesskey/mc-admin-accesskey-create/), checked 2026-10-07.
The permissions Safeguard needs: `s3:ListAllMyBuckets`, `s3:GetBucket*`.
2. On **Compliance › Connectors**, open **MinIO**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ---------- | ------------------------------------------------------------------------ |
| Server URL | Required. Your own server: an https address reachable from the internet. |
| Access key | Required. Stored encrypted and never shown again. |
| Secret key | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read MinIO and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.2`, `CC6.1`, `CC6.6` | 3 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.8.13`, `A.8.20`, `A.8.24` | 3 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(7)`, `164.312(a)(1)`, `164.312(e)(1)` | 3 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `3.5.1` | 2 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.DS-01`, `PR.DS-11`, `PR.IR-01` | 3 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Nextcloud (/docs/compliance-connectors/setup/cloud-storage-provider/nextcloud)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Nextcloud to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Nextcloud's guide | [docs.nextcloud.com](https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/instruction_set_for_users.html) |
## Connect with an API token
1. In Nextcloud:
1. Sign in to Nextcloud.
2. Open your personal settings and go to the **Security** tab.
3. At the bottom of the list of connected browsers and devices, create a new device-specific password.
4. Copy the password immediately: you only have access to it when creating it, because Nextcloud does not save the plain password.
Nextcloud shows the secret only once, so copy it before you leave the page.
Nextcloud's public documentation does not cover every step.
Nextcloud's manual describes the device-specific (app) password in prose and does not quote the name field or create button labels, so they are not given. An app password has the same rights as the account it belongs to. Verification removed the administrator requirement and the Username and Base URL field notes, which the fetched page does not cover.
Source: [docs.nextcloud.com](https://docs.nextcloud.com/server/latest/user_manual/en/session_management.html), checked 2026-10-07.
The permissions Safeguard needs. Nextcloud shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
2. On **Compliance › Connectors**, open **Nextcloud**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------ | ------------------------------------------------------------------------ |
| Base URL | Required. Your own server: an https address reachable from the internet. |
| Username | Required. |
| App password | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Nextcloud and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ---------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.7` | 5 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.14`, `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.3`, `A.8.5` | 5 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(a)(1)`, `164.312(d)` | 5 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01` | 5 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# OneDrive (/docs/compliance-connectors/setup/cloud-storage-provider/onedrive)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect OneDrive to collect cloud storage provider evidence automatically.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated evidence collection |
## Connect with an API token
1. In OneDrive:
1. Sign in to the Microsoft Entra admin center ([https://entra.microsoft.com](https://entra.microsoft.com)) as at least a Cloud Application Administrator.
2. Browse to **Entra ID › App registrations** and select **New registration**. Enter a **Name**, select **Single tenant only - \** and select **Register**.
3. Select **API permissions › Add a permission › Microsoft Graph › Application permissions**, select the read-only permission for the data Safeguard reads, select **Add permissions**, then **Grant admin consent for \**.
4. Select **Certificates & secrets › Client secrets › New client secret**, add a description and expiration, select **Add**, and copy the **Value** (never displayed again).
Where to find the other values:
* **Account / Org / Workspace (optional)**: The app registration's **Overview** page shows the **Application (client) ID**.
OneDrive shows the secret only once, so copy it before you leave the page.
OneDrive's public documentation does not cover every step.
Source: [learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app), [learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/how-to-add-credentials), [learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-configure-app-access-web-apis), [learn.microsoft.com](https://learn.microsoft.com/en-us/graph/api/sharepointsettings-get), checked 2026-10-07.
2. On **Compliance › Connectors**, open **OneDrive**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads OneDrive yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# ownCloud (/docs/compliance-connectors/setup/cloud-storage-provider/owncloud)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect ownCloud to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | --------------------------------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| ownCloud's guide | [doc.owncloud.com](https://doc.owncloud.com/server/11.0/developer_manual/core/apis/provisioning-api.html) |
## Connect with an API token
1. In ownCloud:
1. Sign in to ownCloud as the user Safeguard should connect as (the Provisioning API needs a user with sufficient access rights).
2. Go to **Personal Settings › Security**.
3. In the **App Passwords / Tokens** section, enter an app name in the text field.
4. Click **Create new app passcode**.
5. Copy the username and password / token now: once you click **Done** they are no longer discoverable.
Where to find the other values:
* **Username**: Shown with the new app passcode.
* **Base URL**: The https address of your ownCloud server.
ownCloud shows the secret only once, so copy it before you leave the page.
Steps are for ownCloud Server 11.0 (classic UI). An app passcode has the same rights as the account it belongs to.
Source: [doc.owncloud.com](https://doc.owncloud.com/server/11.0/classic_ui/personal_settings/security.html), [doc.owncloud.com](https://doc.owncloud.com/server/11.0/developer_manual/core/apis/provisioning-api.html), checked 2026-10-07.
The permissions Safeguard needs. ownCloud shows the full user list only to administrators, so this credential must belong to one. Safeguard only reads with it.
2. On **Compliance › Connectors**, open **ownCloud**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------ | ------------------------------------------------------------------------ |
| Base URL | Required. Your own server: an https address reachable from the internet. |
| Username | Required. |
| App password | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read ownCloud and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ---------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# pCloud (/docs/compliance-connectors/setup/cloud-storage-provider/pcloud)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your pCloud connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In pCloud:
1. pCloud documents no settings page for creating an API token. Obtain an auth token through the API: call an authenticated method such as `userinfo` with `getauth=1`, for example `https://api.pcloud.com/userinfo?getauth=1&logout=1` with your `username` and `password` (over SSL) or with digest authentication (`getdigest`, then `username`, `digest` and `passworddigest`).
2. Copy the `auth` value from the response and paste it into Safeguard as the token.
3. Alternatively, obtain a bearer token through OAuth 2.0 (`authorize` then `oauth2_token`) and pass it to API methods as `access_token`.
pCloud issues this credential through its API or its support team, not through its admin screens.
pCloud documents no read-only token scope; an auth token acts as the user. Tokens can be listed with `listtoken` and revoked with `deletetoken`. The API host given in the docs is api.pcloud.com; an EU-region host was not confirmed from a fetched page, so the Base URL location is not documented here.
Source: [docs.pcloud.com](https://docs.pcloud.com/methods/intro/authentication.html), [docs.pcloud.com](https://docs.pcloud.com/methods/oauth_2.0/), checked 2026-10-07.
2. On **Compliance › Connectors**, open **pCloud**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
pCloud publishes no API for what these tests check, so its evidence is an attestation: connect it to record the connection, then attest the result. An accepted attestation counts toward each control below.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | ----------- | ---------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Attestation | `CC6.2`, `CC6.3` | 1 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Attestation | `A.5.18` | 1 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Attestation | `164.308(a)(3)` | 1 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Attestation | `7.2.4` | 1 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Attestation | `PR.AA-05` | 1 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# SharePoint (/docs/compliance-connectors/setup/cloud-storage-provider/sharepoint)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect SharePoint to collect cloud storage provider evidence automatically.
| | |
| -------------------------- | --------------------------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated evidence collection |
| SharePoint's guide | [learn.microsoft.com](https://learn.microsoft.com/en-us/sharepoint/turn-external-sharing-on-or-off) |
## Connect with an API token
1. In SharePoint:
1. Sign in to the Microsoft Entra admin center ([https://entra.microsoft.com](https://entra.microsoft.com)) as at least a Cloud Application Administrator.
2. Browse to **Entra ID › App registrations** and select **New registration**. Enter a **Name**, under **Supported account types** select **Single tenant only - \**, and select **Register**.
3. In the app registration, select **Certificates & secrets › Client secrets › New client secret**. Add a description, select an expiration (24 months at most; Microsoft recommends less than 12), and select **Add**.
4. Copy the client secret **Value**: it is never displayed again after you leave the page.
5. In the app registration, select **API permissions › Add a permission › Microsoft Graph › Application permissions**.
6. Under **Select permissions**, select the permission to grant, then select **Add permissions**.
7. Select **Grant admin consent for \** and confirm.
Where to find the other values:
* **Client ID**: The app registration's **Overview** page shows the **Application (client) ID**.
SharePoint shows the secret only once, so copy it before you leave the page.
SharePoint's public documentation does not cover every step.
SharePointTenantSettings.Read.All is the least-privileged permission for reading SharePoint tenant settings. With delegated access, the signed-in user must be a Global Reader or SharePoint Administrator; the application permission above does not need a signed-in user. Microsoft recommends certificates over client secrets for production. Cloud (optional) is the national cloud: Global, US Government L4/L5 or China (21Vianet), all of which support this API. The Tenant ID label (Directory (tenant) ID) was not quoted on the pages read. Verification: SharePointTenantSettings.Read.All comes from the Graph sharepointsettings-get page, which was not fetched under the three-source limit, so the permission name was removed; the Tenant ID location was not on the pages read and was removed.
Source: [learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app), [learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/how-to-add-credentials), [learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-configure-app-access-web-apis), [learn.microsoft.com](https://learn.microsoft.com/en-us/graph/api/sharepointsettings-get), checked 2026-10-07.
The permissions Safeguard needs: `SharePointTenantSettings.Read.All`, `Global Reader or SharePoint Administrator (signed-in user)`.
2. On **Compliance › Connectors**, open **SharePoint**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ---------------- | ------------------------------------------------- |
| Tenant ID | Required. |
| Client ID | Required. |
| Client secret | Required. Stored encrypted and never shown again. |
| Cloud (optional) | — |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read SharePoint and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | --------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `C1.1`, `CC6.1`, `CC6.7` | 4 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.14`, `A.5.15`, `A.8.3` | 4 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.312(a)(1)` | 2 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-05`, `PR.DS-01` | 4 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Storj (/docs/compliance-connectors/setup/cloud-storage-provider/storj)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Storj connection as cloud storage provider evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Storj:
1. In the Storj console, open **Access Keys** and click **New Access Key**.
2. Enter a **Name** and choose the type: **S3 Credentials** (or **Access Grant**). Click **Next**.
3. Choose **Advanced** rather than **Full Access**, then provide the encryption information.
4. Under permissions select only **Read** and **List**, choose the buckets Safeguard may see, and set an expiration.
5. Click **Create Access**, then write the credentials down or click **Download all** (for an Access Grant, **Download**).
Storj's public documentation does not cover every step.
Storj says API key credentials 'will only appear once'; the S3 credentials section asks you to write them down or download them but does not state the once-only rule in so many words. S3 credentials consist of an access key, secret key and endpoint; where the endpoint label appears was not confirmed. The account/project location was not sourced.
Source: [storj.dev](https://storj.dev/dcs/access), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Storj**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
Storj publishes no API for what these tests check, so its evidence is an attestation: connect it to record the connection, then attest the result. An accepted attestation counts toward each control below.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | ----------- | --------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Attestation | `C1.1`, `CC6.1` | 1 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Attestation | `A.8.3` | 1 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Attestation | `164.312(a)(1)` | 1 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Attestation | `7.2.1` | 1 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Attestation | `PR.DS-01` | 1 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Wasabi (/docs/compliance-connectors/setup/cloud-storage-provider/wasabi)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Wasabi to collect cloud storage provider evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ---------------------------------------------------------------------------------- |
| Category | [Cloud Storage Provider](/docs/compliance-connectors/setup/cloud-storage-provider) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Wasabi's guide | [docs.wasabi.com](https://docs.wasabi.com/docs/bucket-settings) |
## Connect with an API token
1. In Wasabi:
1. In the Wasabi Console, on the policies page click **Create Policy**. Enter a policy name, then in the policy editor enter JSON that allows only `s3:ListAllMyBuckets` and `s3:GetBucket*`. Click **Create Policy** once the console confirms the policy is valid.
2. Click **Users** in the Wasabi menu and select **Create User**. Enable **Programmatic** access, continue through group assignment, and attach your new read-only policy by clicking the **+** next to its name.
3. Click **Access Keys** in the Wasabi menu on the left of the screen, then click **Create Access Key**.
4. Choose **Sub-User**, select the user you just created, and click **Create**.
5. Download the keys as a CSV file or copy them to the clipboard. Paste the Access Key ID into Safeguard's Access key field and the Secret Access Key into its Secret key field.
Wasabi shows the secret only once, so copy it before you leave the page.
Wasabi states the keys cannot be retrieved later if not saved at creation. No built-in read-only policy name was confirmed from the fetched pages, so the steps use a custom policy. A Root User key would have full access; use a Sub-User key with the limited policy.
Source: [docs.wasabi.com](https://docs.wasabi.com/docs/creating-a-new-access-key), [docs.wasabi.com](https://docs.wasabi.com/docs/creating-a-user-account-and-access-key), [docs.wasabi.com](https://docs.wasabi.com/docs/creating-a-policy), checked 2026-10-07.
The permissions Safeguard needs: `s3:ListAllMyBuckets`, `s3:GetBucket*`.
2. On **Compliance › Connectors**, open **Wasabi**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ---------- | ------------------------------------------------- |
| Access key | Required. Stored encrypted and never shown again. |
| Secret key | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Wasabi and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | -------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.2`, `CC6.6` | 3 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.8.13`, `A.8.20` | 3 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(7)`, `164.312(e)(1)` | 3 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1` | 1 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.DS-11`, `PR.IR-01` | 3 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Storage Provider connectors](/docs/compliance-connectors/setup/cloud-storage-provider)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Akamai (/docs/compliance-connectors/setup/cloud-infrastructure/akamai)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Akamai to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ------------------------------------------------------------------------------------- |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Akamai's guide | [techdocs.akamai.com](https://techdocs.akamai.com/iam/docs/two-factor-authentication) |
## Connect with an API token
1. In Akamai:
1. In Akamai Control Center, go to **Identity and Access Management** (**Users and API Clients**).
2. Click **Create API client** and choose to create an advanced client.
3. In the client details, limit the APIs assigned to the client to the ones Safeguard needs and configure read-only permissions for each of them.
4. Click **Create API client**.
5. Under the credentials, click **Download** (an .edgerc file) or **Copy** to get the client token, client secret, access token and host.
Where to find the other values:
* **Host**: The **host** value in the downloaded credentials, for example akab-xxxx.luna.akamaiapis.net.
Akamai's public documentation does not cover every step.
The fetched page confirms the advanced-client flow (customize the assigned APIs and configure read/write permissions per API) but does not name the individual APIs or the exact access-level labels, so check those in the client details screen. Whether the client secret can be viewed again is not stated; download or copy it at creation.
Source: [techdocs.akamai.com](https://techdocs.akamai.com/developer/docs/set-up-authentication-credentials), checked 2026-10-07.
The permissions Safeguard needs: `IAM User Admin: READ-ONLY`, `Application Security: READ-ONLY`, `CPS: READ-ONLY`, `Contract API: READ-ONLY`.
2. On **Compliance › Connectors**, open **Akamai**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------- | ------------------------------------------------- |
| Host | Required. An address under luna.akamaiapis.net. |
| Client token | Required. Stored encrypted and never shown again. |
| Client secret | Required. Stored encrypted and never shown again. |
| Access token | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Akamai and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ----------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7` | 6 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5`, `A.8.20`, `A.8.24` | 6 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)`, `164.312(e)(1)` | 5 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `4.2.1`, `6.4.2`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 6 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-02`, `PR.IR-01` | 6 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Alibaba Cloud (/docs/compliance-connectors/setup/cloud-infrastructure/alibaba-cloud)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Alibaba Cloud to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Alibaba Cloud's guide | [alibabacloud.com](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair) |
## Connect with an API token
1. In Alibaba Cloud:
1. Log on to the RAM console and choose **Identities › Users** in the left-side navigation pane.
2. Find the RAM user Safeguard will use and click its username.
3. On the **Credential** tab, in the **AccessKey** section, click **Create AccessKey**.
4. In the dialog, review the use cases, select one, check **I confirm that it is necessary to create an AccessKey** and click **Continue**.
5. Complete security verification, save the AccessKey ID and AccessKey secret from the dialog (the secret is displayed only once and cannot be retrieved), then click **OK**.
6. In **Identities › Users**, find the same RAM user and click **Attach Policy** in the **Actions** column.
7. In the **Grant Permission** panel, set **Resource scope** to Account level and, under **Permission policy**, select the read-only system policy Safeguard needs.
8. Click **Confirm**, then **Close**.
Where to find the other values:
* **Access key ID**: Shown with the secret in the **Create AccessKey** dialog, and listed in the RAM user's **Credential** tab under **AccessKey**.
Alibaba Cloud shows the secret only once, so copy it before you leave the page.
Alibaba Cloud's public documentation does not cover every step.
Source: [alibabacloud.com](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair), [alibabacloud.com](https://www.alibabacloud.com/help/en/ram/user-guide/grant-permissions-to-the-ram-user), checked 2026-10-07.
The permissions Safeguard needs: `ReadOnlyAccess`.
2. On **Compliance › Connectors**, open **Alibaba Cloud**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------ | ------------------------------------------------- |
| Access key ID | Required. |
| Access key secret | Required. Stored encrypted and never shown again. |
| Region (optional) | — |
| Regions (optional) | — |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Alibaba Cloud and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | --------------------------------------------------------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.2`, `CC6.1`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.2` | 20 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.17`, `A.8.2`, `A.8.5`, `A.8.13`, `A.8.15`, `A.8.20`, `A.8.24` | 20 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 19 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `3.5.1`, `3.7.4`, `4.2.1`, `7.2.2`, `8.3.6`, `8.4.2`, `8.6.3`, `10.2.1` | 19 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.CM-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01` | 20 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Amazon Web Services (/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Amazon Web Services to collect cloud infrastructure evidence automatically.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated evidence collection |
## Connect with an API token
1. In Amazon Web Services:
1. Sign in to the AWS Management Console and open the IAM console (console.aws.amazon.com/iam).
2. In the navigation pane, choose **Users** and choose the user name of a dedicated IAM user for Safeguard.
3. On the **Security credentials** tab, in the **Access keys** section, choose **Create access key**.
4. On the **Access key best practices & alternatives** page, choose **Other** and then choose **Next**.
5. Optionally add a description tag, then select **Create access key**.
6. On the **Retrieve access key** page, choose **Show** to reveal the secret access key, or choose **Download .csv file**. This is your only time to view or download it.
7. In the IAM console navigation pane, choose **Policies**.
8. Select the radio button next to the AWS managed policy **SecurityAudit** (read access to security configuration metadata).
9. Choose **Actions**, then **Attach**, select the Safeguard IAM user and choose **Attach policy**.
Amazon Web Services shows the secret only once, so copy it before you leave the page.
Source: [docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-keys-admin-managed.html), [docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html), [docs.aws.amazon.com](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityAudit.html), [docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Amazon Web Services**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------ | ------------------------------------------------- |
| AWS Access Key ID | Required. Stored encrypted and never shown again. |
| AWS Secret Access Key | Required. Stored encrypted and never shown again. |
| Region | Optional. |
| Session token (optional) | Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Amazon Web Services and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.1`, `A1.2`, `A1.3`, `C1.1`, `CC2.3`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1`, `CC7.2`, `CC7.3`, `CC7.4`, `CC8.1` | 148 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.12`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.24`, `A.5.25`, `A.8.2`, `A.8.3`, `A.8.5`, `A.8.6`, `A.8.8`, `A.8.9`, `A.8.11`, `A.8.12`, `A.8.13`, `A.8.14`, `A.8.15`, `A.8.16`, `A.8.20`, `A.8.24`, `A.8.32` | 148 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(1)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 81 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `3.5.1`, `3.7.4`, `4.2.1`, `6.3.1`, `6.3.3`, `6.4.2`, `6.5.1`, `7.2.1`, `7.2.2`, `8.2.6`, `8.3.6`, `8.4.1`, `8.4.2`, `8.6.3`, `10.2.1`, `10.3.2`, `10.5.1`, `11.3.1`, `11.5.1`, `11.5.2` | 81 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.AE-02`, `DE.CM-01`, `DE.CM-09`, `ID.AM-07`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.IR-03`, `PR.PS-01`, `PR.PS-02`, `PR.PS-04`, `RS.CO-02`, `RS.MA-01` | 148 |
| [CIS AWS Foundations Benchmark](/docs/framework-connectors/cis-aws) | Automated tests | `1.1`, `1.2`, `1.6`, `1.7`, `1.11`, `1.13`, `1.15`, `1.16`, `1.17`, `1.18`, `1.19`, `1.20`, `1.21`, `1.22`, `2.1.1`, `2.1.2`, `2.1.3`, `2.3.2`, `2.4.1`, `3.4`, `3.8`, `3.9`, `4.1`, `4.2`, `4.3`, `4.4`, `4.5`, `4.6`, `4.7`, `4.8`, `4.9`, `4.10`, `4.11`, `4.12`, `4.13`, `4.14`, `4.15`, `4.16`, `5.1`, `5.4`, `5.6` | 41 |
For a CIS benchmark, the numbers are its recommendations.
These tests are switched on per workspace by the Safeguard team.
[Amazon CloudWatch](/docs/compliance-connectors/setup/observability/amazon-cloudwatch), [Amazon S3](/docs/compliance-connectors/setup/cloud-storage-provider/amazon-s3), [AWS CodeCommit](/docs/compliance-connectors/setup/version-control/aws-codecommit), [AWS GovCloud](/docs/compliance-connectors/setup/cloud-infrastructure/aws-govcloud), [AWS Inspector](/docs/compliance-connectors/setup/vulnerability-scanning/aws-inspector), [AWS Security Hub](/docs/compliance-connectors/setup/cspm/aws-security-hub) connect to the same provider as Amazon Web Services, and these tests run for a connection made through any of them.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Aptible (/docs/compliance-connectors/setup/cloud-infrastructure/aptible)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Aptible to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ------------------------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Aptible's guide | [aptible.com](https://www.aptible.com/docs/core-concepts/security-compliance/access-permissions) |
## Connect with an API token
1. In Aptible:
1. SCIM is not enabled by default: reach out to [support@aptible.com](mailto:support@aptible.com) to have SCIM enabled for your organization.
2. Sign in to the Aptible dashboard as an organization owner.
3. Go to **Settings** and select **Provisioning**.
4. Set the **Default Aptible Role** that SCIM-created users receive.
5. Generate the SCIM token and copy it; Aptible displays it only once.
6. Save the configuration.
Aptible shows the secret only once, so copy it before you leave the page.
Source: [aptible.com](https://www.aptible.com/docs/how-to-guides/platform-guides/scim-okta-guide.md), [aptible.com](https://www.aptible.com/docs/core-concepts/security-compliance/authentication/scim.md), checked 2026-10-07.
The permissions Safeguard needs: `SCIM token`. A SCIM token can also create and change users, and Aptible has no read-only one. Safeguard only reads with it.
2. On **Compliance › Connectors**, open **Aptible**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ---------- | ------------------------------------------------- |
| SCIM token | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Aptible and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ------------------------------------ | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.2`, `CC6.3` | 3 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2` | 3 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)` | 3 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `7.2.2`, `7.2.4`, `8.2.5` | 3 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-05` | 3 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# AWS GovCloud (/docs/compliance-connectors/setup/cloud-infrastructure/aws-govcloud)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect AWS GovCloud to collect cloud infrastructure evidence automatically.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated evidence collection |
## Connect with an API token
1. In AWS GovCloud:
1. Sign in to the AWS GovCloud (US) console with an IAM user name and password (GovCloud does not accept standard AWS credentials).
2. Open the IAM console, choose **Users** in the navigation pane and choose the user name of a dedicated IAM user for Safeguard.
3. On the **Security credentials** tab, in the **Access keys** section, choose **Create access key**.
4. On the **Access key best practices & alternatives** page, choose **Other** and then choose **Next**.
5. Optionally add a description tag, then select **Create access key**.
6. On the **Retrieve access key** page, choose **Show** or **Download .csv file**; this is your only time to view the secret.
7. In the IAM console, choose **Policies**, select the AWS managed policy **SecurityAudit**, choose **Actions › Attach**, select the Safeguard user and choose **Attach policy**.
AWS GovCloud shows the secret only once, so copy it before you leave the page.
AWS GovCloud (US) can be accessed only with GovCloud credentials; standard AWS credentials do not work and vice versa. The IAM steps are AWS's standard IAM procedure; the GovCloud Region codes were not quoted on the fetched pages. SecurityAudit grants access to read security configuration metadata.
Source: [docs.aws.amazon.com](https://docs.aws.amazon.com/govcloud-us/latest/UserGuide/govcloud-differences.html), [docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-keys-admin-managed.html), [docs.aws.amazon.com](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html), [docs.aws.amazon.com](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/SecurityAudit.html), checked 2026-10-07.
2. On **Compliance › Connectors**, open **AWS GovCloud**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------ | ------------------------------------------------- |
| AWS Access Key ID | Required. Stored encrypted and never shown again. |
| AWS Secret Access Key | Required. Stored encrypted and never shown again. |
| Region | Optional. |
| Session token (optional) | Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read AWS GovCloud and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.1`, `A1.2`, `A1.3`, `C1.1`, `CC2.3`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1`, `CC7.2`, `CC7.3`, `CC7.4`, `CC8.1` | 148 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.12`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.24`, `A.5.25`, `A.8.2`, `A.8.3`, `A.8.5`, `A.8.6`, `A.8.8`, `A.8.9`, `A.8.11`, `A.8.12`, `A.8.13`, `A.8.14`, `A.8.15`, `A.8.16`, `A.8.20`, `A.8.24`, `A.8.32` | 148 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(1)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 81 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `3.5.1`, `3.7.4`, `4.2.1`, `6.3.1`, `6.3.3`, `6.4.2`, `6.5.1`, `7.2.1`, `7.2.2`, `8.2.6`, `8.3.6`, `8.4.1`, `8.4.2`, `8.6.3`, `10.2.1`, `10.3.2`, `10.5.1`, `11.3.1`, `11.5.1`, `11.5.2` | 81 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.AE-02`, `DE.CM-01`, `DE.CM-09`, `ID.AM-07`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.IR-03`, `PR.PS-01`, `PR.PS-02`, `PR.PS-04`, `RS.CO-02`, `RS.MA-01` | 148 |
| [CIS AWS Foundations Benchmark](/docs/framework-connectors/cis-aws) | Automated tests | `1.1`, `1.2`, `1.6`, `1.7`, `1.11`, `1.13`, `1.15`, `1.16`, `1.17`, `1.18`, `1.19`, `1.20`, `1.21`, `1.22`, `2.1.1`, `2.1.2`, `2.1.3`, `2.3.2`, `2.4.1`, `3.4`, `3.8`, `3.9`, `4.1`, `4.2`, `4.3`, `4.4`, `4.5`, `4.6`, `4.7`, `4.8`, `4.9`, `4.10`, `4.11`, `4.12`, `4.13`, `4.14`, `4.15`, `4.16`, `5.1`, `5.4`, `5.6` | 41 |
For a CIS benchmark, the numbers are its recommendations.
These tests are switched on per workspace by the Safeguard team.
[Amazon CloudWatch](/docs/compliance-connectors/setup/observability/amazon-cloudwatch), [Amazon S3](/docs/compliance-connectors/setup/cloud-storage-provider/amazon-s3), [Amazon Web Services](/docs/compliance-connectors/setup/cloud-infrastructure/amazon-web-services), [AWS CodeCommit](/docs/compliance-connectors/setup/version-control/aws-codecommit), [AWS Inspector](/docs/compliance-connectors/setup/vulnerability-scanning/aws-inspector), [AWS Security Hub](/docs/compliance-connectors/setup/cspm/aws-security-hub) connect to the same provider as AWS GovCloud, and these tests run for a connection made through any of them.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Azure Government (/docs/compliance-connectors/setup/cloud-infrastructure/azure-government)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Azure Government to collect cloud infrastructure evidence automatically.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated evidence collection |
## Connect with an API token
1. In Azure Government:
1. Sign in to the Azure Government portal at portal.azure.us with your Azure Government credentials (the top-left bar shows **Microsoft Azure Government**).
2. Register an app for Safeguard: **Entra ID › App registrations › New registration**, name it, choose **Accounts in this organizational directory only**, and select **Register**.
3. In the app, select **Certificates & secrets › Client secrets › New client secret**, enter a description and duration, select **Add**, and copy the value (shown only once).
4. On the subscription, open **Access control (IAM)** › **Add** › **Add role assignment**. On the **Role** tab select a read-only role (for example Reader) and select **Next**; then on **Members** choose **User, group, or service principal**, **Select members**, find the app, **Select** and **Review + assign**.
Where to find the other values:
* **Account / Org / Workspace (optional)**: The app's overview page in **App registrations** shows the **Directory (tenant) ID** and **Application (client) ID**.
Azure Government shows the secret only once, so copy it before you leave the page.
Azure Government's public documentation does not cover every step.
Source: [learn.microsoft.com](https://learn.microsoft.com/en-us/azure/azure-government/documentation-government-get-started-connect-with-portal), [learn.microsoft.com](https://learn.microsoft.com/en-us/entra/identity-platform/howto-create-service-principal-portal), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Azure Government**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Azure Government and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| --------------------------------------------------------------------------------- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.1`, `A1.2`, `C1.1`, `CC2.3`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC6.8`, `CC7.1`, `CC7.2`, `CC7.3` | 139 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.15`, `A.5.16`, `A.5.17`, `A.5.18`, `A.5.19`, `A.5.24`, `A.6.5`, `A.8.1`, `A.8.2`, `A.8.3`, `A.8.5`, `A.8.6`, `A.8.7`, `A.8.8`, `A.8.9`, `A.8.13`, `A.8.15`, `A.8.16`, `A.8.20`, `A.8.24` | 139 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(1)`, `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(c)(1)`, `164.312(d)`, `164.312(e)(1)` | 134 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `2.2.1`, `3.5.1`, `3.7.4`, `4.2.1`, `5.2.1`, `6.3.3`, `7.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.2.6`, `8.2.8`, `8.4.1`, `8.4.2`, `8.6.3`, `10.2.1`, `10.3.2`, `10.4.1`, `10.5.1`, `11.3.1`, `11.5.1`, `11.5.2` | 127 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.CM-01`, `DE.CM-03`, `DE.CM-09`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.PS-01`, `PR.PS-02`, `PR.PS-04`, `RS.CO-02` | 139 |
| [CIS Microsoft Azure Foundations Benchmark](/docs/framework-connectors/cis-azure) | Automated tests | `2.1.2`, `2.1.9`, `2.1.10`, `2.1.12`, `2.1.13`, `2.1.17`, `2.1.18`, `2.1.19`, `2.1.20`, `2.1.21`, `3.2`, `3.3`, `3.5`, `3.7`, `3.8`, `3.9`, `3.10`, `3.11`, `3.12`, `3.13`, `3.14`, `3.16`, `4.1.1`, `4.1.3`, `4.1.4`, `4.1.6`, `4.2.1`, `4.2.2`, `4.2.3`, `4.2.4`, `4.2.5`, `4.3.1`, `4.3.2`, `4.3.3`, `4.3.4`, `4.3.5`, `4.3.6`, `4.4.1`, `4.4.2`, `4.4.3`, `4.4.4`, `4.5.1`, `4.5.2`, `4.5.3`, `5.1.3`, `5.1.4`, `5.1.5`, `5.1.7`, `5.2.1`, `5.2.2`, `5.2.3`, `5.2.4`, `5.2.5`, `5.2.6`, `5.2.7`, `5.2.8`, `5.2.9`, `5.2.10`, `5.3.1`, `5.5`, `6.3`, `6.5`, `6.6`, `7.1`, `7.2`, `7.3`, `7.4`, `7.9`, `8.1`, `8.2`, `8.3`, `8.4`, `8.5`, `8.6`, `8.7`, `9.1`, `9.2`, `9.3`, `9.4`, `9.5`, `9.6`, `9.7`, `9.8`, `9.9`, `9.10` | 72 |
For a CIS benchmark, the numbers are its recommendations.
These tests are switched on per workspace by the Safeguard team.
[Microsoft Azure](/docs/compliance-connectors/setup/cloud-infrastructure/microsoft-azure), [Microsoft Entra ID](/docs/compliance-connectors/setup/identity-and-sso/microsoft-entra-id) connect to the same provider as Azure Government, and these tests run for a connection made through any of them.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Civo (/docs/compliance-connectors/setup/cloud-infrastructure/civo)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Civo to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Civo's guide | [civo.com](https://www.civo.com/docs/networking/firewalls) |
## Connect with an API token
1. In Civo:
1. In the Civo dashboard, go to the **Profile/Security** section (dashboard.civo.com/security).
2. Copy the API key shown for the account (if your account belongs to an Organization, pick the key tied to the right account).
Source: [civo.com](https://www.civo.com/docs/account/api-keys), checked 2026-10-07.
The permissions Safeguard needs. Civo issues no read-only credential. Safeguard only reads with it, and you can revoke it at any time.
2. On **Compliance › Connectors**, open **Civo**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------ | ------------------------------------------------- |
| API key | Required. Stored encrypted and never shown again. |
| Regions (optional) | — |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Civo and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | --------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.6` | 2 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.8.20` | 2 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.312(e)(1)` | 2 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1` | 2 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.IR-01` | 2 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Cloudflare R2 (/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare-r2)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Cloudflare R2 connection as cloud infrastructure evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Cloudflare R2:
1. In the Cloudflare dashboard, go to the **R2 object storage** page.
2. Under the **Account Details** section, select **Manage** next to **API Tokens**.
3. Choose **Create Account API token** (or **Create User API token**).
4. Under **Permissions**, choose **Admin Read only** (list buckets and view bucket configuration, read and list objects).
5. Create the token and copy the values shown; you will not be able to access the **Secret Access Key** again.
Where to find the other values:
* **Base URL (optional)**: The S3 endpoint is https\://\.r2.cloudflarestorage.com.
* **Account / Org / Workspace (optional)**: Your Cloudflare Account ID: on any domain's **Overview** page, the **API** section shows it, or use the dashboard search › **Copy account ID**.
Cloudflare R2 shows the secret only once, so copy it before you leave the page.
Source: [developers.cloudflare.com](https://developers.cloudflare.com/r2/api/tokens/), [developers.cloudflare.com](https://developers.cloudflare.com/fundamentals/account/find-account-and-zone-ids/), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Cloudflare R2**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Cloudflare R2 yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Cloudflare (/docs/compliance-connectors/setup/cloud-infrastructure/cloudflare)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Cloudflare to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
Step-by-step guide: [Connect Cloudflare](/docs/compliance-connectors/cloudflare).
| | |
| -------------------------- | --------------------------------------------------------------------------------------------------------- |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Cloudflare's guide | [developers.cloudflare.com](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/) |
## Connect with an API token
1. In Cloudflare:
1. In the Cloudflare dashboard, go to **Manage Account › API Tokens** (account token) or **My Profile › API Tokens** (user token).
2. Select **Create Token** and create a custom token.
3. Add these permissions with Read access: **Account Settings Read** (Account), and **Zone Read**, **Zone Settings Read**, **DNS Read** and **Zone WAF Read** (Zone).
4. Under resources, include your account and all zones (or the zones Safeguard should read).
5. Select **Continue to summary**, review, and select **Create Token**.
6. Copy the token secret; it is only shown once.
Where to find the other values:
* **Account ID (optional)**: On any domain's **Overview** page, the **API** section at the bottom shows the Account ID; you can also use the dashboard search (CMD/CTRL + K) › **Copy account ID**, or **Workers & Pages › Account Details**.
Cloudflare shows the secret only once, so copy it before you leave the page.
Cloudflare's public documentation does not cover every step.
Source: [developers.cloudflare.com](https://developers.cloudflare.com/fundamentals/api/get-started/create-token/), [developers.cloudflare.com](https://developers.cloudflare.com/fundamentals/account/find-account-and-zone-ids/), [developers.cloudflare.com](https://developers.cloudflare.com/fundamentals/api/reference/permissions/), checked 2026-10-07.
The permissions Safeguard needs: `Account Settings Read`, `Zone Read`, `Zone Settings Read`, `DNS Read`, `Zone WAF Read`, `Account API Tokens Read`. Optional, read-only: Bot Management Read. The connection does not ask for it by default; without it, the checks that need it show an error naming it.
2. On **Compliance › Connectors**, open **Cloudflare**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| --------------------- | ------------------------------------------------- |
| API token | Required. Stored encrypted and never shown again. |
| Account ID (optional) | — |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Cloudflare and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | -------------------------------------------------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1`, `CC7.2` | 18 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.14`, `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5`, `A.8.9`, `A.8.15`, `A.8.20`, `A.8.24` | 18 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 12 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `4.2.1`, `5.4.1`, `6.4.2`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2`, `8.6.3`, `10.2.1` | 13 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.CM-01`, `DE.CM-09`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-02`, `PR.IR-01` | 16 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Crossplane (/docs/compliance-connectors/setup/cloud-infrastructure/crossplane)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your Crossplane connection as cloud infrastructure evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In Crossplane:
1. If you run Crossplane through Upbound: in the Upbound Console, click your account profile and select **Manage Account**.
2. Choose **API Tokens** from the left menu and click **Create New Token**, then copy the token.
Crossplane's public documentation does not cover every step.
Source: [docs.upbound.io](https://docs.upbound.io/manuals/console/), [docs.crossplane.io](https://docs.crossplane.io/latest/), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Crossplane**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads Crossplane yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# DigitalOcean Spaces (/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean-spaces)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Record your DigitalOcean Spaces connection as cloud infrastructure evidence. Automated collection is not available for this provider yet.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Connection record |
## Connect with an API token
1. In DigitalOcean Spaces:
1. In the DigitalOcean Control Panel left menu, click **Spaces Object Storage**, open the **Access Keys** tab, and click **Create Access Key**.
2. Choose **Limited access**, select the buckets Safeguard should read, and in the **Permissions** dropdown assign **Read**.
3. Create the key, then copy the secret key from the **Access Keys** tab; it appears only once.
DigitalOcean Spaces shows the secret only once, so copy it before you leave the page.
Source: [docs.digitalocean.com](https://docs.digitalocean.com/products/spaces/how-to/manage-access/), checked 2026-10-07.
2. On **Compliance › Connectors**, open **DigitalOcean Spaces**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
No automated compliance test reads DigitalOcean Spaces yet, so no framework lists it. How connectors provide evidence for frameworks: [Frameworks and connectors](/docs/framework-connectors).
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# DigitalOcean (/docs/compliance-connectors/setup/cloud-infrastructure/digitalocean)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect DigitalOcean to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ------------------------------------------------------------------------------------- |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| DigitalOcean's guide | [docs.digitalocean.com](https://docs.digitalocean.com/products/networking/firewalls/) |
## Connect with an API token
1. In DigitalOcean:
1. Log in to the DigitalOcean Control Panel; in the main menu click **Account**, then **API**.
2. On the **Applications & API** page, **Tokens** tab, in the **Personal access tokens** section, click **Generate New Token**.
3. Enter a **Token name** and choose an **Expiration**.
4. Under **Scopes**, select **Read Only** (it grants the api:read alias scope).
5. Generate the token and copy it; for security the secret is only shown once.
DigitalOcean shows the secret only once, so copy it before you leave the page.
The scope options available depend on your team role, and the token's permissions follow later changes the team owner makes to that role. Create the token while the right team is selected.
Source: [docs.digitalocean.com](https://docs.digitalocean.com/reference/api/create-personal-access-token/), checked 2026-10-07.
The permissions Safeguard needs: `*:read`.
2. On **Compliance › Connectors**, open **DigitalOcean**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------ | ------------------------------------------------- |
| Access token | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read DigitalOcean and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ---------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.2`, `CC6.6`, `CC6.7`, `CC7.1`, `CC7.2` | 10 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.8.8`, `A.8.13`, `A.8.16`, `A.8.20`, `A.8.24` | 10 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(7)`, `164.312(e)(1)` | 7 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `4.2.1`, `6.3.3` | 6 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.CM-09`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.PS-02` | 10 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Fastly (/docs/compliance-connectors/setup/cloud-infrastructure/fastly)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Fastly to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ----------------------------------------------------------------------------------------------- |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Fastly's guide | [fastly.com](https://www.fastly.com/documentation/guides/account-info/user-access-and-control/) |
## Connect with an API token
1. In Fastly:
1. As a superuser, go to **Account › API tokens › Personal tokens** (Fastly may ask you to re-authenticate for sudo mode).
2. Click **Create token**.
3. Enter a **Name**, and under **Type** select **Automation token**.
4. Choose a **Role**, and under **Scope** check only **global:read** (read-only access to account information, configuration, and stats).
5. Under **Access**, choose all services (or the ones Safeguard should read) and set the **Expiration**.
6. Click **Create Token** and copy the token string immediately; this is the only time it will be visible.
Fastly shows the secret only once, so copy it before you leave the page.
Only users with the superuser role can create automation tokens. A personal user token with global:read also works but is tied to a person; Fastly documents those separately (Managing personal API tokens). The Role choice for a read-only token was not specified on the page.
Source: [fastly.com](https://www.fastly.com/documentation/guides/account-info/account-management/using-api-tokens/), checked 2026-10-07.
The permissions Safeguard needs: `global:read`.
2. On **Compliance › Connectors**, open **Fastly**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| --------- | ------------------------------------------------- |
| API token | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Fastly and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | --------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.7` | 5 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5`, `A.8.24` | 5 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)`, `164.312(e)(1)` | 5 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `4.2.1`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 5 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-02` | 5 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Fly.io (/docs/compliance-connectors/setup/cloud-infrastructure/fly-io)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Fly.io to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Fly.io's guide | [fly.io](https://fly.io/docs/security/two-factor-authentication/) |
## Connect with an API token
1. In Fly.io:
1. With flyctl signed in to the organization, run `fly tokens create readonly --name "Safeguard" --expiry <duration>` and copy the token it prints.
2. Or, in the Fly.io dashboard, choose the organization from the dropdown, then click **Tokens** to create and manage org tokens.
Where to find the other values:
* **Organization**: The organization's name/slug as shown in the dashboard's organization dropdown.
Fly.io's public documentation does not cover every step.
The read-only org token comes from the flyctl command; the docs did not confirm that the dashboard Tokens page offers a read-only type, nor whether a token is shown only once. If you belong to several orgs, make sure the command targets the right one (the org flag was not covered on the fetched page).
Source: [docs.fly.io](https://docs.fly.io/security/tokens), checked 2026-10-07.
The permissions Safeguard needs: `fly tokens create readonly`.
2. On **Compliance › Connectors**, open **Fly.io**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------ | ------------------------------------------------- |
| Access token | Required. Stored encrypted and never shown again. |
| Organization | Required. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Fly.io and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ---------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.1`, `CC6.2`, `CC6.3` | 4 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5` | 4 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)`, `164.312(d)` | 4 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 4 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-03`, `PR.AA-05` | 4 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# GoDaddy (/docs/compliance-connectors/setup/cloud-infrastructure/godaddy)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect GoDaddy to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| GoDaddy's guide | [developer.godaddy.com](https://developer.godaddy.com/docs/api-users/auth) |
## Connect with an API token
1. In GoDaddy:
1. Recommended: sign in to the GoDaddy developer portal's **Personal Access Token** page.
2. Click **+ Generate Token**.
3. Enter a **Name**, set the **Expiration** (days), and under **Scopes** select only the read access Safeguard needs for domains.
4. Click **Generate Token** and copy it; the token displays once.
5. Alternative (classic key): in your developer account, generate a new key for Production, then copy both the Key and Secret immediately; the Secret is shown once.
GoDaddy shows the secret only once, so copy it before you leave the page.
GoDaddy's public documentation does not cover every step.
Source: [developer.godaddy.com](https://developer.godaddy.com/docs/api-users/auth/how-to), [developer.godaddy.com](https://developer.godaddy.com/docs/api-users/auth), checked 2026-10-07.
The permissions Safeguard needs: `domains.domain:read`. Recommended: a personal access token with only domains.domain:read, created at developer.godaddy.com › Personal Access Tokens; it is read-only. Or a classic API key and secret for the same environment (production or OTE): GoDaddy is retiring those for its Domains API and they carry full account access, though Safeguard only reads with them. Add the customer number to read DNSSEC from GoDaddy; without it, Safeguard checks the public DS record. GoDaddy limits its Domains API to eligible accounts: its documentation asks for at least one domain or a plan that grants management access, and GoDaddy has restricted production access to accounts with 10 or more domains or a Discount Domain Club (Domain Pro) plan. If GoDaddy refuses the account, the tests show an error naming this restriction, never a failure.
2. On **Compliance › Connectors**, open **GoDaddy**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| -------------------------- | ------------------------------------------------- |
| API key | Optional. Stored encrypted and never shown again. |
| API secret | Optional. Stored encrypted and never shown again. |
| Environment (optional) | — |
| Customer number (optional) | For example: 123456789 |
Or, instead: Personal access token.
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read GoDaddy and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | -------------------------------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1` | 11 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.14`, `A.5.15`, `A.5.18`, `A.5.30`, `A.5.34`, `A.8.5`, `A.8.9`, `A.8.20`, `A.8.24` | 11 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.312(d)`, `164.312(e)(1)` | 3 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `5.4.1`, `7.2.4`, `8.4.2` | 3 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.CM-09`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.IR-03` | 11 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Google Cloud Platform (/docs/compliance-connectors/setup/cloud-infrastructure/google-cloud-platform)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Google Cloud Platform to collect cloud infrastructure evidence automatically.
Step-by-step guide: [Connect Google Cloud Platform](/docs/compliance-connectors/google-cloud).
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | OAuth, API token |
| What a connection produces | Automated evidence collection |
## Connect with OAuth
1. On **Compliance › Connectors**, open **Google Cloud Platform**, click **Connect** and choose **OAuth**.
2. Sign in to Google Cloud Platform and approve Safeguard on its consent screen. Use an account that can approve apps for your organization, usually an administrator. Safeguard asks for `https://www.googleapis.com/auth/cloud-platform.read-only`.
3. You return to Safeguard, and the card shows **Verified** once the first check succeeds.
## Connect with an API token
1. In Google Cloud Platform:
1. In the Google Cloud console, go to the **Service accounts** page and select your project.
2. Click the email address of the service account Safeguard will use.
3. Click the **Keys** tab, then the **Add key** drop-down menu, and select **Create new key**.
4. Select **JSON** as the **Key type** and click **Create**; the key file downloads, and you cannot download it again.
5. Paste the full contents of the JSON file into Safeguard.
6. Go to the **IAM** page and select the project (or folder/organization) to audit.
7. Click **Grant Access**, enter the service account's email as the principal.
8. Click **Select a role**, search for the role to grant (Safeguard's form suggests roles/viewer), and click **Save**.
Google Cloud Platform shows the secret only once, so copy it before you leave the page.
Source: [docs.cloud.google.com](https://docs.cloud.google.com/iam/docs/keys-create-delete), [docs.cloud.google.com](https://docs.cloud.google.com/iam/docs/granting-changing-revoking-access), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Google Cloud Platform**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| Service account key (JSON) | Required. Paste the full service-account JSON key. Needs roles/viewer (cloud-platform.read-only). Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Google Cloud Platform and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------------------------------------- | --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.1`, `A1.2`, `C1.1`, `CC2.1`, `CC2.3`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC6.7`, `CC6.8`, `CC7.1`, `CC7.2`, `CC7.3`, `CC8.1` | 114 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.3`, `A.5.9`, `A.5.15`, `A.5.17`, `A.5.18`, `A.5.24`, `A.8.2`, `A.8.3`, `A.8.5`, `A.8.6`, `A.8.8`, `A.8.9`, `A.8.13`, `A.8.14`, `A.8.15`, `A.8.16`, `A.8.20`, `A.8.24`, `A.8.32` | 114 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(1)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(6)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(c)(1)`, `164.312(d)`, `164.312(e)(1)` | 100 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `2.2.1`, `3.5.1`, `3.7.4`, `4.2.1`, `6.3.3`, `6.5.1`, `7.2.1`, `7.2.2`, `8.2.6`, `8.4.2`, `8.6.3`, `10.2.1`, `10.3.2`, `10.4.1`, `10.5.1`, `11.3.1`, `11.5.2` | 100 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.CM-01`, `DE.CM-09`, `ID.AM-02`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.IR-03`, `PR.PS-01`, `PR.PS-02`, `PR.PS-04`, `RS.CO-02` | 112 |
| [CIS Google Cloud Platform Foundations Benchmark](/docs/framework-connectors/cis-gcp) | Automated tests | `1.1`, `1.4`, `1.5`, `1.6`, `1.8`, `1.9`, `1.11`, `1.13`, `1.14`, `1.15`, `1.16`, `2.2`, `2.3`, `2.4`, `2.5`, `2.6`, `2.7`, `2.8`, `2.9`, `2.10`, `2.11`, `2.12`, `2.13`, `2.15`, `2.16`, `3.1`, `3.2`, `3.3`, `3.4`, `3.5`, `3.9`, `4.1`, `4.2`, `4.3`, `4.4`, `4.5`, `4.6`, `4.7`, `4.8`, `4.9`, `4.11`, `6.1.2`, `6.1.3`, `6.2.1`, `6.2.2`, `6.2.3`, `6.2.4`, `6.2.5`, `6.2.6`, `6.2.7`, `6.2.8`, `6.3.1`, `6.3.2`, `6.3.3`, `6.3.4`, `6.3.5`, `6.3.6`, `6.3.7`, `6.4`, `7.1`, `7.3` | 49 |
For a CIS benchmark, the numbers are its recommendations.
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# HashiCorp Consul (/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-consul)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect HashiCorp Consul to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ----------------------------------------------------------------------------------- |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| HashiCorp Consul's guide | [developer.hashicorp.com](https://developer.hashicorp.com/consul/docs/security/acl) |
## Connect with an API token
1. In HashiCorp Consul:
1. With a Consul ACL management token, create a read-only policy: `consul acl policy create -name "safeguard-read" -description "Safeguard read-only" -rules 'agent_prefix "" \{ policy = "read" \}'`.
2. Create a token linked to it: `consul acl token create -description "Safeguard" -policy-name safeguard-read`.
3. Copy the **SecretID** from the output; that is the API token (the AccessorID is only its public identifier).
Where to find the other values:
* **Base URL**: The HTTPS address of your Consul server's HTTP API, reachable from the internet.
HashiCorp Consul issues this credential through its API or its support team, not through its admin screens.
Source: [developer.hashicorp.com](https://developer.hashicorp.com/consul/commands/acl/policy/create), [developer.hashicorp.com](https://developer.hashicorp.com/consul/commands/acl/token/create), [developer.hashicorp.com](https://developer.hashicorp.com/consul/docs/reference/acl/rule), [developer.hashicorp.com](https://developer.hashicorp.com/consul/docs/security/acl), checked 2026-10-07.
The permissions Safeguard needs: `agent:read`.
2. On **Compliance › Connectors**, open **HashiCorp Consul**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| --------- | ------------------------------------------------------------------------ |
| Base URL | Required. Your own server: an https address reachable from the internet. |
| API token | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read HashiCorp Consul and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ---------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.1`, `CC6.6`, `CC6.7` | 2 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.8.9`, `A.8.20`, `A.8.24` | 2 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.312(a)(1)`, `164.312(e)(1)` | 2 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `2.2.1`, `4.2.1` | 2 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-05`, `PR.DS-02`, `PR.PS-01` | 2 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# HashiCorp Nomad (/docs/compliance-connectors/setup/cloud-infrastructure/hashicorp-nomad)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect HashiCorp Nomad to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | -------------------------------------------------------------------------------- |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| HashiCorp Nomad's guide | [developer.hashicorp.com](https://developer.hashicorp.com/nomad/docs/secure/acl) |
## Connect with an API token
1. In HashiCorp Nomad:
1. Write a policy file (for example safeguard.hcl) containing `agent \{ policy = "read" \}`.
2. With a management token, apply it: `nomad acl policy apply -description "Safeguard read-only" safeguard safeguard.hcl`.
3. Create a client token for it: `nomad acl token create -name="safeguard" -policy="safeguard" -type=client`.
4. Copy the **Secret ID** from the output; that is the API token. Store it right away.
Where to find the other values:
* **Base URL**: The HTTPS address of your Nomad server's HTTP API, reachable from the internet.
HashiCorp Nomad issues this credential through its API or its support team, not through its admin screens.
Source: [developer.hashicorp.com](https://developer.hashicorp.com/nomad/docs/secure/acl/policies), [developer.hashicorp.com](https://developer.hashicorp.com/nomad/commands/acl/policy/apply), [developer.hashicorp.com](https://developer.hashicorp.com/nomad/docs/secure/acl/tokens), [developer.hashicorp.com](https://developer.hashicorp.com/nomad/docs/secure/acl), checked 2026-10-07.
The permissions Safeguard needs: `agent:read`.
2. On **Compliance › Connectors**, open **HashiCorp Nomad**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| --------- | ------------------------------------------------------------------------ |
| Base URL | Required. Your own server: an https address reachable from the internet. |
| API token | Required. Stored encrypted and never shown again. |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read HashiCorp Nomad and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ---------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.1`, `CC6.6`, `CC6.7` | 2 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.8.9`, `A.8.20`, `A.8.24` | 2 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.312(a)(1)`, `164.312(e)(1)` | 2 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `2.2.1`, `4.2.1` | 2 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-05`, `PR.DS-02`, `PR.PS-01` | 2 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Heroku (/docs/compliance-connectors/setup/cloud-infrastructure/heroku)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Heroku to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ----------------------------------------------------------------------------------------- |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| Heroku's guide | [devcenter.heroku.com](https://devcenter.heroku.com/articles/multi-factor-authentication) |
## Connect with an API token
1. In Heroku:
1. Install the Heroku CLI and sign in with `heroku login` as a member of the team Safeguard should read.
Heroku's public documentation does not cover every step.
The fetched page covers heroku login and showing the current CLI token with heroku auth:token (a full-account token), but not heroku authorizations:create, token scopes (read, global, identity) or one-time display, so those steps were removed. A sourced least-privilege token path is still missing. Where the dashboard shows team names was not covered.
Source: [devcenter.heroku.com](https://devcenter.heroku.com/articles/authentication), checked 2026-10-07.
The permissions Safeguard needs: `read`.
2. On **Compliance › Connectors**, open **Heroku**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| --------------- | ------------------------------------------------- |
| API key | Required. Stored encrypted and never shown again. |
| Team (optional) | — |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Heroku and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | -------------------------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.2`, `CC6.1`, `CC6.2`, `CC6.3`, `CC6.7`, `CC7.1` | 8 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5`, `A.8.8`, `A.8.13`, `A.8.24` | 8 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(7)`, `164.312(d)`, `164.312(e)(1)` | 7 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `4.2.1`, `6.3.3`, `7.2.2`, `7.2.4`, `8.2.5`, `8.4.2` | 7 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-02`, `PR.DS-11`, `PR.PS-02` | 8 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Hetzner (/docs/compliance-connectors/setup/cloud-infrastructure/hetzner)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect Hetzner to collect cloud infrastructure evidence automatically.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated evidence collection |
## Connect with an API token
1. In Hetzner:
1. In the Hetzner Console, open the project and select **Security** in the left menu bar.
2. Click **API tokens** in the upper menu bar.
3. Choose **Generate API token**.
4. Enter a description and select the **Read** permission (GET requests only).
5. Copy the token now; it is not possible to view it again once the window has been closed.
Hetzner shows the secret only once, so copy it before you leave the page.
Source: [docs.hetzner.com](https://docs.hetzner.com/cloud/api/getting-started/generating-api-token/), checked 2026-10-07.
2. On **Compliance › Connectors**, open **Hetzner**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| ------------------------------------ | ------------------------------------------------- |
| API token / Personal access token | Required. Stored encrypted and never shown again. |
| Base URL (optional) | — |
| Account / Org / Workspace (optional) | — |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read Hetzner and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `A1.2`, `C1.1`, `CC6.1`, `CC6.3`, `CC6.6`, `CC6.7`, `CC7.1`, `CC7.2` | 15 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.17`, `A.8.2`, `A.8.3`, `A.8.5`, `A.8.8`, `A.8.13`, `A.8.15`, `A.8.16`, `A.8.20`, `A.8.24` | 15 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(1)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.308(a)(7)`, `164.312(a)(1)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 15 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `3.5.1`, `3.7.4`, `4.2.1`, `7.2.1`, `7.2.2`, `8.4.2`, `8.6.3`, `10.2.1`, `10.5.1`, `11.3.1` | 13 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.CM-01`, `ID.RA-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.DS-02`, `PR.DS-11`, `PR.IR-01`, `PR.PS-04` | 15 |
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# IBM Cloud (/docs/compliance-connectors/setup/cloud-infrastructure/ibm-cloud)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Connect IBM Cloud to collect cloud infrastructure evidence with automated compliance tests, switched on per workspace.
| | |
| -------------------------- | ------------------------------------------------------------------------------ |
| Category | [Cloud Infrastructure](/docs/compliance-connectors/setup/cloud-infrastructure) |
| Connect with | API token |
| What a connection produces | Automated compliance tests |
| IBM Cloud's guide | [cloud.ibm.com](https://cloud.ibm.com/docs/account?topic=account-manapikey) |
## Connect with an API token
1. In IBM Cloud:
1. In the IBM Cloud console, go to **Manage › Access (IAM)** and select **Service IDs**.
2. (Optional) Select a group from the **Service ID group** menu (the default group is preselected; a service ID cannot be moved to another group later).
3. Click **Create**, enter a name and description for the service ID, and click **Create**.
4. Back on **Service IDs**, click the **Actions** icon for the service ID › **Manage service ID**.
5. Click **API keys**, then click **Create**.
6. Add a name and description for the API key and click **Create**.
7. Save the API key by copying or downloading it to a secure location. It is only available at creation time.
8. In **Manage › Access (IAM) › Service IDs**, click the **Actions** icon for the service ID › **Assign access**.
9. Select a group of services (for account-wide read access, the service group or **All Identity and Access enabled services**) or a single service, then click **Next**.
10. Scope the access to all resources in the account (or to specific resources by attribute) and click **Next**.
11. Select the **Viewer** platform role and the **Reader** service role, then click **Review**.
12. Click **Add** to add the policy to the policy summary, then click **Assign**.
Where to find the other values:
* **Account ID (optional)**: **Manage › Account › Account settings** shows your account ID.
* **Regions (optional)**: Not documented in the IBM pages checked.
IBM Cloud shows the secret only once, so copy it before you leave the page.
Sourced from the Markdown sources of IBM Cloud docs in IBM's official ibm-cloud-docs GitHub organization (cloud.ibm.com/docs returned HTTP 500 earlier). If 'Restrict service ID creation' is enabled in IAM account settings, creating a service ID needs explicit access. Assigning access to a service ID requires the Administrator role on the IAM Identity service or that service ID. IBM notes that without at least Viewer on the resource group, an identity can see but not access resources in it. A user API key (Manage › Access (IAM) › API keys) is an alternative but inherits the user's full access; a service ID key is the least-privilege option. The Regions field has no documented single UI location.
Source: [raw.githubusercontent.com](https://raw.githubusercontent.com/ibm-cloud-docs/iam/master/iam-serviceid.md), [raw.githubusercontent.com](https://raw.githubusercontent.com/ibm-cloud-docs/iam/master/iam-serviceid_keys.md), [raw.githubusercontent.com](https://raw.githubusercontent.com/ibm-cloud-docs/iam/master/iam-mng-access.md), [raw.githubusercontent.com](https://raw.githubusercontent.com/ibm-cloud-docs/account/master/account_settings.md), [cloud.ibm.com](https://cloud.ibm.com/docs/iam?topic=iam-serviceidapikeys), checked 2026-10-07.
The permissions Safeguard needs: `Viewer (platform)`, `Reader (service)`.
2. On **Compliance › Connectors**, open **IBM Cloud**, click **Connect**, choose **API token** and fill in:
| Field | What to enter |
| --------------------- | ------------------------------------------------- |
| API key | Required. Stored encrypted and never shown again. |
| Account ID (optional) | — |
| Regions (optional) | — |
3. Click **Connect with token**.
## Frameworks
Safeguard's automated tests read IBM Cloud and map to the controls below. When a test passes, the result is evidence toward each control it maps to, in every framework listed. It is evidence toward a control, not proof that the control is met on its own.
| Framework | Evidence | Controls | Tests |
| ------------------------------------------------------- | --------------- | ---------------------------------------------------------------------------------------------- | ----- |
| [SOC2](/docs/framework-connectors/soc2) | Automated tests | `CC6.1`, `CC6.2`, `CC6.3`, `CC6.6`, `CC7.2` | 17 |
| [ISO/IEC 27001](/docs/framework-connectors/iso27001) | Automated tests | `A.5.16`, `A.5.17`, `A.5.18`, `A.6.5`, `A.8.2`, `A.8.5`, `A.8.15`, `A.8.20`, `A.8.24` | 17 |
| [HIPAA Security Rule](/docs/framework-connectors/hipaa) | Automated tests | `164.308(a)(3)`, `164.308(a)(4)`, `164.308(a)(5)`, `164.312(b)`, `164.312(d)`, `164.312(e)(1)` | 15 |
| [PCI DSS](/docs/framework-connectors/pci-dss) | Automated tests | `1.3.1`, `3.7.4`, `7.2.2`, `7.2.4`, `8.2.5`, `8.2.8`, `8.4.2`, `8.6.3`, `10.2.1` | 17 |
| [NIST CSF 2.0](/docs/framework-connectors/nist-csf) | Automated tests | `DE.CM-01`, `PR.AA-01`, `PR.AA-03`, `PR.AA-05`, `PR.DS-01`, `PR.IR-01` | 17 |
These tests are switched on per workspace by the Safeguard team.
## Related
* [Cloud Infrastructure connectors](/docs/compliance-connectors/setup/cloud-infrastructure)
* [Compliance connectors](/docs/compliance-connectors): how connecting works, card statuses and multiple accounts
* [Connector setup reference](/docs/compliance-connectors/reference): every connector in one table
* [Frameworks and connectors](/docs/framework-connectors): how connectors provide evidence for frameworks
# Cloud Infrastructure connectors (/docs/compliance-connectors/setup/cloud-infrastructure)
{/* AUTO-GENERATED by scripts/gen-connector-setup.mjs from sg-ui-app lib/compliance. Do not edit by hand: change the app, then run the script. */}
Encryption, logging and configuration of hosting (CC6/CC7/C1).
Each connector has its own page: the credential to create at the vendor, the permissions it needs, what to enter on **Compliance › Connectors**, and the frameworks it provides evidence for. How connecting works, card statuses and multiple accounts: [Compliance connectors](/docs/compl