# Authentication & Getting Started
Source: https://docs.matproof.com/api-reference/authentication

How to authenticate with the Matproof REST API, base URLs, headers, error handling, rate limits, and pagination.

# Authentication & Getting Started

The Matproof REST API exposes everything you can do in the app — manage frameworks, controls, evidence, vendors, risks, findings, people — programmatically. This page covers the basics every API client needs.

## Base URL

```
https://api.matproof.com/v1
```

All endpoints are versioned under `/v1`. Breaking changes will ship under `/v2` — `/v1` stays stable for at least 12 months after a successor version is released.

For local development against a self-hosted Matproof instance, point at your own host (the OpenAPI spec also lists `http://localhost:3333` for the typical dev port).

## Authentication

Every request requires an **API key** sent in the `X-API-Key` header:

```
X-API-Key: mp_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

API keys are scoped to a specific organization and act with the [role](/features/rbac-roles) you assign at creation. Treat them like passwords — never commit them to source control, never expose them client-side.

### Getting an API key

<Steps>
  <Step title="Open Settings → API Keys">
    Only **Owner** and **Admin** roles can create API keys.
  </Step>

  <Step title="Click New API Key">
    * **Name** — describe what this key is for (e.g. "GitHub Actions evidence push")
    * **Acting role** — pick the role this key acts as. Use **Auditor** for read-only integrations
    * **Expires** — optional; recommended for keys with broad access
  </Step>

  <Step title="Copy the key once">
    Matproof shows the key exactly once. Store it in your secrets manager immediately. If you lose it, revoke and create a new one.
  </Step>
</Steps>

### OAuth 2.0, for per-user access

An API key acts as the organization. When you need a request to act as a **person**, with that
person's own permissions, use OAuth 2.0 instead. This is what AI assistants connect with.

The authorization server is `app.matproof.com` and publishes RFC 8414 metadata:

```
https://app.matproof.com/.well-known/oauth-authorization-server
```

The API publishes RFC 9728 protected-resource metadata:

```
https://api.matproof.com/.well-known/oauth-protected-resource
```

Dynamic client registration and PKCE with S256 are supported, so a client can register itself and
complete the flow without a pre-shared secret. Send the resulting token as a bearer token.

Both discovery documents are also reachable through `matproof.com`, which redirects to the host
that owns them.

### MCP server, for AI agents

Matproof runs a hosted [Model Context Protocol](https://modelcontextprotocol.io) server over
Streamable HTTP:

```
https://api.matproof.com/v1/mcp
```

It exposes a small, hand-picked set of tools rather than the REST surface, so a model can hold the
whole set in its head. Connect with an organization API key:

```bash theme={null}
npx mcp-remote https://api.matproof.com/v1/mcp \
  --header "X-API-Key: $MATPROOF_API_KEY"
```

Or with no key at all, over OAuth, in any client that supports custom connectors. The manifest at
[matproof.com/.well-known/mcp.json](https://matproof.com/.well-known/mcp.json) describes the
endpoint, the transport and both auth options.

### Optional: organization scoping

When a single user has access to multiple organizations, set `X-Organization-Id` to scope each request:

```
X-Organization-Id: org_abc123
```

For API keys created within a specific organization, the org is inferred from the key and this header is optional.

## Your first request

```bash theme={null}
curl https://api.matproof.com/v1/people \
  -H "X-API-Key: mp_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
```

Response:

```json theme={null}
{
  "data": [
    { "id": "mem_abc", "name": "Alex Kim", "email": "alex@example.com", "role": "admin" },
    { "id": "mem_def", "name": "Sam Patel", "email": "sam@example.com", "role": "employee" }
  ],
  "meta": { "total": 12, "page": 1, "perPage": 50 }
}
```

## Headers reference

| Header              | Required              | Purpose                                                                                  |
| ------------------- | --------------------- | ---------------------------------------------------------------------------------------- |
| `X-API-Key`         | Always                | Authentication                                                                           |
| `X-Organization-Id` | When ambiguous        | Selects which organization to operate against                                            |
| `Content-Type`      | On `POST` / `PATCH`   | Always `application/json`                                                                |
| `Idempotency-Key`   | Recommended on `POST` | Prevents duplicate writes if the request retries (any unique string per logical request) |

## Pagination

List endpoints return paginated results. Default page size is 50; max is 200.

```bash theme={null}
curl "https://api.matproof.com/v1/people?page=2&perPage=100" \
  -H "X-API-Key: ..."
```

Response includes `meta`:

```json theme={null}
{
  "data": [...],
  "meta": {
    "total": 215,
    "page": 2,
    "perPage": 100,
    "totalPages": 3
  }
}
```

## Error responses

Errors return a standard shape with HTTP status codes:

```json theme={null}
{
  "error": {
    "code": "validation_error",
    "message": "Email already exists for another member of this organization",
    "details": {
      "field": "email",
      "value": "alex@example.com"
    }
  },
  "requestId": "req_xyz789"
}
```

| HTTP  | Code               | When                                                                           |
| ----- | ------------------ | ------------------------------------------------------------------------------ |
| `400` | `validation_error` | Invalid request body or parameters                                             |
| `401` | `unauthorized`     | Missing or invalid API key                                                     |
| `403` | `forbidden`        | API key's role lacks permission for this operation                             |
| `404` | `not_found`        | Resource doesn't exist or isn't visible to your org                            |
| `409` | `conflict`         | Idempotency key reused for a different payload, or unique-constraint violation |
| `429` | `rate_limited`     | Rate limit exceeded — see `Retry-After` header                                 |
| `5xx` | `internal_error`   | Server-side error — safe to retry with same idempotency key                    |

Always log the `requestId` — quote it when contacting support.

## Rate limits

Per-API-key request budgets:

| Plan         | Requests / minute | Burst      |
| ------------ | ----------------- | ---------- |
| Free         | 30                | 60         |
| Starter      | 60                | 120        |
| Professional | 300               | 600        |
| Enterprise   | Negotiated        | Negotiated |

Responses include rate-limit metadata:

```
X-RateLimit-Limit: 300
X-RateLimit-Remaining: 287
X-RateLimit-Reset: 1714828800
```

When you hit the limit, you get `429` with a `Retry-After` header (seconds). Back off and retry.

## Idempotency

For any `POST` that creates a resource, send `Idempotency-Key: <unique-string>`. Matproof remembers the result for 24 hours — retrying with the same key returns the original response without creating a duplicate.

Use a stable, unique string per logical request: a UUID generated by your code, or a deterministic hash of the request payload.

```bash theme={null}
curl -X POST https://api.matproof.com/v1/findings \
  -H "X-API-Key: ..." \
  -H "Idempotency-Key: 9f3a-2b8c-4d12-finding-create" \
  -H "Content-Type: application/json" \
  -d '{ "title": "Vulnerable npm package", "severity": "high" }'
```

## Webhooks

Matproof pushes events to endpoints you configure when:

* A questionnaire is submitted by a vendor
* A control's status changes
* Evidence is about to expire
* A finding is created or its severity changes
* A risk score changes

Configure under **Settings → Webhooks**. Each delivery includes an `X-Matproof-Signature` header (HMAC-SHA256 of the raw body with your webhook secret) — verify it before processing.

## Security best practices

* Store API keys in a secrets manager (AWS Secrets Manager, GCP Secret Manager, HashiCorp Vault, 1Password, Doppler). Never in `.env` files committed to git.
* Issue **one key per integration** — when you decommission an integration, revoke its key
* Use the **Auditor** role for read-only keys (most integrations don't need write)
* Set **expirations** on keys with broad access; rotate before expiry
* Monitor key usage in **Settings → API Keys → \[key] → Usage** and revoke any key not seen in 30 days

## SDKs and codegen

Matproof doesn't ship official SDKs yet. The OpenAPI spec at [openapi.json](https://docs.matproof.com/openapi.json) is OpenAPI 3.0 and works with standard generators:

* `openapi-generator-cli` — official multi-language generator
* `openapi-typescript` — TypeScript types
* `openapi-fetch` — typed fetch wrapper for TS
* `openapi-python-client` — Python client generator

For most use cases, raw HTTP via `fetch` / `requests` / `httpx` is simple enough that an SDK isn't necessary.

## Versioning

* The current major version is **v1**. All paths begin with `/v1/`.
* Backwards-compatible changes (new endpoints, new optional fields, new optional query params) are added to v1 without notice
* Breaking changes ship under `/v2` — v1 is maintained in parallel for at least 12 months
* Subscribe to API changelog notifications under **Settings → API Keys → Subscribe to API changelog**

## What's next

<CardGroup>
  <Card title="Resource Reference" href="/api-reference/resources">
    Catalogue of every resource group — what each covers
  </Card>

  <Card title="Sample: List people" href="/api-reference/people-list">
    A typical list endpoint with full request / response shape
  </Card>
</CardGroup>


# Create a finding
Source: https://docs.matproof.com/api-reference/findings-create

POST /v1/findings
Push a finding from an external scanner, audit, or custom check into Matproof's unified Findings view.

Use this endpoint to push findings from any source that doesn't have a native Matproof integration — a custom security scanner, a CI/CD pipeline check, an internal-audit ticketing system, a manual entry from a board meeting. Pushed findings appear in the unified [Findings](/features/findings) view alongside findings from internal audits, pen-tests, the device agent, and connected integrations.

## Common use cases

* **Custom security scanner** — pipe results from a scanner that isn't on the integrations list (Trivy, Grype, custom SAST)
* **CI/CD pipeline** — fail-the-build checks generate findings that are tracked through to remediation
* **Manual escalation** — issues raised in board / management meetings logged formally
* **Bridging external GRC** — mirror findings from a parent-org GRC tool into a subsidiary's Matproof tenant

## Idempotency

Always send `Idempotency-Key` on `POST /v1/findings` — most use cases retry on transient failure, and you don't want duplicate findings:

```bash theme={null}
curl -X POST https://api.matproof.com/v1/findings \
  -H "X-API-Key: ..." \
  -H "Idempotency-Key: aikido-issue-12345-2026-05-08" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Vulnerable npm package: lodash@4.17.20",
    "severity": "high",
    "source": "external-scanner",
    "description": "CVE-2021-23337 affects production builds. Fix: upgrade to lodash@4.17.21+",
    "linkedControlIds": ["ctrl_iso27001_a8_8"]
  }'
```

The `Idempotency-Key` should encode the originating system's stable identifier — for the Aikido example above, `aikido-issue-{aikido_issue_id}` — so retries always resolve to the same Matproof finding.

## Linked controls

When `linkedControlIds` is provided, the finding immediately appears on those controls' Findings tabs and contributes to the framework's compliance-score calculation. Multiple controls can be linked when a single finding affects multiple frameworks.

## Severity values

`informational` / `low` / `medium` / `high` / `critical`

For external scanners, map their severity scale to Matproof's: most scanners use 0–10 CVSS, where 7+ → `high` and 9+ → `critical`.

## Response

On success, the response includes the created finding's `id`. Store this in your originating system to support future updates (`PATCH /v1/findings/{id}`) — for example, when the underlying scanner reports the issue resolved.


# List people
Source: https://docs.matproof.com/api-reference/people-list

GET /v1/people
Get all members of an organization with their roles and basic profile data.

The list-people endpoint returns every team member visible to your API key's role, with pagination and filtering. It's the canonical example of a Matproof list endpoint — the same conventions (`page` / `perPage` / response shape with `data` and `meta`) apply across every other list endpoint.

## Common use cases

* Pulling the team list to drive your own dashboard or report
* Scripting access reviews against your IdP / HR system
* Detecting drift between Matproof People and an authoritative HR feed (Deel, Workday, BambooHR)

## Pagination

For organizations with more than \~50 members, paginate via `page` and `perPage`:

```bash theme={null}
curl "https://api.matproof.com/v1/people?page=2&perPage=100" \
  -H "X-API-Key: ..."
```

Stop when `meta.page` reaches `meta.totalPages`.

## Filtering by role

To list only Auditors (typically external audit firms), filter via the `role` query parameter:

```bash theme={null}
curl "https://api.matproof.com/v1/people?role=auditor" \
  -H "X-API-Key: ..."
```

Valid role values are the [five built-in roles](/features/rbac-roles): `owner`, `admin`, `auditor`, `employee`, `contractor`.

## Response shape

Every member entry includes the fields needed for access-review evidence: name, email, role, last-login timestamp, and link to any associated devices reported by the [Device Agent](/features/device-agent).

The full schema is rendered in the interactive playground below.


# Resource Reference
Source: https://docs.matproof.com/api-reference/resources

Catalogue of every resource group exposed by the Matproof REST API — what each covers, common operations, and sample endpoints.

# Resource Reference

The Matproof API exposes **182 endpoints across 39 resource groups**. This page is a category-organised index of those resources so you can find what you need quickly. For full request/response schemas of any endpoint, the OpenAPI spec is at [`openapi.json`](/openapi.json) and renders as an interactive playground in the API tab.

## Compliance program

| Resource              | Operations                                                 | Purpose                                                                      |
| --------------------- | ---------------------------------------------------------- | ---------------------------------------------------------------------------- |
| **Organization**      | get, update, transfer ownership, branding                  | Your organization's settings, primary color, logo                            |
| **People**            | list, get, create, bulk-create, update, link/unlink device | Team-member directory feeding access reviews and offboarding                 |
| **Policies**          | list, get, create, update, publish, acknowledge            | Policy library — generated, customized, published, acknowledged              |
| **Risks**             | list, get, create, update, archive                         | Risk register with likelihood / impact / treatment / linked controls         |
| **Findings**          | list, get, create, update, close                           | Unified gaps view — feeds from audits, pen-tests, device agent, integrations |
| **Finding Templates** | list, get, create, update, delete                          | Reusable finding patterns for common gaps                                    |

## Frameworks & SOA

| Resource                             | Operations                                                             | Purpose                                                                     |
| ------------------------------------ | ---------------------------------------------------------------------- | --------------------------------------------------------------------------- |
| **SOA** (Statement of Applicability) | list, get, mark applicable / not-applicable, justify exclusion, export | ISO 27001 SoA workflow                                                      |
| **Framework Editor Task Templates**  | list, get, create, update                                              | Tasks attached to custom-framework controls                                 |
| **Context**                          | get, update, list snapshots                                            | Organization-wide context the AI uses for policy / questionnaire generation |

## Evidence & tasks

| Resource                      | Operations                                           | Purpose                                                      |
| ----------------------------- | ---------------------------------------------------- | ------------------------------------------------------------ |
| **Tasks**                     | list, get, create, update, complete, attach evidence | Tasks linked to controls that produce evidence on completion |
| **Task Management**           | bulk operations, scheduling, reassignment            | Tasks at scale                                               |
| **Task Automations**          | list, run, schedule, log                             | Recurring tasks driven by automation scripts                 |
| **Task Integrations**         | configure per-task integration triggers              | Cross-tool orchestration                                     |
| **Comments**                  | list, create, update, delete                         | Comments on controls, tasks, evidence                        |
| **Attachments**               | upload                                               | File uploads attached to evidence or comments                |
| **Evidence Export**           | export                                               | Compile evidence packages for audits                         |
| **Evidence Export (Auditor)** | auditor-restricted export                            | Same export with auditor-role scoping                        |

## Integrations & sync

| Resource              | Operations                                        | Purpose                                                                                                    |
| --------------------- | ------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| **Connections**       | list, create, update, delete, refresh credentials | Connect AWS / Azure / GCP / GitHub / Google Workspace / Entra ID / etc.                                    |
| **Sync**              | trigger sync, list sync runs, view results        | Run an integration sync on demand                                                                          |
| **AdminIntegrations** | platform-admin operations on integrations         | Internal admin tooling                                                                                     |
| **TaskIntegrations**  | per-task integration bindings                     | Bind specific tasks to specific integrations                                                               |
| **Variables**         | list, create, update, delete                      | Org-level variables (e.g. business names, regulator addresses) referenced from policies and questionnaires |
| **Checks**            | list, get, run, view history                      | Cloud-test checks (continuous configuration validation)                                                    |

## Vendor risk & questionnaires

| Resource               | Operations                                       | Purpose                                                |
| ---------------------- | ------------------------------------------------ | ------------------------------------------------------ |
| **Vendors**            | list, get, create, update, archive               | Vendor register feeding GDPR Art. 28 + DORA Art. 28-30 |
| **Internal - Vendors** | platform-admin operations                        | Internal vendor management                             |
| **Questionnaire**      | list, get, create, send, fill, auto-fill, export | AI-powered questionnaires (incoming and outgoing)      |
| **Knowledge Base**     | list, get, create, update, delete, search        | Saved Q\&A pairs that auto-fill draws from             |

## Trust & sharing

| Resource         | Operations                                                            | Purpose                                               |
| ---------------- | --------------------------------------------------------------------- | ----------------------------------------------------- |
| **Trust Portal** | get/update settings, manage published documents, list NDA signatories | Public security portal you share with prospects       |
| **Trust Access** | list, create, get access decisions, NDA-gate documents                | Granular access control for sensitive trust documents |

## Security testing

| Resource                       | Operations                                          | Purpose                                                      |
| ------------------------------ | --------------------------------------------------- | ------------------------------------------------------------ |
| **Security Penetration Tests** | create test, get status, list runs, download report | AI-powered external pen-test reports                         |
| **Browserbase**                | session management, browser automation              | Headless-browser evidence capture (used internally by tasks) |

## Devices & endpoints

| Resource         | Operations                          | Purpose                                                                 |
| ---------------- | ----------------------------------- | ----------------------------------------------------------------------- |
| **Devices**      | list, get                           | Devices reported by the [Matproof Device Agent](/features/device-agent) |
| **Device Agent** | check-in (used by the agent itself) | Agent-to-platform reporting endpoints                                   |

## Training & awareness

| Resource     | Operations       | Purpose                              |
| ------------ | ---------------- | ------------------------------------ |
| **Training** | assign, complete | Security awareness training tracking |

## OAuth (for building Matproof-integrated apps)

| Resource      | Operations                | Purpose                                                                   |
| ------------- | ------------------------- | ------------------------------------------------------------------------- |
| **OAuth**     | authorize, token, refresh | OAuth 2.0 flow for third-party apps that act on behalf of a Matproof user |
| **OAuthApps** | register, list, manage    | Manage your registered OAuth applications                                 |

## AI assistant

| Resource           | Operations                               | Purpose                                        |
| ------------------ | ---------------------------------------- | ---------------------------------------------- |
| **Assistant Chat** | start session, send message, end session | Programmatic access to the in-app AI assistant |

## Operational

| Resource          | Operations                            | Purpose                                               |
| ----------------- | ------------------------------------- | ----------------------------------------------------- |
| **Webhook**       | configure, list deliveries, redeliver | Webhook subscription management                       |
| **Health**        | health check                          | API health endpoint for status pages                  |
| **CloudSecurity** | get cloud-security state              | Aggregated cloud-security findings across connections |

***

## Sample endpoints

The pages below are concrete walkthroughs of typical endpoints — request shape, response shape, common errors. They use Mintlify's OpenAPI integration to render the interactive playground inline.

<CardGroup>
  <Card title="People — list" href="/api-reference/people-list">
    GET /v1/people — typical list endpoint with pagination
  </Card>

  <Card title="Findings — create" href="/api-reference/findings-create">
    POST /v1/findings — typical create endpoint with idempotency
  </Card>

  <Card title="Vendors — list" href="/api-reference/vendors-list">
    GET /v1/vendors — list with filters and DPA fields
  </Card>
</CardGroup>

For everything else, browse the interactive playground at [openapi.json](/openapi.json) — every endpoint is documented with full request and response schemas, parameter descriptions, and a try-it-now button.

## Adding more endpoint pages

Want a hand-written page for a specific endpoint? Create an MDX file under `api-reference/` with frontmatter pointing to the operation:

```yaml theme={null}
---
title: "Create vendor"
openapi: "POST /v1/vendors"
---
```

Mintlify renders the operation's full schema, parameters, request body, and response — and you can add prose above and below for context, code samples, and gotchas specific to your use case.


# List vendors
Source: https://docs.matproof.com/api-reference/vendors-list

GET /v1/vendors
Retrieve the full vendor register including criticality, DPA status, and DORA Article 28 fields.

The list-vendors endpoint returns your full vendor register — feeding GDPR Article 28 transparency, DORA Article 28-30 ICT third-party risk, and ISO 27001 A.5.19 supplier inventory. Use it to drive procurement-side dashboards, due-diligence reports, or to mirror the register into a parent organization's GRC tool.

## Common use cases

* **Article 28 register export** — pull the full register for GDPR DPA submissions
* **DORA Register of Information (ROI)** — feed the ESAs' XLSX submission format
* **Concentration risk analysis** — pipe the data into a custom analysis (e.g. counting how many critical functions depend on a single hyperscaler)
* **Procurement integration** — sync vendor records bidirectionally with Coupa / Ariba / etc.

## Filtering

Common filters:

| Query parameter         | Values                                | Use                               |
| ----------------------- | ------------------------------------- | --------------------------------- |
| `criticality`           | `critical` / `important` / `standard` | DORA-style criticality slicing    |
| `processesPersonalData` | `true` / `false`                      | GDPR Art. 28 register subset      |
| `ictService`            | `true` / `false`                      | DORA Art. 28 ICT-vendor subset    |
| `category`              | freeform string                       | Industry / category match         |
| `country`               | ISO 3166-1 alpha-2                    | Filter by country of registration |

Combine filters to slice the register narrowly:

```bash theme={null}
# Critical ICT vendors that process personal data
curl "https://api.matproof.com/v1/vendors?criticality=critical&ictService=true&processesPersonalData=true" \
  -H "X-API-Key: ..."
```

## Pagination

Default `perPage` is 50, max 200. For organizations with hundreds of vendors, paginate with `page` and stop when `meta.page === meta.totalPages`.

## DPA status

Each vendor record includes `dpaStatus`: `signed` / `pending` / `not_required`. Filter by `dpaStatus=pending` to surface vendors still missing DPAs — useful for an end-of-quarter DPA cleanup sweep.

## Sub-processors

Sub-processors of each vendor (when collected via the [Article 28 questionnaire](/features/questionnaire-ai)) are returned in the `subProcessors` array. Each sub-processor entry includes name, country, and processing-purpose category.

## Response shape

The interactive playground below renders the full schema. The fields most often consumed by external systems are:

* `id`, `name`, `country`, `category`
* `criticality`, `ictService`, `processesPersonalData`
* `dpaStatus`, `dpaSignedAt`, `dpaUrl`
* `lastReviewedAt`, `nextReviewDue`
* `subProcessors[]` — sub-processor disclosures
* `transferMechanism` — for non-EU vendors handling personal data

For DORA Register of Information submissions, the dedicated **Export → DORA ROI** action in the Matproof UI produces the structured XLSX format ESAs accept — typically more direct than building it from this API yourself.


# Changelog
Source: https://docs.matproof.com/changelog/overview

What's new in Matproof.

## February 2026

### CSRD Supply Chain Module (v1.0)

* **New:** Full CSRD supply chain reporting module
* **New:** Double materiality assessment workflow with stakeholder survey
* **New:** Supplier ESG questionnaire portal (6 languages: EN, DE, FR, ES, IT, NL)
* **New:** Scope 3 GHG calculations (spend-based, activity-based, supplier-specific)
* **New:** ESRS data point mapping view
* **New:** Sanctions screening for all vendors (EU, UN, OFAC lists)
* **Improved:** Vendor risk module — new DORA TPRM classification fields

### Platform improvements

* **New:** XBRL tagging export (preview) — machine-readable ESRS data
* **Improved:** AI policy drafting — now supports sustainability policies (ESRS G1, E1)
* **Fixed:** Evidence expiry notifications were not sending for some users

***

## January 2026

### DORA compliance updates

* **Updated:** DORA Art. 28 register template updated for 2026 RTS requirements
* **New:** ICT concentration risk reporting view
* **Improved:** Sub-processor tracking in vendor module

### ISO 27001:2022

* **New:** Annex A 2022 controls mapping (updated from 2013 version)
* **Improved:** Evidence collection for A.5.23 (Information security for cloud services)

***

## December 2025

### Integrations

* **New:** AWS integration — IAM, CloudTrail, S3 encryption evidence
* **New:** Azure AD integration — conditional access, MFA enforcement evidence
* **Improved:** GitHub integration — now collects Dependabot alerts as vulnerability evidence

### General

* **New:** Evidence bulk upload tool
* **New:** Risk register export (Excel, PDF, JSON)
* **Fixed:** Cross-framework control mapping wasn't showing all linked controls


# Core Concepts
Source: https://docs.matproof.com/concepts

Understand how Matproof structures compliance programs before diving into the features.

## Frameworks

A **framework** is a compliance standard or regulation (e.g., DORA, ISO 27001, CSRD). Each framework has a set of **requirements** broken into **controls**.

Matproof maps controls across frameworks automatically — so evidence you collect for ISO 27001 often satisfies overlapping DORA requirements.

## Controls

A **control** is a specific requirement within a framework. For example:

* "Implement multi-factor authentication for all user accounts" (ISO 27001 A.9.4)
* "Maintain a register of all ICT third-party service providers" (DORA Art. 28)

Controls have a **status**:

| Status         | Meaning                              |
| -------------- | ------------------------------------ |
| ✅ Met          | Evidence collected and approved      |
| ⚠️ Partial     | Some evidence collected, gaps remain |
| ❌ Not met      | No evidence collected                |
| 🔄 In progress | Remediation underway                 |

## Evidence

**Evidence** is documentation that proves a control is met. It can be:

* **Automated** — pulled from connected integrations (e.g., GitHub access logs)
* **Manual** — uploaded documents (policies, screenshots, reports)
* **AI-generated** — policies and procedures created by Matproof

Evidence has an expiry date. Matproof alerts you when evidence is stale.

## Policies

**Policies** are formal documents that define how your organization operates. Matproof generates AI-drafted policies pre-mapped to your frameworks:

* Acceptable Use Policy
* Information Security Policy
* Incident Response Plan
* Business Continuity Plan
* Data Protection Policy
* Vendor Management Policy

Policies are version-controlled. You can edit them, publish new versions, and track acknowledgements.

## Vendors / Third Parties

In compliance context, **vendors** are organizations that process data or provide ICT services on your behalf. Matproof helps you:

* Maintain an Art. 28 register (GDPR) and TPRM register (DORA)
* Send risk questionnaires and collect responses
* Screen against sanctions lists
* Monitor criticality classifications

## Risk Register

The **risk register** contains identified risks to your organization. Each risk has:

* **Likelihood** and **impact** scores
* **Owner** (accountable person)
* **Treatment** (accept, mitigate, transfer, avoid)
* **Linked controls** — what controls reduce this risk

## CSRD / ESG Data

For CSRD, Matproof introduces the concept of **ESG topics** and **materiality**:

* **Double materiality** — assessing both financial impact on your company AND your company's impact on society/environment
* **ESRS standards** — the EU reporting standards (E1-E5, S1-S4, G1) that define what to disclose
* **Value chain data** — ESG metrics collected from your supplier base

See the [CSRD module docs](/csrd/overview) for details.


# Double Materiality Assessment
Source: https://docs.matproof.com/csrd/double-materiality

How to complete your ESRS double materiality assessment in Matproof.

## What is double materiality?

CSRD requires a **double materiality assessment (DMA)** — the process of identifying which sustainability topics are material from two perspectives:

1. **Impact materiality** — How does your company affect people and the environment? (e.g., your Scope 1/2/3 emissions, labor practices in your supply chain)
2. **Financial materiality** — How do sustainability topics affect your company's financial performance? (e.g., climate risks to your assets, regulatory costs)

A topic is material if it meets either threshold — you only need to report on material topics.

## Running a DMA in Matproof

### Step 1: Stakeholder input

Navigate to **CSRD → Double Materiality → Stakeholder Survey**.

Invite internal and external stakeholders to rate sustainability topics by:

* Severity of impact (scale, scope, irremediability)
* Likelihood of occurrence
* Financial significance

Matproof sends a survey link and aggregates responses automatically.

### Step 2: IRO identification

**IROs** = Impacts, Risks, and Opportunities.

For each ESRS topic, Matproof helps you identify and document:

* **Impacts** — actual or potential effects on people/environment
* **Risks** — sustainability-related financial risks
* **Opportunities** — positive financial effects from sustainability actions

Use the IRO matrix in the platform to rate severity and likelihood.

### Step 3: Materiality scoring

Matproof calculates a materiality score for each topic based on:

```
Impact materiality = Severity × Likelihood
Financial materiality = Magnitude × Likelihood × Time horizon
```

Topics scoring above your threshold are marked **material**.

### Step 4: Materiality statement

Once complete, export your **materiality statement** — a required disclosure for CSRD reporters explaining your assessment process and conclusions.

## Which ESRS topics to assess

You must assess all ESRS topics:

| Topic                             | Standard |
| --------------------------------- | -------- |
| Climate change                    | E1       |
| Pollution                         | E2       |
| Water and marine resources        | E3       |
| Biodiversity and ecosystems       | E4       |
| Resource use and circular economy | E5       |
| Own workforce                     | S1       |
| Workers in value chain            | S2       |
| Affected communities              | S3       |
| Consumers and end-users           | S4       |
| Business conduct                  | G1       |

## Tips

<Tip>
  For your first DMA, focus on getting stakeholder input from at least 3-5 internal functions (finance, operations, procurement, legal) plus 2-3 external stakeholders (major customers, suppliers, or NGOs).
</Tip>

<Warning>
  The DMA must be reviewed annually. Material topics can change as your business and external environment evolve.
</Warning>


# ESRS Data Point Mapping
Source: https://docs.matproof.com/csrd/esrs-mapping

See which ESRS disclosure requirements you've covered and what's missing.

## What is ESRS mapping?

The **ESRS mapping view** shows you a complete picture of your CSRD reporting progress — which data points you've collected, which are missing, and what's needed to fill the gaps.

## Navigating the mapping view

Go to **CSRD → ESRS Mapping** to see the full compliance matrix.

Each row represents an **ESRS data point** (a specific metric or disclosure). Columns show:

| Column     | Description                                 |
| ---------- | ------------------------------------------- |
| Standard   | Which ESRS standard (E1, E2, S2, etc.)      |
| Data point | The specific disclosure requirement         |
| Material   | Whether this applies to you (from your DMA) |
| Status     | Collected / Partial / Missing               |
| Source     | Where the data came from                    |
| Value      | The actual data point value                 |

## Filtering

Filter by:

* **Standard** — view only E1, only S2, etc.
* **Status** — see only missing data points
* **Material** — hide non-material topics
* **Mandatory vs. voluntary** — focus on must-have disclosures first

## Data point statuses

| Status         | Meaning                             |
| -------------- | ----------------------------------- |
| ✅ Collected    | Data available and validated        |
| ⚠️ Partial     | Some data collected, not complete   |
| ❌ Missing      | Required data not yet collected     |
| ➖ Not material | Excluded from your report (per DMA) |
| 🔄 Pending     | Awaiting supplier response          |

## Exporting for your report

Once you've collected sufficient data, export your ESRS data in:

* **Excel** — pre-formatted ESRS disclosure table
* **JSON** — for integration with your existing reporting tool
* **PDF** — human-readable summary

The export includes:

* Quantitative disclosures (numbers, percentages, emissions)
* Qualitative disclosures (policy descriptions, governance info)
* Data quality notes (calculation method, estimation flags)
* Sources and assumptions

## Common gaps

The most commonly missing data points for first-time reporters:

1. **Scope 3 Category 1** (purchased goods) — needs supplier activity data
2. **ESRS S2** (value chain workers) — needs supplier labour practice questionnaire
3. **ESRS E2** (pollution) — needs hazardous substance data from suppliers
4. **IRO documentation** — needs completed DMA with documented IROs
5. **Policies** — needs written sustainability policies per material topic

Matproof highlights your top 5 gaps and suggests how to fill them.


# CSRD Module Overview
Source: https://docs.matproof.com/csrd/overview

Collect ESG data from your entire supplier base and generate ESRS-compliant reports.

## What is the CSRD module?

The **CSRD supply chain module** helps companies subject to the Corporate Sustainability Reporting Directive (CSRD) collect the ESG data they need from their supplier base.

Under CSRD, large companies must report on sustainability impacts across their **entire value chain** — including upstream suppliers. This means requesting specific data from potentially hundreds of vendors.

Matproof automates this process end-to-end.

## Who needs this?

You need the CSRD module if:

* Your company is subject to CSRD reporting (>500 employees, or large EU-listed company)
* You need Scope 3 emissions data from suppliers (ESRS E1-6)
* You're preparing a **double materiality assessment** (required for all CSRD reporters)
* You're a supplier receiving ESG questionnaires from corporate customers

<Note>
  **Not sure if you're in scope?** Check our [CSRD scope guide](/csrd/reporting) or use the CSRD readiness checker in the platform.
</Note>

## Key capabilities

<CardGroup>
  <Card title="Double Materiality" icon="scale-balanced" href="/csrd/double-materiality">
    Assess both impact and financial materiality across all ESRS topics to determine what you must report on.
  </Card>

  <Card title="Supplier Questionnaires" icon="clipboard-list" href="/csrd/supplier-questionnaires">
    Send automated ESG questionnaires to suppliers. They respond via a simple portal — no Matproof account needed.
  </Card>

  <Card title="Scope 3 Calculations" icon="calculator" href="/csrd/scope3-calculations">
    Collect activity data from suppliers and calculate Scope 3 GHG emissions across all 15 categories.
  </Card>

  <Card title="ESRS Mapping" icon="map" href="/csrd/esrs-mapping">
    See exactly which ESRS data points you've covered and what's still missing for your report.
  </Card>
</CardGroup>

## ESRS Standards Covered

| Standard | Topic                             | Module Support |
| -------- | --------------------------------- | -------------- |
| ESRS E1  | Climate change (incl. Scope 3)    | Full           |
| ESRS E2  | Pollution                         | Full           |
| ESRS E3  | Water and marine resources        | Full           |
| ESRS E4  | Biodiversity and ecosystems       | Partial        |
| ESRS E5  | Resource use and circular economy | Full           |
| ESRS S2  | Workers in the value chain        | Full           |
| ESRS G1  | Business conduct                  | Full           |

## Workflow

```
1. Double Materiality Assessment
   → Identify which ESRS topics are material to your business

2. Supplier Mapping
   → Upload your supplier list and categorize by spend/risk

3. Questionnaire Dispatch
   → Auto-generate ESRS-aligned questionnaires and send to suppliers

4. Data Collection
   → Suppliers respond via portal; data is validated automatically

5. Scope 3 Calculation
   → Matproof calculates emissions from supplier activity data

6. ESRS Report Generation
   → Export report-ready data points mapped to ESRS disclosure requirements
```

## Reporting timelines

| Company type                | First reporting year | Report due |
| --------------------------- | -------------------- | ---------- |
| Large PIEs (>500 employees) | FY 2024              | 2025       |
| Other large companies       | FY 2025              | 2026       |
| Listed SMEs                 | FY 2026              | 2027       |
| Non-EU subsidiaries         | FY 2028              | 2029       |


# CSRD Reporting
Source: https://docs.matproof.com/csrd/reporting

Who must report, when, and how Matproof helps you prepare your CSRD report.

## Who must report under CSRD?

CSRD applies in phases:

| Company type          | Criteria                                            | First reporting year     |
| --------------------- | --------------------------------------------------- | ------------------------ |
| Large PIEs            | >500 employees AND listed, bank, or insurer         | FY 2024 (report in 2025) |
| Other large companies | 2 of 3: >250 employees, >€40M revenue, >€20M assets | FY 2025 (report in 2026) |
| Listed SMEs           | Listed on EU regulated market                       | FY 2026 (report in 2027) |
| Non-EU subsidiaries   | EU subsidiary of non-EU parent >€150M EU revenue    | FY 2028 (report in 2029) |

<Note>
  The 2026 EU omnibus proposal suggested simplifications to CSRD. Matproof tracks regulatory developments and updates templates accordingly. Check the [changelog](/changelog/overview) for the latest updates.
</Note>

## What to include in your CSRD report

A CSRD report must include:

### General disclosures (ESRS 2)

* Governance: Board oversight of sustainability
* Strategy: Business model and sustainability strategy
* Materiality: Double materiality assessment process and results
* Metrics and targets: How you measure progress

### Topic-specific disclosures

For each material ESRS topic:

* **Policies** — what policies govern this topic
* **Actions and targets** — what you're doing to address it
* **Metrics** — quantitative data points
* **Risks and opportunities** — financial implications

### Value chain information

For material upstream/downstream topics, you must disclose information about your value chain — including data collected from suppliers.

## Report format

CSRD reports must be:

* Included in the **management report** (not a standalone document)
* Tagged with **ESRS XBRL taxonomy** (machine-readable format required from 2026)
* Subject to **limited assurance** (reasonable assurance from 2028)

Matproof exports:

* ESRS data in Excel/JSON format for inclusion in your report
* XBRL tagging assistance (coming Q3 2025)
* Assurance-ready audit trail with data sources and methodology

## Assurance requirements

| Period    | Assurance level      |
| --------- | -------------------- |
| 2025-2027 | Limited assurance    |
| 2028+     | Reasonable assurance |

Limited assurance means your auditor checks that nothing has come to their attention that would indicate the information is misstated. Matproof's audit trail (sources, calculations, methodology) is designed to support this process.

## Preparing your report in Matproof

1. **Complete your DMA** — determine which topics are material
2. **Collect data** — supplier questionnaires, internal data, evidence
3. **Review ESRS mapping** — fill gaps in required data points
4. **Draft disclosures** — use Matproof's AI drafting tool for qualitative sections
5. **Export** — download ESRS data table for your report writer
6. **Assurance prep** — share the audit trail package with your auditor

## Value chain reporting

For Scope 3 and other value chain data, CSRD allows "reasonable effort" in data collection — you don't need 100% supplier response rates.

Best practice:

* Aim for coverage of **>80% of spend** for Category 1 Scope 3
* Use estimation for small/long-tail suppliers (Matproof handles this with spend-based method)
* Document your methodology and coverage rates (required disclosure)


# Scope 3 GHG Calculations
Source: https://docs.matproof.com/csrd/scope3-calculations

How Matproof calculates Scope 3 greenhouse gas emissions from supplier data.

## What is Scope 3?

Scope 3 emissions are **indirect GHG emissions** that occur in a company's value chain — both upstream (suppliers) and downstream (customers, product use, end-of-life).

Under **ESRS E1-6**, CSRD reporters must disclose Scope 3 emissions across all relevant GHG Protocol categories.

## The 15 Scope 3 categories

| Category                         | Type       | Typical data source               |
| -------------------------------- | ---------- | --------------------------------- |
| 1. Purchased goods & services    | Upstream   | Supplier spend + emission factors |
| 2. Capital goods                 | Upstream   | Asset purchases                   |
| 3. Fuel & energy-related         | Upstream   | Energy supplier data              |
| 4. Upstream transportation       | Upstream   | Logistics provider data           |
| 5. Waste generated in operations | Upstream   | Waste handler data                |
| 6. Business travel               | Upstream   | HR / travel booking               |
| 7. Employee commuting            | Upstream   | Employee survey                   |
| 8. Upstream leased assets        | Upstream   | Lease agreements                  |
| 9. Downstream transportation     | Downstream | Customer delivery data            |
| 10. Processing of sold products  | Downstream | Customer data                     |
| 11. Use of sold products         | Downstream | Product performance data          |
| 12. End-of-life treatment        | Downstream | Industry averages                 |
| 13. Downstream leased assets     | Downstream | Lease data                        |
| 14. Franchises                   | Downstream | Franchisee data                   |
| 15. Investments                  | Downstream | Financial data                    |

## Calculation methods in Matproof

Matproof supports the three GHG Protocol calculation methods:

### Spend-based method

Uses supplier spend × sector-specific emission factors.

* **Best for:** First-year reporting, when supplier data is unavailable
* **Data needed:** Spend by category, country
* **Emission factors:** Exiobase + DEFRA databases (updated annually)

### Activity-based method

Uses physical activity data × emission factors.

* **Best for:** High-spend categories where accuracy matters
* **Data needed:** Quantities (kg, km, kWh, etc.) from suppliers
* **More accurate** than spend-based

### Supplier-specific method

Uses actual emissions data reported by suppliers.

* **Best for:** Key suppliers with robust carbon accounting
* **Data needed:** Supplier's verified Scope 1 + 2 emissions, allocated to your share
* **Most accurate** — preferred by auditors

## Setting up Scope 3 in Matproof

1. **Go to CSRD → Scope 3**
2. **Select which categories are material** (based on your DMA results)
3. **Choose calculation method per category**
4. **Map your supplier data** — either from questionnaire responses or manual input
5. **Review calculations** — Matproof shows the math and data sources
6. **Export** — results mapped to ESRS E1-6 disclosure requirements

## Collecting data from suppliers

The supplier questionnaire includes Scope 3 data request fields:

* For **spend-based**: Matproof uses your procurement data automatically
* For **activity-based**: Questionnaire asks for quantities (e.g., "How many tonnes of goods did you deliver to us?")
* For **supplier-specific**: Questionnaire asks for their verified Scope 1+2 emissions and revenue attribution

## Emission factors

Matproof uses the following emission factor databases:

* **Exiobase** — multi-regional input-output tables (spend-based)
* **DEFRA** — UK government emission factors (activity-based)
* **ecoinvent** — lifecycle assessment database (product-level)
* **IPCC AR6** — global warming potentials

Databases are updated annually. You can see which version was used in your calculation audit trail.

<Note>
  ESRS E1-6 requires reporting Scope 3 emissions in **CO2 equivalent (CO2e)**, covering all 6 GHGs from the Kyoto Protocol: CO2, CH4, N2O, HFCs, PFCs, SF6.
</Note>


# Supplier Questionnaires
Source: https://docs.matproof.com/csrd/supplier-questionnaires

Automate ESG data collection from your supplier base using Matproof's questionnaire system.

## Overview

Matproof sends ESRS-aligned questionnaires to your suppliers and collects the responses automatically. Suppliers respond via a **simple web portal** — they don't need a Matproof account.

## Setting up supplier questionnaires

### 1. Import your supplier list

Go to **CSRD → Suppliers → Import**.

Upload a CSV with columns:

```
company_name, contact_email, contact_name, spend_category, country, tier
```

Or add suppliers manually one by one.

### 2. Categorize suppliers

After import, categorize suppliers by:

* **Tier** (Tier 1 = direct, Tier 2 = indirect)
* **Spend category** (e.g., raw materials, logistics, IT services)
* **Risk level** (high, medium, low) — Matproof pre-fills based on country and sector

This determines which questionnaire template is sent.

### 3. Select questionnaire templates

Matproof includes pre-built templates mapped to ESRS:

| Template               | Covers                            |
| ---------------------- | --------------------------------- |
| Standard ESRS          | All material ESRS topics, general |
| Scope 3 emissions (E1) | GHG data, energy consumption      |
| Labour practices (S2)  | Working conditions, wages, safety |
| Business conduct (G1)  | Anti-corruption, ethics           |
| Full ESRS pack         | All of the above combined         |

You can also create custom templates in the questionnaire builder.

### 4. Send questionnaires

Select suppliers and click **Send questionnaire**. Matproof:

1. Generates a unique secure link for each supplier
2. Sends the invitation email from your domain (or matproof.com)
3. Tracks open and completion rates
4. Sends automated reminders (configurable: 7, 14, 21 days)

### 5. Monitor responses

Track response status in the **Response Dashboard**:

* Not opened
* In progress
* Submitted
* Validated ✓

Matproof automatically validates submitted data for:

* Required fields completion
* Data format (e.g., emissions in tCO2e)
* Out-of-range values (flags unusual numbers for review)

## Supplier experience

Suppliers receive an email with a link to a **branded questionnaire portal**. They can:

* Complete the form in their own language (EN, DE, FR, ES, IT, NL)
* Save progress and return later
* Upload supporting documents
* Ask clarifying questions via the portal

No account creation or software installation required.

## Data validation and follow-up

After submission, you can:

* **Approve** the response as-is
* **Request clarification** — sends the supplier an email with specific questions
* **Reject** and ask for resubmission

All communication is tracked in the audit log.

## Export and reporting

Collected data feeds directly into:

* Scope 3 calculations (for E1 data)
* ESRS data point mapping
* Your CSRD report export

You can also export raw supplier responses as CSV or Excel for external reporting tools.


# FAQ & Troubleshooting
Source: https://docs.matproof.com/faq

Answers to the most common questions about using Matproof.

## Getting Started

### What frameworks does Matproof support?

Matproof currently supports: **DORA**, **ISO 27001**, **SOC 2**, **NIS2**, **GDPR**, **CSRD**, and **BaFin BAIT/ZAIT**. Controls are cross-mapped — evidence you collect for one framework automatically counts toward overlapping controls in others.

### How long does setup take?

The setup wizard takes 15–30 minutes. Reaching meaningful compliance coverage (policies approved, vendors added, first integrations connected) takes 2–4 hours of focused work. See the [Onboarding guide](/onboarding) for the recommended order of operations.

### Can I activate multiple frameworks at once?

Yes. Most customers activate 2–3 frameworks from the start. Matproof's cross-framework control mapping means you won't collect the same evidence twice for overlapping controls (e.g., ISO 27001 and NIS2 share many security controls).

### Do I need to be a compliance expert to use Matproof?

No. Matproof is designed for teams without a dedicated compliance officer. The AI policy generator, pre-built control libraries, and step-by-step framework guides are intended to make compliance accessible for engineers, operations leads, and founders managing compliance themselves.

***

## Controls and Evidence

### Why is a control showing as "Not Started" even though I've done the work?

Controls only advance status when evidence is attached. Go to the control, click **Add Evidence**, and upload documentation, screenshots, or link an integration. Once evidence is reviewed and marked compliant, the control status updates.

### How long is evidence valid?

Evidence validity depends on the control. Common expiry windows:

| Evidence Type                  | Typical Expiry         |
| ------------------------------ | ---------------------- |
| Access reviews                 | 90 days                |
| Penetration test reports       | 12 months              |
| Policy acknowledgements        | 12 months              |
| Vendor assessments             | 12 months              |
| Integration-collected evidence | Continuously refreshed |

Matproof sends expiry reminders 30 days before evidence expires. Configure notification preferences under **Settings → User → Notifications**.

### Can I bulk upload evidence?

Yes. Go to **Evidence → Bulk Upload** to upload multiple files at once and assign them to controls in batch.

### Why is my compliance score lower than expected?

The compliance score reflects the percentage of controls in **Compliant** status. Controls with no evidence, expired evidence, or evidence marked as insufficient reduce the score. Go to **Dashboard → Controls by status** and filter by "Gap" or "Not Started" to see what's pulling the score down.

***

## Policies

### How does AI policy generation work?

Matproof generates policies using your organization context (from **Settings → Context Hub**) combined with framework-specific templates. The more detail you provide in the Context Hub, the more relevant the output. Generated policies are drafts — you must review, customize, and publish them.

### Can I import existing policies instead of generating new ones?

Yes. Go to **Policies → Import** to upload existing policy documents (PDF, Word, or Markdown). Matproof stores them and links them to the relevant controls, but AI-generated policies are generally better structured for audit purposes.

### Who needs to acknowledge policies?

Policy acknowledgement requirements depend on the policy type:

* **Security policies** (acceptable use, clean desk) — all employees
* **Role-specific policies** — the relevant role holders
* **Management policies** — policy owner and senior management

Configure acknowledgement requirements per policy under **Policies → \[Policy] → Settings**.

***

## Integrations

### An integration is showing errors after it was working fine — what do I do?

The most common cause is an expired OAuth token or a permission change. Go to **Settings → Integrations → \[Integration] → Reconnect** to re-authorize. If the issue persists, check whether your account permissions in the connected tool have changed.

### Why isn't my integration collecting evidence for some controls?

Some controls require specific configuration in the connected tool, not just connection. For example, the GitHub integration cannot evidence "branch protection enabled" if branch protection was never set up in GitHub — connecting Matproof doesn't create the protection, it reports its status.

### Can I connect more than one AWS account?

Yes. Go to **Settings → Integrations → AWS → Add account** to connect additional accounts. Each account requires a separate cross-account IAM role.

### Does Matproof store the data it collects from integrations?

Matproof stores evidence snapshots (the result of checks at a point in time) but does not continuously mirror your infrastructure data. Raw access to your connected tools is used only to run checks during the scheduled sync.

***

## Vendors and TPRM

### How do I send a vendor questionnaire?

Go to **Vendors → \[Vendor] → Assessments → Send Questionnaire**. Select a template (DORA TPRM, SOC 2 vendor, ISO 27001 supplier) or use a custom template. The vendor receives a link — they do not need a Matproof account to respond.

### A vendor hasn't responded to our questionnaire — can I send a reminder?

Yes. Go to **Vendors → \[Vendor] → Assessments → \[Questionnaire] → Send Reminder**.

### Can I import a vendor list from a spreadsheet?

Yes. Go to **Vendors → Import** and download the CSV template. Fill it in and upload — all vendors will be created with the data from the spreadsheet.

***

## Auditors and Audit Preparation

### How do I give my external auditor access?

Invite them via **Settings → Team → Invite member** with the **Auditor** role. They get read-only access to controls, evidence, policies, and the risk register, and land on a dedicated auditor dashboard. See [Roles and Permissions](/roles-and-permissions) for details.

### Can the auditor export evidence?

Yes. Auditors can download individual evidence files and export compliance reports. They cannot create, edit, or delete any records.

### What format can I export compliance data in?

Matproof supports export in PDF (for reports), Excel (for control lists, risk registers, vendor lists), and JSON (for API consumers). Go to any module and click **Export**.

***

## Billing and Account

### Can I change my plan?

Yes. Go to **Settings → Billing** to upgrade, downgrade, or cancel. Upgrades take effect immediately. Downgrades take effect at the end of the current billing period.

### What happens to my data if I cancel?

Your data is retained for 30 days after cancellation and available for export. After 30 days it is deleted. Export your data before cancelling if you need to retain it.

### Is there a free trial?

Yes — Matproof offers a 14-day free trial on all paid plans. No credit card required. Contact [support@matproof.com](mailto:support@matproof.com) if you need a trial extension for a longer evaluation.

***

## Still stuck?

Contact us at [support@matproof.com](mailto:support@matproof.com) or use the in-app chat. Include your organization name and a description of the issue. For integration-specific issues, include a screenshot of the error from **Settings → Integrations**.


# AI Policy Editor
Source: https://docs.matproof.com/features/ai-policy-editor

Generate and refine compliance policies with AI-powered suggestions, inline editing, and framework-aware content.

## Overview

The AI Policy Editor helps you create compliance policies faster by generating framework-specific content, suggesting improvements inline, and ensuring your policies cover the requirements of your active frameworks. Instead of starting from a blank document, the editor produces a complete draft tailored to your organization that you review, customize, and approve.

<Note>
  The AI Policy Editor is available on all plans. Navigate to **Policies** and click **New Policy** or open an existing policy to access the editor.
</Note>

## Generating a new policy

<Steps>
  ### Select the policy type

  Go to **Policies - New Policy**. Choose from framework-specific templates:

  * Information Security Policy
  * Incident Response Policy
  * Access Control Policy
  * Business Continuity Policy
  * Data Protection Policy
  * Vendor Management Policy
  * And more, depending on your active frameworks

  ### Provide context

  The editor asks for basic context about your organization:

  * Organization name and industry
  * Active frameworks (pre-filled from your settings)
  * Any specific requirements or constraints

  This context shapes the generated content so it reflects your actual environment rather than generic boilerplate.

  ### Review the generated draft

  The AI produces a complete policy draft including:

  * Purpose and scope
  * Roles and responsibilities
  * Policy statements aligned to your framework requirements
  * Review and approval procedures

  The draft appears in the editor where you can make changes immediately.
</Steps>

## Inline AI suggestions

While editing any policy, the AI provides inline suggestions:

* **Completeness checks** - highlights sections where a framework requirement is not yet addressed
* **Improvement suggestions** - recommends stronger language, more specific controls, or additional detail where auditors typically expect it
* **Framework alignment** - shows which specific framework clauses or articles each section addresses

To use inline suggestions:

1. Open a policy in the editor
2. Click the **AI Assist** button or select text and choose **Suggest improvement**
3. Review the suggestion and accept, modify, or dismiss it

<Tip>
  Inline suggestions work best after you have made your initial edits to the generated draft. The AI uses your customizations as additional context for more relevant suggestions.
</Tip>

## Framework-aware content

The editor understands which frameworks you have activated and adjusts content accordingly:

| Framework | Editor behavior                                                                                    |
| --------- | -------------------------------------------------------------------------------------------------- |
| DORA      | Includes ICT risk management language, incident reporting timelines, vendor criticality references |
| ISO 27001 | Aligns sections to Annex A controls, uses ISO terminology                                          |
| NIS2      | References Article 21 measures, includes management accountability language                        |
| GDPR      | Includes data subject rights, legal bases, DPO references                                          |
| SOC 2     | Maps to Trust Services Criteria                                                                    |

If you have multiple frameworks active, the editor produces unified content that satisfies overlapping requirements without duplication.

## Editing and collaboration

The policy editor supports:

* **Rich text editing** - headings, lists, tables, and callouts
* **Version history** - every save creates a version you can review or restore
* **Comments** - add inline comments for reviewers
* **Approval workflow** - submit for review, track approvals, and publish

## Approval workflow

Once a policy is ready:

1. Click **Submit for review**
2. Select the reviewer (typically a compliance lead or CISO)
3. The reviewer receives a notification and can approve, request changes, or reject
4. Approved policies are marked with an approval timestamp and reviewer name - this serves as audit evidence

<Warning>
  Most frameworks require policies to be formally approved by management. Always route policies through the approval workflow rather than publishing directly. The approval record is evidence during audits.
</Warning>

## Exporting policies

Export policies for distribution or audit packages:

1. Open the policy
2. Click **Export**
3. Choose **PDF** or **Word**

Exported documents include the policy content, approval status, version number, and last review date.


# Audit Programs
Source: https://docs.matproof.com/features/audit-programs

Plan and execute internal compliance audits, manage findings, and generate audit reports.

## Overview

Matproof's Audit Programs module lets you run structured internal compliance audits against your frameworks. Create audit programs, assign auditors, work through control checklists, log findings, and generate a final audit report — all in one place.

<CardGroup>
  <Card title="Audit Programs" icon="clipboard-list">
    Plan and scope audits, assign auditors, track progress
  </Card>

  <Card title="Audit Reports" icon="file-chart-column">
    Generate PDF reports with findings, gaps, and recommendations
  </Card>

  <Card title="Audit Dashboard" icon="chart-bar">
    Upcoming audits, overdue items, findings by severity
  </Card>

  <Card title="External Auditors" icon="user-check">
    Invite external auditors with read-only access
  </Card>
</CardGroup>

## Creating an audit program

Navigate to **Audit Programs** (`/[orgId]/audit-programs`) and click **New Audit Program**.

You will configure:

| Field         | Description                                                    |
| ------------- | -------------------------------------------------------------- |
| **Framework** | The compliance framework being audited (ISO 27001, DORA, etc.) |
| **Scope**     | Which systems, departments, or processes are in scope          |
| **Auditor**   | Internal team member or external auditor assigned to lead      |
| **Schedule**  | Start date, end date, and any recurring cadence                |

Once created, Matproof auto-generates an **audit checklist** from the controls attached to the selected framework. Every in-scope control becomes a checklist item.

## Running the audit checklist

Inside a program (`/[orgId]/audit-programs/[programId]`), the checklist view shows all controls to be reviewed. For each control, the auditor can:

* Mark the control as **Conformant**, **Partial**, or **Non-conformant**
* Add **notes** on what was reviewed and how
* Attach or request **evidence** directly from the checklist item
* Log a **finding** when a gap or deficiency is identified

<Tip>
  Evidence requests can be sent to control owners from within the checklist. They receive a notification and can upload evidence without needing access to the full audit program.
</Tip>

## Logging findings

A finding is a documented gap, deficiency, or non-conformity identified during the audit.

Each finding includes:

* **Title** — short description of the gap
* **Severity** — informational, minor, major, critical
* **Linked control** — which control it relates to
* **Description** — detail on what was found and why it is an issue
* **Recommendation** — suggested remediation
* **Status** — open, in review, resolved

Findings can automatically generate [Corrective Actions](/features/corrective-actions) to ensure gaps are tracked through to resolution. All findings — whether raised inside an audit program, from a penetration test, from the device agent, or manually — also surface in the unified [Findings](/features/findings) view, so compliance leads see one list across every source.

## Inviting external auditors

You can invite external auditors by email from the program's **Auditors** tab.

External auditors receive the **Auditor role**, which grants:

* Read-only access to controls, evidence, and policies in scope
* Access to their dedicated auditor view at `/[orgId]/auditor`
* No ability to modify data or settings

<Note>
  External auditors cannot see controls, evidence, or findings outside the specific program they are assigned to.
</Note>

<Warning>
  Do not grant external auditors admin or editor roles. Always use the Auditor role to ensure read-only access.
</Warning>

## Generating the audit report

Once the checklist is complete, click **Generate Report** to produce a PDF audit report.

The report includes:

* **Executive summary** — scope, methodology, overall assessment
* **Control status summary** — conformant, partial, non-conformant counts
* **Evidence summary** — evidence collected per control
* **Findings** — all logged findings with severity and recommendations
* **Gaps and risks** — areas requiring immediate attention
* **Recommendations** — prioritized remediation steps

Reports are accessible under **Audit Reports** (`/[orgId]/audit-reports`) and can be downloaded at any time.

## Audit dashboard

The Audit Dashboard (`/[orgId]/audit-dashboard`) gives a real-time overview of your audit program health:

* **Upcoming audits** — programs scheduled in the next 30/60/90 days
* **Overdue items** — checklist items or evidence requests past their due date
* **Findings by severity** — breakdown of open findings across all programs
* **Recent activity** — latest updates across active audit programs

<Tip>
  Use the audit dashboard before board or committee meetings to get a quick read on compliance posture and open findings.
</Tip>


# Audit Trail
Source: https://docs.matproof.com/features/audit-trail

Immutable, tamper-proof log of every action taken in Matproof — who did what, and when.

## Overview

Matproof's Audit Trail (`/[orgId]/audit-trail`) records every action taken across your compliance program in an immutable, tamper-proof log. This gives you full visibility into platform activity and provides the evidence trail that regulators and external auditors expect.

<Warning>
  Audit trail entries cannot be edited or deleted. This is by design — any modification would compromise its integrity as evidence.
</Warning>

## What gets logged

Every significant action in Matproof creates an audit trail entry:

| Category           | Actions captured                                                  |
| ------------------ | ----------------------------------------------------------------- |
| **Policies**       | Created, updated, published, reviewed, archived                   |
| **Evidence**       | Uploaded, linked to control, deleted, expiry changed              |
| **Controls**       | Status changed, owner reassigned, framework mapping updated       |
| **Users**          | Invited, role changed, removed                                    |
| **Vendors**        | Added, risk assessment updated, removed                           |
| **Settings**       | Organisation settings changed, SSO configured, integrations added |
| **Audit programs** | Created, finding logged, report generated                         |
| **Risk register**  | Risk created, score updated, treatment changed                    |

Each entry records:

* **Timestamp** — exact date and time (UTC)
* **User** — who performed the action
* **Action type** — what they did
* **Object type** — what was affected (policy, control, user, etc.)
* **Object ID** — the specific record
* **Details** — before/after values where applicable

## Filtering and searching

Use the filter bar to narrow the audit trail:

| Filter          | Options                                           |
| --------------- | ------------------------------------------------- |
| **Date range**  | Custom start/end date                             |
| **User**        | Filter by specific team member                    |
| **Action type** | e.g. evidence\_uploaded, control\_status\_changed |
| **Object type** | Policy, Control, Evidence, User, Vendor, etc.     |

You can combine filters — for example, show all evidence uploads by a specific user in the last 30 days.

<Tip>
  When preparing for an external audit, filter by date range and export the relevant window. Auditors typically want to see activity for the period under review.
</Tip>

## Exporting for auditors

The full audit trail — or any filtered view — can be exported as CSV.

To export:

1. Apply any filters needed to scope the export
2. Click **Export CSV** in the top right
3. The file downloads with all visible columns: timestamp, user, action, object type, object ID, details

This CSV is commonly requested by:

* **DORA supervisors** during ICT risk examinations
* **ISO 27001 certification auditors** reviewing access and change controls
* **Internal audit teams** conducting periodic reviews

## Data retention

Audit trail data is retained for a minimum of **5 years**.

<Note>
  DORA Art. 12 requires financial entities to retain logs for a minimum of 5 years. ISO 27001 Annex A 8.15 requires logging and monitoring of system activities. Matproof's default retention satisfies both requirements.
</Note>

## Why it matters for compliance

**DORA (Digital Operational Resilience Act)**

DORA requires financial entities to maintain logs of ICT-related activities and provide them to competent authorities on request. The audit trail covers ICT risk management actions, user access changes, and system configuration events.

**ISO 27001 Annex A 8.15 — Logging**

ISO 27001 requires that logs record user activities, exceptions, and information security events. The audit trail provides this evidence across your compliance program operations.

**ISO 27001 Annex A 8.16 — Monitoring activities**

The ability to filter, review, and export activity logs supports the monitoring controls required under ISO 27001.

<Warning>
  If you are subject to DORA examination, regulators may request the audit trail for a specific time window with short notice. Keep exports current and make sure your team knows how to generate them.
</Warning>


# Cloud Tests
Source: https://docs.matproof.com/features/cloud-tests

Automated infrastructure resilience testing for DORA compliance.

## What are Cloud Tests?

Cloud Tests are automated checks that verify your infrastructure behaves correctly under stress, failure, and recovery scenarios. They run against your connected cloud environments and produce pass/fail results that serve directly as DORA evidence.

DORA (Digital Operational Resilience Act) requires significant financial entities to conduct **Threat-Led Penetration Testing (TLPT)** and demonstrate operational resilience. Cloud Tests in Matproof automate the technical layer of this requirement.

<Note>
  Cloud Tests are primarily relevant for organizations in scope for DORA. If you are pursuing ISO 27001 or SOC 2, the results can also support resilience and availability controls in those frameworks.
</Note>

## Why DORA requires resilience testing

DORA Article 25 mandates that ICT systems supporting critical functions are tested for their ability to:

* Withstand disruptions and continue operating
* Recover from failures within defined time objectives
* Maintain data integrity during incidents

Manual testing alone is not sufficient for continuous compliance. Cloud Tests give you automated, repeatable proof.

## Supported cloud providers

Connect your infrastructure before running tests:

| Provider | Status    |
| -------- | --------- |
| AWS      | Available |
| Azure    | Available |
| GCP      | Available |
| Hetzner  | Available |

To connect a provider, go to **Settings → Integrations** and follow the setup guide for your cloud.

## Test types

<CardGroup>
  <Card title="Availability tests" icon="signal">
    Verify that services remain accessible under expected load conditions. Confirms uptime SLAs are achievable.
  </Card>

  <Card title="Recovery tests" icon="rotate-right">
    Simulate failures and measure how quickly systems restore to normal operation. Tests your RTO (Recovery Time Objective).
  </Card>

  <Card title="Failover tests" icon="shuffle">
    Trigger failover to redundant systems and confirm traffic reroutes correctly without data loss or extended downtime.
  </Card>

  <Card title="Data integrity tests" icon="database">
    Validate that data remains consistent and uncorrupted after failures, restores, or replication events.
  </Card>
</CardGroup>

## Setting up your first test

1. Go to **Cloud Tests** in the sidebar
2. Click **New test**
3. Fill in the test details:
   * **Name** — a descriptive label (e.g., "EU production failover — monthly")
   * **Target environment** — select your connected cloud account and region
   * **Test type** — choose from the four types above
   * **Schedule** — one-time, weekly, or monthly
4. Click **Run test** or **Save schedule** to activate

<Warning>
  Run tests in staging environments first. Failover and recovery tests interact with live infrastructure and can cause brief disruptions if misconfigured.
</Warning>

## Scheduling recurring tests

DORA requires ongoing resilience validation, not just point-in-time audits. Use recurring schedules to stay compliant continuously.

Recommended schedule:

* Availability tests: weekly
* Recovery and failover tests: monthly
* Data integrity tests: after every major infrastructure change and monthly

Tests run automatically at the scheduled time. You receive an alert if a test fails or produces a partial result.

## Reviewing results

Each test run produces a result record with:

| Field         | Description                                  |
| ------------- | -------------------------------------------- |
| **Result**    | Pass / Fail / Partial                        |
| **Duration**  | How long the test took to complete           |
| **Target**    | The environment and service tested           |
| **Timestamp** | When the test ran                            |
| **Details**   | Breakdown of what was tested and what failed |

A **Partial** result means some sub-checks passed and others failed. Expand the result to see which components need attention.

To view results:

1. Go to **Cloud Tests**
2. Click any test to open its history
3. Filter by date range or result type

## Using results as DORA evidence

Passed test results are automatically available as evidence in the Evidence module.

To link a test result to a DORA control:

1. Open the relevant DORA control in **Controls**
2. Click **Add evidence**
3. Select **Cloud test result** and choose the test
4. The result is attached and the control status updates when evidence is sufficient

<Tip>
  Map each test type to its corresponding DORA control when you set the test up. This keeps evidence collection automatic and removes manual work during audits.
</Tip>

## Alerts on failure

When a test fails, Matproof sends an alert to:

* The test owner
* Any team members subscribed to compliance alerts

Alerts include the test name, what failed, and a direct link to the result. Resolve the underlying infrastructure issue, then re-run the test to generate a fresh pass result for your evidence trail.


# Frameworks
Source: https://docs.matproof.com/features/compliance-frameworks

How to add, manage, and gap-assess compliance frameworks in Matproof — and what's supported out of the box.

# Frameworks

This page covers how frameworks work in Matproof: how to add one, how cross-framework control mapping reduces duplicate work, and where to find the dedicated guide for each framework.

## What's supported

Matproof ships **16 frameworks** ready to adopt:

| Framework                                                | Region / Domain                        |
| -------------------------------------------------------- | -------------------------------------- |
| [DORA](/frameworks/dora)                                 | EU financial services                  |
| [NIS2](/frameworks/nis2)                                 | EU cybersecurity                       |
| [GDPR](/frameworks/gdpr)                                 | EU data protection                     |
| [BaFin MaRisk](/frameworks/bafin-marisk)                 | German banking risk management         |
| [ISO 27001](/frameworks/iso27001)                        | Information security management (ISMS) |
| [ISO 42001](/frameworks/iso42001)                        | AI management systems                  |
| [ISO 9001](/frameworks/iso9001)                          | Quality management                     |
| [SOC 2](/frameworks/soc2)                                | Trust services criteria                |
| [HIPAA](/frameworks/hipaa)                               | US healthcare data                     |
| [PCI DSS](/frameworks/pci-dss)                           | Payment card security                  |
| [NEN 7510](/frameworks/nen7510)                          | Dutch healthcare                       |
| [NIST CSF](/frameworks/nist)                             | NIST Cybersecurity Framework           |
| [NIST 800-53](/frameworks/nist-800-53)                   | US federal control catalog             |
| [EU AI Act](/frameworks/eu-ai-act)                       | EU AI governance                       |
| [Cyber Resilience Act](/frameworks/cyber-resilience-act) | EU product security                    |
| [CSRD](/frameworks/csrd)                                 | EU sustainability reporting            |

If you need a framework that isn't on this list — TISAX, CIS Controls, BSI IT-Grundschutz, a national transposition layer, an internal control catalog — you build it yourself with [Custom Frameworks](/features/custom-frameworks). Custom frameworks behave identically to built-in ones (same control mapping, same evidence flow, same audit export).

## Adding a framework

<Steps>
  <Step title="Open Settings → Frameworks">
    From the sidebar, go to **Settings → Frameworks**. You see all currently active frameworks plus an **Add framework** button.
  </Step>

  <Step title="Pick from the catalog">
    Browse the catalog of 16 built-in frameworks plus any custom frameworks your organization has built. Click **Add** on the one you want.
  </Step>

  <Step title="Set the scope (some frameworks only)">
    A few frameworks ask for additional scope before activation:

    * **NIST 800-53** — pick the baseline (LOW / MODERATE / HIGH or full catalog)
    * **PCI DSS** — pick your merchant level
    * **CSRD** — pick the reporting year(s) you're preparing for
    * **Custom frameworks** — pick which version of the framework to adopt
  </Step>

  <Step title="Run gap assessment">
    Matproof scans your existing evidence, policies, and risks against the new framework's controls and produces a gap report. Controls already covered by overlapping frameworks are auto-marked compliant; the rest become open work.
  </Step>

  <Step title="Assign control owners">
    Open the framework's controls list and assign each open control to a team member. Without owners, evidence doesn't get collected and the score doesn't move.
  </Step>
</Steps>

## Cross-framework control mapping

The single biggest reason Matproof exists: a control implemented once should satisfy every framework that requires it. Concrete example:

```
"Multi-factor authentication enforced for all privileged accounts"
  → satisfies:
     - ISO 27001  A.5.17, A.8.2, A.8.5
     - SOC 2      CC6.1, CC6.2
     - DORA       Article 9(4)(c)
     - NIS2       Article 21(2)(d), 21(2)(j)
     - HIPAA      164.312(d)
     - PCI DSS    8.4
```

Collect the evidence once (e.g. an Okta admin export showing MFA enforcement). Matproof links it to all 6 frameworks. The control's status flips to "Implemented" everywhere it's referenced.

This is why pursuing multiple certifications in parallel takes far less than 6× the effort of a single certification — the overlap typically lands at 50–70%.

## Viewing framework status

Every active framework has its own dashboard at `/[orgId]/frameworks/[frameworkInstanceId]`:

* **Compliance score** — percentage of controls with sufficient unexpired evidence
* **Controls by status** — implemented / in-progress / not started / not applicable
* **Findings** — open gaps and non-conformities (see [Findings](/features/findings))
* **Upcoming evidence expirations** — evidence falling out of date in the next 90 days
* **Recent activity** — control updates, evidence uploads, policy changes
* **Versioning** — when the framework's underlying standard updates, you can migrate to the new version while keeping evidence history

## Removing or deactivating a framework

You can deactivate a framework if your organization no longer needs it (e.g. you sunset a SOC 2 audit because you switched to ISO 27001). Deactivation:

* Hides the framework from the dashboard and reports
* Preserves all controls, evidence, and history (you can reactivate later)
* Does not delete shared evidence — controls reused by other active frameworks keep their evidence

To deactivate: **Settings → Frameworks → \[framework] → Deactivate**.

To permanently remove (rare; usually only for custom frameworks you no longer maintain): contact [support@matproof.com](mailto:support@matproof.com).

## Audit export

Before an audit, export the framework's complete evidence package:

1. Open the framework dashboard
2. Click **Export → Evidence Package**
3. Choose format: ZIP (recommended for auditors), PDF (executive summary), CSV (control list only)
4. The ZIP contains: control list with statuses, all linked evidence, policy versions, risk register entries, vendor entries, and findings — folder-organized to match the framework's chapter structure

Most external auditors accept Matproof's evidence package format directly, no further reformatting needed.

<CardGroup>
  <Card title="Custom Frameworks" href="/features/custom-frameworks">
    Build your own frameworks for transpositions or industry standards
  </Card>

  <Card title="Controls" href="/features/controls">
    The shared layer beneath every framework
  </Card>

  <Card title="Findings" href="/features/findings">
    Track gaps across every framework in one view
  </Card>

  <Card title="Evidence Collection" href="/features/evidence-collection">
    Automate evidence from your existing tools
  </Card>
</CardGroup>


# Controls
Source: https://docs.matproof.com/features/controls

The building blocks of every compliance framework — track status, assign owners, and link evidence.

## What is a control?

A control is a specific security or operational requirement that a compliance framework mandates. Every framework is made up of controls — DORA has around 70, ISO 27001 has 93, and SOC 2 has roughly 60 criteria.

Examples of controls:

* "Implement multi-factor authentication for all privileged accounts"
* "Conduct annual penetration testing of critical systems"
* "Maintain a documented incident response plan"

When you activate a framework in Matproof, its full control set is automatically populated into your Controls module.

<Note>
  Controls are only visible when **Advanced Mode** is enabled for your organization. Go to **Settings → Organization** to enable it.
</Note>

## Control structure

Each control contains:

| Field                 | Description                                              |
| --------------------- | -------------------------------------------------------- |
| **Status**            | Not started / In progress / Implemented / Not applicable |
| **Owner**             | The team member responsible for this control             |
| **Evidence**          | Evidence tasks linked to this control                    |
| **Policies**          | Internal policies that satisfy this control              |
| **Risks**             | Risks that this control mitigates                        |
| **Framework mapping** | Which frameworks reference this control                  |

## How controls map to frameworks

Controls are the shared layer beneath multiple frameworks. A single control — like "Encrypt data at rest" — can satisfy requirements across DORA, ISO 27001, and SOC 2 simultaneously.

When you collect evidence for a control, all frameworks that reference it are updated automatically.

<Tip>
  If you are pursuing multiple certifications, prioritize controls that appear in more than one framework first. Check the **Framework mapping** field on each control to see overlap.
</Tip>

## Updating control status

1. Go to **Controls** and open a control
2. Click **Status** and select the current state
3. Add a note if needed (useful for partial implementations)

Status options:

<CardGroup>
  <Card title="Not started" icon="circle">
    Control has not been addressed yet.
  </Card>

  <Card title="In progress" icon="circle-half-stroke">
    Implementation is underway but not complete.
  </Card>

  <Card title="Implemented" icon="circle-check">
    Control is fully implemented and evidenced.
  </Card>

  <Card title="Not applicable" icon="ban">
    Control does not apply to your organization's scope.
  </Card>
</CardGroup>

<Warning>
  Marking a control as **Not applicable** requires a justification note. Auditors will review these during assessments.
</Warning>

## Linking evidence

Evidence tasks are the primary way controls move to **Implemented** status.

To link evidence to a control:

1. Open the control
2. Click **Add evidence**
3. Select an existing evidence task or create a new one
4. Once the evidence task is marked complete, the control status updates automatically

You can link multiple evidence items to a single control. The control is considered implemented when all required evidence is collected and unexpired.

## Assigning owners

Every control should have an owner — the person accountable for implementation and ongoing compliance.

1. Open a control
2. Click **Owner** → search for a team member
3. The owner receives notifications when evidence expires or the control status changes

<Note>
  Owners do not need to collect evidence themselves. They are accountable for ensuring it gets done.
</Note>

## Filtering and searching

Use filters to focus on what matters:

| Filter              | Use case                                                 |
| ------------------- | -------------------------------------------------------- |
| **Framework**       | View controls for a specific framework (e.g., DORA only) |
| **Status**          | Find all controls that are not started or in progress    |
| **Owner**           | See what a specific person is responsible for            |
| **Evidence expiry** | Surface controls with expiring evidence                  |

## Exporting for audits

Before an audit, export your controls for review:

1. Go to **Controls**
2. Apply any filters (e.g., by framework)
3. Click **Export**
4. Choose CSV or the full evidence package (ZIP)

The export includes control names, statuses, owners, linked evidence, and policy references — matching the structure auditors expect.


# Corrective Actions
Source: https://docs.matproof.com/features/corrective-actions

Track and resolve control gaps, audit findings, and risk deficiencies through to closure.

## Overview

Corrective Actions (`/[orgId]/corrective-actions`) are remediation tasks created when a control gap, audit finding, or risk deficiency is identified. They ensure that identified problems are formally tracked, assigned, and resolved — with evidence of closure.

<Note>
  ISO 27001 Clause 10.1 requires organisations to react to nonconformities and take action to control and correct them. Corrective actions in Matproof are your documented proof of compliance with this requirement.
</Note>

## Corrective action fields

Each corrective action includes:

| Field             | Description                                           |
| ----------------- | ----------------------------------------------------- |
| **Title**         | Short description of what needs to be fixed           |
| **Description**   | Detail on the gap or deficiency and its impact        |
| **Priority**      | Critical, high, medium, low                           |
| **Owner**         | Team member responsible for resolution                |
| **Due date**      | Deadline for resolution                               |
| **Status**        | Open, In Progress, Resolved, Overdue                  |
| **Linked record** | The control, risk, or audit finding that triggered it |

## Creating a corrective action

### Manually

Navigate to **Corrective Actions** and click **New Corrective Action**. Fill in the fields, link to the relevant control or risk, and assign an owner.

### From a finding

Findings — whether logged inside an [Audit Program](/features/audit-programs), raised by a penetration test, surfaced by the [Device Agent](/features/device-agent), or detected by Cloud Tests — all funnel into the unified [Findings](/features/findings) view. From any finding, click **Create Corrective Action** to spawn one pre-populated with the finding title, severity, and linked control.

<Tip>
  Creating corrective actions directly from findings produces the cleanest audit paper trail: auditors can trace from finding → corrective action → resolution evidence in one flow without you reconstructing the chain manually.
</Tip>

### From the risk register

On any risk in the [Risk Register](/features/risk-management), you can create a corrective action to address a specific treatment gap or overdue mitigation task.

## Assigning owners

Every corrective action requires an owner — the team member accountable for resolving it. Owners receive:

* An email notification when assigned
* Reminders as the due date approaches
* A notification when the action becomes overdue

Owners can update status and add progress notes directly from the corrective actions view.

## Tracking progress

The corrective actions list shows all open actions with their status, owner, due date, and priority. You can filter by:

* **Status** — Open, In Progress, Resolved, Overdue
* **Owner** — filter to a specific team member
* **Priority** — show only critical or high priority items
* **Linked record type** — control, risk, or finding

Status transitions:

```
Open → In Progress → Resolved
              ↓
           Overdue (if due date passes without resolution)
```

## Closing with evidence

When marking a corrective action as **Resolved**, Matproof prompts for closure evidence — proof that the remediation was completed.

Examples of acceptable closure evidence:

* Screenshot of the new configuration or control in place
* Policy document showing the updated procedure
* Test results confirming the fix
* Third-party confirmation or certificate

The uploaded evidence is stored against the corrective action and linked to the relevant control's evidence library.

<Warning>
  For ISO 27001 audits, corrective actions closed without evidence may not satisfy auditor requirements. Always attach supporting documentation before marking resolved.
</Warning>

## The overdue dashboard

The corrective actions dashboard highlights:

* **Overdue actions** — past their due date without resolution
* **Actions by owner** — who has the most open items and where bottlenecks are
* **Resolution rate over time** — are you closing actions faster than they are being opened
* **By priority** — how many critical or high priority items remain open

<Tip>
  Review the overdue dashboard weekly. A growing backlog of overdue corrective actions is a red flag during ISO 27001 surveillance audits — it signals the organisation is not effectively managing nonconformities.
</Tip>

## ISO 27001 Clause 10 alignment

Corrective actions in Matproof directly address ISO 27001 Clause 10.1 requirements:

| Clause 10.1 requirement            | How Matproof covers it                                    |
| ---------------------------------- | --------------------------------------------------------- |
| React to the nonconformity         | Log finding → create corrective action                    |
| Take action to control and correct | Assign owner, set due date, track status                  |
| Evaluate the need for action       | Priority field, linked risk/control context               |
| Implement action needed            | Status tracking, owner notifications                      |
| Review effectiveness               | Closure evidence required before resolving                |
| Make changes to ISMS if needed     | Link corrective action back to control or policy          |
| Retain documented information      | All actions, evidence, and history are stored permanently |


# CSRD Supply Chain Module
Source: https://docs.matproof.com/features/csrd-supply-chain

End-to-end ESG data collection from your supplier base for CSRD reporting.

This page provides a feature overview. For full documentation, see the [CSRD module section](/csrd/overview).

## What it does

The CSRD supply chain module automates the most time-consuming part of CSRD reporting: **collecting ESG data from your suppliers**.

Without automation, this requires:

* Manually emailing hundreds of suppliers
* Following up repeatedly
* Manually entering responses into spreadsheets
* Calculating Scope 3 emissions by hand

Matproof replaces all of this with an automated workflow.

## Key features

<CardGroup>
  <Card title="Supplier portal" icon="globe">
    Suppliers respond to questionnaires via a secure, branded web portal. No account needed.
  </Card>

  <Card title="6 languages" icon="language">
    Questionnaires available in EN, DE, FR, ES, IT, NL. Suppliers respond in their language.
  </Card>

  <Card title="Scope 3 calculations" icon="calculator">
    Automatic GHG calculations using spend-based, activity-based, or supplier-specific methods.
  </Card>

  <Card title="ESRS mapping" icon="map">
    Collected data is automatically mapped to ESRS data point requirements.
  </Card>

  <Card title="Sanctions screening" icon="shield">
    All suppliers screened against EU, UN, and OFAC sanctions lists.
  </Card>

  <Card title="Audit trail" icon="file-lines">
    Full calculation methodology, data sources, and assumptions documented for assurance.
  </Card>
</CardGroup>

## Learn more

* [CSRD Module Overview](/csrd/overview)
* [Double Materiality Assessment](/csrd/double-materiality)
* [Supplier Questionnaires](/csrd/supplier-questionnaires)
* [Scope 3 Calculations](/csrd/scope3-calculations)
* [ESRS Data Point Mapping](/csrd/esrs-mapping)
* [CSRD Reporting](/csrd/reporting)


# Custom Frameworks
Source: https://docs.matproof.com/features/custom-frameworks

Build your own compliance frameworks, transposition layers, or industry standards entirely in the Matproof UI.

# Custom Frameworks

The Custom Frameworks editor lets you create and maintain compliance frameworks that aren't shipped out of the box — national transpositions of EU regulations (e.g. country-specific DORA or NIS2 implementations), industry-specific standards (TISAX, CIS Controls, internal policies), or proprietary control sets your organization or auditors require.

Custom frameworks behave exactly like built-in ones: they participate in cross-framework control mapping, support evidence automation, and produce audit-ready reports.

## When to Use Custom Frameworks

* **National transposition layers** — Add country-specific articles on top of an EU base framework (e.g. German BSI IT-Grundschutz on top of NIS2, Italian or French DORA national transposition)
* **Industry standards** — TISAX, CIS Controls, NIST SP 800-171, FedRAMP overlays, sector-specific schemes
* **Internal control catalogs** — Your own corporate security baseline, supplier code of conduct, ESG framework
* **Auditor-requested frameworks** — Custom control sets your auditor or regulator needs you to track

## What You Can Build

A custom framework in Matproof has the same structure as a built-in one:

| Object                | Purpose                                                                                           |
| --------------------- | ------------------------------------------------------------------------------------------------- |
| **Framework**         | Top-level container — name, version, description, regulator/source                                |
| **Requirements**      | The articles, controls, or clauses of the framework (e.g. "Article 9: Risk Management")           |
| **Control Templates** | Reusable controls that satisfy one or more requirements (e.g. "Quarterly access review")          |
| **Policy Templates**  | Document templates that the framework requires (e.g. "Incident Response Policy")                  |
| **Task Templates**    | Recurring tasks that produce evidence (e.g. "Annual penetration test", "Quarterly access review") |

Each requirement can be linked to one or more controls; controls can be linked to one or more policy templates; and policy/task templates can be reused across multiple custom and built-in frameworks.

## Building a Custom Framework

<Steps>
  <Step title="Open the Framework Editor">
    Go to **Settings > Custom Frameworks** and click **Create Framework**.
  </Step>

  <Step title="Define the framework metadata">
    Set the name, version, regulator/issuing body, jurisdiction, and a description. Choose whether the framework is mandatory or voluntary in your context.
  </Step>

  <Step title="Add requirements">
    Open the framework and add requirements one by one — each gets an identifier (e.g. "A.5.1"), a title, and a description. You can group requirements into chapters or domains.
  </Step>

  <Step title="Attach controls">
    For each requirement, attach one or more control templates. You can reuse controls already defined in built-in frameworks (so a single control can satisfy ISO 27001 A.5.15 *and* your custom framework's section 3.2).
  </Step>

  <Step title="Attach policies and tasks">
    Optionally link policy templates and task templates to controls so the framework drives the right document and evidence creation when adopted.
  </Step>

  <Step title="Publish and adopt">
    Publish the framework version. It now appears in Settings > Frameworks alongside built-in ones — your team adopts it the same way as DORA or NIS2.
  </Step>
</Steps>

## Versioning

Custom frameworks are versioned. When the underlying regulation or standard changes, create a new version of the framework — Matproof tracks the diff between versions and lets you migrate adopted controls forward without losing evidence history.

## API Access

Every custom framework operation is also available via the [REST API](/api-reference) — useful when you maintain framework definitions in source control or want to sync them from an external system. Endpoints cover frameworks, requirements, controls, policies, and tasks.

## Limitations

* Custom frameworks count against your plan's **framework limit**. See [Plans & Pricing](/features/plans). Enterprise plans include unlimited custom frameworks.
* Cross-framework control mapping is automatic for controls you reuse across frameworks; Matproof does not auto-map between custom frameworks based on text similarity (you control the linkage explicitly).

## Getting Started

<CardGroup>
  <Card title="Frameworks Overview" href="/frameworks/dora">
    See built-in frameworks before deciding what to build custom
  </Card>

  <Card title="API Reference" href="/api-reference">
    Manage custom frameworks programmatically
  </Card>
</CardGroup>


# Device Agent
Source: https://docs.matproof.com/features/device-agent

Endpoint compliance agent for macOS — runs native security checks every hour and matches installed software against the NVD CVE database.

# Device Agent

The **Matproof Device Agent** is a lightweight tray application that runs on each user's machine and reports endpoint compliance evidence to your Matproof organization. It produces evidence for ISO 27001 (A.8.8), SOC 2 (CC7.1), HIPAA (164.308), NIS 2 (Art. 21), DORA (Art. 9), and PCI DSS (6.3.1) — without needing a separate MDM product.

## What the Agent Checks

Every hour, the agent runs **10 native compliance checks** on the host machine:

| Check                         | What it verifies                                                                |
| ----------------------------- | ------------------------------------------------------------------------------- |
| Disk encryption               | FileVault is enabled on the boot volume                                         |
| Antivirus                     | XProtect / built-in malware protection is active                                |
| Password policy               | Minimum length and complexity meet your policy                                  |
| Screen lock                   | Screen lock is enabled with an acceptable timeout                               |
| Firewall                      | Application Firewall is enabled                                                 |
| OS patch freshness            | macOS version is supported and current                                          |
| Antivirus signature freshness | XProtect definitions are recent                                                 |
| Backup                        | A backup destination is configured and recent                                   |
| MDM enrollment                | Device is enrolled in MDM (if your org requires it)                             |
| Idle-lock verified            | The screen actually locks after the configured timeout (not just configured to) |

Every 6 hours, the agent additionally captures a **software inventory** of installed applications via `system_profiler`. The inventory feeds CVE matching (see below).

## CVE Matching (Tier 3A)

The agent's installed-app inventory is joined against the **NVD CVE database** by Matproof's API. For around 30 high-impact applications (browsers, communication tools, dev runtimes, IDEs, containerization), Matproof maintains a curated CPE map that converts each installed version into a precise CPE identifier and queries the NVD for known vulnerabilities affecting that version.

The result:

* A `vulnerableAppsCount` per device on the device list
* Evidence rows automatically created on the relevant control (`installed_apps` evidence)
* Findings raised for high or critical CVEs affecting devices in your fleet
* 24-hour cache to stay within NVD's rate limits

This satisfies the "vulnerability management on endpoints" requirements in ISO 27001 A.8.8, SOC 2 CC7.1, NIS 2 Art. 21, DORA Art. 9, and PCI DSS 6.3.1.

## Platform Support

| OS                                             | Status              | Architecture                   |
| ---------------------------------------------- | ------------------- | ------------------------------ |
| macOS 12+ (Monterey, Ventura, Sonoma, Sequoia) | Generally available | Intel x64, Apple Silicon arm64 |
| Windows 10 / 11                                | Beta                | x64                            |
| Linux                                          | Roadmap             | —                              |

Builds are **code-signed and notarized** with the Matproof Apple Developer ID and stapled before distribution.

## System Requirements

| Requirement | Minimum                                                        |
| ----------- | -------------------------------------------------------------- |
| macOS       | 12 (Monterey)                                                  |
| Windows     | 10                                                             |
| Memory      | 256 MB RAM available                                           |
| Disk        | 200 MB                                                         |
| Network     | Outbound HTTPS to `agents.matproof.com` and `api.matproof.com` |

## Installation

<Steps>
  <Step title="Download the installer">
    From your Matproof portal, navigate to **People > \[Your User] > Devices** and click **Install Device Agent**. The portal serves the right DMG (Intel or Apple Silicon) automatically.

    Direct DMG link: `https://agents.matproof.com/installers/Matproof-Device-Agent-{version}-{arch}.dmg`
  </Step>

  <Step title="Run the installer">
    On macOS, open the DMG and drag **Matproof Device Agent** to Applications. Launch it once from Applications to register the tray icon.
  </Step>

  <Step title="Pair the agent with your account">
    The agent opens your default browser to the Matproof portal pairing page. Sign in (if you aren't already), and the portal returns a one-shot code to the agent over `localhost`. The agent registers with your organization automatically.
  </Step>

  <Step title="First check-in">
    Within 60 seconds the first compliance check runs and the device appears in your organization's device list under **People > Devices**.
  </Step>
</Steps>

## Updates

The agent supports auto-updates via `electron-updater`. Matproof publishes signed builds to `agents.matproof.com/installers/` and the agent checks for new versions on launch and periodically.

## Privacy and Data Minimization

The agent reports **only** the compliance signals listed above and the installed-app inventory. It does **not**:

* Read user files, documents, browsing history, or chat content
* Capture screenshots
* Run keystroke logging
* Track location
* Send raw command output — only the boolean result of each check
* Send installed-app inventory to anywhere other than your Matproof organization

The full list of check methods and their data minimization is in `packages/device-agent/SPEC.md` in the Matproof source repository (Enterprise customers under NDA can request access).

## What Admins See

In the Matproof app under **People > Devices**:

* One row per registered device with owner, OS, last check-in, and overall pass/fail
* Drilldown to the individual checks and their last-known state
* `vulnerableAppsCount` column reflecting CVE matches
* Evidence tied to the relevant controls (e.g. encryption evidence on the "Endpoint Disk Encryption" control)
* Findings raised automatically for failed checks or critical CVEs

## Manual Evidence Collection (Devices Without the Agent)

For devices where the agent can't be installed (Linux until GA, BYOD without consent, vendor-managed machines), Matproof supports manual evidence upload. The required evidence types and how to obtain them on each OS are described below.

<Accordion title="macOS — Manual Evidence">
  ### macOS (Monterey, Ventura, Sonoma, Sequoia)

  **Enable FileVault**

  1. Open **System Settings** → **Privacy & Security** → **FileVault**
  2. Click **Turn On FileVault**, enter your password, and record the recovery key
  3. Screenshot the FileVault settings page showing "FileVault is enabled for the disk"

  **Screen Auto-lock**

  1. **System Settings** → **Lock Screen**
  2. Set **Start Screen Saver when inactive** to ≤ 5 minutes
  3. Set **Require password after sleep or screen saver begins** to **Immediately**
  4. Screenshot showing both settings

  **Automatic Security Updates**

  1. **System Settings** → **General** → **Software Update** → **Automatic Updates**
  2. Enable all toggles
  3. Screenshot the page showing updates enabled

  **Antivirus (XProtect)**

  XProtect is built into macOS and runs by default. Verify macOS is fully updated and screenshot the Software Update page.

  **Firewall**

  1. **System Settings** → **Network** → **Firewall**
  2. Turn on the firewall
  3. Screenshot the firewall settings page showing it enabled
</Accordion>

<Accordion title="Windows — Manual Evidence">
  ### Windows 10 and 11

  **Enable BitLocker**

  1. Press **Start**, type **Manage BitLocker**, open it
  2. Select the system drive (usually C:) and click **Turn on BitLocker**
  3. Save the recovery key to a Microsoft Account, USB drive, or your secure store
  4. Screenshot the BitLocker Drive Encryption window showing "On" for C:

  **Screen Lock after 5 Minutes**

  1. **Start** → **Settings** → **Personalization** → **Lock screen** → **Screen timeout settings**
  2. Set **Screen turns off** to 5 minutes
  3. **Settings** → **Accounts** → **Sign-in options** → **Require sign-in: When PC wakes up**
  4. Screenshot both settings

  **Minimum Password Length (Local Policy)**

  1. Press **Win + R**, type `secpol.msc`
  2. Navigate to **Account Policies** → **Password Policy**
  3. Set **Minimum password length** to 8 or more
  4. Screenshot the Password Policy window

  **Automatic Updates**

  1. **Settings** → **Update and Security** → **Windows Update** → **Advanced options**
  2. Enable Automatic updates
  3. Screenshot showing updates enabled

  **Antivirus (Windows Defender)**

  1. **Settings** → **Update and Security** → **Windows Security** → **Virus and threat protection**
  2. Verify **Real-time protection** is on
  3. Screenshot the Windows Security window
</Accordion>

<Note>
  Manual evidence is uploaded as a comment plus attachment on the relevant device task. Tag the upload with the user's email so it ties back to the right person in your team.
</Note>

## Frameworks Covered

| Framework | Mapped Requirement                          |
| --------- | ------------------------------------------- |
| ISO 27001 | A.8.1, A.8.2, A.8.7, A.8.8, A.8.20          |
| SOC 2     | CC6.1, CC6.6, CC6.7, CC7.1                  |
| HIPAA     | 164.308(a)(5), 164.310(d)(1), 164.312(a)(1) |
| NIS 2     | Article 21(2)(d), 21(2)(g)                  |
| DORA      | Article 9(2), 9(3), 9(4)(g)                 |
| PCI DSS   | 6.3.1, 8.6.3, 9.5                           |

<CardGroup>
  <Card title="Findings" href="/features/findings">
    See how device-agent findings flow into your unified findings view
  </Card>

  <Card title="Cloud Tests" href="/features/cloud-tests">
    Cloud-side configuration checks that pair with endpoint checks
  </Card>
</CardGroup>


# Evidence Collection
Source: https://docs.matproof.com/features/evidence-collection

How Matproof collects evidence — automated from connected tools, from the device agent, from cloud and pen-tests, plus manual upload for the rest.

# Evidence Collection

Evidence proves a control is implemented and working. In Matproof, every control has an evidence panel that pulls from four different sources:

| Source                | What it covers                                                        |
| --------------------- | --------------------------------------------------------------------- |
| **Integrations**      | Cloud, identity, source-control, ticketing systems — automated        |
| **Device Agent**      | Endpoint compliance signals from each user's machine — automated      |
| **Cloud Tests**       | Continuous configuration checks against AWS / Azure / GCP — automated |
| **Penetration tests** | AI-powered or third-party pen-test reports — semi-automated           |
| **Manual upload**     | Any document, screenshot, or report that an integration can't capture |

This page covers how each source works and when to use which.

## Automated: integrations

Connect tools you already use and Matproof scans them on a schedule, populating evidence on every control they cover.

| Integration                       | Evidence collected                                                                                              | Controls typically covered                              |
| --------------------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
| **GitHub / GitLab / Bitbucket**   | Branch protection rules, PR review requirements, signed-commits policy, access logs, secret scanning status     | Change management, secure SDLC, source-code access      |
| **Google Workspace**              | User list, role assignments, MFA enforcement, admin audit logs, group memberships                               | Identity & access, awareness training                   |
| **Microsoft Entra ID (Azure AD)** | Conditional access policies, MFA enforcement, admin role assignments, sign-in logs                              | Identity & access                                       |
| **AWS**                           | IAM policies, encryption-at-rest configuration, CloudTrail logging, S3 public-access settings, GuardDuty status | Cryptography, access control, logging, threat detection |
| **Azure**                         | RBAC assignments, encryption settings, Defender for Cloud findings, activity logs                               | Same control families as AWS                            |
| **GCP**                           | IAM policies, encryption settings, Security Command Center findings                                             | Same control families as AWS                            |
| **Okta**                          | User lifecycle, MFA factors, app assignments, audit logs                                                        | Identity & access                                       |
| **Jira / Linear**                 | Ticket data for incident records, change requests, approval workflows                                           | Incident management, change management                  |
| **Aikido Security**               | Vulnerability findings ingested as Findings                                                                     | Vulnerability management                                |

### Connecting an integration

<Steps>
  <Step title="Open Settings → Integrations">
    Go to **Settings → Integrations**. Each integration shows whether it's currently connected and what it covers.
  </Step>

  <Step title="Click Connect">
    For OAuth integrations (Google Workspace, Okta, GitHub), you'll be redirected to authorize Matproof on the third-party side and then back. For API-key integrations (AWS, some custom systems), paste credentials with the documented minimum permissions.
  </Step>

  <Step title="Wait for the first scan">
    The first scan typically takes 5–30 minutes depending on the size of the connected system. You'll see evidence start appearing on relevant controls as the scan completes.
  </Step>

  <Step title="Set scan frequency">
    Default is daily. For high-velocity systems (e.g. GitHub on a fast-moving codebase), you can increase to hourly. Frequency setting is per integration.
  </Step>
</Steps>

Each integration is OAuth-scoped to the minimum read-only permissions needed. Matproof never writes to integrated systems unless you explicitly enable a write feature.

## Automated: Device Agent

The [Matproof Device Agent](/features/device-agent) runs on each team member's macOS or Windows machine and reports endpoint compliance signals every hour: disk encryption, screen lock, OS patch level, antivirus, firewall, MDM enrollment, plus a 6-hourly software inventory that's matched against the NVD CVE database for vulnerable installed apps.

Device-agent evidence flows to controls like:

* ISO 27001 A.8.1 (User endpoint devices), A.8.7 (Protection against malware), A.8.8 (Management of technical vulnerabilities)
* SOC 2 CC6.1, CC6.6, CC7.1
* HIPAA 164.308, 164.310, 164.312
* NIS2 Article 21(2)(d), 21(2)(g)
* DORA Article 9
* PCI DSS 6.3.1, 8.6.3

Roll out the agent to your team via **People → \[Member] → Devices → Send install link**.

## Automated: Cloud Tests

[Cloud Tests](/features/cloud-tests) run continuous configuration checks against your AWS / Azure / GCP environments — separate from the integration scan, focused on misconfigurations rather than identity. Failed checks produce findings; passing checks produce evidence.

## Automated: Penetration Tests

[Penetration Tests](/features/penetration-tests) generates an AI-powered external pen-test report against a target URL on demand. The resulting findings flow into the Findings module; the report itself can be attached as evidence on annual-pen-test controls.

For third-party penetration tests (when an external firm runs the test), upload the report manually as evidence on the relevant control.

## Manual evidence upload

For controls that can't be covered by an integration — internal procedures, BCP test results, board minutes, awareness-training screenshots, vendor SOC 2 reports — upload manually:

<Steps>
  <Step title="Open the control">
    Go to **Controls** (under whichever framework or via the unified controls list) and open the control you want to evidence.
  </Step>

  <Step title="Click Add evidence">
    Choose between **Upload file** (any format), **Add link** (URL to an external system), or **Add note** (text-only attestation).
  </Step>

  <Step title="Set metadata">
    * **Description** — what this evidence demonstrates
    * **Expiry date** — when the evidence becomes stale (defaults are sensible per control type)
    * **Owner** — usually the person responsible for refreshing it
  </Step>

  <Step title="Save">
    Evidence appears immediately on the control. The control's status updates if all required evidence is now in place.
  </Step>
</Steps>

## Bulk upload

For initial setup or annual refreshes, upload many files at once:

1. Go to **Evidence → Bulk upload**
2. Download the evidence-mapping template (CSV)
3. Fill in: filename, control IDs, description, expiry date
4. Upload the ZIP containing both the template and the files

Matproof maps each file to its declared control(s) automatically.

## Evidence expiry

Every piece of evidence has an expiry date. Matproof emails the evidence owner **30 days before expiry** so there's time to collect a refresh.

Sensible defaults by evidence type:

| Evidence type                 | Default expiry |
| ----------------------------- | -------------- |
| Access reviews                | 6 months       |
| Awareness training records    | 12 months      |
| Penetration test reports      | 12 months      |
| BCP / DR test results         | 12 months      |
| Vendor risk assessments       | 12 months      |
| Policy acknowledgements       | 12 months      |
| Cryptography algorithm review | 24 months      |
| Risk assessment               | 12 months      |

You can override per control. Audit framework requirements often dictate the expiry — Matproof picks the strictest default.

## Evidence Review

Evidence isn't useful unless someone checks it. The [Evidence Review](/features/evidence-review) module gives compliance leads a workflow to approve, reject, or request more from each piece of evidence as it arrives. Auditors typically expect this review trail.

<CardGroup>
  <Card title="Controls" href="/features/controls">
    Where evidence attaches
  </Card>

  <Card title="Evidence Review" href="/features/evidence-review">
    Approve and reject evidence as it arrives
  </Card>

  <Card title="Device Agent" href="/features/device-agent">
    Endpoint evidence
  </Card>

  <Card title="Cloud Tests" href="/features/cloud-tests">
    Continuous cloud configuration evidence
  </Card>
</CardGroup>


# Evidence Review
Source: https://docs.matproof.com/features/evidence-review

Submit evidence for review, approve or reject submissions, and maintain a complete audit trail of all evidence decisions.

## Overview

The Evidence Review workflow ensures that every piece of compliance evidence is validated before it counts toward your control status. Team members submit evidence, reviewers approve or reject it with comments, and every action is recorded in an immutable activity log that auditors can inspect.

<Note>
  Evidence Review is enabled by default. To configure who can approve evidence, go to **Settings - Roles and Permissions**.
</Note>

## How it works

<Steps>
  ### Submit evidence

  When a team member collects evidence for a control:

  1. Go to **Controls** and open the relevant control
  2. Click **Add evidence**
  3. Upload the file or link the automated evidence source
  4. Add a description explaining what the evidence demonstrates
  5. Click **Submit for review**

  The evidence status changes to **Pending review** and the assigned reviewer is notified.

  ### Review and decide

  Reviewers see pending evidence in their **Review queue** (accessible from the sidebar or dashboard):

  1. Open the evidence item
  2. Review the uploaded file or linked data
  3. Check that the evidence actually demonstrates the control requirement
  4. Choose one of:
     * **Approve** - evidence is accepted and the control status updates accordingly
     * **Reject** - evidence is sent back with a comment explaining what needs to change
     * **Request changes** - evidence stays in queue with specific feedback for the submitter

  ### Resubmit if needed

  If evidence is rejected or changes are requested:

  1. The submitter receives a notification with the reviewer's comments
  2. The submitter uploads corrected evidence or adds clarification
  3. The evidence re-enters the review queue
</Steps>

## Activity audit log

Every evidence action is recorded in the activity log with:

| Field                | Description                                                            |
| -------------------- | ---------------------------------------------------------------------- |
| **Timestamp**        | Exact date and time of the action                                      |
| **User**             | Who performed the action                                               |
| **Action**           | Submitted, approved, rejected, requested changes, resubmitted, expired |
| **Comment**          | Any notes or feedback provided                                         |
| **Evidence version** | Which version of the evidence the action applies to                    |

The activity log is immutable - entries cannot be edited or deleted. This provides a complete chain of custody that auditors require.

To view the log:

1. Open any evidence item
2. Click the **Activity** tab
3. The full history is displayed in chronological order

<Tip>
  During audits, export the activity log for specific controls by going to **Controls - Export** and selecting **Include evidence activity log**. This gives auditors the evidence chain without needing platform access.
</Tip>

## Review queue

The review queue aggregates all pending evidence across your organization:

* Access it from **Evidence - Review queue** in the sidebar
* Filter by framework, control, submitter, or date
* Sort by submission date to process oldest items first
* Bulk approve multiple items if they share the same review criteria

## Configuring reviewers

By default, the **Owner** and **Admin** built-in roles can approve evidence. **Auditor**, **Employee**, and **Contractor** can submit but not approve. To grant approval rights to additional people without elevating them to Admin, define a custom role with the evidence-approval permission:

1. Go to **Settings → Roles & Permissions**
2. Click **New role** and grant the Evidence module's **Approve** permission (alongside any other permissions the role needs — usually View on Controls and Frameworks)
3. Assign that custom role to the people you want as reviewers
4. Optionally, configure per-framework reviewers so that DORA evidence is reviewed by one team and ISO 27001 evidence by another

See [Roles & Permissions](/features/rbac-roles) for the full role model and how custom roles work.

<Warning>
  Segregation of duties matters for audits. The person who submits evidence should not be the same person who approves it. Configure your roles to enforce this separation.
</Warning>

## Automatic evidence review

For evidence collected automatically from integrations (GitHub, AWS, Google Workspace, etc.), you can configure auto-approval rules:

1. Go to **Settings - Evidence - Auto-approval**
2. Define rules based on evidence source and type
3. Automated evidence that matches a rule is approved automatically
4. A log entry records the auto-approval with the rule that triggered it

Auto-approval is useful for recurring, well-understood evidence (like MFA status checks or access logs) where manual review adds no value.

<Note>
  Auto-approved evidence is still visible in the activity log and can be manually revoked if needed.
</Note>


# Findings
Source: https://docs.matproof.com/features/findings

Track gaps, non-conformities, and remediation across every framework, control, and audit in one unified view.

# Findings

Findings is Matproof's unified view of every gap, non-conformity, vulnerability, and remediation item across your compliance program. Whether a finding originates from an internal audit, an external auditor, a penetration test, the device agent, a vendor questionnaire, or a manual entry — it ends up in one place with consistent structure and lifecycle.

## Why Findings Are Centralized

Compliance programs typically scatter gaps across spreadsheets, audit reports, ticket systems, and email threads. Matproof's Findings module solves that by:

* **One status taxonomy** — open, in-progress, resolved, accepted-risk, closed-no-action — applied to all sources
* **One owner model** — every finding has an owner and (optionally) a due date
* **One remediation flow** — convert findings into corrective actions or tasks; track evidence on close-out
* **Cross-framework scope** — a single finding can be linked to multiple controls and frameworks at once

## Sources of Findings

| Source                    | Example                                                           |
| ------------------------- | ----------------------------------------------------------------- |
| **Internal audits**       | Auditor flags missing access review evidence on ISO 27001 A.5.15  |
| **External audits**       | SOC 2 audit firm raises a non-conformity on CC6.6                 |
| **Penetration tests**     | AI pen-test finds an exposed admin endpoint on a target URL       |
| **Device agent**          | A laptop reports FileVault disabled or a vulnerable installed app |
| **Vendor questionnaires** | A supplier's response indicates non-compliance with your DPA      |
| **Cloud tests**           | Automated cloud configuration check fails (e.g. S3 bucket public) |
| **Manual entry**          | Compliance team logs an issue surfaced in a meeting               |

## Finding Structure

Every finding carries:

* **Title and description** — what was found
* **Source** — origin module (audit, pentest, device agent, manual, etc.)
* **Severity** — informational / low / medium / high / critical
* **Status** — open / in-progress / resolved / accepted-risk / closed
* **Scope** — which controls, frameworks, requirements, vendors, or assets it relates to
* **Owner** — the person responsible for remediation
* **Due date** — when remediation is expected
* **Evidence** — attached documents or links proving remediation

## Lifecycle

<Steps>
  <Step title="Detection">
    A finding is created automatically (by an integration, scan, or audit module) or manually.
  </Step>

  <Step title="Triage">
    Compliance team reviews, sets severity, assigns an owner, links the finding to relevant controls and frameworks.
  </Step>

  <Step title="Remediation">
    Owner addresses the underlying issue. Optionally creates a [corrective action](/features/audit-programs) for tracked, multi-step work.
  </Step>

  <Step title="Verification">
    Owner attaches evidence of remediation. Compliance team verifies and closes the finding.
  </Step>

  <Step title="Audit trail">
    Closed findings remain in the system with full history — useful for next audit cycle or auditor questions.
  </Step>
</Steps>

## Finding Templates

For recurring finding types (e.g. "missing access review evidence", "expired security training"), Matproof ships **Finding Templates** so audit teams don't rewrite the same description and remediation steps every time. Templates pre-fill title, description, severity, and recommended remediation; the user fills in scope and owner.

You can also create your own finding templates for organization-specific patterns.

## Reporting

The Findings overview supports:

* Filtering by status, severity, source, owner, framework, control, or due date
* Aggregations by framework — instant view of how many open findings affect each framework
* Aggregations by owner — accountability dashboards
* Export to CSV / PDF for auditor handover

## Integrations

Findings tie into the rest of the platform:

* A finding linked to a control surfaces directly on that control's page
* A finding linked to a framework counts against that framework's compliance score
* Closing a finding can satisfy task completion (if the finding was raised against a task)
* A finding's remediation can be tracked as a [corrective action](/features/audit-programs) for ISO 9001 / ISO 27001 audit programs

## Getting Started

<CardGroup>
  <Card title="Audit Management" href="/features/audit-programs">
    Internal audits and corrective actions
  </Card>

  <Card title="Penetration Tests" href="/features/penetration-tests">
    Auto-generate findings from pen-test reports
  </Card>

  <Card title="Device Agent" href="/features/device-agent">
    Endpoint findings from compliance checks
  </Card>

  <Card title="Vendor Management" href="/features/vendor-risk">
    Findings from supplier questionnaires
  </Card>
</CardGroup>


# Incidents
Source: https://docs.matproof.com/features/incidents

Log, classify, and report ICT incidents in line with DORA requirements.

## Overview

Matproof's Incidents module manages the full lifecycle of ICT incidents under DORA — from initial detection through NCA notification, resolution, and post-incident review. Every incident you log generates linked evidence automatically.

## DORA incident reporting requirements

DORA mandates that financial entities report major ICT incidents to their competent authority (NCA) within strict deadlines:

| Report type              | Deadline | Trigger                      |
| ------------------------ | -------- | ---------------------------- |
| **Initial notification** | 4 hours  | Incident classified as major |
| **Intermediate report**  | 72 hours | After initial notification   |
| **Final report**         | 1 month  | After incident resolution    |

<Warning>
  The 4-hour clock starts when the incident is **classified as major** — not when it is detected. Classification happens in Matproof after you assess the incident against DORA's criteria.
</Warning>

## What makes an incident "major"

DORA defines a major ICT incident by the following criteria. Matproof guides you through each one during classification:

* **Number of clients affected** — threshold varies by entity type
* **Duration** — incidents exceeding defined downtime thresholds
* **Geographic spread** — impact across multiple member states
* **Data loss** — availability, integrity, or confidentiality impact
* **Criticality of services** — payment, trading, custody, or other critical functions affected
* **Economic impact** — financial loss to the entity or clients

Matproof computes a classification recommendation based on your inputs. You confirm or override, and the 4-hour timer starts on confirmation.

## Incident lifecycle

Every incident moves through five stages:

```
Detection → Classification → Notification → Resolution → Post-Incident Review
```

Each stage is timestamped. Matproof tracks time elapsed between stages so you can see at a glance whether you are inside the DORA reporting window.

## Creating an incident

1. Go to **Incidents** → **New incident**
2. Fill in the detection details:
   * **Title** — short description of the incident
   * **Detection date and time** — when your team first became aware
   * **ICT systems affected** — select from your registered assets
   * **Initial description** — what is known at time of logging
3. Save as draft — the incident is now in **Detection** stage

<Tip>
  Log incidents as soon as they are detected, even if details are incomplete. You can update the incident record as the situation develops. Early logging protects you if the incident later meets major criteria.
</Tip>

## Classifying severity

After detection, classify the incident:

1. Open the incident → **Classify**
2. Step through each DORA major incident criterion
3. Matproof calculates a severity recommendation:
   * **Minor** — below all major thresholds, internal handling only
   * **Significant** — approaching thresholds, monitor closely
   * **Major** — meets one or more DORA major criteria, NCA notification required
4. Confirm the classification

If you classify an incident as **major**, the 4-hour NCA notification timer activates immediately and appears at the top of the incident record.

## Generating the NCA notification

For major incidents, generate the initial notification report directly from Matproof:

1. Open the incident → **Generate report** → **Initial notification**
2. Review the pre-filled report — Matproof pulls in incident details, affected services, and classification rationale
3. Add any additional context required by your NCA
4. Export as PDF or submit via the NCA's reporting portal

<Note>
  Report templates follow the DORA regulatory technical standards (RTS) format. You can customize the template under **Settings → Incident reporting**.
</Note>

Repeat the process at 72 hours for the **intermediate report** and at resolution for the **final report**. Matproof reminds you of each deadline via in-app notification and email.

## Logging resolution steps

As the incident progresses, document your response in the timeline:

* Go to the incident → **Timeline** tab → **Add entry**
* Choose entry type: action taken, status update, escalation, or external communication
* Attach supporting files (runbooks, screenshots, logs)

All timeline entries are timestamped and linked to the responsible team member.

## Post-incident review

After resolution, DORA requires a post-incident analysis to identify root cause and prevent recurrence.

1. Open the incident → **Post-incident review**
2. Complete the review fields:
   * **Root cause** — what caused the incident
   * **Detection gap** — why it was not caught earlier
   * **Response effectiveness** — what worked, what did not
   * **Corrective actions** — tasks to prevent recurrence (linked to your task tracker)
3. Mark the review as complete

<Tip>
  Link corrective actions directly to controls in your compliance framework. This closes the loop between incident management and your ongoing control program.
</Tip>

## Evidence integration

Every incident automatically generates evidence records that attach to relevant DORA controls:

* Incident log → evidence for DORA Art. 17 (ICT-related incident management)
* NCA notification report → evidence for DORA Art. 19 (reporting obligations)
* Post-incident review → evidence for DORA Art. 17 (lessons learned)

View linked evidence on the incident detail page under the **Evidence** tab.

<CardGroup>
  <Card title="Risk Management" icon="shield" href="/features/risk-management">
    Link incident root causes to risks in your risk register
  </Card>

  <Card title="Evidence Collection" icon="folder-open" href="/features/evidence-collection">
    Understand how incident evidence maps to your controls
  </Card>
</CardGroup>


# Penetration Tests
Source: https://docs.matproof.com/features/penetration-tests

Manage penetration testing programs with provider integration, finding tracking, and automated evidence collection.

## Overview

The Penetration Tests module lets you plan, execute, and track penetration testing engagements directly in Matproof. Connect your testing provider, import findings, track remediation, and automatically link results as evidence against the relevant compliance controls.

Penetration testing is required or recommended by most compliance frameworks:

| Framework | Requirement                                                                  |
| --------- | ---------------------------------------------------------------------------- |
| DORA      | TLPT (Threat-Led Penetration Testing) every 3 years for significant entities |
| ISO 27001 | A.18.2.3 - Technical compliance review                                       |
| SOC 2     | CC7.1 - System monitoring and penetration testing                            |
| PCI DSS   | Requirement 11.4 - Annual penetration testing                                |
| NIS2      | Article 21 - Testing effectiveness of cybersecurity measures                 |

<Note>
  Navigate to **Penetration Tests** in the sidebar to access the module.
</Note>

## Creating a test engagement

<Steps>
  ### Define the scope

  1. Go to **Penetration Tests - New Test**
  2. Enter the engagement details:
     * **Name** - descriptive label (e.g., "Q1 2026 External Infrastructure Test")
     * **Type** - External network, internal network, web application, API, mobile, social engineering, or TLPT
     * **Scope** - list the systems, networks, or applications being tested
     * **Provider** - select your testing provider or enter a new one
     * **Scheduled dates** - start and end dates for the engagement
  3. Save the engagement

  ### Execute the test

  The testing provider conducts the engagement. During the test period, the engagement status shows as **In progress** in Matproof.

  ### Import findings

  After the test completes:

  1. Open the engagement
  2. Click **Import findings**
  3. Upload the provider's report (PDF, CSV, or JSON formats supported)
  4. Matproof parses findings and creates individual records for each vulnerability

  You can also add findings manually if needed.
</Steps>

## Finding management

Each finding contains:

| Field                 | Description                                                            |
| --------------------- | ---------------------------------------------------------------------- |
| **Title**             | Short description of the vulnerability                                 |
| **Severity**          | Critical, High, Medium, Low, Informational                             |
| **Description**       | Detailed description including the attack vector and impact            |
| **Affected asset**    | Which system or application is vulnerable                              |
| **Status**            | Open, In remediation, Remediated, Accepted, False positive             |
| **Remediation owner** | Team member responsible for fixing the issue                           |
| **Due date**          | Target date for remediation                                            |
| **Evidence**          | Proof of remediation (screenshot, configuration change, retest result) |

### Remediation workflow

1. Review imported findings and assign owners
2. Set remediation due dates based on severity:
   * Critical: 7 days (recommended)
   * High: 30 days
   * Medium: 90 days
   * Low: next scheduled maintenance window
3. Owners update the finding status as they work through fixes
4. Upload remediation evidence (configuration changes, patches applied, retest results)
5. When all findings are addressed, mark the engagement as **Completed**

<Warning>
  Do not mark critical or high severity findings as **Accepted** without documenting a risk acceptance rationale. Auditors will scrutinize accepted findings, especially for frameworks that require active vulnerability remediation.
</Warning>

## Provider integration

Matproof integrates with penetration testing providers to streamline finding import:

* **Manual upload** - upload the provider's report in PDF, CSV, or JSON
* **API integration** - for providers with API access, configure automatic finding sync

To configure a provider:

1. Go to **Settings - Integrations - Penetration Testing**
2. Select your provider or add a custom one
3. Follow the setup instructions for API-based sync

## Linking to compliance controls

Penetration test results serve as evidence for multiple framework controls. To link findings:

1. Open a completed engagement
2. Click **Link to controls**
3. Matproof suggests relevant controls based on the engagement type and findings
4. Confirm the mapping - the engagement summary and finding status become evidence on those controls

<Tip>
  Set up recurring test engagements (quarterly or annually) and link them to the same controls. This creates a continuous evidence trail that demonstrates ongoing testing over time.
</Tip>

## Scheduling and reminders

Stay on top of your testing program:

1. Go to **Penetration Tests - Schedule**
2. Set up recurring reminders (e.g., "External pentest due every 12 months")
3. Matproof sends notifications 30 days before the next test is due
4. Track compliance with testing schedules from the dashboard

## Reporting

Generate penetration test summary reports:

1. Open a completed engagement
2. Click **Generate report**
3. The report includes: scope, findings by severity, remediation status, and timeline
4. Export as PDF for management review or audit evidence


# People
Source: https://docs.matproof.com/features/people

Manage employees and devices for access reviews, security training, and offboarding compliance.

## Overview

The People module is where you manage the humans in your compliance program — employees, contractors, and team members. It is separate from user accounts: someone can be tracked as an employee in People without having a Matproof login.

Key use cases:

* **Access review evidence** for ISO 27001 A.8.2 and SOC 2 CC6.2
* **Security awareness training** tracking and attestation
* **Offboarding checklists** to ensure access is revoked on departure
* **Device inventory** for ISO 27001 asset management and DORA endpoint security

## The People dashboard

Go to **People → Dashboard** for a real-time compliance overview of your workforce:

* Training completion rate across the team
* Offboarding tasks past due
* Devices with unresolved compliance issues
* Access reviews due or overdue

<Tip>
  Bookmark the People dashboard for your quarterly management review — the completion rates and open tasks make strong evidence of an active compliance program.
</Tip>

## Adding employees

### Manual entry

1. Go to **People → All**
2. Click **Add person**
3. Fill in name, email, role, and department
4. Optionally set their start date and manager

### Import from Google Workspace or Microsoft 365

If you have the Google Workspace or Microsoft 365 integration connected, you can sync your directory automatically:

1. Go to **Settings → Integrations** and connect Google Workspace or Azure AD
2. Go to **People → All → Import**
3. Select your connected directory and click **Sync**

Matproof maps directory users to People records and keeps them in sync. New hires and departures are reflected automatically.

<Note>
  Importing from your HR system is the recommended approach for teams larger than 10. It eliminates manual data entry and ensures your People list stays current.
</Note>

## Employee profile

Each employee record tracks:

| Field             | Purpose                                                      |
| ----------------- | ------------------------------------------------------------ |
| Name and email    | Identity and communication                                   |
| Role / department | Used to scope access reviews and training assignments        |
| Start date        | Triggers onboarding task checklists                          |
| Manager           | Used for offboarding approval flows                          |
| Access rights     | List of systems and permissions (for access review evidence) |
| Training status   | Completion status of assigned security training              |
| Devices           | Linked company devices                                       |
| Status            | Active / Offboarding / Offboarded                            |

## Tracking security training

Assign training to employees and track completion:

1. Open an employee record → **Training** tab
2. Click **Assign training**
3. Select the training module (security awareness, GDPR, acceptable use policy, etc.)
4. Set a due date
5. The employee receives an email with a link to complete it

Matproof records completion timestamps and generates a training log you can export as evidence for auditors.

<Tip>
  Assign security awareness training to all employees at least once a year. ISO 27001 A.6.3 and SOC 2 CC1.4 both require documented training.
</Tip>

## Running access reviews

Access reviews demonstrate that only the right people have access to the right systems — a core requirement for ISO 27001, SOC 2, and NIS 2.

1. Go to **People → All** → click **Start access review**
2. Select scope: all employees or a specific department
3. Reviewers (typically managers) confirm or revoke access for each system
4. Matproof generates a timestamped access review report when complete

<Warning>
  Access reviews must be completed, not just started. Auditors look for the completed report with reviewer sign-off. Incomplete reviews can be a finding.
</Warning>

## Offboarding

When an employee leaves:

1. Open their record → click **Start offboarding**
2. Matproof generates a checklist: revoke system access, collect devices, archive accounts, notify HR, etc.
3. Each task is assigned to a responsible person with a due date
4. Mark tasks complete as they are done
5. Close the offboarding when all tasks are done

The completed offboarding record serves as evidence that access was revoked in a timely manner.

## Devices

Go to **People → Devices** to see every device registered against an employee, what compliance signals it's reporting, and any open vulnerabilities.

### How devices get into Matproof

Three ways:

1. **Matproof Device Agent (recommended)** — install the [Matproof Device Agent](/features/device-agent) on each user's machine. The agent reports endpoint compliance signals every hour (FileVault, screen lock, OS patch level, antivirus, firewall, MDM enrollment) plus a 6-hourly software inventory matched against the NVD CVE database. This is the path that produces actual evidence on endpoint controls.
2. **MDM sync** — if you operate an MDM (Jamf, Kandji, Microsoft Intune), connect it as an integration. Matproof imports the device list and combines it with what the device agent reports.
3. **Manual entry** — for devices that can't run the agent (Linux until GA, vendor-managed machines), add them by hand for asset-inventory purposes.

The Matproof Device Agent and an external MDM are not mutually exclusive — use the agent for compliance signals and the MDM for fleet management; Matproof reconciles them.

### What's tracked per device

| Field                              | Compliance relevance                                                     |
| ---------------------------------- | ------------------------------------------------------------------------ |
| Device name and type               | Asset inventory (ISO 27001 A.8.1)                                        |
| Assigned to                        | Links device to employee                                                 |
| OS and version, patch freshness    | DORA Article 9, ISO 27001 A.8.8                                          |
| Encryption (FileVault / BitLocker) | ISO 27001 A.8.24, DORA Article 9, HIPAA 164.312(a)(2)(iv)                |
| Screen lock and idle timeout       | ISO 27001 A.7.7, SOC 2 CC6.6                                             |
| Firewall status                    | ISO 27001 A.8.20, NIS 2 Article 21                                       |
| Antivirus + signature freshness    | ISO 27001 A.8.7                                                          |
| MDM enrollment                     | Validated by the agent, optionally sourced from external MDM             |
| `vulnerableAppsCount`              | CVE-matched installed software (Tier 3A); ISO 27001 A.8.8, PCI DSS 6.3.1 |
| Last seen                          | Activity tracking                                                        |

Failed checks and high-severity CVEs raise [Findings](/features/findings) automatically and surface against the relevant control.

<CardGroup>
  <Card title="Matproof Device Agent" icon="laptop" href="/features/device-agent">
    The agent that produces endpoint compliance evidence
  </Card>

  <Card title="ISO 27001 A.8" icon="shield-check" href="/frameworks/iso27001">
    Asset inventory + endpoint security control family
  </Card>
</CardGroup>


# Plans & Pricing
Source: https://docs.matproof.com/features/plans

Compare Matproof Free, Starter, Professional, and Enterprise plans.

# Plans & Pricing

Matproof offers four plans. New organisations start a 14-day trial with no credit card up front; during the trial the organisation runs with Starter limits. Pick a plan before the trial ends to keep working without interruption.

| Plan             | Price (monthly) | Price (yearly)           | Frameworks | Team members | Integrations    |
| ---------------- | --------------- | ------------------------ | ---------- | ------------ | --------------- |
| **Free**         | €0              | €0                       | 1          | 3            | 0               |
| **Starter**      | €480 / mo       | €384 / mo (€4,608 / yr)  | 1          | 10           | 10              |
| **Professional** | €1,200 / mo     | €960 / mo (€11,520 / yr) | 3          | 50           | 100             |
| **Enterprise**   | Custom          | Custom                   | Unlimited  | Unlimited    | Unlimited + API |

> The **Free** plan is intentionally minimal — most organisations go straight into the 14-day trial. Free is the safe default for accounts where billing has lapsed or no plan has been chosen.

## What's Included

### Free

* 1 compliance framework
* Up to 3 team members
* Compliance dashboard and gap analysis
* View-only access to controls and tasks
* Community support

### Starter — €480/mo or €384/mo billed yearly

Everything in Free, plus:

* Up to 10 team members
* 10 integrations
* Basic evidence automation
* Policy templates library
* Email support

### Professional — €1,200/mo or €960/mo billed yearly

Everything in Starter, plus:

* Up to 3 frameworks
* Up to 50 team members
* 100 integrations
* Advanced evidence automation
* AI policy generator
* Vendor risk management
* Trust center
* Priority support

### Enterprise — Custom

Everything in Professional, plus:

* Unlimited frameworks (including custom frameworks)
* Unlimited team members
* Unlimited integrations and API access
* Enterprise evidence automation
* Advanced vendor risk and TPRM
* Custom trust center
* Dedicated success manager
* SSO / SAML
* Optional self-hosting

## Trial

Every new organisation starts on a **14-day trial** with no credit card required. A banner counts down the remaining days. The trial window is managed in Stripe: extending it or ending it early happens there, and the app mirrors the date. When the trial ends without a plan, the organisation falls back to the Free plan.

## Included in every plan

* **AI provider choice** — Under Settings → AI provider an admin picks where the platform's AI runs: **Standard** (OpenAI and Anthropic) or **Mistral AI** (Paris, EU). The choice applies to all AI features of the organisation. It is included in every plan.
* **EU data residency for search** — Vector search embeddings run on an EU provider for every plan. Organisations with Confidential AI Mode get embeddings inside the attested enclave as well.

## Penetration testing

Penetration testing is a separate subscription, independent of the compliance plan. Manage it under Settings → Billing.

| Tier                   | Price               | Included                                                                                                                                                                         |
| ---------------------- | ------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Pentest Starter**    | €299 / month        | 3 full pentest runs per month, GitHub App with auto-created issues, up to 50 target URLs per scan, PDF / Markdown / SARIF / JSON export, SOC 2 / ISO 27001 / DORA / NIS2 mapping |
| **Pentest Growth**     | €1,490 / month      | 20 runs per month (additional runs €149 each), Cloud (AWS) and Mobile agents, continuous schedules, authenticated scanning, webhook delivery, priority support                   |
| **Pentest Enterprise** | From €2,499 / month | Custom scope, dedicated environments, custom evidence mapping                                                                                                                    |

Organisations that received penetration testing through an invite, a trial or a manual activation by Matproof see it as active under Billing without a Stripe subscription.

## Add-on modules

These modules are activated per organisation by Matproof after a conversation. Billing shows which ones are active and offers a contact link for the rest.

| Module                          | What it does                                                                                                                      |
| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
| **Cloud Security Posture**      | CSPM across AWS, Azure and GCP; misconfigurations become framework evidence                                                       |
| **Shadow AI Discovery**         | Finds AI tools in use across the organisation and brings them under governance                                                    |
| **Threat-Led Scenario Testing** | Runs ATT\&CK kill chains for DORA Art. 25 scenario testing                                                                        |
| **Confidential AI Mode**        | Inference and embeddings run in an EU attested enclave (AMD SEV-SNP). When active it takes precedence over the AI provider choice |

## Metered limits

* **Security questionnaires** — 5 per month (Starter), 50 per month (Professional), unlimited (Enterprise)
* **Device agent endpoints** — included; volume pricing on Enterprise

## Self-Hosting

Enterprise customers can self-host Matproof on their own infrastructure. See [Self-Hosting](/self-hosting/docker) for the Docker deployment guide and the EU sovereignty story.

## Frequently Asked Questions

**Can I switch plans?** Yes — upgrade or downgrade any time from Settings > Billing. Upgrades are pro-rated; downgrades take effect at the end of the current billing period.

**Do you offer non-profit or startup pricing?** Yes, contact [sales@matproof.com](mailto:sales@matproof.com).

**What payment methods do you accept?** Credit card via Stripe (all major cards). Enterprise customers can pay by SEPA bank transfer or invoice.

**Are prices in USD or EUR?** Prices are in EUR. USD-denominated billing is available on request for Enterprise customers.

<CardGroup>
  <Card title="Start your trial" href="https://app.matproof.com">
    Spin up an organization in under 5 minutes
  </Card>

  <Card title="Contact sales" href="mailto:sales@matproof.com">
    Talk to us about Enterprise pricing
  </Card>
</CardGroup>


# Policy Management
Source: https://docs.matproof.com/features/policy-management

AI-generated policies in 6 languages, mapped to your compliance frameworks, with versioning and acknowledgement tracking.

# Policy Management

Matproof generates a complete policy library pre-mapped to your active frameworks. Policies are produced in your chosen language (German, English, French, Spanish, Italian, or Dutch), version-controlled, and ready for review — so you start from a draft tailored to your organization, not a blank page.

## Languages

When you set up your organization, you pick a **policy language** — the language Matproof generates policies in. Supported languages:

| Language | Code |
| -------- | ---- |
| German   | `de` |
| English  | `en` |
| French   | `fr` |
| Spanish  | `es` |
| Italian  | `it` |
| Dutch    | `nl` |

You can change the policy language at any time in **Settings → Organization**.

### Also generate English

DACH organizations often need parallel English versions of policies for international auditors, customers, or partners. Enable **Also generate English** in Settings to have Matproof produce both your primary-language version and an English version of every policy. The two versions stay in sync — when you edit one, the other can be regenerated to match.

This is independent of the UI locale (the language the Matproof app itself displays in). You can run the app in German while generating policies in French.

## Included policies

| Policy                      | Frameworks satisfied         |
| --------------------------- | ---------------------------- |
| Information Security Policy | ISO 27001, SOC 2, DORA, NIS2 |
| Acceptable Use Policy       | ISO 27001, SOC 2             |
| Access Control Policy       | ISO 27001, SOC 2, DORA       |
| Incident Response Plan      | ISO 27001, SOC 2, DORA, NIS2 |
| Business Continuity Plan    | ISO 27001, DORA              |
| Disaster Recovery Plan      | ISO 27001, DORA              |
| Data Protection Policy      | GDPR, ISO 27001              |
| Vendor Management Policy    | ISO 27001, DORA, GDPR        |
| Change Management Policy    | ISO 27001, SOC 2, DORA       |
| Risk Management Policy      | ISO 27001, SOC 2, DORA       |
| Cryptography Policy         | ISO 27001                    |
| Physical Security Policy    | ISO 27001                    |
| AI Use Policy               | EU AI Act, ISO 42001         |
| Sustainability Policy       | CSRD / ESRS                  |
| Supply Chain ESG Policy     | CSRD / ESRS                  |

Custom frameworks can declare their own required policies — see [Custom Frameworks](/features/custom-frameworks).

## Generating policies

<Steps>
  <Step title="Open Policies → Generate">
    From the sidebar, go to **Policies → Generate**. Matproof shows the policies suggested by your active frameworks.
  </Step>

  <Step title="Pick which policies to draft">
    Click **Generate all**, or select specific policies. Drafting takes 1–3 minutes per policy.
  </Step>

  <Step title="Review the draft in the editor">
    Each generated policy opens in the [AI Policy Editor](/features/ai-policy-editor) with sections, headings, and framework alignment notes already in place.
  </Step>

  <Step title="Customize">
    Edit, rewrite, or accept as-is. The AI's draft is calibrated from your setup-wizard answers (industry, size, geography, work pattern), so it's usually 70–80% right out of the box.
  </Step>

  <Step title="Set review dates and assign owners">
    Each policy needs a designated owner and a review cadence (typically annual). Auditors check both.
  </Step>

  <Step title="Publish">
    Click **Publish**. The policy becomes available for team acknowledgement and counts as evidence on the controls it satisfies.
  </Step>
</Steps>

## The Policy Editor

The editor supports:

* **Rich text** — headings, lists, tables, callouts
* **Inline AI suggestions** — highlights gaps against framework requirements; offers stronger language where auditors expect specifics
* **Multi-language toggle** — if "Also generate English" is enabled, switch between primary language and English views without losing edits
* **Version history** — every save is a version; restore any prior version; diff between versions
* **Comments** — inline comments for reviewers
* **Approval workflow** — submit → review → approve, with the approval timestamp and reviewer name preserved as audit evidence

See [AI Policy Editor](/features/ai-policy-editor) for the editor's deeper capabilities.

## Publishing and acknowledgements

When you publish a policy:

* Team members in the relevant role receive a notification
* They can acknowledge reading the policy in the platform
* Acknowledgement rate is tracked and exposed as evidence on training/awareness controls
* For mandatory policies (typically driven by ISO 27001 or DORA), unacknowledged users surface as a finding

You can require **re-acknowledgement** when a policy is materially updated — useful for major policy changes (new incident reporting timeline, updated access control rules).

## Version control

Matproof keeps full version history on every policy:

* Saving creates a version automatically — you cannot lose work
* Previous versions are archived (never deleted) and accessible from the policy header
* The change log records who changed what and when
* Affected team members are notified of material updates
* Re-acknowledgement can be required on update

This audit trail satisfies ISO 27001 A.5.1 (policies for information security), SOC 2 CC2.2 (communication of policies), and DORA Article 5 (governance and organisation).

## Exporting policies

Export individual policies or the full policy library:

* **PDF** — for distribution and audit packages (includes approval status, version, last review date)
* **Word (`.docx`)** — for further editing outside Matproof
* **ZIP bundle** — full policy library at the current version, organized by framework

Open any policy and click **Export**, or go to **Policies → Export library** for the bundle.

<CardGroup>
  <Card title="AI Policy Editor" href="/features/ai-policy-editor">
    Editor capabilities and inline AI suggestions
  </Card>

  <Card title="Frameworks" href="/features/compliance-frameworks">
    How policies link to framework controls
  </Card>

  <Card title="Evidence Collection" href="/features/evidence-collection">
    Acknowledgements and version history as control evidence
  </Card>
</CardGroup>


# AI Questionnaire
Source: https://docs.matproof.com/features/questionnaire-ai

Auto-fill vendor security questionnaires and send assessments to your own vendors — powered by your existing controls and policies.

## Overview

The AI Questionnaire module handles both sides of the vendor assessment process:

<CardGroup>
  <Card title="Respond to customers" icon="inbox">
    Customers send you a security questionnaire. Matproof reads your existing policies, controls, and evidence to auto-fill the answers.
  </Card>

  <Card title="Assess your vendors" icon="paper-plane">
    You send a questionnaire to a vendor. Track their responses and score their security posture from one place.
  </Card>
</CardGroup>

<Note>
  AI Questionnaire is included on every plan. Per-month answer-generation quotas vary by tier — see [Plans & Pricing](/features/plans).
</Note>

## Importing a questionnaire

Matproof accepts the most common formats used in vendor assessments:

* **SIG Lite** (Shared Assessments)
* **CAIQ** (Cloud Security Alliance)
* **Custom Excel or Word** questionnaires

**To import:**

1. Go to **Questionnaire** (`/[orgId]/questionnaire`)
2. Click **New Questionnaire**
3. Select the type: **Respond** (incoming from customer) or **Send** (outgoing to vendor)
4. Upload the file or paste the questions directly
5. Matproof parses the questions and displays them in the editor

For outgoing questionnaires, enter the vendor's name and email. Matproof sends them a link to complete the form.

## AI auto-fill (responding to customers)

When you receive a questionnaire from a customer, Matproof's AI reads each question and matches it against:

* Your published **policies**
* Your mapped **controls** and their evidence
* Your **knowledge base** of saved standard answers

**To run auto-fill:**

1. Open the imported questionnaire
2. Click **Auto-fill with AI**
3. Review each answer — green means high confidence, yellow means review recommended
4. Edit any answers before exporting

<Tip>
  Auto-fill accuracy improves over time as you add more evidence and refine your knowledge base. Run it even on your first questionnaire — it handles most standard questions out of the box.
</Tip>

<Warning>
  Always review AI-generated answers before sending. The AI works from your documented controls — if a control is not yet documented in Matproof, the answer may be incomplete.
</Warning>

## Knowledge base

The knowledge base stores your approved answers to common security questions so they can be reused across questionnaires without re-generating them each time.

**To manage:**

1. Go to **Questionnaire** → **Knowledge Base** (`/[orgId]/questionnaire/knowledge-base`)
2. Add a question-answer pair manually, or save an answer directly from a questionnaire you have already reviewed
3. Tag answers by topic (e.g., access control, encryption, incident response) for faster retrieval

When AI auto-fill runs on a new questionnaire, it checks the knowledge base first before generating a new answer. If a match is found, the saved answer is used directly.

## Statement of Applicability (SOA)

The SOA is an ISO 27001 requirement. It lists every control from Annex A and states whether it applies to your organization, and if not, why it is excluded.

**To generate your SOA:**

1. Go to **Questionnaire** → **SOA** (`/[orgId]/questionnaire/soa`)
2. Matproof pre-populates applicability based on the frameworks you have activated and the controls you have mapped
3. Review each control — mark as **Applicable**, **Not applicable**, or add an exclusion justification
4. Export as PDF or Excel for your ISO 27001 audit

<Note>
  The SOA must be reviewed and updated at least annually under ISO 27001. Matproof tracks when the SOA was last modified so you can demonstrate this to auditors.
</Note>

## Sending questionnaires to vendors

Use this flow when you need to assess a third-party vendor's security before onboarding them or as part of annual vendor reviews.

1. Go to **Questionnaire** → **New Questionnaire** → **Send to Vendor**
2. Select a template (SIG Lite is recommended for most vendor assessments) or upload a custom one
3. Enter the vendor's name and contact email
4. Set a response deadline
5. Send — the vendor receives a link to fill in the form directly (no Matproof account required)

Responses are collected in the questionnaire view. You can score each section and attach the completed questionnaire to the vendor's record in Matproof's vendor risk module.

<Tip>
  Pair vendor questionnaire results with your [Vendor Risk](/features/vendor-risk) module to build a complete risk profile for each third party.
</Tip>

## Exporting responses

Once you have reviewed and finalized your answers:

1. Open the questionnaire
2. Click **Export**
3. Choose the output format: **Excel**, **Word**, or **PDF**

The exported file preserves the original structure of the questionnaire with your answers filled in, so it is ready to send back to the customer without reformatting.


# Roles & Permissions
Source: https://docs.matproof.com/features/rbac-roles

Role-based access control in Matproof — five built-in roles plus organization-defined custom roles.

# Roles & Permissions

Matproof uses role-based access control to ensure team members only see and do what their role requires. Every team member is assigned exactly one role per organization.

## Built-in roles

Matproof ships five built-in roles. These cover most team structures and cannot be deleted.

| Role           | Typical user                                        | What they can do                                                                                    |
| -------------- | --------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
| **Owner**      | Founder, CEO, organization creator                  | Everything: settings, billing, role management, delete organization                                 |
| **Admin**      | CISO, compliance lead, head of security             | Everything except billing and deleting the organization                                             |
| **Auditor**    | External auditor, internal audit team, board member | Read-only across the program — view controls, evidence, policies, reports — cannot create or modify |
| **Employee**   | Engineering, finance, HR, operations team members   | Submit evidence, complete assigned tasks, acknowledge policies, view their own assignments          |
| **Contractor** | External consultant, agency, temporary staff        | Same as Employee but flagged as non-employee for offboarding and access-review evidence             |

The Auditor role is intentionally narrow — assign it to external audit firms during an audit window so they can review your program without modifying it. The Employee and Contractor roles are intentionally similar in product capability; the distinction is for audit reporting (some frameworks require contractor counts to be tracked separately).

## Assigning a role

<Steps>
  <Step title="Open the team member's profile">
    Go to **People** and click into the team member.
  </Step>

  <Step title="Set their role">
    Click **Role** and pick from the five built-in roles or any custom role your organization has defined.
  </Step>

  <Step title="Confirm">
    The new role takes effect immediately. The change is recorded in the [Audit Trail](/features/audit-trail).
  </Step>
</Steps>

## Custom roles

If the five built-in roles don't fit, define custom roles with a tailored permission set. Common patterns: an "Evidence Reviewer" who can approve evidence but not modify frameworks, a "Department Lead" who can manage their team's controls without seeing the rest of the program, or a "Vendor Manager" focused on the vendor-risk module.

### Creating a custom role

1. Go to **Settings → Roles & Permissions**
2. Click **New role**
3. Name it (e.g. "Evidence Reviewer", "DPO Read-Only", "Vendor Owner")
4. Pick the permissions to grant — toggles per module (Frameworks, Controls, Policies, Evidence, Risks, Vendors, Audit Programs, etc.) with View / Create / Edit / Delete / Approve actions
5. Save — the custom role is now assignable to team members

### Best practices for custom roles

* **Start narrow.** Grant the minimum permissions needed; widen only when someone hits a wall. It's easier to grant more access than to reclaim it.
* **Don't recreate the built-ins.** If you need "everything except billing," use Admin. If you need "read-only," use Auditor.
* **Document the role's purpose** in the description field so future admins know why it exists.

## Audit trail

Every role assignment, custom-role definition, and permission change is recorded in the [Audit Trail](/features/audit-trail) with timestamp, actor, and the before/after state. Most frameworks (ISO 27001 A.5.15–A.5.18, DORA Article 9, NIS2 Article 21, SOC 2 CC6.1) require this evidence — Matproof produces it automatically.

## Best practices

* Keep **Owner** to one or two people; treat it like root access
* Default new team members to **Employee**; promote to **Admin** only when needed
* Use **Auditor** for external auditors; revoke after the audit window closes
* Review role assignments quarterly — assign the review as a [corrective action](/features/corrective-actions) so the review itself is documented

<CardGroup>
  <Card title="People" href="/features/people">
    Add team members, assign roles, manage devices
  </Card>

  <Card title="Audit Trail" href="/features/audit-trail">
    Where all role changes are logged
  </Card>
</CardGroup>


# Risk Management
Source: https://docs.matproof.com/features/risk-management

Identify, assess, and treat risks across your compliance program.

## Overview

Matproof's risk management module helps you identify, document, and track risks — with automatic linkage to the controls designed to mitigate them.

## Risk register

The risk register is your central view of all identified risks.

Each risk includes:

* **Risk ID** — unique identifier
* **Category** — cybersecurity, operational, compliance, financial, etc.
* **Description** — what the risk is
* **Likelihood** — probability (1-5)
* **Impact** — severity (1-5)
* **Inherent risk score** — Likelihood × Impact (before controls)
* **Residual risk score** — risk remaining after controls
* **Owner** — accountable person
* **Treatment** — accept, mitigate, transfer, avoid
* **Controls** — linked controls that reduce this risk
* **Status** — open, in treatment, accepted, closed

## Risk scoring

Matproof uses a 5×5 risk matrix:

```
Impact:  1 (Negligible) → 5 (Critical)
Likelihood: 1 (Rare) → 5 (Almost certain)

Risk score = Likelihood × Impact
  1-5:   Low (green)
  6-12:  Medium (amber)
  13-19: High (red)
  20-25: Critical (dark red)
```

## Risk treatment

For each risk, select a treatment:

| Treatment    | When to use                                       |
| ------------ | ------------------------------------------------- |
| **Mitigate** | Implement controls to reduce likelihood or impact |
| **Accept**   | Risk is within tolerance; no action needed        |
| **Transfer** | Insurance, contract clauses, outsourcing          |
| **Avoid**    | Stop the activity that creates the risk           |

Accepted risks require documented justification and periodic review.

## Linking risks to controls

When you add a control to a risk, Matproof tracks how effective the control is at reducing the risk score.

Example:

```
Risk: Unauthorized access to production database
  Inherent: Likelihood 4 × Impact 5 = 20 (Critical)

Controls applied:
  ✓ MFA enforced on all accounts
  ✓ Database access requires VPN
  ✓ Access reviewed quarterly

  Residual: Likelihood 2 × Impact 5 = 10 (Medium)
```

## Framework mapping

Risks are automatically linked to relevant framework requirements:

* **ISO 27001 Annex A** — risk treatment maps to controls
* **DORA Art. 5-6** — ICT risk management requirements
* **CSRD ESRS 2** — sustainability risk identification requirement

## Risk assessment export

Export your risk register for:

* Audit evidence (ISO 27001, SOC 2)
* Board reporting
* CSRD IRO documentation
* DORA risk management report

Available in Excel, PDF, or JSON format.


# Sentinel Methodology
Source: https://docs.matproof.com/features/sentinel-methodology

How Matproof Sentinel runs penetration tests — the agents, the tools, what we test, what we don't claim, and how findings map to compliance frameworks.

## What Sentinel is

Matproof Sentinel is an AI-orchestrated penetration testing engine built in-house. Each scan is driven by ten specialised agents that coordinate to enumerate, probe, and validate a target's attack surface — then ship a structured report with findings mapped to your active compliance frameworks (DORA, NIS2, ISO 27001, SOC 2, PCI DSS, HIPAA, NEN 7510).

This page is the technical methodology reference. If you need the customer-facing workflow guide instead — how to create scans, view reports, mark findings remediated — see [Penetration Tests](/features/penetration-tests).

## The agents

A scan runs ten agents in five staged groups. Each agent has a narrow remit, its own toolchain, and writes structured findings to a shared store. The orchestrator coordinates dependencies between them.

<AccordionGroup>
  <Accordion title="Stage 1 · ReconAgent">
    **Goal:** Map the target's attack surface.

    **Tools:** `nmap` (port scan + service detection), `subfinder` (passive DNS subdomain enumeration), `amass intel` (OSINT — ASNs, netblocks, related domains), `dnsx` (DNS resolution), `httpx` (HTTP probing, technology fingerprinting, TLS, headers).

    **Emits:** open ports, live subdomains, server versions, exposed paths, weak TLS configurations, missing security headers.
  </Accordion>

  <Accordion title="Stage 2 · InfraAgent">
    **Goal:** Test TLS, DNS security, and infrastructure hygiene at depth.

    **Tools:** `testssl.sh` (TLS deep audit), `nmap` with NSE scripts, DNS-security probes (SPF, DKIM, DMARC, CAA, DNSSEC), cloud bucket probes (S3 / GCS / Azure unintended-public-access checks).

    **Emits:** weak ciphers, expired/misconfigured certs, missing email-auth records, exposed buckets, missing DNS security records.
  </Accordion>

  <Accordion title="Stage 2 · WebAppAgent">
    **Goal:** Black-box web application testing against discovered HTTP surface.

    **Tools:** `nuclei` (CVE templates + exposure templates), `sqlmap` (SQL injection), `ffuf` (directory/file fuzzing), `jwt_tool` (JWT analysis), raw HTTP probes.

    **Emits:** known CVEs on detected stacks, SQLi, exposed admin paths, insecure JWT validation, sensitive file exposure.
  </Accordion>

  <Accordion title="Stage 2 · BrowserAgent (DAST)">
    **Goal:** Catch JS-rendered vulnerabilities the HTTP-only agents miss.

    **Tools:** OWASP ZAP daemon — AJAX Spider (Selenium-driven JS rendering) + traditional spider + active scan, DOM XSS detection.

    **Emits:** DOM-based XSS, client-side prototype pollution, JS-rendered authentication issues.
  </Accordion>

  <Accordion title="Stage 2 · CloudAgent (opt-in)">
    **Goal:** Audit your cloud account configuration when you provide a read-only STS role.

    **Tools:** `prowler` (AWS-focused, \~300 controls covering CIS / NIST / PCI).

    **Emits:** IAM misconfigurations, exposed storage, missing CloudTrail / encryption, untagged production resources.

    **Opt-in:** disabled by default. Activate by passing `cloud_audit` config at scan creation.
  </Accordion>

  <Accordion title="Stage 2 · MobileAgent (opt-in)">
    **Goal:** Static analysis of mobile binaries (iOS .ipa, Android .apk).

    **Tools:** MobSF (Mobile Security Framework).

    **Emits:** hardcoded secrets, insecure cryptography, weak SSL pinning, exposed components, insecure data storage.

    **Opt-in:** disabled by default. Provide a `mobile_binary_path` to enable.
  </Accordion>

  <Accordion title="Stage 3 · ApiAgent">
    **Goal:** Property-based API fuzzing on discovered OpenAPI / GraphQL surfaces.

    **Tools:** OpenAPI auto-discovery, Schemathesis property-based fuzzing.

    **Emits:** broken object-level authorization (BOLA), broken function-level authorization (BFLA), mass assignment, schema-violation responses.

    **Dependency:** runs after WebAppAgent so endpoint discovery is complete.
  </Accordion>

  <Accordion title="Stage 3 · SourceCodeAgent (opt-in)">
    **Goal:** Static analysis of your source code when you connect a repo.

    **Tools:** `semgrep` (SAST across 1000+ rules covering OWASP Top 10, language-specific patterns), `gitleaks` (committed-secret scanning including git history), pattern grep for custom rules.

    **Emits:** code-level vulnerabilities (SQLi, XSS, command injection), secrets in code, historical secret commits, unsafe deserialisation, insecure cryptography use.

    **Opt-in:** triggered by providing `repoUrl` at scan creation. Authentication via either the Matproof GitHub App (recommended), OAuth, or a Personal Access Token.
  </Accordion>

  <Accordion title="Stage 4 · SupplyChainAgent (opt-in)">
    **Goal:** Vulnerability surface from dependencies, containers, and IaC.

    **Tools:** `trivy` (npm/pip/maven/etc CVE scan + container image CVE scan + IaC misconfiguration scan + secret scan).

    **Emits:** vulnerable dependencies (with CVE + CVSS + remediation paths), exposed secrets in IaC, container CVEs, Terraform/Helm/Dockerfile misconfigurations.

    **Dependency:** reuses the SourceCodeAgent's clone — same opt-in gate.
  </Accordion>

  <Accordion title="Stage 5 · ValidatorAgent">
    **Goal:** Confirm or reject findings by reproducing them.

    For each non-INFO finding from earlier agents, the ValidatorAgent re-probes the target with a targeted reproduction attempt, then attaches one of:

    * `VALIDATED` — confirmed exploitable with PoC evidence
    * `UNVERIFIED` — could not reproduce in available time, finding still ships
    * `FALSE_POSITIVE` — verified non-issue and demoted in the report

    Validated findings ship with concrete PoC payloads, request/response pairs, and step-by-step reproduction details. Unverified findings stay visible because absence of a successful reproduction is not absence of vulnerability — it's signal you can investigate manually.
  </Accordion>
</AccordionGroup>

## What we test

| Layer            | Agents                   | Surface                                                    |
| ---------------- | ------------------------ | ---------------------------------------------------------- |
| Reconnaissance   | Recon                    | Subdomains, ports, TLS, headers, technology fingerprinting |
| Network/Infra    | Infra                    | TLS depth, DNS security, cloud bucket probes               |
| HTTP application | WebApp + Browser         | OWASP Top 10 patterns, CVE templates, DOM XSS              |
| API              | Api                      | OpenAPI / GraphQL fuzzing, BOLA / BFLA                     |
| Source code      | SourceCode + SupplyChain | SAST + secrets + dependencies + IaC + containers           |
| Cloud (opt-in)   | Cloud                    | AWS configuration audit via Prowler                        |
| Mobile (opt-in)  | Mobile                   | Static analysis of .ipa / .apk binaries                    |
| Validation       | Validator                | Exploit reproduction for every non-INFO finding            |

## What we don't claim

A penetration test that's worth its compliance evidence is honest about its limits. Sentinel makes the following explicit non-claims:

* **No social-engineering testing.** Phishing, vishing, physical access. If your framework requires red-team SE assessment (TLPT under DORA Article 26 for significant entities), you still need a human red team for that workstream.
* **No destructive testing.** Sentinel does not run payloads that modify data, drop tables, escalate privileges with write side-effects, or trigger DoS conditions. Validated findings stop at the boundary of demonstrating exploitability.
* **No zero-day discovery.** Sentinel finds known-vulnerability classes (CVEs, OWASP patterns, misconfigurations). Discovering novel zero-days requires human exploit research and is out of scope.
* **No human verification.** Findings are produced by AI agents and validated by an AI agent. We mark validated findings as such, but we do not employ a human pentester to manually re-confirm every result before report delivery. For evidence-quality requirements beyond what Sentinel produces, engage a human firm.
* **No business-logic discovery beyond template patterns.** Sentinel catches business-logic issues that match well-known patterns (BOLA, mass assignment, BFLA), but it does not deeply reason about your domain's specific business rules.

## Compliance framework coverage

Every finding Sentinel emits is automatically tagged with references to the compliance controls it satisfies. This is the mapping per finding category, used by the matproof platform to populate evidence rows on the relevant framework requirements.

| Framework           | Article / Control                                                                                       | Sentinel coverage                                                                                              |
| ------------------- | ------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| DORA                | Art. 24-27 — Digital operational resilience testing                                                     | All scans satisfy basic DORA Art. 25 testing. TLPT (Art. 26) requires human red team for significant entities. |
| NIS2                | Art. 21 — Risk-management measures, technical effectiveness                                             | All scans                                                                                                      |
| ISO 27001           | A.8.8 Technical vulnerability management; A.8.29 Security testing; A.18.2.3 Technical compliance review | All scans                                                                                                      |
| SOC 2               | CC7.1 System monitoring & penetration testing                                                           | All scans                                                                                                      |
| PCI DSS             | Requirement 11.4 — annual penetration testing                                                           | All scans (with caveats — PCI scope requires segmentation testing also)                                        |
| HIPAA               | §164.308(a)(8) Periodic technical evaluation                                                            | All scans                                                                                                      |
| BaFin MaRisk / BAIT | AT 7.2 Tz. 13 — Penetration testing of critical systems                                                 | All scans                                                                                                      |
| NEN 7510            | A.18.2.3 — Independent review of information security                                                   | All scans                                                                                                      |

The mapping logic is in `apps/api/src/security-penetration-tests/control-mapping.ts` if you want to inspect the per-finding rules.

## Authentication & scoping

**Target authorization.** Sentinel will not scan a target until you've proven domain ownership via either DNS TXT or HTTP file challenge. This is a hard requirement enforced at scan creation; it protects both Matproof and customers from accidental scans of third-party infrastructure.

**Authenticated scanning.** Many real vulnerabilities only manifest behind login. You can pass session cookies or Bearer tokens at scan creation via the `authHeaders` field — Sentinel includes them on every HTTP probe so the agents can test post-login surface (IDOR, privesc, mass assignment).

**Multi-target scope.** A single scan can include the primary target plus up to 50 additional target URLs. Useful when your domain hosts multiple apps (qa1/qa2/qa3/dev/api) and you want all of them in scope explicitly rather than relying on subdomain auto-pivot.

**Source-code access.** Three options in order of preference:

1. **GitHub App** (recommended): you install Matproof Sentinel on your GitHub org and choose exactly which repositories we can read. Works regardless of org-level third-party OAuth-app policies.
2. **OAuth**: simpler one-click flow, but blocked by orgs that restrict third-party OAuth apps.
3. **Personal Access Token**: paste a classic GitHub PAT with `repo` scope. Works for any user.

## Data handling

* **Scan inputs** (target URLs, auth headers, repo URLs, configuration) are stored encrypted at rest on EU infrastructure.
* **Findings** are persisted in the Matproof database (EU region) and linked to your organization. We don't share findings across tenants.
* **Source code** cloned during a scan is processed in a temporary workspace and deleted after the scan finishes. Source code is never persisted beyond the scan's lifetime; only the resulting findings + line references remain.
* **Reports** (Markdown + PDF + SARIF) are retained for the lifetime of your account. You can delete a scan and its report at any time via the API; cascading deletes remove findings, agent error logs, and webhook delivery records.
* **AI provider** (Anthropic) sees the target URL, scan configuration, and tool outputs for the agent's reasoning step. Anthropic does not retain customer data per our enterprise agreement.

## Deliverables

Every completed scan produces:

* **Markdown report** with executive summary, per-severity findings, per-agent coverage, and remediation guidance per finding.
* **PDF report** suitable for compliance auditors.
* **SARIF 2.1.0 export** for ingestion into GitHub Advanced Security, GitLab, or Azure DevOps.
* **Evidence rows** linked to every relevant compliance requirement in your active frameworks — populated automatically via the per-finding control mapping.

## Reproducibility

Scan inputs and outputs are deterministic with respect to the target's state at the time of scanning. Re-running the same scan a week later will produce different findings if the target has changed (new code deployed, patches applied, new subdomains added) — which is what you want from a continuous-testing program.

The full agent execution log, including every tool invocation and its raw output, is retained server-side for audit. Available on request via the API; not shown in the customer-facing report to keep it readable.


# Trust Center
Source: https://docs.matproof.com/features/trust-center

A public-facing security portal that shows customers and prospects your compliance posture.

## Overview

The Trust Center is a hosted public page where security teams, procurement officers, and prospects can review your security posture without sending you a questionnaire. You share a link — they self-serve.

It displays your active certifications, compliance frameworks, published policies, uptime status, and data residency information. For sensitive documents you can require visitors to sign an NDA before gaining access.

<Tip>
  Send your Trust Center link early in enterprise sales cycles to pre-empt security review delays. Many vendor assessments can be closed without a back-and-forth questionnaire.
</Tip>

## What your Trust Center shows

<CardGroup>
  <Card title="Certifications" icon="seal-check">
    ISO 27001, SOC 2, and other certificates you have uploaded to Matproof, with expiry dates.
  </Card>

  <Card title="Compliance frameworks" icon="list-check">
    Frameworks you are actively working toward or have completed, such as GDPR, NIS2, or DORA.
  </Card>

  <Card title="Security policies" icon="file-lines">
    Published policies from your policy library — only ones you explicitly make visible appear here.
  </Card>

  <Card title="Uptime and reliability" icon="chart-line">
    Current and historical uptime, pulled from your linked status page.
  </Card>

  <Card title="Data residency" icon="globe">
    Where your customer data is stored and processed.
  </Card>

  <Card title="NDA-gated documents" icon="lock">
    Sensitive documents that require a signed NDA before the visitor can download them.
  </Card>
</CardGroup>

## Setting up your portal

1. Go to **Trust Center** → **Portal Settings** (`/[orgId]/trust/portal-settings`)
2. Upload your company logo
3. Set the public display name
4. Add a short description of your security program
5. Configure data residency and uptime settings
6. Save — your portal is live at your unique Trust Center URL

<Note>
  The Trust Center URL is public but unlisted. Anyone with the link can view it. If you want to restrict access, use the NDA gate described below.
</Note>

## Publishing documents

You control exactly which policies and documents appear on your portal.

1. Go to **Trust Center** → **Documents**
2. Toggle visibility on any policy from your policy library
3. To add a non-policy document (e.g., a penetration test summary), upload it directly
4. Set the access level: **Public** (visible immediately) or **NDA-gated** (requires signature)

Published documents appear in the **Security Policies** section of your portal within seconds.

<Warning>
  Only publish documents you are comfortable sharing externally. NDA-gating adds a signature step but does not prevent a signed visitor from sharing the content.
</Warning>

## NDA gate

When NDA gating is enabled, visitors must enter their name and email and accept your NDA terms before accessing gated documents.

**To enable:**

1. Go to **Portal Settings** → **NDA**
2. Toggle **Require NDA for sensitive documents**
3. Upload your NDA template or use Matproof's default
4. Save

Each accepted NDA is logged with the visitor's name, email, and timestamp. You can export this log from **Portal Settings** → **NDA Signatories**.

<Note>
  NDA gating is available as a feature flag (`is-trust-nda-enabled`). Contact support to enable it for your organization.
</Note>

## Sharing with customers

Once your portal is live, copy the link from the Trust Center dashboard and share it:

* In email during security review conversations
* In your sales deck or security one-pager
* In your product's documentation or website footer
* As a response to vendor questionnaires that ask for a security page

Prospects can bookmark the URL — the page always reflects your current posture as you update certifications and policies.

## Using the Trust Center in enterprise sales

A Trust Center link reduces friction in three common scenarios:

**Vendor assessment questionnaires** — Instead of filling out every question from scratch, share the link and note which sections are answered by your published policies and certificates.

**Procurement reviews** — Buyers doing due diligence can check your security posture asynchronously, without scheduling a call with your team.

**Renewal reviews** — Existing customers can verify your continued compliance without asking for updated documents every year.

<Tip>
  Pair the Trust Center with Matproof's AI Questionnaire module. Use the Trust Center for initial visibility and the AI Questionnaire to handle formal vendor assessment forms. See [AI Questionnaire](/features/questionnaire-ai).
</Tip>


# Vendor Risk Management
Source: https://docs.matproof.com/features/vendor-risk

Manage third-party risk: GDPR Article 28 register, DORA ICT third-party risk, supplier questionnaires, sanctions screening.

# Vendor Risk Management

Matproof's vendor risk module manages the full lifecycle of third-party relationships — from onboarding and risk assessment through ongoing monitoring and contract review. It produces evidence for GDPR Article 28, DORA Article 28-30, ISO 27001 A.5.19–A.5.23, and SOC 2 CC9.2 simultaneously.

## What it covers

| Capability                     | What it does                                                                                                              |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
| **Vendor register**            | Central inventory of all third-party relationships with criticality classification                                        |
| **Article 28 register (GDPR)** | Required register of every processor that handles personal data on your behalf                                            |
| **DORA TPRM**                  | ICT third-party risk register with criticality, exit strategies, concentration risk, contractual checklist per Article 30 |
| **Risk questionnaires**        | Send security/data assessments to vendors via [Questionnaire AI](/features/questionnaire-ai)                              |
| **Sanctions screening**        | Automated screening against EU, UN, OFAC, UK lists                                                                        |
| **Findings**                   | Vendor-related gaps surface in the unified [Findings](/features/findings) view                                            |
| **Ongoing review cycles**      | Scheduled re-reviews based on criticality                                                                                 |

## Adding vendors

### Manual entry

1. Go to **Vendor Risk → Vendors → Add vendor**
2. Enter name, primary contact email, country of registration, contract value
3. Classify by category (ICT, professional services, goods, marketing, financial)
4. Save — Matproof creates the vendor record and starts a sanctions screen

### Bulk import via CSV

Go to **Vendor Risk → Vendors → Import** and upload a CSV with the columns Matproof expects:

```csv theme={null}
name,category,contact_email,country,contract_value,ict_service,processes_personal_data
Stripe,Payments,vendor@stripe.com,IE,120000,no,yes
Atlassian,SaaS,vendor@atlassian.com,AU,30000,yes,yes
Acme Print Shop,Goods,vendor@acmeprint.de,DE,8000,no,no
```

Matproof imports each row, runs sanctions screening, and prompts you to classify criticality afterwards.

### Sync from procurement (optional)

If you run procurement in Coupa, SAP Ariba, or a similar system, Matproof can pull the vendor list via integration. Contact support to enable.

## Classifying vendors

Each vendor needs three classifications. Set them when you add the vendor or in bulk afterwards.

| Field                       | Options                         | Why                                         |
| --------------------------- | ------------------------------- | ------------------------------------------- |
| **Criticality**             | Critical / Important / Standard | Required for DORA; drives review frequency  |
| **Processes personal data** | Yes / No                        | Triggers Article 28 DPA requirement         |
| **ICT service**             | Yes / No                        | Triggers DORA Article 30 contractual review |

Matproof's classification helper asks a few questions about the vendor and recommends a criticality level. You confirm or override.

## GDPR Article 28 register

The Article 28 register tracks every processor that handles personal data on your behalf. Required by GDPR for every controller.

For each entry Matproof tracks:

* Vendor name and primary contact
* Categories of personal data processed (employee data, customer data, special categories, etc.)
* Purpose of processing
* Data transfer mechanism (SCCs / adequacy decision / DPF / not applicable)
* DPA status — signed / pending / not required (with the actual DPA file attached)
* Sub-processor list provided by the vendor
* Last review date

Export as PDF or Excel for your DPO or your supervisory authority.

## DORA ICT Third-Party Risk

For ICT vendors, Matproof tracks the additional information DORA Article 28–30 requires:

* **Criticality classification** per the EBA guidelines
* **Contractual requirements checklist** per Article 30 (mandatory clauses: data location, audit rights, exit strategy, sub-contracting limits, etc.)
* **Exit strategy** — documented plan for migrating off the vendor
* **Concentration risk** — alerts when too many critical functions depend on one provider, one region, or one parent group
* **Sub-processor tracking** — vendor's own sub-processor list, refreshed at each review cycle
* **Register of information** — the Article 28 ROI export format that DORA-supervised entities submit to their NCA

The DORA ROI export produces the structured XLSX format the European Supervisory Authorities (ESAs) accept.

## Vendor questionnaires

Send security and risk questionnaires to your vendors via the [Questionnaire AI](/features/questionnaire-ai) module. Matproof ships templates aligned to common standards:

* **DORA ICT third-party assessment** — covers Article 30 mandatory clauses
* **ISO 27001 vendor security questionnaire** — Annex A.5.19–A.5.23 alignment
* **GDPR Article 28 data processor assessment** — DPA-readiness check
* **SIG Lite** — Shared Assessments standard
* **CAIQ** — Cloud Security Alliance standard

Vendors respond via a secure link — no Matproof account required. Responses are scored automatically and attached to the vendor's record.

## Sanctions screening

Matproof screens every vendor on import and monthly afterwards against:

* EU Consolidated Sanctions List
* UN Security Council Sanctions
* OFAC Specially Designated Nationals (SDN)
* UK Financial Sanctions

Hits raise a [finding](/features/findings) tagged "sanctions match — review required" and pause any further automation against that vendor until a compliance lead reviews and dispositions.

## Review cycles

Each vendor has a review frequency tied to its criticality:

| Criticality     | Default review cadence                 |
| --------------- | -------------------------------------- |
| Critical (DORA) | Annually + on contract material change |
| Important       | Annually                               |
| Standard        | Every 2 years                          |

Matproof emails the vendor's owner 30 days before a review is due. The review workflow re-runs the questionnaire, refreshes sanctions screening, and re-confirms criticality.

<CardGroup>
  <Card title="Questionnaire AI" href="/features/questionnaire-ai">
    Send and respond to vendor questionnaires
  </Card>

  <Card title="DORA framework" href="/frameworks/dora">
    What DORA Article 28-30 requires of you
  </Card>

  <Card title="Findings" href="/features/findings">
    Track vendor gaps in the unified findings view
  </Card>

  <Card title="GDPR" href="/frameworks/gdpr">
    Article 28 obligations
  </Card>
</CardGroup>


# Getting Started with BaFin MaRisk
Source: https://docs.matproof.com/frameworks/bafin-marisk

A practical guide to implementing BaFin MaRisk requirements for German banking and financial institutions using Matproof.

# Getting Started with BaFin MaRisk

MaRisk (Mindestanforderungen an das Risikomanagement) is BaFin's circular on the minimum requirements for risk management in German credit institutions and financial services institutions. It implements the EBA Guidelines on internal governance and translates Basel requirements into binding supervisory expectations for the German market.

The current version (MaRisk 7.0, effective 2023) incorporates requirements from the EBA Guidelines on ICT and security risk management, making it directly relevant to operational resilience and IT governance. MaRisk applies to all institutions supervised by BaFin under the KWG (German Banking Act).

Matproof maps MaRisk requirements to controls, policies, and evidence workflows so you can demonstrate compliance during BaFin audits and Section 44 KWG examinations.

<Note>
  Activate MaRisk under **Settings - Frameworks - BaFin MaRisk**. Controls are pre-populated across all MaRisk modules (AT, BT, BTR).
</Note>

***

## Am I in Scope?

MaRisk applies to:

* Credit institutions (Kreditinstitute) under Section 1(1) KWG
* Financial services institutions (Finanzdienstleistungsinstitute) under Section 1(1a) KWG
* Payment institutions and e-money institutions (to the extent BaFin circular applies)
* Groups of institutions at both individual entity and group level

<Tip>
  MaRisk applies proportionally. Smaller, less complex institutions may implement simplified approaches where the circular explicitly allows it. Document your proportionality assessment in your risk management framework.
</Tip>

***

## MaRisk Structure

MaRisk is organized into modules:

| Module                    | Scope                                                                           | Matproof Module                 |
| ------------------------- | ------------------------------------------------------------------------------- | ------------------------------- |
| **AT** (Allgemeiner Teil) | General requirements: governance, risk strategy, internal controls, outsourcing | Policies, Controls, Vendor Risk |
| **AT 7**                  | IT resources and IT risk management (incorporates EBA ICT Guidelines)           | Controls, Evidence              |
| **AT 9**                  | Outsourcing                                                                     | Vendor Risk                     |
| **BT** (Besonderer Teil)  | Specific requirements for organizational structure and processes                | Controls                        |
| **BT 1**                  | Lending business                                                                | Controls                        |
| **BT 2**                  | Trading business                                                                | Controls                        |
| **BT 3**                  | Internal control system requirements                                            | Controls, Audit Programs        |
| **BTR**                   | Risk types: credit, market, liquidity, operational risk                         | Risk Management                 |

***

## Key Requirements in Matproof

<CardGroup>
  <Card title="Risk Strategy" icon="compass">
    **Policies, Risk Management**

    Document a risk strategy consistent with the business strategy. The management board is responsible for defining the institution's risk appetite and ensuring adequate risk management.
  </Card>

  <Card title="IT Governance (AT 7)" icon="server">
    **Controls, Evidence**

    Implement IT risk management covering IT strategy, information security, IT operations, and IT project management. This module now incorporates EBA ICT Guidelines requirements.
  </Card>

  <Card title="Outsourcing (AT 9)" icon="building">
    **Vendor Risk**

    Classify outsourced activities by materiality. Material outsourcing requires risk analysis, contractual safeguards, exit strategies, and ongoing monitoring.
  </Card>

  <Card title="Internal Control System" icon="scale-balanced">
    **Controls, Audit Programs**

    Maintain the three lines of defense: operational management, risk management and compliance, and internal audit. Document segregation of duties.
  </Card>

  <Card title="Operational Risk" icon="triangle-exclamation">
    **Risk Management, Incidents**

    Identify, assess, and manage operational risks including IT failures, fraud, and process errors. Maintain a loss database and report material incidents.
  </Card>

  <Card title="Business Continuity" icon="rotate-right">
    **Policies, Controls**

    Maintain business continuity plans for time-critical activities and processes. Test plans regularly and document results.
  </Card>
</CardGroup>

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 - Document your risk strategy and governance

  MaRisk AT 4.2 requires a written risk strategy derived from the business strategy:

  1. Go to **Policies - Generate** and create your Risk Management Framework Policy
  2. Document the management board's risk appetite statement
  3. Define roles and responsibilities for risk management across the three lines of defense
  4. Ensure the supervisory board (Aufsichtsrat) receives regular risk reporting

  ### Step 2 - IT risk management (AT 7)

  AT 7 is one of the most operationally intensive MaRisk modules:

  1. Document your IT strategy and ensure it aligns with the business strategy
  2. Complete controls for information security management (AT 7.2)
  3. Document IT operations including change management and incident handling (AT 7.3)
  4. Establish IT project management governance with risk assessment for major projects (AT 7.4)
  5. Define access rights management (AT 7.2) with regular recertification

  <Warning>
    BaFin examiners pay close attention to AT 7 implementation. Ensure your information security officer (ISB) has sufficient authority and reports directly to the management board.
  </Warning>

  ### Step 3 - Outsourcing register and risk assessments (AT 9)

  1. Go to **Vendor Risk** and create a complete outsourcing register
  2. Classify each outsourced activity as **material** or **non-material**
  3. For material outsourcing: conduct a risk analysis, verify contractual clauses (including BaFin audit rights), and document exit strategies
  4. Establish ongoing monitoring with defined escalation criteria
  5. Ensure BaFin notification requirements are met for material outsourcing arrangements

  ### Step 4 - Internal control system and segregation of duties

  1. Document your three lines of defense model
  2. Map key processes and verify segregation of duties (AT 4.3.1)
  3. Ensure the compliance function covers all regulatory requirements and reports to the management board
  4. Document the internal audit function's scope, independence, and reporting line

  ### Step 5 - Operational risk management

  1. Go to **Risk Management - New Risk Assessment** for operational risk
  2. Document your operational risk identification and assessment methodology
  3. Set up the **Incidents** module for operational loss event tracking
  4. Define risk indicators (KRIs) and escalation thresholds
  5. Ensure operational risk is included in the overall risk reporting

  ### Step 6 - Business continuity management

  1. Identify time-critical activities and processes
  2. Go to **Policies - Generate** and create your Business Continuity Policy
  3. Document recovery time objectives (RTOs) and recovery point objectives (RPOs)
  4. Conduct and document BCP tests at least annually
  5. Link test results as evidence against the relevant MaRisk controls

  ### Step 7 - Internal audit and gap review

  1. Go to **Audit Programs - New Audit - MaRisk**
  2. Run an internal audit covering all MaRisk modules
  3. Document findings as Corrective Actions with remediation timelines
  4. Ensure the audit report is presented to the management board and supervisory board
</Steps>

***

## Common BaFin Examination Findings

| Finding                         | How to Avoid                                                                                                                          |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Incomplete outsourcing register | Include all outsourced activities, not just IT. Review procurement records for missed arrangements.                                   |
| IT risk management gaps (AT 7)  | Ensure the ISB role is formally established with clear authority. Document IT risk assessments for all critical systems.              |
| Missing segregation of duties   | Map dual-control requirements for all risk-relevant processes. Document compensating controls where full segregation is not feasible. |
| Insufficient BCP testing        | Test plans annually at minimum. Document test scenarios, results, and improvement actions.                                            |
| Risk reporting gaps             | Ensure ad-hoc reporting triggers are defined and management board reporting covers all material risk types.                           |

***

## Relationship to Other Frameworks

| Framework          | Overlap with MaRisk                                                                                                                                                         |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **DORA**           | DORA supersedes parts of MaRisk AT 7 for ICT risk. Institutions in scope for DORA should implement both, with DORA taking precedence for ICT-specific requirements.         |
| **ISO 27001**      | Strong overlap with AT 7 information security requirements. ISO 27001 certification can serve as evidence for many AT 7 controls.                                           |
| **EBA Guidelines** | MaRisk 7.0 incorporates EBA Guidelines on internal governance and ICT security risk management. Compliance with MaRisk generally satisfies the underlying EBA requirements. |

***

## Next Steps

* [Risk Management](/features/risk-management) - building your MaRisk-compliant risk assessment framework
* [Vendor Risk](/features/vendor-risk) - outsourcing register and material outsourcing assessments
* [Incidents](/features/incidents) - operational loss event tracking and reporting
* [Audit Programs](/features/audit-programs) - internal audit planning for BaFin examinations


# Getting Started with CSRD
Source: https://docs.matproof.com/frameworks/csrd

A step-by-step checklist for companies activating the CSRD framework in Matproof — from double materiality assessment to ESRS report generation.

# Getting Started with CSRD

The Corporate Sustainability Reporting Directive (CSRD) requires companies to report on sustainability matters using the **European Sustainability Reporting Standards (ESRS)**. Unlike other compliance frameworks, CSRD starts with a mandatory first step you cannot skip: the **double materiality assessment (DMA)**.

The DMA determines which topics you are required to report on. Everything else follows from it.

<Note>
  To activate CSRD in Matproof, go to **Settings → Frameworks → CSRD** and click **Activate**. This unlocks the DMA tab and CSRD Report tab under Vendors.
</Note>

***

## Am I in Scope?

CSRD uses a phased rollout. Use this checklist to determine your reporting obligation:

**Wave 1 — Reporting from 2025 (FY 2024 data)**

* Large public-interest entities already reporting under NFRD
* 500+ employees

**Wave 2 — Reporting from 2028 (FY 2027 data)**

* Large EU companies not previously under NFRD
* Meets 2 of 3: 250+ employees, €50M+ net turnover, €25M+ total assets
* Postponed by 2 years under the Stop-the-Clock Directive (EU 2025/794)

**Wave 3 — Reporting from 2029 (FY 2028 data)**

* Listed SMEs (with opt-out until 2030)

**Wave 4 — Reporting from 2030 (FY 2029 data)**

* Non-EU companies with €150M+ EU net turnover and an EU subsidiary or branch
* The EU Omnibus Simplification Package proposes raising this threshold to €450M. Check current status before planning.

<Warning>
  **Regulatory timeline alert:** The Stop-the-Clock Directive (EU 2025/794), adopted April 2025, postponed Wave 2 and Wave 3 by two years. The EU Omnibus Simplification Package may further change scope and requirements. Always verify current timelines before planning your reporting cycle.
</Warning>

<Warning>
  If your parent company is in scope, your entity may be required to provide data even if you individually fall below the thresholds. Check your group consolidation structure.
</Warning>

***

## The 6-Step CSRD Workflow in Matproof

<Steps>
  ### Step 1 — Complete the double materiality assessment

  Navigate to **Vendors → CSRD DMA tab**.

  The DMA evaluates each ESRS topic across two dimensions:

  * **Impact materiality** — Does your business cause positive or negative impacts on people and the environment?
  * **Financial materiality** — Do sustainability matters create risks or opportunities that affect your financial position?

  A topic is material if it is significant on **either** dimension. You must report on all material topics.

  Work through each ESRS topic area in the DMA tab and record your assessment. Involve your CFO (financial materiality) and sustainability lead (impact materiality) in this step — regulators expect evidence of cross-functional input.

  <Tip>
    Start with the topics most likely to be material for your sector. For manufacturing, these are typically E1 (Climate Change), S1 (Own Workforce), and G1 (Business Conduct). For financial services, add E4 (Biodiversity and Ecosystems) and S2 (Workers in the Value Chain).
  </Tip>

  ### Step 2 — Identify your material ESRS topics

  Once the DMA is complete, Matproof generates your **material topic list** — the specific ESRS disclosure requirements you are obligated to report on.

  Review this list carefully. For each material topic you will need:

  * A policy or target
  * Quantitative performance data (where required by the standard)
  * Supplier data for value chain topics (E1, S2, S3, S4)

  <Note>
    ESRS 2 (General Disclosures) is mandatory for all in-scope companies regardless of DMA results. It covers governance, strategy, and risk management disclosures.
  </Note>

  ### Step 3 — Map your suppliers

  Go to **Vendors** and ensure all relevant suppliers are added to your vendor list. For CSRD purposes, "relevant" means suppliers that:

  * Contribute to your Scope 3 emissions categories
  * Fall within material value chain topics (e.g., S2 if you have overseas manufacturing)
  * Are significant by spend or volume

  Assign each supplier a **CSRD relevance tag** so questionnaires are targeted correctly.

  ### Step 4 — Send supplier questionnaires

  From **Vendors**, select the suppliers tagged for CSRD and send the **CSRD Supplier Questionnaire**.

  The questionnaire covers:

  * GHG emissions data (Scope 1, 2, and relevant Scope 3 categories)
  * Social metrics (workforce data, working conditions)
  * Governance disclosures if required by your material topics

  Track response status in the **Vendors → CSRD DMA tab**. Matproof shows you a response rate per questionnaire batch.

  <Tip>
    **Improving supplier response rates:**

    * Send a personal email to your procurement contact before the automated questionnaire lands — a heads-up doubles response rates
    * Set a firm deadline (3 weeks works better than open-ended)
    * Offer a 30-minute call for suppliers who are confused — most questions come from the same 2-3 items
    * For non-responsive critical suppliers, escalate through your commercial relationship manager
  </Tip>

  ### Step 5 — Collect and validate Scope 3 data

  Scope 3 has 15 categories. Most companies only need data for:

  | Category   | Description                              | Typical source          |
  | ---------- | ---------------------------------------- | ----------------------- |
  | **Cat 1**  | Purchased goods and services             | Supplier questionnaires |
  | **Cat 4**  | Upstream transportation and distribution | Logistics providers     |
  | **Cat 11** | Use of sold products                     | Product lifecycle data  |

  <Note>
    You are required to report on Scope 3 categories that are material under your DMA. If Cat 11 is not material for your business (e.g., you sell B2B services), you do not need to report it — but document your reasoning.
  </Note>

  Enter or import your Scope 3 data in **Vendors → CSRD DMA tab → Emissions Data**. Matproof validates entries and flags gaps before report generation.

  ### Step 6 — Generate the ESRS report

  Once your DMA is complete, supplier data is collected, and Scope 3 is entered, go to **Vendors → CSRD Report tab**.

  Click **Generate ESRS Report**. Matproof produces a structured report aligned to ESRS disclosure requirements for your material topics.

  Review the generated report for:

  * Missing data fields (shown in red)
  * Topics where you have a policy gap
  * Metrics that require additional narrative explanation

  Export the report in PDF or XBRL-tagged format for your statutory filing.
</Steps>

***

## The Four Things Teams Get Wrong

### 1. Not knowing if they're in scope

The phased rollout and group consolidation rules create genuine confusion. Before spending time on the DMA, confirm your wave and check whether your parent entity's scope affects your obligations.

### 2. Starting the DMA without the right stakeholders

The DMA is not a compliance checkbox — it is a business decision about what your company considers material. Completing it without input from Finance, Operations, and Legal produces assessments that won't survive auditor scrutiny. Budget 2-3 working sessions with cross-functional leads.

### 3. Sending supplier questionnaires without preparation

Suppliers receiving a sustainability questionnaire cold — no context, no deadline, no contact — respond at rates below 20%. A brief outreach from your procurement team before the questionnaire lands consistently achieves 50-70% response rates.

### 4. Reporting on all 15 Scope 3 categories by default

Teams assume they need all 15 categories and get paralyzed. Your DMA determines which Scope 3 categories are material. For most companies outside heavy industry, three categories (Cat 1, Cat 4, Cat 11) cover 80-90% of the required disclosure.

***

## What a Completed CSRD Module Looks Like

A complete CSRD implementation in Matproof should have:

* DMA completed with all ESRS topics assessed and materiality decisions documented
* Material topic list reviewed and signed off by a senior stakeholder
* All relevant suppliers mapped and tagged in Vendors
* Supplier questionnaires sent with at least one follow-up round completed
* Scope 3 data entered for all material categories
* ESRS report generated with no red (missing data) fields remaining
* Report exported and ready for external assurance review

<Tip>
  Limited assurance is required from the outset for all in-scope companies. The transition to reasonable assurance depends on the Commission adopting standards by October 2028. Matproof's completeness tracking helps you prepare, but assurance levels are determined by your auditor's methodology, not by a data completeness score.
</Tip>

***

## ESRS Topic Reference

| ESRS Standard | Topic                             | Commonly Material For                 |
| ------------- | --------------------------------- | ------------------------------------- |
| ESRS 2        | General Disclosures               | All companies (mandatory)             |
| E1            | Climate Change                    | All sectors                           |
| E2            | Pollution                         | Manufacturing, chemicals, agriculture |
| E3            | Water and Marine Resources        | Food, beverages, textiles             |
| E4            | Biodiversity and Ecosystems       | Agriculture, forestry, real estate    |
| E5            | Resource Use and Circular Economy | Retail, packaging, electronics        |
| S1            | Own Workforce                     | All companies                         |
| S2            | Workers in the Value Chain        | Companies with global supply chains   |
| S3            | Affected Communities              | Extractives, infrastructure           |
| S4            | Consumers and End-users           | Consumer goods, financial services    |
| G1            | Business Conduct                  | All companies                         |

***

## Next Steps

* [Double Materiality Assessment guide](/csrd/double-materiality) — detailed walkthrough of the DMA process
* [Supplier questionnaires](/features/vendor-risk) — how to send, chase, and import supplier responses
* [Scope 3 emissions data](/csrd/scope-3) — category-by-category data collection guide
* [Generating your ESRS report](/csrd/esrs-report) — export formats, XBRL tagging, and assurance preparation


# Getting Started with the Cyber Resilience Act
Source: https://docs.matproof.com/frameworks/cyber-resilience-act

A practical guide to meeting CRA product security requirements for manufacturers, importers, and distributors of products with digital elements.

# Getting Started with the Cyber Resilience Act

The Cyber Resilience Act (CRA) establishes mandatory cybersecurity requirements for **products with digital elements** sold on the EU market. This covers hardware and software products that can connect to a device or network - from IoT devices and operating systems to firmware and standalone software applications.

The CRA entered into force on December 10, 2024. Reporting obligations for actively exploited vulnerabilities begin **September 11, 2026**, and the full set of product security requirements becomes enforceable on **December 11, 2027**.

Matproof maps CRA obligations to controls, evidence workflows, and vulnerability management processes so manufacturers can demonstrate compliance to market surveillance authorities.

<Note>
  Activate the CRA under **Settings - Frameworks - Cyber Resilience Act**. Controls are pre-populated based on whether your products are classified as default, important (Class I or II), or critical.
</Note>

***

## Am I in Scope?

The CRA applies to any organization that places products with digital elements on the EU market:

| Role             | Definition                                                          | Key Obligations                                                                                           |
| ---------------- | ------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
| **Manufacturer** | Develops or has a product developed and markets it under their name | Full compliance: secure by design, vulnerability handling, technical documentation, conformity assessment |
| **Importer**     | Places a product from a non-EU manufacturer on the EU market        | Verify manufacturer compliance, ensure product bears CE marking, maintain documentation                   |
| **Distributor**  | Makes a product available on the EU market (without modifying it)   | Verify CE marking and documentation, report known vulnerabilities to manufacturer                         |

<Warning>
  Open source software developed in a non-commercial context is generally excluded. However, if an open source project is used commercially or integrated into a commercial product, the CRA may apply to the integrator as the manufacturer.
</Warning>

***

## Product Classification

The CRA uses a tiered classification for products with digital elements:

| Category                 | Examples                                                                                              | Conformity Assessment                         |
| ------------------------ | ----------------------------------------------------------------------------------------------------- | --------------------------------------------- |
| **Default**              | Most consumer and business software, IoT devices without critical functions                           | Self-assessment (Annex VIII)                  |
| **Important - Class I**  | Password managers, VPNs, network management systems, security information and event management (SIEM) | Harmonised standard or third-party assessment |
| **Important - Class II** | Operating systems, firewalls, tamper-resistant microprocessors, industrial automation systems         | Third-party assessment required               |
| **Critical**             | Hardware devices with security boxes, smart meter gateways, smartcards                                | European cybersecurity certification required |

<Tip>
  Most software products fall into the default category and can use self-assessment. Check Annexes III and IV of the regulation for the complete product lists in each class.
</Tip>

***

## Key Enforcement Dates

| Date               | Milestone                                                                                         |
| ------------------ | ------------------------------------------------------------------------------------------------- |
| December 10, 2024  | Regulation enters into force                                                                      |
| June 11, 2026      | Conformity assessment bodies can begin operating                                                  |
| September 11, 2026 | **Vulnerability and incident reporting obligations apply**                                        |
| December 11, 2027  | **Full enforcement** - all product security requirements, conformity assessments, penalties apply |

***

## Core Requirements in Matproof

<CardGroup>
  <Card title="Secure by Design" icon="shield-halved">
    **Controls**

    Products must be designed and developed with appropriate cybersecurity measures from the start. No known exploitable vulnerabilities at time of release.
  </Card>

  <Card title="Vulnerability Handling" icon="bug">
    **Incidents, Controls**

    Manufacturers must identify and remediate vulnerabilities throughout the product's expected lifetime (minimum 5 years). Provide security updates free of charge.
  </Card>

  <Card title="Technical Documentation" icon="file-lines">
    **Evidence, Policies**

    Maintain documentation covering security architecture, risk assessment, SBOM (Software Bill of Materials), and testing results.
  </Card>

  <Card title="Conformity Assessment" icon="clipboard-check">
    **Audit Programs**

    Complete the applicable conformity assessment procedure before placing the product on the market. Affix CE marking.
  </Card>

  <Card title="Incident Reporting" icon="bell">
    **Incidents**

    Report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware. Report severe incidents within 72 hours.
  </Card>

  <Card title="Security Updates" icon="arrow-rotate-right">
    **Controls**

    Provide timely, free security updates for the entire support period. Document your update delivery mechanism.
  </Card>
</CardGroup>

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 - Inventory your products with digital elements

  List every product your organization manufactures, imports, or distributes that connects to a device or network.

  1. Go to **Controls - CRA - Product Inventory**
  2. For each product, document: product name, version, intended use, connectivity type, and expected product lifetime
  3. Classify each product (default, important Class I/II, or critical)

  ### Step 2 - Conduct product security risk assessments

  For each product:

  1. Go to **Risk Management - New Risk Assessment**
  2. Assess cybersecurity risks based on the product's intended use, connectivity, and data processed
  3. Document risk mitigation measures built into the product design
  4. Include risks from third-party components and dependencies

  ### Step 3 - Implement secure development practices

  The CRA requires security to be integrated into the development lifecycle:

  * Implement secure coding standards and code review processes
  * Conduct security testing (static analysis, dynamic analysis, fuzz testing)
  * Manage third-party dependencies and track known vulnerabilities
  * Generate and maintain a **Software Bill of Materials (SBOM)** for each product
  * Document these practices in your Secure Development Policy

  Go to **Policies - Generate** to create your CRA-aligned Secure Development Policy.

  ### Step 4 - Establish vulnerability handling

  Set up your vulnerability management process:

  1. Configure the **Incidents** module for vulnerability intake (from researchers, users, and monitoring)
  2. Define your coordinated vulnerability disclosure policy
  3. Establish a process for issuing security updates within a reasonable timeframe
  4. Maintain a vulnerability log with remediation timelines
  5. Provide a public contact point for vulnerability reports

  <Warning>
    From September 2026, you must report actively exploited vulnerabilities to ENISA within 24 hours of becoming aware. Set up your reporting workflow before this deadline.
  </Warning>

  ### Step 5 - Build technical documentation

  The CRA requires comprehensive technical documentation including:

  * Product description and intended purpose
  * Security architecture and design decisions
  * Risk assessment results
  * SBOM listing all components and dependencies
  * Testing and validation results
  * Instructions for secure configuration and use

  Upload all documentation as evidence against the relevant CRA controls in Matproof.

  ### Step 6 - Conformity assessment

  Complete the applicable assessment procedure:

  1. Go to **Audit Programs - New Audit - CRA**
  2. For default products: complete the self-assessment using the internal control procedure (Annex VIII)
  3. For Important Class II and Critical products: engage a notified body for third-party assessment
  4. Affix CE marking and draft the EU declaration of conformity
  5. Register in the EU product database where required

  ### Step 7 - Post-market monitoring

  After placing the product on the market:

  1. Monitor for new vulnerabilities in your product and its components
  2. Issue security updates as needed and notify users
  3. Report actively exploited vulnerabilities to ENISA (24-hour deadline from September 2026)
  4. Report severe security incidents within 72 hours
  5. Update technical documentation when the product changes materially
</Steps>

***

## Penalties

| Violation                                          | Maximum Penalty                                                      |
| -------------------------------------------------- | -------------------------------------------------------------------- |
| Essential cybersecurity requirements (Annex I)     | Up to 15M EUR or 2.5% of global annual turnover, whichever is higher |
| Other CRA obligations                              | Up to 10M EUR or 2% of global annual turnover, whichever is higher   |
| Incorrect or misleading information to authorities | Up to 5M EUR or 1% of global annual turnover, whichever is higher    |

***

## Next Steps

* [Risk Management](/features/risk-management) - product security risk assessments
* [Incidents](/features/incidents) - vulnerability reporting and handling workflows
* [Audit Programs](/features/audit-programs) - conformity assessment procedures
* [Vendor Risk](/features/vendor-risk) - managing third-party component risks in your supply chain


# Getting Started with DORA
Source: https://docs.matproof.com/frameworks/dora

A step-by-step checklist for EU financial institutions and ICT providers activating the DORA framework in Matproof.

# Getting Started with DORA

The Digital Operational Resilience Act (DORA) has been enforceable since **January 17, 2025**. It applies to EU financial entities (over 20 categories listed in Article 2) and their ICT third-party service providers. Providers designated as critical by the ESAs are additionally subject to direct oversight. Once you activate DORA in Matproof, you'll see approximately **70 controls** across five pillars.

This guide walks you through exactly what to do — in order — so you make real progress from day one.

<Note>
  If you haven't activated DORA yet, go to **Settings → Frameworks → DORA** and click **Activate**. Your controls will be pre-populated automatically.
</Note>

***

## What DORA Requires at a Glance

| DORA Pillar                               | Core Obligation                                                                                                                                 | Matproof Module    |
| ----------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
| 1. ICT Risk Management                    | Maintain an ICT risk management framework with documented policies                                                                              | Policies, Controls |
| 2. ICT Incident Reporting                 | Report major incidents within 4 hours of classification as major, and no later than 24 hours after detection                                    | Incidents          |
| 3. Digital Operational Resilience Testing | Entities identified by competent authorities must conduct TLPT at least every 3 years; all others must conduct proportionate resilience testing | Cloud Tests        |
| 4. Third-Party ICT Risk Management        | Register, classify, and monitor all ICT vendors by criticality                                                                                  | Vendor Risk        |
| 5. Information Sharing                    | May participate in voluntary threat intelligence sharing arrangements (Article 45)                                                              | Voluntary          |

***

## Am I in Scope?

DORA applies to you if your organization is any of the following:

* Credit institution, payment institution, or e-money institution
* Investment firm or crypto-asset service provider
* Insurance or reinsurance undertaking
* Central counterparty or trade repository
* ICT third-party service providers — all are indirectly affected through contractual requirements (Articles 28-30); those designated as **critical** by an ESA are additionally subject to direct oversight (Articles 31-44)

<Note>
  This is a non-exhaustive list. Article 2(1) covers 21 categories of financial entities. Consult the full list in the Regulation if your entity type is not shown above.
</Note>

<Warning>
  ICT providers that serve in-scope financial entities may be directly supervised under DORA even if they are not themselves financial institutions. Check with your legal counsel if you are unsure.
</Warning>

<Tip>
  DORA applies proportionally based on entity size, risk profile, and complexity (Article 4). Microenterprises may apply a simplified ICT risk management framework under Article 16.
</Tip>

***

## The 5 DORA Pillars in Matproof

<CardGroup>
  <Card title="ICT Risk Management" icon="diagram-project">
    **Policies + Controls**

    Document your ICT risk strategy, define risk tolerance, and complete the governance controls in Pillar 1. Start here before anything else.
  </Card>

  <Card title="Incident Reporting" icon="bell">
    **Incidents Module**

    Set up your 4-hour initial reporting workflow. Configure incident classification thresholds that match your regulator's criteria.
  </Card>

  <Card title="Resilience Testing" icon="flask">
    **Cloud Tests**

    Schedule and document your TLPT cycles. Matproof tracks test scope, results, and remediation actions.
  </Card>

  <Card title="Third-Party Risk" icon="building">
    **Vendor Risk**

    Build your ICT third-party register and classify each vendor by DORA criticality. Send risk assessments directly from the platform.
  </Card>

  <Card title="Information Sharing" icon="share-nodes">
    **Voluntary (Article 45)**

    Financial entities may voluntarily participate in threat intelligence sharing arrangements. This pillar is encouraged but not mandatory.
  </Card>
</CardGroup>

***

## Recommended 8-Week Implementation Plan

Follow this sequence. Skipping ahead — especially past vendor mapping — is the most common reason DORA audits go poorly.

<Steps>
  ### Week 1 — Policies and governance

  Navigate to **Policies** and complete the three foundational DORA policies:

  * ICT Risk Management Policy
  * Information Security Policy
  * Business Continuity and Disaster Recovery Policy

  Assign an owner to each policy. Without owners, controls will stall at review time.

  ### Week 2 — Pillar 1 controls (ICT Risk Management)

  Open **Controls → Pillar 1** and work through the \~18 governance and risk framework controls. These establish the foundation every other pillar depends on.

  <Tip>
    Sort controls by **Priority: High** to tackle the regulator-visible ones first. Controls marked with a lock icon are required for initial compliance.
  </Tip>

  ### Week 3 — Vendor register and DORA criticality classification

  Go to **Vendor Risk** and import or manually add all ICT third-party vendors. For each vendor, set the **DORA Criticality** field:

  * **Critical** — supports functions that would cause severe disruption if interrupted
  * **Important** — supports significant functions but with workarounds available
  * **Standard** — no material impact if the vendor fails

  This classification drives which vendors require enhanced contractual clauses and deeper assessments under Article 28-30.

  ### Week 4 — Vendor risk assessments

  For all vendors classified as Critical or Important, send a **DORA Vendor Assessment** from the vendor record. Matproof includes a pre-built DORA assessment template aligned to RTS requirements.

  Track response status in **Vendor Risk → Assessments**.

  ### Week 5 — Pillar 2 controls + incident reporting setup

  Open **Incidents** and configure your incident classification criteria. DORA mandates:

  * **Initial notification** to competent authority within **4 hours** of classifying an incident as major (and no later than **24 hours** after detection)
  * **Intermediate report** within **72 hours** of submitting the initial notification
  * **Final report** within **1 month**

  Set up the notification workflow so the right team members are alerted automatically when an incident is classified.

  <Warning>
    The 4-hour clock starts from the moment you classify an incident as **major** — not from when it was detected. Define your internal escalation threshold carefully so classification happens fast.
  </Warning>

  ### Week 6 — Pillar 3 controls and testing schedule

  Go to **Cloud Tests** and create your TLPT schedule. If you have not yet completed a TLPT, document the planned scope, threat intelligence provider, and target date.

  Complete the Pillar 3 controls in the Controls module. These ask for evidence that testing is planned, scoped, and tracked.

  ### Week 7 — Pillar 4 and 5 controls

  Work through the remaining controls in Pillars 4 and 5:

  * Pillar 4: contractual obligations review, exit strategies for critical vendors
  * Pillar 5: consider participation in a voluntary information sharing arrangement (e.g., FS-ISAC) under Article 45

  ### Week 8 — Gap review and evidence collection

  Run **Controls → Export** to produce a compliance gap report. Review any controls still in **Not Started** or **In Progress** status. Assign remediation tasks and set due dates.

  Share the report with your CISO or compliance lead for final sign-off.
</Steps>

***

## The Three Things Teams Get Wrong

### 1. Not prioritizing controls

With \~70 controls across five pillars, trying to do everything at once leads to nothing getting done. Filter by **Priority: High** and work pillar by pillar in the order above.

### 2. Missing the 4-hour incident notification window

Most teams only discover this requirement after a real incident. Set up the **Incidents** module before you need it. Define what constitutes a "major incident" internally, document it, and run at least one tabletop exercise.

### 3. Skipping vendor criticality classification

DORA's third-party risk rules (Articles 28-44) are among the most operationally complex. Without classifying vendors, you cannot determine which ones need enhanced contractual clauses, sub-outsourcing controls, or exit plans. This is also the area regulators scrutinize most.

***

## Control Prioritization Reference

| Priority  | Controls to complete first                                                    |
| --------- | ----------------------------------------------------------------------------- |
| Immediate | ICT Risk Management Policy, incident classification criteria, vendor register |
| Week 1-2  | All Pillar 1 high-priority controls, governance structure documentation       |
| Week 3-4  | Critical and Important vendor assessments, contractual clause review          |
| Week 5-6  | Incident workflow live test, TLPT schedule documented                         |
| Week 7-8  | Remaining controls, evidence collection, gap report                           |

***

## What Good Looks Like

By the end of week 8, a complete DORA implementation in Matproof should have:

* All three foundational policies **Approved** with assigned owners
* Every ICT vendor in the register with a **DORA Criticality** classification
* All Critical and Important vendors with a completed assessment on file
* The Incidents module configured with classification criteria and a live notification workflow
* A TLPT schedule documented in Cloud Tests
* At least 85% of controls in **Completed** or **In Review** status

<Tip>
  Use **Dashboard → DORA Overview** to see your pillar-by-pillar completion percentage at a glance. This is the view your auditor will want to see.
</Tip>

***

## Next Steps

* [Configure the Incidents module](/features/incidents) — detailed incident classification and reporting workflow setup
* [Vendor Risk assessments](/features/vendor-risk) — how to send, track, and score assessments
* [Cloud Tests and TLPT](/features/cloud-tests) — scheduling and documenting your resilience testing program


# EU AI Act
Source: https://docs.matproof.com/frameworks/eu-ai-act

EU AI Act compliance - risk-based AI governance requirements

# EU AI Act

## Overview

The EU AI Act (Regulation (EU) 2024/1689) is the world's first comprehensive legal framework for artificial intelligence. It takes a risk-based approach, imposing stricter requirements on AI systems that pose higher risks to health, safety, and fundamental rights.

The regulation was published on **July 12, 2024** and enters into force in stages, with key compliance deadlines through 2027.

### Who It Applies To

* **Providers** of AI systems placed on the EU market or put into service in the EU (regardless of where they are established)
* **Deployers** of AI systems within the EU
* **Importers and distributors** of AI systems in the EU
* **Product manufacturers** placing products with integrated AI on the EU market

## Risk Classification

The EU AI Act classifies AI systems into four risk levels:

### Unacceptable Risk (Prohibited)

AI systems that pose a clear threat to safety, livelihoods, or rights are banned entirely:

* Social scoring by governments
* Real-time remote biometric identification in public spaces (with limited exceptions for law enforcement)
* Manipulation techniques that exploit vulnerabilities
* Emotion recognition in workplaces and educational institutions (with exceptions)
* Untargeted scraping of facial images from the internet or CCTV for facial recognition databases

### High Risk

AI systems that significantly affect health, safety, or fundamental rights. These face the most extensive requirements:

* **Biometric identification and categorization** (not real-time in public spaces)
* **Critical infrastructure management** (energy, water, transport)
* **Education and vocational training** (admissions, assessments, proctoring)
* **Employment** (recruitment, promotion, task allocation, performance monitoring)
* **Essential services** (credit scoring, insurance pricing, emergency services)
* **Law enforcement** (risk assessment, evidence analysis, crime prediction)
* **Migration and border control** (visa processing, risk assessment)
* **Justice and democracy** (legal research, judicial decisions)

### Limited Risk

AI systems with specific transparency obligations:

* Chatbots and conversational AI (must disclose they are AI)
* AI-generated content (deepfakes must be labeled)
* Emotion recognition systems (must inform users)
* Biometric categorization systems (must inform users)

### Minimal Risk

All other AI systems - free to develop and use without specific AI Act obligations. This includes most current business applications like spam filters, AI-powered search, and recommendation systems.

## Requirements for High-Risk AI Systems

| Requirement                         | Description                                                                                     |
| ----------------------------------- | ----------------------------------------------------------------------------------------------- |
| Risk management system              | Continuous risk identification, analysis, and mitigation throughout the AI system lifecycle     |
| Data governance                     | Training, validation, and testing datasets must be relevant, representative, and free of errors |
| Technical documentation             | Comprehensive documentation of the system before it is placed on the market                     |
| Record-keeping                      | Automatic logging of events during operation for traceability                                   |
| Transparency                        | Clear instructions for deployers including intended purpose, capabilities, and limitations      |
| Human oversight                     | Design must allow effective oversight by natural persons                                        |
| Accuracy, robustness, cybersecurity | Systems must achieve appropriate levels throughout their lifecycle                              |
| Quality management system           | Providers must implement a QMS covering all the above                                           |

## Key Compliance Dates

| Date               | What Applies                                                               |
| ------------------ | -------------------------------------------------------------------------- |
| August 1, 2024     | Entry into force                                                           |
| February 2, 2025   | Prohibitions on unacceptable risk AI apply                                 |
| August 2, 2025     | Obligations for general-purpose AI models apply                            |
| **August 2, 2026** | **Main body applies - including high-risk AI system requirements**         |
| August 2, 2027     | Obligations for high-risk AI in Annex I (product safety legislation) apply |

## How Matproof Helps

Matproof ships a complete EU AI Act module with **98 requirements**, control templates, policy templates, task templates, and dedicated tooling for the parts of the regulation that don't fit a generic compliance UI.

### AI System Inventory

A first-class **AI Systems** section tracks every AI system in your organization with the metadata the regulation requires:

* Unique identifier, version, intended purpose, and target market
* Provider vs. deployer role per system
* Risk classification (unacceptable / high / limited / minimal)
* Annex III category if applicable
* Lifecycle stage (development / testing / production / decommissioned)
* Data sources, model dependencies, and downstream integrations

The inventory feeds every other module — risk assessments, conformity records, post-market monitoring, and incident reporting all reference systems by ID.

### Risk Classification

* Guided assessment to classify each AI system by risk level
* Decision tree based on the AI Act's Annex III categories
* Auto-risk: Matproof analyzes the system's intended purpose and suggests a likely classification
* Re-assessment workflows when systems change purpose or capability

### Foundation Model Cards (GPAI)

For **General-Purpose AI Models** (GPAI) and foundation models you deploy or fine-tune, Matproof provides structured **Model Cards** documenting:

* Model architecture, parameters, and provenance
* Training data summary (Article 53(1)(d) requirement)
* Capabilities and limitations
* Energy consumption and compute estimates
* Acceptable use policy
* Copyright compliance attestations
* Systemic risk assessment for models above the FLOP threshold (Article 51)

Cards are versioned alongside the model and exported as part of your technical documentation.

### High-Risk Compliance

* Control framework covering all Article 9–15 requirements (98 requirements seeded)
* Risk management system templates aligned with Article 9
* Data governance checklists for training data quality (Article 10)
* Technical documentation templates matching Annex IV
* Human oversight procedure templates (Article 14)
* Accuracy, robustness, and cybersecurity evidence collection (Article 15)
* Conformity assessment preparation per Article 43

### Post-Market Monitoring

The Post-Market Monitoring (PMM) module covers Article 72:

* PMM plan templates per system
* Performance metric tracking (accuracy drift, fairness drift, error rates)
* Anomaly and incident detection workflows
* Serious incident reporting per Article 73 — auto-generated reports for the relevant national authority
* Scheduled PMM reviews with audit trail

### Quality Management System (QMS)

For providers, Matproof generates the QMS documentation Article 17 requires:

* Strategy for regulatory compliance
* Examination, test, and validation procedures
* Technical specifications and standards applied
* Data management procedures
* Risk management system reference
* Post-market monitoring system reference
* Incident reporting procedures
* Records of communication with national authorities

### Policy Templates

* AI use policy for organizations deploying AI systems
* Responsible AI development guidelines
* Data governance policies for AI training data
* Transparency and disclosure templates
* Human oversight procedures
* AI literacy training plan (Article 4)

### Evidence Automation

* Model documentation and version tracking
* Training data provenance records
* Testing and validation evidence
* Deployment monitoring dashboards
* Audit trail for AI system changes
* Logged events per Article 12 record-keeping requirements

### Regulatory Monitoring

* Updates on EU AI Act implementing acts and guidance
* National transposition tracking across EU member states
* Harmonized standards development monitoring
* AI Office publications and guidance notes
* Code of Practice for GPAI updates

## Getting Started

1. Select **EU AI Act** as a framework during onboarding
2. Inventory your AI systems using Matproof's guided workflow
3. Classify each system by risk level
4. For high-risk systems, work through the Article 9–15 compliance requirements
5. For GPAI models, generate Foundation Model Cards
6. Set up Post-Market Monitoring plans for production systems

<CardGroup>
  <Card title="AI Policy Editor" href="/features/ai-policy-editor">
    Generate AI governance policies
  </Card>

  <Card title="ISO 42001" href="/frameworks/iso42001">
    The companion AI management system standard — pairs well with the EU AI Act
  </Card>
</CardGroup>


# Getting Started with GDPR
Source: https://docs.matproof.com/frameworks/gdpr

How to use Matproof to document and maintain GDPR compliance for your organization.

# Getting Started with GDPR

The General Data Protection Regulation (GDPR) has applied since **May 25, 2018**. It governs how organizations collect, process, store, and delete personal data of data subjects in the EU — regardless of where the organization itself is based. Non-compliance exposes organizations to fines of up to **€20M or 4% of global annual turnover**.

Matproof's GDPR framework maps accountability and governance controls to your policies, vendor assessments, and evidence library. It is designed to complement your GDPR documentation (RoPA, DPIAs) rather than replace dedicated privacy management tools.

<Note>
  Activate GDPR under **Settings → Frameworks → GDPR**. Your control set focuses on organizational and technical measures under Article 32, accountability documentation, and vendor (processor) management.
</Note>

***

## Who Must Comply?

GDPR applies to you if:

* You are established in the EU (regardless of where you process data)
* You are outside the EU but offer goods or services to data subjects in the EU
* You are outside the EU but monitor the behaviour of data subjects in the EU (e.g., analytics, tracking)

There is no minimum size threshold. A one-person business processing EU customer data must comply.

***

## Key GDPR Roles

| Role                | Definition                                     | Your Obligation                                                                           |
| ------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **Data Controller** | Determines the purpose and means of processing | Primary accountability — must have lawful basis, honor data subject rights, maintain RoPA |
| **Data Processor**  | Processes data on behalf of a controller       | Must follow controller instructions, sign DPA, implement Article 32 measures              |
| **Sub-processor**   | Processor used by another processor            | Controller must approve sub-processors; DPA chain must flow down                          |

Most SaaS companies are both: a **controller** for their own employee data, and a **processor** for their customers' data.

***

## Core GDPR Requirements at a Glance

| Article    | Requirement                                                                                                                                    | Matproof Module    |
| ---------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
| Art. 5     | Data minimisation, purpose limitation, accuracy                                                                                                | Policies           |
| Art. 13-14 | Privacy notices for data subjects                                                                                                              | Policies           |
| Art. 24    | Responsibility of the controller                                                                                                               | Controls           |
| Art. 25    | Data protection by design and by default                                                                                                       | Controls           |
| Art. 28    | Data Processing Agreements with processors                                                                                                     | Vendor Risk        |
| Art. 30    | Records of Processing Activities (RoPA)                                                                                                        | Controls, Policies |
| Art. 32    | Technical and organisational measures (TOMs)                                                                                                   | Controls, Evidence |
| Art. 33    | Breach notification to supervisory authority (72 hours) — only if the breach is likely to result in a risk to individuals' rights and freedoms | Incidents          |
| Art. 34    | Communication to data subjects when high risk                                                                                                  | Incidents          |
| Art. 35    | Data Protection Impact Assessments (DPIAs)                                                                                                     | Controls           |
| Art. 37    | Data Protection Officer (DPO) appointment where required                                                                                       | People, Settings   |

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 — Map your data flows

  You cannot protect data you haven't mapped. Before anything else:

  1. Identify every system where you store or process personal data
  2. For each system, document: what data, whose data, legal basis for processing, retention period, who has access
  3. Identify all third-party processors you share data with (cloud providers, SaaS tools, analytics platforms)

  This becomes the basis for your **Records of Processing Activities (RoPA)** — required under Article 30 for all organizations unless they have fewer than 250 employees AND their processing is occasional, does not pose risks to data subjects, and does not involve special category or criminal offence data. In practice, this exemption rarely applies — most organizations processing customer or employee data regularly must maintain a RoPA regardless of size.

  Document your data flows in the **Context Hub** (Settings → Context Hub) so Matproof's AI can generate relevant policies.

  ### Step 2 — Establish lawful bases

  Every processing activity needs a lawful basis. The six lawful bases under Article 6:

  | Basis                    | When to use                                                                                         |
  | ------------------------ | --------------------------------------------------------------------------------------------------- |
  | **Consent**              | Subject has freely given, specific, informed, unambiguous consent                                   |
  | **Contract**             | Processing necessary to perform a contract with the subject                                         |
  | **Legal obligation**     | Processing required by law                                                                          |
  | **Vital interests**      | Necessary to protect someone's life                                                                 |
  | **Public task**          | Necessary for a task in the public interest                                                         |
  | **Legitimate interests** | Necessary for your (or a third party's) legitimate interests, unless overridden by subject's rights |

  Document the lawful basis for each processing activity in your RoPA. This is what supervisory authorities ask for first.

  ### Step 3 — Generate GDPR policies

  Go to **Policies → Generate** and generate the GDPR policy set:

  * Privacy Policy (external — for data subjects)
  * Data Retention and Deletion Policy
  * Data Subject Rights Procedure
  * Personal Data Breach Response Policy
  * Data Protection by Design Policy
  * Acceptable Use Policy (for employees handling personal data)

  Assign a DPO or privacy lead as owner of each policy.

  ### Step 4 — Implement Article 32 technical measures

  Article 32 requires "appropriate technical and organisational measures" — but does not specify exactly what. In practice, supervisory authorities look for:

  | Measure                                     | Evidence in Matproof                            |
  | ------------------------------------------- | ----------------------------------------------- |
  | Encryption at rest and in transit           | Technical documentation, configuration exports  |
  | Access controls and least privilege         | Access logs, IAM policy exports, access reviews |
  | Pseudonymisation where possible             | Architecture diagrams, code review evidence     |
  | Regular testing (penetration tests, audits) | Pen test reports, audit records                 |
  | Business continuity and recovery            | BCP document, DR test results                   |

  Work through the Article 32 controls in **Controls → GDPR** and attach evidence for each.

  ### Step 5 — Manage processors and DPAs

  Article 28 requires a written **Data Processing Agreement (DPA)** with every third party that processes personal data on your behalf.

  1. Go to **Vendor Risk** and add all processors (cloud providers, SaaS tools, analytics, email platforms)
  2. For each processor, upload or link their DPA
  3. Review the DPA to confirm it includes all Article 28(3) requirements
  4. For critical processors, send a vendor risk assessment to verify their security posture

  <Warning>
    If you use sub-processors (your processor uses another company to process data), you must inform controllers and obtain approval. Document sub-processor chains in Vendor Risk.
  </Warning>

  ### Step 6 — Configure breach notification workflow

  GDPR Article 33 requires notifying your supervisory authority within **72 hours** of becoming aware of a personal data breach.

  1. Go to **Incidents → Settings**
  2. Configure GDPR breach classification criteria (what qualifies as a personal data breach)
  3. Set up escalation so the DPO is notified immediately
  4. Document the supervisory authority contact details (your lead DPA in the EU)

  The 72-hour clock starts when your organization becomes aware — not when you confirm the full scope.

  ### Step 7 — Data subject rights process

  GDPR grants data subjects: right of access (DSAR), right to rectification, right to erasure, right to portability, right to restrict processing, right to object, and right not to be subject to solely automated decision-making (Article 22).

  Document your response procedures and assign owners:

  * Access request response within **1 month** (extendable by up to 2 further months for complex or numerous requests — data subject must be informed of the extension within the first month)
  * Erasure ("right to be forgotten") workflow including downstream processor deletion
  * Portability export format and process

  ### Step 8 — DPIAs for high-risk processing

  Article 35 requires a **Data Protection Impact Assessment (DPIA)** before starting any processing that is "likely to result in a high risk" to individuals. This includes:

  * Large-scale processing of sensitive data
  * Systematic monitoring of individuals
  * Automated decision-making with significant effects

  Document DPIAs as evidence in the relevant controls. Supervisory authorities require DPIAs to be completed before processing begins.
</Steps>

***

## Breach Notification Quick Reference

| Step                     | Timeline | Action                                                       |
| ------------------------ | -------- | ------------------------------------------------------------ |
| Breach detected          | T+0      | Contain breach, assess scope, notify DPO                     |
| Within 72 hours          | T+72h    | Notify lead supervisory authority (even if incomplete)       |
| High risk to individuals | ASAP     | Notify affected data subjects directly                       |
| Documentation            | Ongoing  | Log in breach register regardless of notification obligation |

Not all breaches require supervisory authority notification. If the breach is unlikely to result in a risk to individuals' rights and freedoms, notification is not required — but you must still document the breach in your internal breach register (Article 33(5)).

***

## Common Mistakes

### 1. Consent as the default lawful basis

Consent is one of the hardest lawful bases to maintain (it must be freely given, withdrawable, and documented). For B2B SaaS processing customer data, **legitimate interests** or **contract** is usually more appropriate for most processing activities.

### 2. DPAs treated as a checkbox

Many organizations collect DPAs from processors but never review them. Article 28 requires DPAs to include specific provisions — collect them and verify the content.

### 3. Ignoring employee data

GDPR applies to employee personal data too. Recruitment data, payroll, performance records, and monitoring activities all require a lawful basis and retention policy.

***

## Next Steps

* [Incidents](/features/incidents) — 72-hour breach notification workflow
* [Vendor Risk](/features/vendor-risk) — DPA tracking and processor risk assessments
* [People Module](/features/people) — employee data handling and access management
* [Policy Management](/features/policy-management) — privacy policy generation and acknowledgement tracking


# Getting Started with HIPAA
Source: https://docs.matproof.com/frameworks/hipaa

A practical guide to meeting HIPAA requirements for covered entities and business associates using Matproof.

# Getting Started with HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) establishes national standards for protecting the privacy and security of individually identifiable health information in the United States. HIPAA applies to **covered entities** (health plans, healthcare clearinghouses, and healthcare providers who transmit health information electronically) and their **business associates**.

HIPAA compliance is enforced by the U.S. Department of Health and Human Services (HHS) Office for Civil Rights (OCR). Matproof maps HIPAA requirements to controls, policies, and evidence workflows so you can demonstrate compliance during OCR audits and respond to breach investigations.

<Note>
  Activate HIPAA under **Settings - Frameworks - HIPAA**. Controls are pre-populated across the Privacy Rule, Security Rule, and Breach Notification Rule.
</Note>

***

## Am I in Scope?

| Entity Type            | Definition                                                                                    | Key Obligations                                                                            |
| ---------------------- | --------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ |
| **Covered Entity**     | Health plans, healthcare clearinghouses, healthcare providers who transmit PHI electronically | Full compliance with Privacy, Security, and Breach Notification Rules                      |
| **Business Associate** | Any entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity  | Security Rule compliance, breach notification, Business Associate Agreement (BAA) required |

<Warning>
  If you handle Protected Health Information (PHI) for a US healthcare organization - even as a technology vendor or cloud provider - you are likely a business associate and must comply with HIPAA.
</Warning>

***

## HIPAA Rules in Matproof

<CardGroup>
  <Card title="Privacy Rule" icon="lock">
    **Policies, Controls**

    Governs the use and disclosure of PHI. Requires a Notice of Privacy Practices, patient rights (access, amendment, accounting of disclosures), and minimum necessary standards.
  </Card>

  <Card title="Security Rule" icon="shield-halved">
    **Controls, Evidence**

    Requires administrative, physical, and technical safeguards to protect electronic PHI (ePHI). Includes risk analysis, access controls, audit controls, transmission security, and encryption.
  </Card>

  <Card title="Breach Notification Rule" icon="bell">
    **Incidents**

    Requires notification to affected individuals, HHS, and (for breaches affecting 500+ individuals) the media. Notification deadlines: 60 days for individuals and HHS, without unreasonable delay for business associates to covered entities.
  </Card>

  <Card title="Business Associate Agreements" icon="file-contract">
    **Vendor Risk**

    Track BAAs with all business associates. Ensure agreements include required provisions for PHI handling, breach notification, and termination.
  </Card>
</CardGroup>

***

## Security Rule Safeguards

The Security Rule organizes requirements into three categories:

### Administrative Safeguards

| Standard                         | Requirement                                                                               | Matproof Control          |
| -------------------------------- | ----------------------------------------------------------------------------------------- | ------------------------- |
| Security Management Process      | Risk analysis, risk management, sanction policy, information system activity review       | Risk Management, Controls |
| Assigned Security Responsibility | Designate a security official                                                             | People                    |
| Workforce Security               | Authorization, supervision, clearance procedures, termination procedures                  | People, Controls          |
| Information Access Management    | Access authorization, access establishment and modification                               | Controls                  |
| Security Awareness and Training  | Security reminders, malicious software protection, log-in monitoring, password management | People, Controls          |
| Security Incident Procedures     | Response and reporting                                                                    | Incidents                 |
| Contingency Plan                 | Data backup, disaster recovery, emergency mode operations, testing, criticality analysis  | Policies, Controls        |
| Evaluation                       | Periodic technical and nontechnical evaluation                                            | Audit Programs            |

### Physical Safeguards

| Standard                  | Requirement                                                                                        |
| ------------------------- | -------------------------------------------------------------------------------------------------- |
| Facility Access Controls  | Contingency operations, facility security plan, access control and validation, maintenance records |
| Workstation Use           | Policies for workstation use and security                                                          |
| Workstation Security      | Physical safeguards for workstations accessing ePHI                                                |
| Device and Media Controls | Disposal, media re-use, accountability, data backup and storage                                    |

### Technical Safeguards

| Standard                        | Requirement                                                                                         |
| ------------------------------- | --------------------------------------------------------------------------------------------------- |
| Access Control                  | Unique user identification, emergency access procedure, automatic logoff, encryption and decryption |
| Audit Controls                  | Mechanisms to record and examine activity in information systems containing ePHI                    |
| Integrity                       | Mechanisms to authenticate ePHI and protect against improper alteration or destruction              |
| Person or Entity Authentication | Verify the identity of persons seeking access to ePHI                                               |
| Transmission Security           | Integrity controls and encryption for ePHI transmitted over networks                                |

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 - Conduct a risk analysis

  The Security Rule requires a thorough risk analysis as the foundation for all other safeguards:

  1. Go to **Risk Management - New Risk Assessment**
  2. Identify all systems that create, receive, maintain, or transmit ePHI
  3. Identify threats and vulnerabilities to each system
  4. Assess the likelihood and impact of each threat
  5. Document current safeguards and identify gaps
  6. Determine the risk level for each threat-vulnerability combination

  <Warning>
    Risk analysis is the single most common HIPAA deficiency cited in OCR enforcement actions. It must be thorough, documented, and updated regularly - not a one-time checkbox exercise.
  </Warning>

  ### Step 2 - Generate HIPAA policies

  Go to **Policies - Generate** and create the required HIPAA policy set:

  * Privacy Policy (Notice of Privacy Practices)
  * Information Security Policy
  * Access Control Policy
  * Incident Response and Breach Notification Policy
  * Business Continuity and Disaster Recovery Policy
  * Workforce Security and Training Policy
  * Device and Media Controls Policy

  Assign each policy to an owner and ensure management approval is documented.

  ### Step 3 - Implement Security Rule safeguards

  Work through the controls in **Controls - HIPAA**:

  1. Implement administrative safeguards (risk management, workforce security, access management, training)
  2. Implement physical safeguards (facility access, workstation security, device controls)
  3. Implement technical safeguards (access controls, audit logging, encryption, transmission security)
  4. For each control, document the implementation and link supporting evidence

  ### Step 4 - Business Associate management

  1. Go to **Vendor Risk** and identify all business associates (any entity handling PHI on your behalf)
  2. Ensure a signed BAA is in place for each business associate
  3. Upload BAAs as evidence against the relevant controls
  4. Conduct periodic assessments of business associate security practices
  5. Track BAA renewal dates and maintain a current register

  ### Step 5 - Workforce training

  1. Go to **People - Training**
  2. Assign HIPAA privacy and security training to all workforce members with access to PHI
  3. Provide role-specific training for staff with elevated access
  4. Track completion and document refresher training schedules
  5. Link training records as evidence against the Security Awareness and Training controls

  ### Step 6 - Breach notification setup

  Configure your breach response workflow:

  1. Go to **Incidents** and set up HIPAA breach classification criteria
  2. Define the breach risk assessment methodology (the four-factor test for determining if notification is required)
  3. Establish notification templates and workflows for individuals, HHS, and media (for breaches of 500+ records)
  4. Document the process for the annual submission of breaches affecting fewer than 500 individuals

  ### Step 7 - Audit and evaluation

  1. Go to **Audit Programs - New Audit - HIPAA**
  2. Conduct a periodic evaluation of your security safeguards (required by the Evaluation standard)
  3. Review audit log data from systems containing ePHI
  4. Document findings as Corrective Actions with remediation timelines
  5. Update your risk analysis based on audit findings and environmental changes
</Steps>

***

## Penalties

| Tier | Violation Type                             | Penalty per Violation | Annual Maximum |
| ---- | ------------------------------------------ | --------------------- | -------------- |
| 1    | Lack of knowledge                          | $137 - $68,928        | \$2,067,813    |
| 2    | Reasonable cause                           | $1,379 - $68,928      | \$2,067,813    |
| 3    | Willful neglect (corrected within 30 days) | $13,785 - $68,928     | \$2,067,813    |
| 4    | Willful neglect (not corrected)            | \$68,928+             | \$2,067,813    |

Penalty amounts are adjusted annually for inflation. Criminal penalties (up to \$250,000 and imprisonment) may apply for knowing misuse of PHI.

***

## Next Steps

* [Risk Management](/features/risk-management) - conducting your HIPAA risk analysis
* [Vendor Risk](/features/vendor-risk) - managing Business Associate Agreements
* [Incidents](/features/incidents) - configuring breach notification workflows
* [People](/features/people) - workforce training tracking and access management


# Getting Started with ISO 27001
Source: https://docs.matproof.com/frameworks/iso27001

A step-by-step guide to implementing ISO 27001 in Matproof and preparing for certification.

# Getting Started with ISO 27001

ISO 27001 is the international standard for Information Security Management Systems (ISMS). Certification demonstrates to customers, partners, and regulators that your organization manages information security systematically. Matproof pre-loads **93 controls** based on ISO 27001:2022 Annex A, mapped to your ISMS policies, risk register, and evidence library.

This guide walks you through implementation in the recommended order to reach audit-readiness.

<Note>
  To activate ISO 27001, go to **Settings → Frameworks → ISO 27001** and click **Activate**. Your Annex A control set will be pre-populated immediately.
</Note>

***

## What ISO 27001 Requires at a Glance

| ISO 27001 Area                              | Core Requirement                                                    | Matproof Module           |
| ------------------------------------------- | ------------------------------------------------------------------- | ------------------------- |
| Clauses 4-6: Context, Leadership & Planning | Define ISMS scope, interested parties, and risk management approach | Controls, Policies        |
| Clause 7: Support                           | Documented procedures, competence, awareness, communication         | Policies, People          |
| Clause 8: Operation                         | Risk assessments, treatment plans, Annex A controls                 | Risk Management, Controls |
| Clause 9: Performance                       | Internal audits, management reviews, metrics                        | Audit Programs            |
| Clause 10: Improvement                      | Corrective actions for nonconformities                              | Corrective Actions        |
| Annex A                                     | 93 information security controls across 4 themes                    | Controls, Evidence        |

***

## Am I in Scope?

ISO 27001 is voluntary but effectively mandatory if:

* You sell to enterprise customers who require it in their vendor assessments
* You process personal data or sensitive customer information
* You operate in industries with regulatory overlap (finance, healthcare, critical infrastructure)
* You need a recognized security credential to enter new markets

The standard applies to any organization, any size, any industry.

***

## The 4 Annex A Themes in Matproof

<CardGroup>
  <Card title="Organisational Controls" icon="building">
    **37 controls — Policies, roles, asset management, supplier relationships**

    Start here. These establish the governance foundation all other controls depend on.
  </Card>

  <Card title="People Controls" icon="users">
    **8 controls — Hiring, training, offboarding, disciplinary process**

    Managed in the People module. Link employment records and training completions as evidence.
  </Card>

  <Card title="Physical Controls" icon="lock">
    **14 controls — Physical security, clear desk, secure areas**

    Upload site assessments and physical security documentation as evidence.
  </Card>

  <Card title="Technological Controls" icon="microchip">
    **34 controls — Access control, cryptography, logging, malware protection**

    Automate evidence collection by connecting your cloud and SaaS integrations.
  </Card>
</CardGroup>

***

## Recommended 12-Week Implementation Plan

ISO 27001 certification requires a Stage 1 (documentation review) and Stage 2 (implementation audit) audit. This plan prepares you for certification over approximately 16-20 weeks, with Stage 1 readiness by week 12.

<Steps>
  ### Week 1-2 — Define ISMS scope and context

  The first thing your auditor will check is whether your ISMS scope is clearly defined and appropriate.

  1. Go to **Settings → Organization** and document your ISMS scope statement
  2. Identify interested parties (customers, regulators, employees, partners)
  3. List applicable legal, regulatory, and contractual requirements
  4. Document what is explicitly **out of scope** and why

  <Tip>
    Keep your initial scope narrow. Certifying a single product or business unit is faster and cheaper than certifying the whole company. You can expand scope later.
  </Tip>

  ### Week 3-4 — Risk assessment

  ISO 27001 Clause 8.2 requires a formal risk assessment as the basis for selecting Annex A controls.

  1. Go to **Risk Management → New Risk Assessment**
  2. Identify assets, threats, and vulnerabilities for each asset
  3. Score inherent risk (likelihood × impact)
  4. Define your risk acceptance criteria — your auditor will ask for this
  5. For risks above your acceptance threshold, document a treatment plan

  Controls you choose from Annex A must be justified by your risk assessment. This is what the **Statement of Applicability (SOA)** documents.

  ### Week 5-6 — Generate and customize policies

  1. Go to **Policies → Generate** and generate the full ISO 27001 policy set
  2. Prioritize these 5 foundational policies:
     * Information Security Policy
     * Access Control Policy
     * Acceptable Use Policy
     * Incident Response Policy
     * Business Continuity Policy
  3. Customize each policy to reflect your actual environment (reference your tech stack, team structure, and regulatory context from the Context Hub)
  4. Assign a policy owner and set a review date
  5. Publish and distribute for employee acknowledgement

  ### Week 7-8 — Complete Annex A controls

  Open **Controls → ISO 27001 → Annex A** and work through each theme:

  1. Start with **Organisational Controls** — these document decisions already made in Weeks 1-6
  2. **People Controls** — link to onboarding/offboarding checklists and training records in the People module
  3. **Physical Controls** — upload physical security assessments, visitor logs, clean desk policy acknowledgements
  4. **Technological Controls** — connect integrations to automate evidence for access control, logging, and configuration

  <Warning>
    Every Annex A control you mark as **Not Applicable** needs a written justification. These are documented in the Statement of Applicability and are always reviewed by auditors.
  </Warning>

  ### Week 9 — Statement of Applicability (SOA)

  The SOA is a required ISO 27001 document that lists all Annex A controls and states whether each is:

  * **Applicable and implemented** — link to the evidence
  * **Applicable but not yet implemented** — document the plan
  * **Not applicable** — document the justification

  Export the SOA from **Controls → Export → SOA**. Review it with your ISMS owner before submitting to your auditor.

  ### Week 10 — Internal audit

  ISO 27001 Clause 9.2 requires internal audits at planned intervals. In practice, your certification body will expect at least one complete internal audit cycle before the Stage 2 audit.

  1. Go to **Audit Programs → New Audit**
  2. Create an internal audit against the ISO 27001 control set
  3. Assign an internal auditor (someone independent from the implementation)
  4. Document findings and create **Corrective Actions** for each gap

  <Tip>
    Run the internal audit 4-6 weeks before your Stage 2 date to leave time to close corrective actions before the external auditor arrives.
  </Tip>

  ### Week 11 — Corrective actions

  Work through all findings from the internal audit:

  1. Go to **Corrective Actions** and filter by the internal audit
  2. Assign owners and due dates
  3. Close each action with evidence before the Stage 2 date

  ### Week 12 — Management review and final prep

  ISO 27001 Clause 9.3 requires a management review before certification.

  1. Export the **ISMS Performance Report** from **Audit Programs → Reports**
  2. Present to your leadership team: risk status, audit findings, control completeness, incidents
  3. Document the management review outputs (decisions made, resources allocated)
  4. Final check: ensure all applicable controls are in **Implemented** status with evidence attached, or have a documented remediation plan with a credible timeline
</Steps>

***

## The Three Things Teams Get Wrong

### 1. Scope creep

Starting with "the whole company" creates a compliance project that never ends. Pick the narrowest defensible scope — a product, a team, a data type — certify that, then expand.

### 2. The SOA is an afterthought

The Statement of Applicability is a primary deliverable, not an export at the end. Build it as you work through controls. Auditors read it before they look at anything else.

### 3. No internal audit before the external one

Stage 2 auditors will raise nonconformities for gaps they find. If you walk in with zero corrective actions documented, they conclude you haven't been running your ISMS — because every ISMS finds issues. Run a real internal audit and close the findings.

***

## Certification Timeline Reference

| Milestone                              | Typical Timeline |
| -------------------------------------- | ---------------- |
| ISMS scope defined                     | Week 1-2         |
| Risk assessment complete               | Week 4           |
| Policies approved                      | Week 6           |
| Annex A controls >80% complete         | Week 8           |
| SOA finalized                          | Week 9           |
| Internal audit complete                | Week 10-11       |
| Stage 1 audit (documentation review)   | Week 12-14       |
| Corrective actions from Stage 1 closed | Week 14-16       |
| Stage 2 audit (implementation audit)   | Week 16-20       |

***

## What Good Looks Like

Before submitting to your certification body:

* ISMS scope statement documented and approved
* Risk assessment complete with all risks above threshold assigned a treatment plan
* All 5 foundational policies published, owned, and acknowledged
* SOA complete with justifications for all Not Applicable controls
* At least one internal audit completed with findings documented
* All corrective actions from the internal audit closed with evidence
* Management review documented since ISMS establishment

***

## Next Steps

* [Risk Management](/features/risk-management) — ISO 27001-aligned risk assessment and treatment workflow
* [Policy Management](/features/policy-management) — generating, customizing, and distributing your policy library
* [Audit Programs](/features/audit-programs) — running internal audits and producing the management review report
* [Corrective Actions](/features/corrective-actions) — Clause 10.2 compliance through tracked remediation


# Getting Started with ISO 42001
Source: https://docs.matproof.com/frameworks/iso42001

A practical guide to building an AI management system aligned to ISO/IEC 42001 using Matproof.

# Getting Started with ISO 42001

ISO/IEC 42001:2023 is the international standard for **Artificial Intelligence Management Systems (AIMS)**. It provides a framework for organizations that develop, provide, or use AI systems to manage AI-related risks responsibly, establish governance, and demonstrate trustworthy AI practices.

Published in December 2023, ISO 42001 is the first management system standard specifically for AI. It follows the familiar ISO high-level structure (Harmonized Structure), making it straightforward to integrate with ISO 27001, ISO 9001, and other management system standards.

Matproof maps ISO 42001 requirements to controls, policies, and evidence workflows so you can build your AIMS and prepare for certification.

<Note>
  Activate ISO 42001 under **Settings - Frameworks - ISO 42001**. Controls are pre-populated based on the standard's clauses and Annex A/B controls.
</Note>

***

## Who Should Implement ISO 42001?

ISO 42001 is relevant to any organization involved in the AI lifecycle:

* Organizations that **develop** AI systems
* Organizations that **deploy or operate** AI systems
* Organizations that **provide data or components** for AI systems
* Organizations seeking to demonstrate responsible AI governance to customers, regulators, or partners

<Tip>
  ISO 42001 pairs well with the EU AI Act. While the AI Act sets legal requirements, ISO 42001 provides the management system framework to meet them systematically. Certification can support your conformity assessment evidence.
</Tip>

***

## Standard Structure

ISO 42001 follows the ISO Harmonized Structure:

| Clause | Topic                                                                                         | Matproof Module           |
| ------ | --------------------------------------------------------------------------------------------- | ------------------------- |
| 4      | Context of the organization                                                                   | Policies, Controls        |
| 5      | Leadership                                                                                    | Policies, People          |
| 6      | Planning (risk and opportunity assessment)                                                    | Risk Management           |
| 7      | Support (resources, competence, awareness, communication, documented information)             | People, Evidence          |
| 8      | Operation (AI risk assessment, AI risk treatment, AI system impact assessment)                | Risk Management, Controls |
| 9      | Performance evaluation (monitoring, measurement, analysis, internal audit, management review) | Audit Programs, Controls  |
| 10     | Improvement (nonconformity, corrective action, continual improvement)                         | Corrective Actions        |

### Annex A - AI Controls

Annex A provides a set of reference controls organized into key themes:

* AI policies and governance
* AI system lifecycle management
* Data management for AI
* AI system performance monitoring
* Third-party and supply chain considerations
* Responsible AI (fairness, transparency, accountability)

### Annex B - Implementation Guidance

Annex B provides detailed implementation guidance for each Annex A control.

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 - Define the AIMS scope and context

  1. Identify the AI systems and activities covered by your AIMS
  2. Document interested parties and their requirements (customers, regulators, affected persons)
  3. Determine the boundaries and applicability of your AIMS
  4. Record the scope in **Settings - Organization**

  ### Step 2 - Establish AI governance and leadership

  1. Go to **Policies - Generate** and create your AI Management System Policy
  2. Ensure top management demonstrates commitment to the AIMS
  3. Assign roles and responsibilities for AI governance
  4. Define your AI risk appetite and ethical principles
  5. Document the governance structure in the People module

  ### Step 3 - AI risk assessment

  Clause 6.1 and Clause 8 require both organizational and AI system-level risk assessments:

  1. Go to **Risk Management - New Risk Assessment**
  2. Assess organizational risks to the AIMS (Clause 6.1)
  3. For each AI system, conduct an **AI risk assessment** covering: accuracy, reliability, security, bias, fairness, transparency, and safety
  4. Conduct **AI system impact assessments** for systems that may significantly affect individuals or groups
  5. Document risk treatment plans with clear ownership

  ### Step 4 - Implement Annex A controls

  Work through the Annex A control set in **Controls - ISO 42001**:

  * AI system lifecycle controls (design, development, deployment, monitoring, decommissioning)
  * Data management controls (data quality, provenance, bias assessment)
  * Performance and monitoring controls
  * Third-party and supply chain controls
  * Responsible AI controls (fairness, transparency, explainability, accountability)

  For each control, document its implementation, assign an owner, and link supporting evidence.

  <Tip>
    If you already have ISO 27001 implemented, many ISO 42001 controls around information security, access management, and risk methodology will overlap. Use the framework mapping in Matproof to identify shared controls and avoid duplicate effort.
  </Tip>

  ### Step 5 - Data governance for AI

  AI systems depend on data quality. ISO 42001 requires specific data management practices:

  1. Document data sources, quality criteria, and preprocessing steps for each AI system
  2. Assess training and testing data for bias and representativeness
  3. Establish data provenance tracking
  4. Define data retention and deletion policies aligned with your AI systems' lifecycles

  ### Step 6 - Monitoring and measurement

  1. Define performance metrics for each AI system (accuracy, fairness metrics, drift indicators)
  2. Establish monitoring processes to detect performance degradation
  3. Document how you measure the effectiveness of your AIMS
  4. Set up regular management reviews (at least annually)

  ### Step 7 - Internal audit

  1. Go to **Audit Programs - New Audit - ISO 42001**
  2. Audit against all clauses and applicable Annex A controls
  3. Document findings as Corrective Actions
  4. Verify that corrective actions address root causes
  5. Present audit results to management as input for the management review

  ### Step 8 - Management review and certification

  1. Conduct a formal management review covering: AIMS performance, risk assessment results, audit findings, and improvement opportunities
  2. Document management review outputs (decisions and actions)
  3. When ready, engage an accredited certification body for Stage 1 and Stage 2 audits
</Steps>

***

## Relationship to Other Standards

| Standard          | Relationship                                                                                                                           |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| **ISO 27001**     | Shared Harmonized Structure. ISO 42001 addresses AI-specific risks while ISO 27001 covers information security. Many controls overlap. |
| **ISO 9001**      | Quality management practices complement AI system lifecycle management.                                                                |
| **EU AI Act**     | ISO 42001 certification provides structured evidence for EU AI Act compliance, particularly for high-risk AI system governance.        |
| **ISO/IEC 23894** | AI risk management guidance that complements the risk assessment requirements in ISO 42001.                                            |

***

## Next Steps

* [Risk Management](/features/risk-management) - conducting AI risk assessments and impact assessments
* [Policy Management](/features/policy-management) - generating your AI Management System Policy
* [Controls](/features/controls) - working through Annex A controls
* [Audit Programs](/features/audit-programs) - planning your internal audit and certification


# Getting Started with ISO 9001
Source: https://docs.matproof.com/frameworks/iso9001

A practical guide to building a quality management system aligned to ISO 9001:2015 using Matproof.

# Getting Started with ISO 9001

ISO 9001:2015 is the international standard for **Quality Management Systems (QMS)**. It is the most widely adopted management system standard in the world, with over one million organizations certified across 170 countries. ISO 9001 applies to any organization regardless of size, sector, or industry.

The standard focuses on consistently meeting customer requirements, enhancing customer satisfaction, and driving continual improvement. It follows the ISO Harmonized Structure, making it straightforward to integrate with ISO 27001, ISO 42001, and other management system standards.

Matproof maps ISO 9001 requirements to controls, policies, and evidence workflows so you can build your QMS and prepare for certification.

<Note>
  Activate ISO 9001 under **Settings - Frameworks - ISO 9001**. Controls are pre-populated based on the standard's clauses.
</Note>

***

## ISO 9001 Structure

| Clause | Topic                                                                                  | Matproof Module          |
| ------ | -------------------------------------------------------------------------------------- | ------------------------ |
| 4      | Context of the organization (interested parties, scope, QMS processes)                 | Policies, Controls       |
| 5      | Leadership (commitment, policy, roles and responsibilities)                            | Policies, People         |
| 6      | Planning (risks and opportunities, quality objectives, change planning)                | Risk Management          |
| 7      | Support (resources, competence, awareness, communication, documented information)      | People, Evidence         |
| 8      | Operation (planning, requirements, design, production, release, nonconforming outputs) | Controls                 |
| 9      | Performance evaluation (monitoring, analysis, internal audit, management review)       | Audit Programs, Controls |
| 10     | Improvement (nonconformity, corrective action, continual improvement)                  | Corrective Actions       |

***

## The Seven Quality Management Principles

ISO 9001 is built on seven principles:

<CardGroup>
  <Card title="Customer Focus" icon="users">
    Understand and meet customer requirements. Enhance customer satisfaction.
  </Card>

  <Card title="Leadership" icon="user-tie">
    Establish unity of purpose and direction. Create conditions for people to achieve quality objectives.
  </Card>

  <Card title="Engagement of People" icon="people-group">
    Competent, empowered people at all levels are essential.
  </Card>

  <Card title="Process Approach" icon="diagram-project">
    Manage activities as interrelated processes that function as a coherent system.
  </Card>

  <Card title="Improvement" icon="chart-line">
    Successful organizations focus on continual improvement.
  </Card>

  <Card title="Evidence-Based Decision Making" icon="magnifying-glass-chart">
    Decisions based on analysis and evaluation of data and information.
  </Card>

  <Card title="Relationship Management" icon="handshake">
    Manage relationships with interested parties (suppliers, partners) to optimize performance.
  </Card>
</CardGroup>

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 - Define QMS scope and context

  1. Identify internal and external factors relevant to your organization's purpose and strategic direction
  2. Document interested parties and their requirements (customers, regulators, employees, suppliers)
  3. Determine the scope of your QMS - which products, services, and locations are covered
  4. Map your key processes and their interactions

  ### Step 2 - Establish quality policy and objectives

  1. Go to **Policies - Generate** and create your Quality Policy
  2. Ensure the policy includes a commitment to meeting requirements and continual improvement
  3. Define measurable quality objectives at relevant functions, levels, and processes
  4. Document how you plan to achieve each objective (actions, resources, responsibilities, timelines)

  ### Step 3 - Risk-based thinking

  ISO 9001:2015 integrates risk-based thinking throughout the standard:

  1. Go to **Risk Management - New Risk Assessment**
  2. Identify risks and opportunities that could affect QMS outcomes
  3. Plan actions to address risks and opportunities
  4. Integrate these actions into your QMS processes
  5. Evaluate the effectiveness of your risk treatments

  <Tip>
    ISO 9001 does not require a formal risk management methodology. A simple risk register with likelihood, impact, and treatment plans is sufficient for most organizations.
  </Tip>

  ### Step 4 - Process documentation and controls

  Work through the controls in **Controls - ISO 9001**:

  * Document key processes (inputs, outputs, responsibilities, resources, criteria)
  * Establish operational controls for product and service delivery
  * Define requirements for design and development (if applicable)
  * Set up controls for externally provided processes, products, and services
  * Document your release criteria and handling of nonconforming outputs

  ### Step 5 - Competence and training

  1. Determine the competence needed for personnel affecting QMS performance
  2. Go to **People** and document training records, education, and experience for relevant roles
  3. Where gaps exist, provide training and verify its effectiveness
  4. Retain documented information as evidence of competence

  ### Step 6 - Monitoring, measurement, and analysis

  1. Determine what needs to be monitored and measured
  2. Define methods for monitoring, measurement, analysis, and evaluation
  3. Track customer satisfaction through surveys, feedback, and complaint analysis
  4. Analyze data trends to identify improvement opportunities

  ### Step 7 - Internal audit

  1. Go to **Audit Programs - New Audit - ISO 9001**
  2. Plan audits covering all clauses and processes at planned intervals
  3. Select auditors who are objective and impartial (auditors should not audit their own work)
  4. Document findings as Corrective Actions
  5. Verify corrective action effectiveness

  ### Step 8 - Management review and certification

  1. Conduct a management review covering: audit results, customer feedback, process performance, risk assessment results, and improvement opportunities
  2. Document decisions and actions from the review
  3. When ready, engage an accredited certification body
  4. Stage 1 audit reviews documentation; Stage 2 audit verifies implementation
</Steps>

***

## Required Documented Information

ISO 9001 requires you to maintain (policies/procedures) and retain (records/evidence) specific documented information:

| Type         | Examples                                                                                                                                                         |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Maintain** | Quality Policy, quality objectives, QMS scope, process descriptions                                                                                              |
| **Retain**   | Monitoring and measurement results, internal audit results, management review outputs, records of nonconformities and corrective actions, evidence of competence |

<Note>
  ISO 9001:2015 uses the term "documented information" rather than "documents" and "records." You have flexibility in how you organize and store this information - Matproof handles both policies (maintained) and evidence (retained) in the appropriate modules.
</Note>

***

## Next Steps

* [Policy Management](/features/policy-management) - generating your Quality Policy and process documentation
* [Risk Management](/features/risk-management) - risk-based thinking and opportunity assessment
* [Corrective Actions](/features/corrective-actions) - managing nonconformities and driving improvement
* [Audit Programs](/features/audit-programs) - planning internal audits and certification


# Getting Started with NEN 7510
Source: https://docs.matproof.com/frameworks/nen7510

A practical guide to implementing NEN 7510 information security for Dutch healthcare organizations using Matproof.

# Getting Started with NEN 7510

NEN 7510 is the Dutch standard for information security in healthcare. It is based on ISO 27001 and ISO 27002 but adds healthcare-specific requirements for protecting patient data (persoonlijke gezondheidsinformatie). NEN 7510 compliance is effectively mandatory for all Dutch healthcare organizations under the Wbp (now superseded by GDPR/AVG) and is referenced by the Dutch Healthcare Inspectorate (IGJ) and the Dutch Data Protection Authority (AP).

NEN 7510 consists of two parts:

* **NEN 7510-1** - Management system requirements (based on ISO 27001)
* **NEN 7510-2** - Implementation guidance (based on ISO 27002, with healthcare-specific controls)

Supplementary standards **NEN 7512** (electronic communication) and **NEN 7513** (logging of access to patient data) provide additional requirements that are commonly implemented alongside NEN 7510.

Matproof maps NEN 7510 requirements to controls, policies, and evidence workflows so you can demonstrate compliance to the IGJ and AP.

<Note>
  Activate NEN 7510 under **Settings - Frameworks - NEN 7510**. Controls are pre-populated based on NEN 7510-1 and the healthcare-specific extensions in NEN 7510-2.
</Note>

***

## Am I in Scope?

NEN 7510 applies to any organization that processes patient health information in the Netherlands:

* Hospitals, clinics, and GP practices
* Mental healthcare institutions
* Pharmacies and laboratories
* Health insurers
* Municipal health services (GGD)
* IT service providers that process health data for healthcare organizations
* Home care and long-term care providers

<Warning>
  If you provide IT systems or services that process patient data for Dutch healthcare organizations, you are expected to comply with NEN 7510 even if you are not a healthcare provider yourself. This is typically enforced through contractual requirements and data processing agreements.
</Warning>

***

## NEN 7510 Structure

Since NEN 7510 is based on ISO 27001/27002, it follows a familiar structure with healthcare additions:

| Section              | Topic                                                                             | Matproof Module                                     |
| -------------------- | --------------------------------------------------------------------------------- | --------------------------------------------------- |
| Clauses 4-10         | Information security management system (ISMS) requirements (aligned to ISO 27001) | Policies, Controls, Risk Management, Audit Programs |
| Annex A / NEN 7510-2 | Control objectives and controls, with healthcare-specific extensions              | Controls, Evidence                                  |
| NEN 7512             | Trust framework for electronic communication of health information                | Controls                                            |
| NEN 7513             | Logging requirements for access to patient records                                | Controls, Evidence                                  |

### Key Healthcare-Specific Extensions

NEN 7510-2 adds or strengthens controls in these areas compared to ISO 27002:

* **Access control for patient data** - role-based access, break-glass procedures for emergencies, automatic session timeouts
* **Logging and auditability** - all access to patient records must be logged with who, when, what, and why (NEN 7513)
* **Data exchange** - electronic exchange of patient data must meet trust requirements (NEN 7512)
* **Mobile devices** - specific controls for tablets, smartphones, and portable media used in clinical settings
* **Physical security** - controls for clinical environments where patient data is visible on screens or printed

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 - Establish your ISMS

  NEN 7510-1 requires a formal information security management system:

  1. Define the ISMS scope - which systems, departments, and locations process patient data
  2. Go to **Policies - Generate** and create your Information Security Policy
  3. Assign an information security officer (informatiebeveiligingsfunctionaris)
  4. Ensure management commitment is documented (board-level approval of the ISMS)

  ### Step 2 - Conduct a risk assessment

  1. Go to **Risk Management - New Risk Assessment**
  2. Identify all systems that process patient health information
  3. Assess threats and vulnerabilities specific to your healthcare context
  4. Include risks related to patient safety (not just data confidentiality)
  5. Document risk treatment decisions and acceptance criteria

  <Tip>
    NEN 7510 places equal emphasis on availability and integrity of health data, not just confidentiality. A system outage that prevents access to patient records during treatment is a serious risk that must be assessed.
  </Tip>

  ### Step 3 - Implement NEN 7510-2 controls

  Work through the controls in **Controls - NEN 7510**:

  1. Start with access control - implement role-based access to patient records, break-glass procedures for emergencies, and automatic session lockout
  2. Implement logging per NEN 7513 - log all access to patient records including user identity, timestamp, patient identity, and type of access
  3. Address mobile device and removable media controls for clinical staff
  4. Implement physical security controls for treatment rooms, reception areas, and anywhere patient data is displayed
  5. Address electronic data exchange per NEN 7512

  <Warning>
    NEN 7513 logging requirements are strict. Every access to a patient record - including read access - must be logged. Patients have the right to request an access log showing who viewed their data.
  </Warning>

  ### Step 4 - Generate healthcare-specific policies

  In addition to the standard information security policies, NEN 7510 requires:

  * Patient Data Access Control Policy (including break-glass procedures)
  * Mobile Device Policy for clinical environments
  * Electronic Health Data Exchange Policy
  * Logging and Audit Policy (aligned with NEN 7513)

  Go to **Policies - Generate** to create these from the NEN 7510 templates.

  ### Step 5 - Vendor and processor management

  1. Go to **Vendor Risk** and identify all IT vendors that process patient data
  2. Ensure data processing agreements (verwerkersovereenkomsten) are in place per GDPR/AVG
  3. Verify that vendors comply with NEN 7510 or equivalent standards
  4. Conduct periodic assessments of vendor security practices

  ### Step 6 - Staff awareness and training

  1. Go to **People - Training**
  2. Assign information security awareness training to all staff with access to patient data
  3. Include healthcare-specific scenarios (e.g., proper handling of patient data in clinical settings, responding to data requests, break-glass procedure usage)
  4. Track completion and retain records as evidence

  ### Step 7 - Internal audit and certification

  1. Go to **Audit Programs - New Audit - NEN 7510**
  2. Audit against NEN 7510-1 ISMS requirements and applicable NEN 7510-2 controls
  3. Include NEN 7512 and NEN 7513 controls in the audit scope
  4. Document findings as Corrective Actions
  5. If pursuing formal certification, engage an accredited audit body
</Steps>

***

## Relationship to Other Standards

| Standard       | Relationship                                                                                                                                                        |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **ISO 27001**  | NEN 7510-1 is based on ISO 27001. An ISO 27001 certificate covers the ISMS foundation but does not address healthcare-specific controls.                            |
| **GDPR / AVG** | NEN 7510 compliance supports GDPR compliance for the security of processing (Article 32). The AP references NEN 7510 as the benchmark for healthcare data security. |
| **NEN 7512**   | Specifies trust requirements for electronic health data exchange. Implement alongside NEN 7510 if your organization exchanges patient data electronically.          |
| **NEN 7513**   | Specifies logging requirements for access to patient records. Considered mandatory practice for all Dutch healthcare organizations.                                 |

***

## Next Steps

* [Controls](/features/controls) - working through NEN 7510-2 healthcare controls
* [Risk Management](/features/risk-management) - healthcare-specific risk assessments
* [Vendor Risk](/features/vendor-risk) - managing processors handling patient data
* [Audit Programs](/features/audit-programs) - internal audit and certification preparation


# Getting Started with NIS2
Source: https://docs.matproof.com/frameworks/nis2

A practical guide to meeting NIS2 obligations for essential and important entities using Matproof.

# Getting Started with NIS2

The NIS2 Directive (EU 2022/2555) expands EU cybersecurity obligations to a much wider range of sectors than the original NIS Directive. Member states were required to transpose NIS2 into national law by **October 17, 2024**. If you are an **essential** or **important entity**, you are now subject to enforceable cybersecurity requirements — including mandatory incident reporting and potential personal liability for management.

Matproof maps NIS2 requirements to a set of controls, policies, and incident workflows so you can demonstrate compliance to your national competent authority (NCA).

<Note>
  Activate NIS2 under **Settings → Frameworks → NIS2**. Your control set will be pre-populated and mapped to the 10 minimum security measures under Article 21.
</Note>

***

## Am I in Scope?

NIS2 distinguishes two tiers of entities:

### Essential Entities (EE)

Subject to proactive supervision and higher penalties (up to €10M or 2% of global annual turnover, whichever is higher):

* Energy (electricity, oil, gas, hydrogen, district heating and cooling)
* Transport (air, rail, water, road)
* Banking (credit institutions)
* Financial market infrastructures
* Health (hospitals, laboratories, pharma manufacturers)
* Drinking water supply and distribution
* Wastewater collection, disposal, and treatment
* Digital infrastructure (DNS, TLDs, cloud computing services, data centres, CDNs, trust services, IXPs, electronic communications networks and services)
* ICT service management (MSPs, MSSPs)
* Public administration (central government)
* Space

### Important Entities (IE)

Subject to reactive supervision (lower penalties — €7M or 1.4% of global annual turnover, whichever is higher):

* Postal and courier services
* Waste management
* Chemicals manufacturing and distribution
* Food production and distribution
* Manufacturing (medical devices, computer/electronic products, electrical equipment, machinery, motor vehicles, other transport equipment)
* Digital providers (online marketplaces, search engines, social networks)
* Research

<Tip>
  Size thresholds apply: medium enterprises (50+ employees or €10M+ turnover) or large enterprises (250+ employees or €50M+ turnover) in these sectors are in scope. Smaller entities may be in scope if they are sole providers of critical services. Note: medium-sized entities in Annex I sectors are generally classified as Important entities, while large entities (250+ employees) in Annex I sectors are classified as Essential entities.
</Tip>

***

## The 10 NIS2 Minimum Security Measures

Article 21 requires essential and important entities to implement these 10 measures:

| #  | Measure                                                                                                                                             | Matproof Module           |
| -- | --------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------- |
| 1  | Policies on risk analysis and information system security                                                                                           | Policies, Risk Management |
| 2  | Incident handling                                                                                                                                   | Incidents                 |
| 3  | Business continuity (BCP, DR, crisis management)                                                                                                    | Policies, Controls        |
| 4  | Supply chain security (ICT product/service security)                                                                                                | Vendor Risk               |
| 5  | Security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure               | Controls                  |
| 6  | Policies to assess effectiveness of cybersecurity measures                                                                                          | Audit Programs            |
| 7  | Basic cyber hygiene practices and cybersecurity training                                                                                            | People, Policies          |
| 8  | Policies and procedures on cryptography and encryption                                                                                              | Policies, Controls        |
| 9  | Human resources security, access control policies, asset management                                                                                 | People, Controls          |
| 10 | Multi-factor authentication or continuous authentication, secured voice, video and text communications, and secured emergency communication systems | Controls, Evidence        |

***

## Management Accountability

NIS2 introduces **management accountability with potential personal liability**. Governing bodies:

* Must approve cybersecurity risk management measures
* Are liable for infringements by the entity
* Must undergo cybersecurity training
* The scope of personal liability depends on national transposition of the Directive.

<Warning>
  Document management sign-off on your NIS2 risk management measures and policies. Matproof tracks policy approvals with timestamps — this is your evidence that management has approved and reviewed the program.
</Warning>

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 — Determine your entity classification and NCA

  Identify whether you are an **essential entity** or **important entity** based on your sector and size. Register with your national competent authority (NCA) — most member states require self-registration. Check your national NIS2 transposition law for deadlines and registration requirements.

  Document your entity classification in **Settings → Organization**.

  ### Step 2 — Conduct a risk assessment

  NIS2 Article 21(1) requires risk management measures proportionate to the risks. Start with a formal risk assessment:

  1. Go to **Risk Management → New Risk Assessment**
  2. Assess risks to your network and information systems
  3. Include supply chain risks (ICT vendors and service providers)
  4. Score each risk and assign treatment plans
  5. Document your risk acceptance criteria

  The risk assessment is the foundation for the policies you generate next.

  ### Step 3 — Generate NIS2 policies

  Go to **Policies → Generate** and generate the NIS2 policy set. Key policies to prioritize:

  * Information Security Policy
  * Incident Response Policy
  * Business Continuity and Disaster Recovery Policy
  * Supply Chain Security Policy
  * Cryptography and Encryption Policy
  * Access Control Policy
  * Cybersecurity Training Policy

  Assign each policy to a member of the **management body** as owner — this documents management accountability.

  ### Step 4 — Configure the Incidents module

  NIS2 incident reporting requirements are strict:

  | Report Type           | Deadline                                                  | Recipient             |
  | --------------------- | --------------------------------------------------------- | --------------------- |
  | Early warning         | **24 hours** after becoming aware of significant incident | National CSIRT or NCA |
  | Incident notification | **72 hours**                                              | National CSIRT or NCA |
  | Final report          | **1 month** after incident notification                   | National CSIRT or NCA |

  If the incident is still ongoing when the final report is due, submit a progress report instead, then a final report within one month of handling the incident.

  1. Go to **Incidents → Settings** and configure your NIS2 incident classification criteria
  2. Define what constitutes a "significant incident" for your sector
  3. Set up escalation workflows so the right people are alerted within 24 hours
  4. Document your CSIRT/NCA contact details

  <Warning>
    The 24-hour early warning obligation is stricter than most other frameworks. Do not wait for full investigation — the early warning only requires that you are aware of the incident and its basic nature.
  </Warning>

  ### Step 5 — Map and assess your supply chain

  NIS2 Article 21(2)(d) specifically requires supply chain security. This is one of the most operationally demanding requirements.

  1. Go to **Vendor Risk** and import or add all ICT vendors and service providers
  2. Classify each vendor by criticality to your network and information systems
  3. Send a **NIS2 Supplier Assessment** to critical vendors
  4. Review vendors' own security practices and policies
  5. Document exit plans for critical single-source providers

  ### Step 6 — Complete Article 21 controls

  Work through the NIS2 control set in **Controls → NIS2**:

  * For each of the 10 minimum measures, link the relevant policies and evidence
  * Controls for human resources (Measure 9) should link to records in the **People** module
  * Controls for MFA and access (Measure 10) should be backed by integration evidence from your identity provider

  ### Step 7 — Cybersecurity training

  NIS2 requires cybersecurity awareness training for all staff and specialized training for management.

  1. Go to **People → Training**
  2. Assign cybersecurity awareness training to all employees
  3. Assign a management-level cybersecurity briefing to your governing body
  4. Track completion and link records as evidence against the relevant control

  ### Step 8 — Audit and ongoing monitoring

  1. Go to **Audit Programs → New Audit → NIS2**
  2. Run an internal audit against the 10 measures
  3. Document findings as Corrective Actions
  4. Set a recurring schedule — annual audit is the minimum for most entities
</Steps>

***

## Incident Reporting Quick Reference

| Trigger                       | Timeline  | Action                                                                                                                                                                                                                        |
| ----------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Significant incident detected | T+0       | Classify the incident, initiate internal escalation                                                                                                                                                                           |
| Within 24 hours               | T+24h     | Send early warning to NCA/CSIRT (whether suspected unlawful/malicious cause, whether cross-border impact possible)                                                                                                            |
| Within 72 hours               | T+72h     | Send incident notification (updated assessment, indicators of compromise)                                                                                                                                                     |
| Within 1 month                | T+1 month | Send final report (root cause, remediation, lessons learned). If the incident is still ongoing when the final report is due, submit a progress report instead, then a final report within one month of handling the incident. |

Use the **Incidents module** to track timeline, auto-generate draft notifications, and attach evidence to each report.

***

## Key Differences from NIS1

If you were already compliant with the original NIS Directive:

| Area                  | NIS1                  | NIS2                                 |
| --------------------- | --------------------- | ------------------------------------ |
| Scope                 | 7 sectors             | 18 sectors                           |
| Notification deadline | "Without undue delay" | 24h early warning + 72h notification |
| Management liability  | No                    | Yes — personal liability             |
| Supply chain          | Recommended           | Mandatory measure                    |
| Penalty               | National law          | Up to €10M/2% global turnover        |
| Enforcement           | Reactive              | Proactive for essential entities     |

***

## Next Steps

* [Incidents](/features/incidents) — configuring NIS2-compliant incident classification and multi-stage reporting
* [Vendor Risk](/features/vendor-risk) — supply chain security assessments and monitoring
* [People Module](/features/people) — employee training records and access management
* [Risk Management](/features/risk-management) — risk assessments proportionate to your sector


# Getting Started with NIST CSF and 800-53
Source: https://docs.matproof.com/frameworks/nist

A practical guide to implementing NIST Cybersecurity Framework and NIST 800-53 security controls using Matproof.

# Getting Started with NIST CSF and 800-53

The National Institute of Standards and Technology (NIST) publishes two of the most widely referenced cybersecurity frameworks in the world:

* **NIST Cybersecurity Framework (CSF) 2.0** - A voluntary framework for managing and reducing cybersecurity risk, organized around six core functions. Used by organizations of all sizes and sectors.
* **NIST SP 800-53 Rev. 5** - A comprehensive catalog of security and privacy controls, primarily used by US federal agencies and their contractors. Increasingly adopted by private sector organizations seeking a rigorous control baseline.

Matproof supports both frameworks. CSF provides the strategic risk management structure, while 800-53 provides the detailed control catalog. Many organizations use CSF for governance and communication, then map specific controls from 800-53 for implementation.

<Note>
  Activate NIST CSF and/or NIST 800-53 under **Settings - Frameworks**. You can activate both - Matproof automatically maps controls between them so you avoid duplicate work.
</Note>

***

## NIST CSF 2.0 - The Six Core Functions

CSF 2.0 (released February 2024) organizes cybersecurity activities into six functions:

<CardGroup>
  <Card title="Govern (GV)" icon="gavel">
    Establish and monitor cybersecurity risk management strategy, expectations, and policy. New in CSF 2.0.
  </Card>

  <Card title="Identify (ID)" icon="magnifying-glass">
    Understand your assets, business environment, risks, and supply chain to manage cybersecurity risk.
  </Card>

  <Card title="Protect (PR)" icon="shield-halved">
    Implement safeguards to ensure delivery of critical services.
  </Card>

  <Card title="Detect (DE)" icon="radar">
    Identify the occurrence of cybersecurity events in a timely manner.
  </Card>

  <Card title="Respond (RS)" icon="bell">
    Take action regarding a detected cybersecurity incident.
  </Card>

  <Card title="Recover (RC)" icon="rotate-right">
    Maintain plans for resilience and restore capabilities impaired by a cybersecurity incident.
  </Card>
</CardGroup>

<Tip>
  CSF 2.0 added the **Govern** function to emphasize that cybersecurity risk management must be integrated into enterprise risk management and driven by leadership. Start with Govern if you are building a program from scratch.
</Tip>

***

## NIST 800-53 - Control Families

NIST SP 800-53 Rev. 5 contains over 1,000 controls organized into 20 families:

| Family                                    | Code | Description                                              |
| ----------------------------------------- | ---- | -------------------------------------------------------- |
| Access Control                            | AC   | Access enforcement, least privilege, account management  |
| Awareness and Training                    | AT   | Security awareness, role-based training                  |
| Audit and Accountability                  | AU   | Audit logging, review, analysis                          |
| Assessment, Authorization, and Monitoring | CA   | Security assessments, system authorization               |
| Configuration Management                  | CM   | Baseline configuration, change control                   |
| Contingency Planning                      | CP   | Backup, recovery, continuity                             |
| Identification and Authentication         | IA   | User identification, MFA, credential management          |
| Incident Response                         | IR   | Incident handling, reporting, monitoring                 |
| Maintenance                               | MA   | System maintenance, tools, remote maintenance            |
| Media Protection                          | MP   | Media access, transport, sanitization                    |
| Physical and Environmental Protection     | PE   | Physical access, environmental controls                  |
| Planning                                  | PL   | Security planning, rules of behavior                     |
| Program Management                        | PM   | Risk management strategy, enterprise architecture        |
| Personnel Security                        | PS   | Screening, termination, transfer                         |
| PII Processing and Transparency           | PT   | Privacy, consent, data processing                        |
| Risk Assessment                           | RA   | Risk assessment, vulnerability scanning                  |
| System and Services Acquisition           | SA   | System development lifecycle, supply chain               |
| System and Communications Protection      | SC   | Boundary protection, cryptography, transmission security |
| System and Information Integrity          | SI   | Flaw remediation, malicious code protection, monitoring  |
| Supply Chain Risk Management              | SR   | Supply chain controls, component authenticity            |

<Note>
  You do not need to implement all 1,000+ controls. Select a baseline (Low, Moderate, or High) based on your system's security categorization (FIPS 199), then tailor controls to your environment.
</Note>

***

## Which Framework Should I Use?

| Use Case                                      | Recommended Framework                                                           |
| --------------------------------------------- | ------------------------------------------------------------------------------- |
| Building a cybersecurity program from scratch | Start with CSF 2.0 for structure, add 800-53 controls for implementation detail |
| US federal agency or contractor (FISMA)       | 800-53 is mandatory                                                             |
| FedRAMP cloud authorization                   | 800-53 Moderate or High baseline                                                |
| Private sector, non-regulated                 | CSF 2.0 is typically sufficient                                                 |
| Mapping to multiple frameworks                | CSF 2.0 maps well to ISO 27001, DORA, and other frameworks                      |
| Detailed technical controls needed            | 800-53 provides the most granular control catalog available                     |

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 - Establish governance (CSF: Govern)

  1. Go to **Policies - Generate** and create your Cybersecurity Risk Management Policy
  2. Define roles and responsibilities for cybersecurity governance
  3. Establish your risk appetite and risk tolerance levels
  4. Ensure leadership oversight of the cybersecurity program
  5. Document supply chain risk management expectations

  ### Step 2 - Identify assets and risks (CSF: Identify)

  1. Create an inventory of hardware, software, data, and services
  2. Go to **Risk Management - New Risk Assessment**
  3. Identify threats and vulnerabilities to your critical assets
  4. Assess risks based on likelihood and impact
  5. Prioritize risks for treatment based on your risk appetite

  ### Step 3 - Select your control baseline (800-53)

  If using NIST 800-53:

  1. Categorize your information systems using FIPS 199 (Low, Moderate, or High impact)
  2. Select the corresponding 800-53 baseline
  3. Matproof pre-populates the applicable controls based on your selection
  4. Tailor the baseline - add or remove controls based on your specific environment, threats, and risk assessment

  <Tip>
    Most commercial organizations implementing 800-53 voluntarily choose the Moderate baseline. It provides strong security coverage without the full rigor of the High baseline required for national security systems.
  </Tip>

  ### Step 4 - Implement protective controls (CSF: Protect)

  Work through the controls in **Controls - NIST**:

  * Access control and identity management (AC, IA)
  * Security awareness and training (AT)
  * Data protection and cryptography (SC)
  * Configuration management and change control (CM)
  * Maintenance and media protection (MA, MP)

  For each control, document the implementation, assign an owner, and link evidence.

  ### Step 5 - Detection and monitoring (CSF: Detect)

  1. Implement audit logging across systems in scope (AU)
  2. Configure continuous monitoring for security events
  3. Establish security event correlation and analysis processes
  4. Define detection thresholds and alerting criteria
  5. Link monitoring evidence to the relevant controls

  ### Step 6 - Incident response (CSF: Respond)

  1. Go to **Incidents** and configure your incident response workflow
  2. Define incident classification criteria and escalation procedures
  3. Establish communication plans for internal teams, leadership, and external parties
  4. Document lessons learned processes for post-incident improvement
  5. Test your incident response plan at least annually

  ### Step 7 - Recovery planning (CSF: Recover)

  1. Develop and document recovery plans for critical systems and services
  2. Define recovery time objectives (RTOs) and recovery point objectives (RPOs)
  3. Test recovery procedures regularly
  4. Document improvements identified during recovery testing
  5. Link recovery test results as evidence against the relevant controls

  ### Step 8 - Assessment and continuous improvement

  1. Go to **Audit Programs - New Audit - NIST**
  2. Assess your implementation against CSF functions and/or 800-53 controls
  3. Document findings as Corrective Actions
  4. Update your risk assessment based on findings
  5. Establish a continuous monitoring program to maintain compliance over time
</Steps>

***

## CSF 2.0 Profiles and Tiers

### Profiles

CSF profiles describe your organization's current and target cybersecurity posture. Create two profiles in Matproof:

* **Current Profile** - where you are today (based on your control assessment results)
* **Target Profile** - where you need to be (based on risk appetite, business requirements, and regulatory obligations)

The gap between the two profiles drives your implementation roadmap.

### Tiers

CSF implementation tiers describe the degree of rigor in your cybersecurity risk management:

| Tier                   | Description                                                                                                             |
| ---------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Tier 1 - Partial       | Ad hoc, reactive. Limited awareness of cybersecurity risk.                                                              |
| Tier 2 - Risk Informed | Risk management practices are approved by management but may not be organization-wide.                                  |
| Tier 3 - Repeatable    | Risk management practices are formally established, regularly updated, and informed by threat landscape changes.        |
| Tier 4 - Adaptive      | Organization adapts cybersecurity practices based on lessons learned and predictive indicators. Continuous improvement. |

***

## Next Steps

* [Risk Management](/features/risk-management) - risk assessments aligned to NIST methodology
* [Controls](/features/controls) - working through CSF and 800-53 control sets
* [Incidents](/features/incidents) - incident response workflow configuration
* [Audit Programs](/features/audit-programs) - security assessments and continuous monitoring


# NIST SP 800-53
Source: https://docs.matproof.com/frameworks/nist-800-53

NIST Special Publication 800-53 Revision 5 — security and privacy controls for federal information systems.

# NIST SP 800-53

## Overview

**NIST Special Publication 800-53 Revision 5** is the U.S. federal catalog of security and privacy controls for federal information systems and organizations. It is the foundational control set behind FedRAMP, FISMA, the DoD Risk Management Framework, and many state and sector-specific U.S. compliance regimes.

Matproof ships the full Revision 5 control catalog with mappings into your other adopted frameworks.

### Who It Applies To

* **U.S. federal agencies** — Required under FISMA
* **Federal contractors and FedRAMP CSPs** — Cloud providers serving the U.S. federal government
* **DoD and intelligence community systems** — Through the Risk Management Framework (RMF)
* **State and local governments** — Many adopt 800-53 as a baseline by reference
* **Private organizations** that need to demonstrate alignment with U.S. federal expectations

## Control Families

NIST 800-53 organizes controls into 20 families. The major ones:

| Family                                | Code   | Focus                                                   |
| ------------------------------------- | ------ | ------------------------------------------------------- |
| Access Control                        | AC     | Account management, separation of duties, remote access |
| Awareness and Training                | AT     | Security awareness program                              |
| Audit and Accountability              | AU     | Logging, monitoring, audit retention                    |
| Assessment, Authorization, Monitoring | CA     | System assessments, ATO process                         |
| Configuration Management              | CM     | Baseline configurations, change control                 |
| Contingency Planning                  | CP     | Backup, DR, COOP                                        |
| Identification and Authentication     | IA     | MFA, credential management                              |
| Incident Response                     | IR     | IR plan, reporting, training                            |
| Maintenance                           | MA     | System maintenance procedures                           |
| Media Protection                      | MP     | Sanitization, transport, disposal                       |
| Physical and Environmental Protection | PE     | Facility security                                       |
| Planning                              | PL     | System security plan, rules of behavior                 |
| Personnel Security                    | PS     | Background checks, termination procedures               |
| Risk Assessment                       | RA     | Risk assessments, vulnerability scanning                |
| System and Services Acquisition       | SA     | Supplier risk, secure SDLC                              |
| System and Communications Protection  | SC     | Boundary protection, cryptography                       |
| System and Information Integrity      | SI     | Flaw remediation, malicious code protection             |
| Supply Chain Risk Management          | SR     | C-SCRM program, supplier review                         |
| Privacy                               | PT, PM | Privacy controls (added in Rev 5)                       |

## Control Baselines

NIST 800-53 controls apply via **baselines** depending on system impact level:

* **LOW** baseline — minimum controls for low-impact systems
* **MODERATE** baseline — most federal systems sit here
* **HIGH** baseline — systems where loss of confidentiality, integrity, or availability would have catastrophic impact

Matproof lets you select a baseline when adopting NIST 800-53; only the relevant controls are included in your program.

## How Matproof Helps

### Control Catalog

* Full Revision 5 control catalog (1,189 controls including enhancements)
* Pre-tagged by family and baseline
* Searchable across control text and supplemental guidance

### FedRAMP Alignment

* FedRAMP LOW / MODERATE / HIGH baselines pre-configured
* FedRAMP-specific control parameters tracked
* Continuous Monitoring (ConMon) artifact templates

### Cross-Framework Mapping

NIST 800-53 maps extensively into other frameworks Matproof ships:

* ISO 27001 — Annex A controls
* SOC 2 — Trust Services Criteria
* NIST Cybersecurity Framework (CSF) — through the CSF-to-800-53 informative references
* HIPAA — Security Rule safeguards
* DORA / NIS2 — security requirements

A single piece of evidence (e.g. an MFA configuration screenshot) can satisfy controls across all of these frameworks at once.

### Evidence Automation

* Cloud integration evidence (AWS, Azure, GCP) automatically populates AC, AU, CM, IA, SC controls
* Device Agent evidence populates SI, CM, AC controls for endpoints
* Manual evidence with structured templates for the rest

### System Security Plan (SSP)

* Generate SSPs from your control implementations
* Export-ready format for ATO submissions
* Continuous updates as controls change

## Getting Started

1. Select **NIST 800-53** as a framework during onboarding (or in Settings > Frameworks)
2. Choose your impact baseline: LOW / MODERATE / HIGH (or full catalog)
3. Review the control mapping into your other adopted frameworks
4. Assign control owners across your organization
5. Connect cloud and identity integrations to start populating evidence

<CardGroup>
  <Card title="NIST CSF" href="/frameworks/nist">
    The companion Cybersecurity Framework — risk-based, lighter weight
  </Card>

  <Card title="Frameworks Overview" href="/frameworks/dora">
    See all 16 frameworks Matproof supports
  </Card>
</CardGroup>


# Getting Started with PCI DSS
Source: https://docs.matproof.com/frameworks/pci-dss

A practical guide to meeting PCI DSS v4.0 requirements for organizations that store, process, or transmit cardholder data using Matproof.

# Getting Started with PCI DSS

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements for any organization that stores, processes, or transmits cardholder data. PCI DSS v4.0 is the current version, with the transition period from v3.2.1 completed on **March 31, 2024**. Additional future-dated requirements in v4.0 become mandatory on **March 31, 2025**.

PCI DSS is maintained by the PCI Security Standards Council and enforced through the payment card brands (Visa, Mastercard, American Express, Discover, JCB). Compliance is validated through Self-Assessment Questionnaires (SAQs) or on-site assessments by a Qualified Security Assessor (QSA), depending on your transaction volume and merchant level.

Matproof maps PCI DSS v4.0 requirements to controls, policies, and evidence workflows so you can prepare for your annual assessment.

<Note>
  Activate PCI DSS under **Settings - Frameworks - PCI DSS**. Controls are pre-populated across all 12 requirements and their sub-requirements.
</Note>

***

## Am I in Scope?

PCI DSS applies to any entity that stores, processes, or transmits **cardholder data** or **sensitive authentication data**, including:

* Merchants (online and physical)
* Payment processors and acquirers
* Issuers
* Service providers that handle cardholder data on behalf of other entities

<Tip>
  Reduce your scope by minimizing where cardholder data is stored and processed. Using a PCI-compliant payment processor (like Stripe or Adyen) that tokenizes card data can significantly reduce the number of applicable requirements.
</Tip>

***

## The 12 PCI DSS Requirements

PCI DSS is organized into six goals and 12 requirements:

| Goal                                            | Requirement                                                                          | Matproof Module       |
| ----------------------------------------------- | ------------------------------------------------------------------------------------ | --------------------- |
| **Build and Maintain a Secure Network**         | 1. Install and maintain network security controls                                    | Controls              |
|                                                 | 2. Apply secure configurations to all system components                              | Controls              |
| **Protect Account Data**                        | 3. Protect stored account data                                                       | Controls, Evidence    |
|                                                 | 4. Protect cardholder data with strong cryptography during transmission              | Controls              |
| **Maintain a Vulnerability Management Program** | 5. Protect all systems and networks from malicious software                          | Controls              |
|                                                 | 6. Develop and maintain secure systems and software                                  | Controls, Policies    |
| **Implement Strong Access Control Measures**    | 7. Restrict access to system components and cardholder data by business need to know | Controls, People      |
|                                                 | 8. Identify users and authenticate access to system components                       | Controls              |
|                                                 | 9. Restrict physical access to cardholder data                                       | Controls              |
| **Regularly Monitor and Test Networks**         | 10. Log and monitor all access to system components and cardholder data              | Controls, Evidence    |
|                                                 | 11. Test security of systems and networks regularly                                  | Controls, Cloud Tests |
| **Maintain an Information Security Policy**     | 12. Support information security with organizational policies and programs           | Policies, People      |

***

## PCI DSS v4.0 Key Changes

If you were compliant with v3.2.1, these are the most significant changes in v4.0:

| Change                           | Impact                                                                                                                                                    |
| -------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Customized approach**          | Organizations can now meet requirements using alternative controls with a customized validation approach, in addition to the traditional defined approach |
| **Targeted risk analysis**       | Required for certain requirements where frequency or scope is determined by the entity                                                                    |
| **Enhanced authentication**      | Multi-factor authentication required for all access to the cardholder data environment (not just remote access)                                           |
| **Automated technical controls** | Greater emphasis on automated mechanisms for detection and response                                                                                       |
| **Security awareness**           | Enhanced training requirements including phishing awareness                                                                                               |

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 - Define your cardholder data environment (CDE)

  1. Identify all systems that store, process, or transmit cardholder data
  2. Map data flows showing how cardholder data enters, moves through, and exits your environment
  3. Identify all connected systems and networks
  4. Document the CDE scope in **Settings - Organization**
  5. Review scope annually and after any significant change to your environment

  <Warning>
    Scope creep is the most common PCI DSS compliance failure. Any system connected to the CDE is in scope. Use network segmentation to limit scope and reduce the number of applicable controls.
  </Warning>

  ### Step 2 - Generate PCI DSS policies

  Go to **Policies - Generate** and create the required policy set:

  * Information Security Policy
  * Acceptable Use Policy
  * Access Control Policy
  * Network Security Policy
  * Encryption and Key Management Policy
  * Incident Response Policy
  * Change Management Policy
  * Vulnerability Management Policy
  * Physical Security Policy

  Each policy must be reviewed at least annually and updated when the environment changes.

  ### Step 3 - Network security and secure configurations

  Requirements 1 and 2 establish the foundation:

  1. Document and implement network security controls (firewalls, network segmentation)
  2. Establish secure configuration standards for all system components
  3. Remove or disable unnecessary services, protocols, and accounts
  4. Link configuration evidence to the relevant controls in Matproof

  ### Step 4 - Protect account data

  Requirements 3 and 4 address data protection:

  1. Inventory all locations where cardholder data is stored
  2. Implement strong cryptography for stored data (Requirement 3) and data in transit (Requirement 4)
  3. Document your encryption key management procedures
  4. Implement data retention and disposal policies
  5. Never store sensitive authentication data after authorization

  ### Step 5 - Vulnerability management

  Requirements 5 and 6:

  1. Deploy anti-malware solutions on all systems commonly affected by malware
  2. Establish a vulnerability management program with regular scanning
  3. Apply critical security patches within one month of release
  4. Implement secure software development practices if you develop payment applications
  5. Conduct vulnerability scans quarterly (internal and external ASV scans)

  ### Step 6 - Access control and authentication

  Requirements 7, 8, and 9:

  1. Implement role-based access control - restrict access to cardholder data by business need to know
  2. Assign unique IDs to all users with access to system components
  3. Implement multi-factor authentication for all access to the CDE
  4. Implement physical access controls for facilities housing cardholder data
  5. Document and link access reviews as evidence in Matproof

  ### Step 7 - Logging, monitoring, and testing

  Requirements 10 and 11:

  1. Enable audit logging for all system components in the CDE
  2. Review logs daily (automated log monitoring tools are recommended)
  3. Conduct quarterly internal and external vulnerability scans
  4. Perform annual penetration testing of the CDE
  5. Implement change detection mechanisms for critical files

  ### Step 8 - Security policy and training

  Requirement 12:

  1. Ensure all policies are current and reviewed annually
  2. Conduct security awareness training for all personnel upon hire and annually
  3. Include phishing simulation exercises (new in v4.0)
  4. Maintain an incident response plan and test it annually
  5. Conduct a targeted risk analysis where required by specific sub-requirements

  ### Step 9 - Assessment preparation

  1. Go to **Audit Programs - New Audit - PCI DSS**
  2. Run an internal assessment against all applicable requirements
  3. Remediate gaps documented as Corrective Actions
  4. Determine your merchant level and appropriate validation method (SAQ or QSA assessment)
  5. Engage a QSA if required, or complete the appropriate SAQ
</Steps>

***

## Merchant Levels

| Level | Transaction Volume (Visa)                                                   | Validation                                         |
| ----- | --------------------------------------------------------------------------- | -------------------------------------------------- |
| 1     | Over 6 million transactions per year                                        | Annual on-site QSA assessment + quarterly ASV scan |
| 2     | 1-6 million transactions per year                                           | Annual SAQ + quarterly ASV scan                    |
| 3     | 20,000 - 1 million e-commerce transactions per year                         | Annual SAQ + quarterly ASV scan                    |
| 4     | Fewer than 20,000 e-commerce or up to 1 million other transactions per year | Annual SAQ + quarterly ASV scan (recommended)      |

<Note>
  Merchant levels and validation requirements vary by card brand. The table above reflects Visa's classification. Check with your acquiring bank for your specific obligations.
</Note>

***

## Next Steps

* [Controls](/features/controls) - working through PCI DSS requirement controls
* [Evidence Collection](/features/evidence-collection) - automated evidence from integrations
* [Cloud Tests](/features/cloud-tests) - vulnerability scanning and penetration testing evidence
* [Vendor Risk](/features/vendor-risk) - service provider compliance management


# Getting Started with SOC 2
Source: https://docs.matproof.com/frameworks/soc2

How to prepare for and achieve SOC 2 Type I or Type II using Matproof.

# Getting Started with SOC 2

SOC 2 (System and Organization Controls 2) is the security framework US enterprise customers expect from SaaS vendors. A SOC 2 report — issued by a licensed CPA firm — attests that your organization's controls around security, availability, processing integrity, confidentiality, and privacy meet AICPA Trust Services Criteria.

Matproof maps the SOC 2 **Common Criteria (CC)** and selected additional criteria to your controls, evidence, and policies so you can prepare for audit without a spreadsheet.

<Note>
  Activate SOC 2 under **Settings → Frameworks → SOC 2**. Your control set (\~60 controls mapped to the 33 Common Criteria) will be pre-populated. You can add criteria for Availability, Confidentiality, and Privacy separately.
</Note>

***

## SOC 2 Type I vs. Type II

|                         | Type I                                                 | Type II                                                                                           |
| ----------------------- | ------------------------------------------------------ | ------------------------------------------------------------------------------------------------- |
| **What it attests**     | Controls are designed appropriately at a point in time | Controls operated effectively over a review period (typically 3-12 months; 6+ months recommended) |
| **Audit duration**      | 2-4 weeks                                              | 3-6 months observation period + audit                                                             |
| **What customers want** | Proof you have controls in place                       | Proof controls work consistently                                                                  |
| **When to pursue**      | First SOC 2, fast-track option                         | Required by enterprise customers                                                                  |

<Tip>
  Target Type I first if you need a report quickly. Many enterprises will accept Type I while you accumulate the observation period for Type II.
</Tip>

***

## The 5 Trust Services Criteria

| Criteria                      | What It Covers                                                          | Required?                                  |
| ----------------------------- | ----------------------------------------------------------------------- | ------------------------------------------ |
| **Security (CC)**             | Logical and physical access, change management, risk, incident response | Always required                            |
| **Availability (A)**          | System uptime, performance, disaster recovery                           | Optional — add if customers require it     |
| **Processing Integrity (PI)** | Complete, accurate, and timely data processing                          | Optional — relevant for payment processors |
| **Confidentiality (C)**       | Protection of confidential information                                  | Optional — common for B2B SaaS             |
| **Privacy (P)**               | Collection, use, and disposal of personal information                   | Optional — relevant if you process PII     |

Most SaaS companies start with **Security only**. Add Availability and Confidentiality for enterprise deals.

***

## Recommended Implementation Plan

<Steps>
  ### Step 1 — Define your system description

  Every SOC 2 report opens with a **System Description** — a document written by management that describes what your system does, the infrastructure it runs on, and the controls in place.

  Document the following in your **Settings → Context Hub**:

  * What your product does and what data it processes
  * Cloud infrastructure (AWS, GCP, Azure regions and services)
  * Subservice organizations (Stripe, Twilio, Okta — services you rely on that have their own controls)
  * Boundaries of the in-scope system

  Your auditor uses this to scope the audit. Be specific and accurate — discrepancies between the description and the actual system are findings.

  ### Step 2 — Select your Trust Services Criteria

  In **Settings → Frameworks → SOC 2**, choose which criteria apply to your system. Start with Security (Common Criteria) unless your customers explicitly require others.

  The controls list will update to reflect your selected criteria.

  ### Step 3 — Complete Common Criteria controls

  The Common Criteria (CC1-CC9) cover nine control categories. Work through them in this order:

  | Category                                   | Focus                                                           | Key Controls                                                           |
  | ------------------------------------------ | --------------------------------------------------------------- | ---------------------------------------------------------------------- |
  | CC1 — Control Environment                  | Tone from the top, code of conduct, org structure               | Policy approvals, org chart                                            |
  | CC2 — Communication and Information        | Internal and external communication                             | Security awareness training                                            |
  | CC3 — Risk Assessment                      | Identify and analyze risks                                      | Risk register                                                          |
  | CC4 — Monitoring Activities                | Evaluating whether controls are present and functioning         | Management reviews of control effectiveness, internal audit activities |
  | CC5 — Control Activities                   | Policies, procedures, and technology controls                   | Access reviews, change management                                      |
  | CC6 — Logical and Physical Access Controls | Access provisioning, MFA, authentication                        | Access logs, offboarding evidence                                      |
  | CC7 — System Operations                    | Incident detection, vulnerability management, and response      | Incident log, vulnerability scans, monitoring tools                    |
  | CC8 — Change Management                    | Code review, deployment controls                                | GitHub branch protection, CI/CD                                        |
  | CC9 — Risk Mitigation                      | Business disruption response and vendor/partner risk management | Vendor assessments, BCP                                                |

  <Tip>
    CC6 (Logical and Physical Access Controls) and CC8 (Change Management) are where most findings occur. Connect your GitHub and identity provider integrations early so evidence is collected automatically.
  </Tip>

  ### Step 4 — Generate and approve policies

  SOC 2 auditors check for documented policies covering:

  * Information Security Policy
  * Access Control Policy
  * Change Management Policy
  * Incident Response Policy
  * Vendor Management Policy
  * Business Continuity and Disaster Recovery Policy

  Go to **Policies → Generate** and generate all SOC 2 policies. Customize them to match your actual environment, assign owners, and mark them **Approved**.

  ### Step 5 — Connect integrations for automated evidence

  SOC 2 evidence collection is heavily focused on access control, change management, and monitoring. Connect these integrations to automate evidence:

  | Integration                        | Evidence It Provides                                        |
  | ---------------------------------- | ----------------------------------------------------------- |
  | **GitHub**                         | Branch protection rules, PR review logs, deployment history |
  | **Google Workspace / Okta**        | User access lists, MFA enforcement status, admin logs       |
  | **AWS / GCP / Azure**              | Configuration checks, IAM policy snapshots, CloudTrail logs |
  | **Vanta / Drata-style auto-tests** | Continuous control testing                                  |

  Go to **Settings → Integrations** to connect your tools.

  ### Step 6 — Run access reviews

  CC6 requires periodic access reviews — evidence that you regularly check who has access to what and remove inappropriate access.

  1. Go to **People → Access Reviews**
  2. Initiate an access review for each critical system
  3. Document approvals and removals
  4. Set a recurring schedule (quarterly is typical for SOC 2)

  ### Step 7 — Accumulate observation period evidence (Type II only)

  For Type II, your auditor reviews evidence over a 3-12 month observation period. This means controls must operate consistently, not just be in place at audit time.

  Track:

  * Regular access review completions
  * Incident log entries (even if zero incidents — document that monitoring was active)
  * Change management records (PRs reviewed, deployments approved)
  * Vendor assessment records

  ### Step 8 — Readiness assessment

  Before engaging a CPA firm, run a readiness assessment:

  1. Go to **Audit Programs → New Audit → SOC 2 Readiness**
  2. Work through the control checklist
  3. Document gaps as **Corrective Actions**
  4. Close corrective actions before the formal audit begins

  Most CPA firms offer a readiness assessment as a paid service — doing it internally in Matproof first saves significant cost.
</Steps>

***

## Evidence Checklist

These are the most commonly requested evidence items in a SOC 2 audit:

| Control Area             | Evidence to Collect                                                                    |
| ------------------------ | -------------------------------------------------------------------------------------- |
| Access Control           | User access list exports (quarterly), MFA enforcement screenshots, offboarding tickets |
| Change Management        | PR review history, deployment approval records, code freeze policies                   |
| Incident Response        | Incident log, post-mortem documents, escalation procedure                              |
| Vendor Risk              | Vendor risk assessments, SOC 2 reports from key subservice orgs                        |
| Background Checks        | Employee background check policy and completion records                                |
| Encryption               | Encryption at rest/in transit documentation, key management policy                     |
| Vulnerability Management | Penetration test report, patch cadence records                                         |
| Business Continuity      | BCP document, DR test results                                                          |

***

## Common Audit Findings

### 1. No formal offboarding process

The most frequent CC6 finding. "We remove access when people leave" is not sufficient — auditors want a ticket or checklist showing the exact steps taken for each departure.

### 2. Access reviews not completed on schedule

Committing to quarterly reviews in your policy and then having no evidence of review completion in the audit period is an immediate finding.

### 3. Subservice organization SOC 2 reports not reviewed

SOC 2 best practice requires you to obtain and review your key subservice organizations' SOC 2 reports regularly (typically annually). Stripe, AWS, and your identity provider all publish these. Document that you have reviewed them.

***

## Next Steps

* [Evidence Collection](/features/evidence-collection) — connecting integrations and automating evidence uploads
* [People Module](/features/people) — employee records, access reviews, and offboarding checklists
* [Vendor Risk](/features/vendor-risk) — managing subservice organizations and requesting their SOC 2 reports
* [Audit Programs](/features/audit-programs) — running your SOC 2 readiness assessment


# AI Providers (Anthropic, OpenAI, Hugging Face, W&B)
Source: https://docs.matproof.com/integrations/ai-providers

Connect AI provider credentials so Matproof can produce automated EU AI Act and ISO 42001 evidence against your AI training and inference infrastructure.

# AI Providers

Matproof's AI integrations capture evidence about the AI systems your organization develops or deploys — for the EU AI Act, ISO 42001, and the AI-related parts of NIS 2 and DORA. These integrations differ from cloud or identity integrations: they don't continuously sync data into Matproof. Instead, you store credentials with read-only scopes, and Matproof's [AI Systems inventory](/frameworks/eu-ai-act) module runs targeted checks against your AI infrastructure when you trigger them or on a schedule.

## What's available

| Provider             | Use case                                                       | Evidence produced                                                                                                                   |
| -------------------- | -------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| **Anthropic**        | Claude API usage tracking                                      | Model versions in production, usage logs, content-filter configuration, system-prompt inventory                                     |
| **OpenAI**           | GPT API usage tracking                                         | Same as Anthropic — model versions, usage logs, fine-tune lineage                                                                   |
| **Hugging Face**     | Open-source model registry, dataset cards, fine-tuning history | Model cards (Article 53 GPAI documentation), dataset provenance, training-data lineage                                              |
| **Weights & Biases** | ML experiment tracking                                         | Training runs, hyperparameters, evaluation metrics, model artefacts — for technical-documentation evidence under EU AI Act Annex IV |

## Why these matter for the EU AI Act

The EU AI Act expects providers and deployers of high-risk AI systems to produce specific technical documentation (Article 11, Annex IV) and post-market monitoring evidence (Article 72). Without these integrations, you'd produce that evidence by hand — exporting screenshots from each provider, pasting CSVs of training runs into spreadsheets, manually tracking model versions through deployment cycles.

Matproof's AI integrations populate the [Foundation Model Cards](/frameworks/eu-ai-act) and AI System Inventory directly from the provider, so your evidence stays current as your models change.

## Connecting an AI provider

The connection flow is identical across providers. Each requires only a read-only API key (no OAuth flow — these providers don't offer OAuth for org-level reads).

<Steps>
  <Step title="Generate a read-only API key in the provider's console">
    | Provider         | Where                                                                                    |
    | ---------------- | ---------------------------------------------------------------------------------------- |
    | Anthropic        | [console.anthropic.com](https://console.anthropic.com) → Settings → API Keys             |
    | OpenAI           | [platform.openai.com](https://platform.openai.com) → API Keys                            |
    | Hugging Face     | [huggingface.co](https://huggingface.co) → Settings → Access Tokens (use **Read** scope) |
    | Weights & Biases | [wandb.ai](https://wandb.ai) → User Settings → API keys                                  |
  </Step>

  <Step title="Restrict the key (if the provider supports it)">
    * **OpenAI**: scope the key to **Read-only** project permissions
    * **Anthropic**: scope to a specific workspace
    * **Hugging Face**: pick **Read** scope (not **Write**)
    * **W\&B**: viewer-level access; restrict to specific projects if you only want certain projects scanned
  </Step>

  <Step title="Add the credential in Matproof">
    Go to **Settings → Integrations**, find the AI provider, and click **Connect**. Paste the API key. Matproof tests the connection and stores the credential encrypted.
  </Step>

  <Step title="Link to your AI Systems inventory">
    Open **AI Systems** in the sidebar. For each AI system you've registered, link the relevant provider credential. Matproof now pulls model metadata, usage logs, and training metadata for that system on the next scheduled scan (or run a manual scan immediately).
  </Step>
</Steps>

## What evidence each integration produces

### Anthropic

* **Models in use** — every Claude model version your org has called in the last 90 days, by API key
* **Usage logs** — request count, token volume, error rate per model (rolled up; no individual prompts retained)
* **Content-filter configuration** — Anthropic's safety settings on each workspace
* **System-prompt inventory** — for AI systems registered with system-prompt tracking enabled

Maps to: EU AI Act Article 13 (transparency), Article 17 (QMS), Article 72 (post-market monitoring); ISO 42001 A.6.

### OpenAI

* **Models in use** — production model versions, including fine-tune lineage (which base model + which fine-tune dataset)
* **Usage logs** — request volume per project per model
* **Moderation flag rate** — how often the OpenAI moderation API flagged content over time
* **Fine-tune history** — datasets used, training runs, evaluation metrics

Maps to: EU AI Act Article 11 (technical docs), Annex IV; ISO 42001 A.6, A.7.

### Hugging Face

* **Organization model cards** — Matproof imports model cards for any model your HF org publishes or maintains. These satisfy EU AI Act Article 53(1)(a–c) GPAI documentation requirements.
* **Dataset cards** — for training datasets your org owns or uses
* **Fine-tune lineage** — base model → fine-tune model relationships
* **Evaluation results** — published evaluation metrics on model cards

Maps to: EU AI Act Article 53 (GPAI obligations), Annex IV; ISO 42001 A.7.

### Weights & Biases

* **Training runs** — every run with hyperparameters, dataset references, evaluation metrics
* **Model artefacts** — versioned model weights with provenance
* **Sweep / experiment results** — hyperparameter tuning campaigns
* **Reports** — W\&B reports linked as documentation artefacts

Maps to: EU AI Act Article 11 (technical documentation), Annex IV (records of training/testing); ISO 42001 A.6.2.

## Privacy and data handling

These integrations read **metadata** about your AI usage — not the prompts, completions, or training data themselves.

* Matproof does not store any prompts you send to Anthropic or OpenAI
* Matproof does not download training datasets from Hugging Face (only the dataset card / metadata)
* Matproof does not store model weights from W\&B (only the run metadata)

If your AI infrastructure processes personal data, your existing GDPR / DPA obligations apply at the provider level, not at the Matproof level.

## Disconnecting

For each provider, **Settings → Integrations → \[Provider] → Disconnect**. The encrypted credential is purged from Matproof's secrets store.

Also revoke the API key in the provider's console — disconnection only removes the credential from Matproof; the key itself remains valid in the provider's system until you delete it there.

<CardGroup>
  <Card title="EU AI Act" href="/frameworks/eu-ai-act">
    The framework that drives most AI-integration use cases
  </Card>

  <Card title="ISO 42001" href="/frameworks/iso42001">
    AI management system companion standard
  </Card>
</CardGroup>


# Aikido Security Integration
Source: https://docs.matproof.com/integrations/aikido

Connect Aikido to ingest vulnerability scan results and repository security findings into Matproof's unified Findings view.

## Overview

The Aikido Security integration syncs vulnerability and repository-scanning data from Aikido into Matproof, so the security findings your scanner produces become evidence for compliance controls — without copy-pasting CSVs every quarter.

Aikido covers SAST, SCA (dependency vulnerabilities), IaC scanning, container scanning, surface monitoring, secrets scanning, and license compliance. Matproof ingests the issues Aikido finds and routes them to the unified [Findings](/features/findings) view, where they're tracked through to closure alongside findings from internal audits, pen tests, the device agent, and elsewhere.

**Evidence ingested:**

* Open security issues by severity (informational, low, medium, high, critical)
* Repository scan activity (which repos scanned, when last scanned)
* Stale-scan detection (repos not scanned in 7+ days)
* Issue-count thresholds (configurable — fail the check if open issues exceed your threshold)
* Severity-breakdown summaries

***

## Prerequisites

* Aikido Security workspace with at least one repository or asset configured
* Aikido API credentials (Client ID + Client Secret)
* Matproof Admin or Owner role

***

## Connecting Aikido

<Steps>
  <Step title="Generate API credentials in Aikido">
    In Aikido Security: **Settings → API → Create API client**. Issue a client with the **read** scope on Issues and Repositories. Copy the **Client ID** and **Client Secret** — Aikido shows the secret only once.
  </Step>

  <Step title="Add credentials to Matproof">
    In Matproof: **Settings → Integrations → Aikido Security → Connect**. Paste the Client ID and Client Secret. Matproof tests the connection and runs the first scan.
  </Step>

  <Step title="Configure check thresholds">
    Open **Integrations → Aikido → Configure** and set the thresholds Matproof uses to evaluate your security posture:

    | Setting                         | What it does                                                                               |
    | ------------------------------- | ------------------------------------------------------------------------------------------ |
    | **Minimum severity to fail on** | Issues at this severity or higher cause the check to fail (low / medium / high / critical) |
    | **Maximum allowed open issues** | If total open issues exceed this number, the check fails regardless of severity            |
    | **Repository filter**           | Restrict to specific repos; leave empty for all repos                                      |
    | **Include snoozed issues**      | Whether snoozed (deferred) issues count against the threshold                              |
  </Step>

  <Step title="Verify it works">
    Click **Run** on any Aikido check in the integration view. You should see a recent run with passing or failing evidence within seconds. If a check fails with `HTTP 401: Unauthorized`, verify the Client ID and Client Secret and confirm the **read** scope is enabled.
  </Step>
</Steps>

***

## What gets mapped to which controls

| Evidence Collected                      | Control Examples                                                          |
| --------------------------------------- | ------------------------------------------------------------------------- |
| Open critical/high CVEs below threshold | Vulnerability management (ISO 27001 A.8.8, SOC 2 CC7.1, NIS 2 Article 21) |
| Repositories scanned within last 7 days | Secure SDLC / change management evidence                                  |
| Stale scans surfaced as findings        | Vulnerability management process effectiveness                            |
| Severity-tier breakdown                 | Risk-based vulnerability prioritization (ISO 27001 A.5.12)                |
| Snooze rationale (when included)        | Risk-acceptance documentation                                             |

***

## Aikido findings in the unified Findings view

Every issue Aikido reports becomes a finding in Matproof's unified [Findings](/features/findings) view, tagged with source = `aikido`. From there:

* Triage, assign owners, set due dates as you would any other finding
* Convert high-severity issues to [Corrective Actions](/features/corrective-actions) for tracked remediation
* Mark closed when Aikido shows the issue resolved on its next sync — or override manually with attached evidence

This means your weekly findings review covers Aikido's output alongside internal audit findings, pen-test results, and device-agent CVEs — one queue, one taxonomy.

***

## Common issues

### `HTTP 401: Unauthorized` on every check

Most often the credentials don't have the **read** scope on the right resources. Re-issue the API client in Aikido with **Issues: read** and **Repositories: read** explicitly granted, and update the credentials in Matproof.

### "Stale scan" check fails right after connecting

The 7-day staleness window starts when Aikido first scans a repo, not when Matproof connects. If you connected Aikido and added repos in the same week, all repos may show as "never scanned" for the first day or two. Trigger manual scans in Aikido or wait for the scheduled scans to complete.

### Issue count differs between Matproof and Aikido dashboard

Matproof's threshold check filters by your configured **minimum severity** and (optionally) excludes snoozed issues. The Aikido dashboard shows everything. Check your Matproof configuration under **Integrations → Aikido → Configure** — adjusting **minimum severity** to "informational" makes the counts match.

***

## Disconnecting

Go to **Settings → Integrations → Aikido Security → Disconnect**. The encrypted credentials are purged from Matproof.

In Aikido: also revoke the API client from **Settings → API → \[client] → Revoke** to fully cut access on the Aikido side.

Previously ingested findings remain in Matproof's Findings view (so historical audit context is preserved). Future Aikido scans won't sync until you reconnect.

***

## References

* [Aikido API documentation](https://apidocs.aikido.dev/reference)

<CardGroup>
  <Card title="Findings" href="/features/findings">
    Where Aikido-ingested issues land
  </Card>

  <Card title="Corrective Actions" href="/features/corrective-actions">
    Track remediation of high-severity findings to closure
  </Card>
</CardGroup>


# API Integration
Source: https://docs.matproof.com/integrations/api

Push evidence and data to Matproof via API.

## Overview

Use the Matproof REST API to push evidence from your own tools, trigger assessments, or build custom integrations.

## Base URL

```
https://api.matproof.com/v1
```

## Authentication

See [API Authentication](/api-reference/authentication) for how to get and use your API key.

## Use cases

* Push evidence from your CI/CD pipeline (e.g., test results, security scan reports)
* Sync vendor data from your procurement system
* Trigger compliance assessments from external workflows
* Export data to your own reporting tools

## Rate limits

| Plan         | Requests per minute |
| ------------ | ------------------- |
| Starter      | 60                  |
| Professional | 300                 |
| Enterprise   | Unlimited           |

## Webhooks

Matproof can send webhooks to your systems when:

* A vendor submits a questionnaire response
* A control status changes
* Evidence is about to expire
* A risk score changes

Configure webhooks in **Settings → Webhooks**.


# AWS Integration
Source: https://docs.matproof.com/integrations/aws

Connect AWS to collect IAM, CloudTrail, and infrastructure security evidence automatically.

## Overview

The AWS integration reads security and configuration data from your AWS account to provide evidence for infrastructure controls. It uses a read-only IAM role — Matproof never modifies your AWS environment.

**Evidence collected automatically:**

* IAM users, roles, and policy assignments
* Root account MFA status
* CloudTrail logging enabled and configured
* S3 bucket encryption and public access settings
* Security groups with overly permissive rules (0.0.0.0/0 ingress)
* KMS key rotation status
* Password policy strength settings
* Unused IAM credentials (access keys not used in 90+ days)
* AWS Config enabled status
* GuardDuty enabled status

***

## Prerequisites

* AWS account with permission to create IAM roles
* Matproof Admin or Owner role
* Ability to run a CloudFormation template or create IAM resources manually

***

## Connecting AWS

Matproof uses a **cross-account IAM role** with read-only permissions. This is the AWS-recommended pattern for third-party integrations.

### Option A — CloudFormation (recommended)

1. Go to **Settings → Integrations → AWS → Connect**
2. Click **Deploy CloudFormation Stack**
3. You will be redirected to your AWS Console with the CloudFormation template pre-loaded
4. Review the template — it creates a single IAM role with the `ReadOnlyAccess` managed policy
5. Click **Create stack**
6. Once the stack is created, copy the **Role ARN** from the Outputs tab
7. Paste the Role ARN back in Matproof and click **Verify connection**

### Option B — Manual IAM role

1. In AWS IAM, create a new role with **Another AWS account** as the trusted entity
2. Enter Matproof's AWS account ID (shown in the integration setup screen)
3. Attach the `ReadOnlyAccess` managed policy
4. Add a condition: `sts:ExternalId` = the external ID shown in Matproof (prevents confused deputy attacks)
5. Copy the Role ARN and paste it in Matproof

<Note>
  Matproof only ever calls `sts:AssumeRole` to assume your read-only role. It cannot elevate privileges or access resources outside the `ReadOnlyAccess` scope.
</Note>

***

## Multi-Account Setup

If you use AWS Organizations with multiple accounts, you can connect each account separately. For large organizations, Matproof supports an **Organizations-level connection** that scans all member accounts using a delegated admin role. Contact support to set this up.

***

## What Gets Mapped to Which Controls

| Evidence Collected                             | Control Examples                                         |
| ---------------------------------------------- | -------------------------------------------------------- |
| Root account MFA enabled                       | Privileged access controls (SOC 2 CC6, ISO 27001 A.5.16) |
| CloudTrail enabled in all regions              | Logging and monitoring controls (DORA Art. 10)           |
| No S3 buckets with public read/write           | Data protection controls                                 |
| IAM password policy meets requirements         | Access control policy controls                           |
| No access keys unused for 90+ days             | Account lifecycle controls                               |
| KMS key rotation enabled                       | Cryptography controls (ISO 27001 A.8.24)                 |
| GuardDuty enabled                              | Threat detection controls                                |
| Security groups — no 0.0.0.0/0 on port 22/3389 | Network security controls                                |

***

## Interpreting Failed Checks

Go to **Integrations → AWS → Evidence** to see all checks with pass/fail status.

Failed checks appear as gaps on the relevant control. Click any failed check to see:

* Which specific resource is failing (e.g., bucket name, security group ID)
* What the expected configuration is
* A direct link to the AWS Console to fix it

<Tip>
  Sort by **Severity: High** to prioritize the checks that will most impact your compliance score. Root account MFA and CloudTrail are always the highest severity.
</Tip>

***

## Common Issues

### "Connection verification failed — invalid role ARN"

Check that:

1. The external ID in Matproof matches what you configured in the IAM role trust policy
2. The role ARN is copied exactly (including the account ID)
3. The Matproof AWS account ID is correctly listed as a trusted principal in the role

### "CloudTrail shows as failing but we have it enabled"

Matproof checks that CloudTrail is enabled in **all regions** with a multi-region trail, and that log file validation is enabled. A trail that only covers your primary region will fail this check.

### "Some checks show N/A"

Checks for services you don't use (e.g., GuardDuty in a region you don't operate in) show as N/A. These do not affect your compliance score — they are skipped in the gap calculation.

***

## Supported Regions

Matproof scans all standard AWS regions. GovCloud and China regions are not currently supported. Contact support if you require coverage for these.

***

## Disconnecting

Go to **Settings → Integrations → AWS → Disconnect**. Then delete the IAM role from your AWS account to fully revoke access.


# Microsoft Entra ID (Azure AD) Integration
Source: https://docs.matproof.com/integrations/azure-ad

Connect Microsoft Entra ID to collect identity, MFA, and conditional access evidence.

## Overview

The Microsoft Entra ID integration (formerly Azure Active Directory) connects to your Microsoft 365 tenant to collect identity and access management evidence for compliance controls.

**Evidence collected automatically:**

* User list with roles, licenses, and last sign-in
* MFA registration and enforcement status per user
* Conditional Access policy configuration
* Privileged role assignments (Global Admins, Security Admins)
* Guest user accounts and their access
* Risky sign-ins detected by Entra ID Protection
* Self-service password reset (SSPR) configuration
* Sign-in and audit logs summary

***

## Prerequisites

* Microsoft Entra ID (Azure AD) tenant — included with Microsoft 365 Business or Enterprise plans
* Matproof Admin or Owner role
* Microsoft 365 Global Administrator account to authorize the connection

<Note>
  After initial authorization, Global Admin rights are not needed for ongoing evidence collection. Matproof uses the Microsoft Graph API with application permissions scoped to read-only directory and audit data.
</Note>

***

## Connecting Microsoft Entra ID

1. Go to **Settings → Integrations**
2. Click **Connect** next to Microsoft Entra ID / Azure AD
3. Sign in with a Global Administrator Microsoft 365 account
4. Review and grant the requested application permissions (admin consent required)
5. Return to Matproof — the integration status will show **Connected**

The first sync runs immediately. Subsequent syncs run every 24 hours.

***

## Permissions Requested

Matproof registers an application in your Entra ID tenant with the following Microsoft Graph permissions (all read-only, application-level):

| Permission                   | What It's Used For                             |
| ---------------------------- | ---------------------------------------------- |
| `User.Read.All`              | User list, MFA status, last sign-in            |
| `Directory.Read.All`         | Group memberships, role assignments            |
| `AuditLog.Read.All`          | Sign-in logs and audit events                  |
| `Policy.Read.All`            | Conditional Access policy configuration        |
| `IdentityRiskyUser.Read.All` | Risky user detections from Entra ID Protection |

***

## What Gets Mapped to Which Controls

| Evidence Collected                       | Control Examples                                         |
| ---------------------------------------- | -------------------------------------------------------- |
| MFA registration rate                    | MFA controls (SOC 2 CC6.1, DORA Art. 9, NIS2 Measure 10) |
| Conditional Access — MFA required        | Conditional access controls                              |
| Global Admin count (should be ≤ 5)       | Privileged access management                             |
| Guest user access review                 | Third-party and external access controls                 |
| Risky sign-ins detected and responded to | Threat detection and incident controls                   |
| SSPR enabled                             | Account self-service controls                            |

***

## Conditional Access

Matproof evaluates your Conditional Access policies and reports whether they cover the key scenarios compliance frameworks care about:

| Scenario                    | What Matproof Checks                                             |
| --------------------------- | ---------------------------------------------------------------- |
| MFA for all users           | CA policy requiring MFA applies to "All users"                   |
| MFA for admins              | Privileged role members required to use MFA                      |
| Block legacy authentication | CA policy blocking legacy auth protocols (IMAP, POP, basic auth) |
| Compliant device required   | CA policy requires device compliance for sensitive apps          |

Policies that are in **Report-only** mode are shown but do not count as implemented controls — they must be in **Enabled** state.

<Tip>
  Legacy authentication blocking is a quick win that addresses a very common attack vector. If your tenant still allows it, Matproof will flag this and you can fix it in one Conditional Access policy.
</Tip>

***

## Privileged Role Monitoring

Matproof tracks all users assigned to privileged Entra ID roles:

* Global Administrator
* Security Administrator
* Exchange Administrator
* SharePoint Administrator
* User Administrator
* Privileged Role Administrator

For each role, it reports how many members are assigned, when their assignment was last reviewed, and whether they have MFA enrolled. Compliance frameworks typically require ≤5 Global Admins and Just-in-Time (JIT) assignment via PIM where possible.

***

## Common Issues

### "Admin consent failed"

The person authorizing must be a Global Administrator — not a user with delegated admin permissions. Application permissions require Global Admin consent.

### "MFA stats don't match what I see in the Entra portal"

Matproof reports **MFA registration** (user has registered a method) separately from **MFA enforcement** (Conditional Access requires MFA at sign-in). A user can be registered but not enforced — both metrics are shown.

### "Risky users showing as detected but we've already remediated them"

Dismissed risks in Entra ID Protection are reflected in the next sync (within 24 hours). If they still appear, check that the dismissal was confirmed in the Entra portal under **Protection → Risky users**.

***

## Disconnecting

Go to **Settings → Integrations → Microsoft Entra ID → Disconnect**. Also remove the Matproof enterprise application from your Entra ID tenant under **Enterprise applications** to fully revoke access.


# Deel Integration
Source: https://docs.matproof.com/integrations/deel

Connect Deel to sync your employee and contractor directory into Matproof — driving access reviews, training assignments, and offboarding automation.

## Overview

The Deel integration mirrors your global workforce — full-time employees, contractors, EOR-employed staff — into Matproof's [People](/features/people) module. Hires, role changes, and terminations flow through automatically, so your access-review and offboarding evidence stays current without manual sync work.

**What gets synced:**

* Employee and contractor records (name, work email, role, country of work, employment type)
* Department / team assignments
* Manager hierarchy
* Hire date, termination date
* Active / pending / terminated status
* Contract type (full-time, contractor, EOR) — drives the [Roles & Permissions](/features/rbac-roles) Employee vs Contractor distinction Matproof tracks

The integration is **read-only** — Matproof does not create, modify, or terminate Deel records.

***

## Why connect Deel

Without an HR system sync, your People list in Matproof drifts out of sync with reality the day someone joins or leaves. That breaks access-review evidence (auditors flag stale lists), it breaks offboarding (former employees still appear active), and it breaks training assignments (new hires never get auto-assigned).

With Deel connected:

* **New hires** appear in Matproof within 24 hours, ready for training assignment and onboarding-checklist auto-creation
* **Terminations** automatically trigger the offboarding workflow in Matproof, pre-populating the standard checklist
* **Contractor vs employee** distinction stays accurate for audit reporting (some frameworks require contractor counts to be disclosed separately)

***

## Prerequisites

* Deel admin or org-owner account (required to issue an API key)
* Matproof Admin or Owner role
* A Deel plan that includes API access — most paid Deel plans include this; verify in your Deel account settings

***

## Connecting Deel

<Steps>
  <Step title="Generate a Deel API key">
    In Deel: **Settings → API Keys → New API key**. Name it `matproof-readonly`. Deel issues a single token — copy it; you'll only see it once.
  </Step>

  <Step title="Add the credential in Matproof">
    Go to **Settings → Integrations**, find **Deel**, click **Connect**, paste the API key. Matproof immediately tests the connection and runs the first sync.
  </Step>

  <Step title="Map roles">
    In **Settings → Integrations → Deel → Configure**, choose how Deel employment types map to Matproof's [built-in roles](/features/rbac-roles):

    | Deel type                | Recommended Matproof role |
    | ------------------------ | ------------------------- |
    | Full-time employee       | Employee                  |
    | Contractor               | Contractor                |
    | EOR (Employer of Record) | Employee                  |
    | Independent contractor   | Contractor                |

    You can override any individual person's role in Matproof's People module — the Deel sync respects manual overrides on subsequent syncs.
  </Step>

  <Step title="Confirm the first sync">
    The first sync typically completes within 1–5 minutes for organizations under 500 people. Open **People** to see the imported list. Subsequent syncs run every 24 hours by default.
  </Step>
</Steps>

<Note>
  Matproof requests **read-only** access to your Deel directory. It cannot hire, fire, change pay, or modify any Deel record.
</Note>

***

## What gets mapped to which controls

| Evidence Collected                                   | Control Examples                                              |
| ---------------------------------------------------- | ------------------------------------------------------------- |
| Up-to-date workforce inventory                       | Asset / personnel inventory (ISO 27001 A.6.1, A.6.5)          |
| Termination dates → offboarding checklist completion | Access removal on termination (ISO 27001 A.5.11, SOC 2 CC6.4) |
| Contractor vs employee counts                        | Workforce-mix disclosure (some DORA / NIS 2 reporting fields) |
| Manager hierarchy for access-review approvals        | Access review controls (ISO 27001 A.5.18, SOC 2 CC6.2)        |
| Department assignments                               | Segregation of duties (ISO 27001 A.5.3)                       |
| Hire date                                            | Background-check timing evidence                              |

***

## Offboarding automation

When a Deel record's status changes to **Terminated** (or a future-dated termination passes), Matproof automatically:

1. Marks the matching Person as **Offboarding** in Matproof
2. Creates the standard offboarding checklist (revoke system access, collect devices, archive Matproof account, notify IT, etc.)
3. Notifies the employee's manager (or a configured offboarding owner) to work the checklist
4. On checklist completion, marks the Person as **Offboarded** — the timestamped record becomes evidence for ISO 27001 A.5.11 and SOC 2 CC6.4

The Deel-driven offboarding flow does **not** automatically revoke access in third-party systems — that requires connections to AWS / Google Workspace / Entra ID / Okta. Matproof produces the checklist and tracks completion; the actual revocation is performed via those integrations or manually.

***

## Common issues

### "API key invalid"

Deel API keys are tied to the user who created them. If the user who issued the key is offboarded from Deel, the key is revoked. Have a current admin issue a new key and update Matproof.

### "Some employees aren't appearing"

Matproof imports records that are **Active** or in **Onboarding** status by default. To include other statuses, go to **Settings → Integrations → Deel → Configure → Employee status filter** and adjust.

### "Email addresses don't match between Deel and Matproof"

Matproof matches Deel records to existing Matproof users by **work email**. If a person's Deel email is `firstname.lastname@company.com` but their Matproof account is `flastname@company.com`, the sync creates a duplicate. Two fixes:

* Update the Deel record to the canonical work email
* Or: manually merge the records in **People → \[duplicate] → Merge with…**

***

## Disconnecting

Go to **Settings → Integrations → Deel → Disconnect**. The encrypted API key is purged from Matproof's secrets store.

In Deel: also revoke the API key from **Settings → API Keys → matproof-readonly → Revoke** to fully cut access on the Deel side.

After disconnection, previously imported People records remain in Matproof (so audit history is preserved). Future hires and terminations will not sync until you reconnect.

<CardGroup>
  <Card title="People" href="/features/people">
    Where Deel-synced records land
  </Card>

  <Card title="Roles & Permissions" href="/features/rbac-roles">
    How Employee vs Contractor distinctions work
  </Card>
</CardGroup>


# Google Cloud Platform Integration
Source: https://docs.matproof.com/integrations/gcp

Connect GCP to collect IAM, Security Command Center, encryption, and audit-log evidence automatically.

## Overview

The Google Cloud Platform (GCP) integration reads security and configuration data from your GCP organization or project to provide evidence for cloud-infrastructure controls. It uses a read-only **service account** with viewer-level roles — Matproof never modifies your GCP environment.

**Evidence collected automatically:**

* IAM policies, role bindings, and group inheritance
* Service accounts and their key rotation status
* Cloud Storage bucket encryption (CMEK / Google-managed) and public-access settings
* VPC firewall rules with overly permissive ingress (e.g., `0.0.0.0/0` on sensitive ports)
* Cloud KMS key rotation cadence
* Cloud Audit Logs configuration (Admin Activity, Data Access, System Event)
* Security Command Center (SCC) findings
* Cloud SQL encryption and backup configuration
* GKE cluster shielded-nodes, binary authorization, and network-policy status

***

## Prerequisites

* GCP project or organization where Matproof should read configuration data
* Permission to create a service account with `Viewer` and `Security Reviewer` roles
* Matproof Admin or Owner role
* (Recommended) Security Command Center Standard or Premium tier — Matproof reads SCC findings if available

***

## Connecting GCP

GCP supports connection at either the **project** level (single project) or the **organization** level (Matproof scans every project in your org). For multi-project setups, organization-level is recommended — it scales without re-onboarding each project.

### Step-by-step

<Steps>
  <Step title="Create the service account">
    In GCP Console, go to **IAM & Admin → Service Accounts → Create Service Account**:

    * Name: `matproof-readonly`
    * Description: `Read-only access for Matproof compliance evidence`
  </Step>

  <Step title="Grant the required roles">
    On the service account, grant:

    * `roles/iam.securityReviewer` — for IAM policy reads
    * `roles/viewer` — for resource configuration reads
    * `roles/securitycenter.findingsViewer` — for SCC findings (if SCC is enabled)
    * `roles/logging.viewer` — for audit log metadata

    For **organization-level** connections, grant the roles at the organization node (not just one project).
  </Step>

  <Step title="Create a service-account key">
    On the service account → **Keys → Add key → Create new key → JSON**. Download the JSON file. Treat it as a credential — store it only briefly until step 4.
  </Step>

  <Step title="Upload the key to Matproof">
    In Matproof: **Settings → Integrations → Google Cloud → Connect → Upload service-account key**. Paste or upload the JSON. Matproof immediately tests the connection and runs the first scan.
  </Step>

  <Step title="(Optional) Delete the local key">
    Once Matproof shows **Connected**, delete the JSON file from your local machine. Matproof has stored the credential encrypted in our secrets store; you don't need a copy.
  </Step>
</Steps>

<Note>
  Matproof only ever uses the service account for read calls. Roles granted are intentionally minimum for visibility — no `Editor`, no `Owner`, no project-creation rights.
</Note>

***

## What gets mapped to which controls

| Evidence Collected                                     | Control Examples                                        |
| ------------------------------------------------------ | ------------------------------------------------------- |
| Service-account key rotation within 90 days            | Cryptography / credential lifecycle (ISO 27001 A.8.24)  |
| No GCS buckets with public read/write                  | Data protection (ISO 27001 A.5.10, GDPR Art. 32)        |
| Cloud Audit Logs enabled (Admin + Data Access)         | Logging and monitoring (DORA Art. 10, ISO 27001 A.8.15) |
| Firewall — no `0.0.0.0/0` on port 22, 3389, 3306       | Network security                                        |
| KMS key rotation enabled and ≤ 90 days                 | Cryptography controls                                   |
| GKE shielded nodes enabled                             | Workload integrity                                      |
| GKE binary authorization enforced                      | Software supply chain                                   |
| SCC findings — High and Critical resolved within SLA   | Vulnerability management                                |
| IAM bindings — no broad `roles/owner` to user accounts | Privileged access management                            |

***

## Multi-project setups

When connected at the organization level, Matproof discovers all projects under the org and scans each. The discovered project list appears in **Integrations → Google Cloud → Projects**, where you can:

* See per-project compliance status
* Exclude specific projects from scanning (e.g., sandbox or experimental projects)
* Tag projects with environment (`prod`, `staging`, `dev`) so audit-relevant evidence focuses on production

For project-level connections, only the connected project is scanned. To add more projects, repeat the connection flow per project — or upgrade to organization-level access.

***

## Common issues

### "Permission denied on Security Command Center"

SCC findings are only visible to service accounts with `roles/securitycenter.findingsViewer` granted at either the organization or the SCC source level. If SCC is enabled but findings come back empty, verify the role is granted at the **organization** node, not just on a project. SCC is an org-scoped service.

### "Audit logs are enabled but Matproof reports them as missing"

Matproof checks for **Data Access audit logs** specifically — these are off by default in GCP. Admin Activity logs are on by default and don't satisfy the data-access logging requirement under DORA Art. 10. Enable them under **IAM & Admin → Audit Logs**.

### "Service-account key shows as nearing expiry"

GCP service-account keys don't have a hard expiry, but Matproof flags keys older than 90 days as a finding (per CIS GCP Foundations Benchmark 1.6). Rotate by creating a new key, uploading to Matproof, and deleting the old one — typically a 5-minute task.

### "I can't see my GKE clusters"

GKE inventory needs `roles/container.viewer` in addition to the base viewer role. Add it on the service account and run a manual sync.

***

## Disconnecting

In Matproof: **Settings → Integrations → Google Cloud → Disconnect**. The encrypted key is purged from our secrets store.

In GCP: also **delete the service account** (not just disable) so the key is fully revoked. Go to **IAM & Admin → Service Accounts → matproof-readonly → Delete**.

<CardGroup>
  <Card title="AWS" href="/integrations/aws">
    The AWS-side equivalent
  </Card>

  <Card title="Azure" href="/integrations/azure-ad">
    Microsoft Azure (cloud + Entra ID)
  </Card>
</CardGroup>


# GitHub Integration
Source: https://docs.matproof.com/integrations/github

Connect GitHub to automatically collect code security and access control evidence.

## Overview

The GitHub integration connects Matproof to your GitHub organization and automatically collects evidence for controls related to code security, access management, and change management. Once connected, evidence is collected continuously — no manual uploads needed.

**Evidence collected automatically:**

* Branch protection rules (require PR reviews, status checks, signed commits)
* Repository access lists and permission levels
* Dependabot alert status and vulnerability remediation
* Code review records (PRs merged without review flagged)
* GitHub Actions workflow security settings
* Organization-level MFA enforcement status
* Outside collaborators and their access levels

***

## Prerequisites

* GitHub organization account (GitHub Free, Team, or Enterprise)
* Matproof Admin or Owner role
* GitHub organization owner permissions (required to authorize the OAuth app)

***

## Connecting GitHub

1. Go to **Settings → Integrations**
2. Click **Connect** next to GitHub
3. You will be redirected to GitHub to authorize the Matproof OAuth app
4. Select your GitHub organization
5. Grant the requested permissions (read-only access to organization data)
6. You will be redirected back to Matproof — the integration status will show **Connected**

The first evidence sync runs immediately after connection. Subsequent syncs run every 24 hours.

<Note>
  Matproof requests **read-only** access to your GitHub organization. It cannot create, modify, or delete any repositories, code, or settings.
</Note>

***

## What Gets Mapped to Which Controls

| Evidence Collected                         | Control Examples                                         |
| ------------------------------------------ | -------------------------------------------------------- |
| Branch protection rules enabled            | Change management controls (SOC 2 CC8, ISO 27001 A.8.32) |
| PR review required before merge            | Code review controls                                     |
| MFA enforced for all members               | Access control / MFA controls (SOC 2 CC6, DORA Art. 9)   |
| Dependabot alerts resolved within SLA      | Vulnerability management controls                        |
| No outside collaborators with write access | Third-party access controls                              |
| Signed commits required                    | Code integrity controls                                  |

***

## Interpreting the Evidence

After the first sync, go to **Integrations → GitHub → Evidence** to see what was collected. Each item shows:

* **Status** — Pass / Fail / Warning
* **Control** — which control this evidence maps to
* **Last checked** — when the check last ran
* **Detail** — the raw finding (e.g., "Branch protection not enabled on `main` in repo `backend`")

Failing items are surfaced as control gaps and appear on your compliance dashboard.

***

## Common Issues

### "Some repositories are not being scanned"

By default, Matproof scans all repositories in your organization. If you have private repositories that are not appearing, check that the GitHub OAuth app was authorized with access to all repositories (not just selected ones).

To update: go to GitHub → Settings → Applications → Matproof → Repository access → change to "All repositories".

### "Branch protection check is failing but we have protection enabled"

Matproof checks for specific branch protection settings. A protection rule that only blocks force pushes will still fail the "require PR review" check. Review which specific settings are required under **Integrations → GitHub → Evidence → \[failing check] → Required settings**.

### "MFA enforcement shows as failing for some members"

GitHub reports MFA status at the organization level. Members who joined before you enabled MFA enforcement but haven't yet enabled it will show as non-compliant. The integration surfaces this so you can follow up — it is intentional behavior, not a bug.

***

## Disconnecting

Go to **Settings → Integrations → GitHub → Disconnect**. This removes the connection and stops evidence collection. Previously collected evidence is retained.

Also revoke the Matproof OAuth app from your GitHub organization settings under **Settings → Third-party Access**.


# Google Workspace Integration
Source: https://docs.matproof.com/integrations/google-workspace

Connect Google Workspace to collect user access, MFA, and admin activity evidence.

## Overview

The Google Workspace integration pulls user and security data from your Google Workspace account to provide continuous evidence for identity, access control, and admin activity controls.

**Evidence collected automatically:**

* User list with roles and last login dates
* MFA (2-Step Verification) enrollment status per user
* Admin role assignments and changes
* Inactive users (no login in 90+ days)
* Super admin activity log
* Password policies (strength requirements, expiry)
* External sharing settings for Google Drive
* OAuth apps authorized by users

***

## Prerequisites

* Google Workspace Business Starter or higher (Admin Console access required)
* Matproof Admin or Owner role
* Google Workspace Super Administrator account to authorize the connection

***

## Connecting Google Workspace

1. Go to **Settings → Integrations**
2. Click **Connect** next to Google Workspace
3. Sign in with a Google Workspace Super Administrator account
4. Review and grant the requested read-only permissions
5. Select your domain and confirm

The initial sync runs immediately. Subsequent syncs run every 24 hours.

<Warning>
  A Super Administrator account is required to authorize the integration — not a delegated admin. This is a Google restriction on directory API access. Once authorized, Matproof does not retain your admin credentials.
</Warning>

***

## Permissions Requested

Matproof requests the following Google API scopes (all read-only):

| Scope                                     | What It's Used For                 |
| ----------------------------------------- | ---------------------------------- |
| `admin.directory.user.readonly`           | List users, MFA status, last login |
| `admin.directory.rolemanagement.readonly` | Admin role assignments             |
| `admin.reports.audit.readonly`            | Admin activity logs                |
| `admin.reports.usage.readonly`            | User activity and last login data  |

***

## What Gets Mapped to Which Controls

| Evidence Collected       | Control Examples                                         |
| ------------------------ | -------------------------------------------------------- |
| MFA enrollment rate      | MFA controls (SOC 2 CC6.1, DORA Art. 9, NIS2 Measure 10) |
| Inactive user accounts   | Access review / account lifecycle controls               |
| Admin role assignments   | Privileged access management controls                    |
| External sharing policy  | Data protection controls (ISO 27001 A.5.14)              |
| OAuth app authorizations | Third-party app access controls                          |

***

## Interpreting MFA Status

Matproof reports two MFA metrics:

* **Enforcement** — whether your Google Workspace policy requires 2-Step Verification for all users
* **Enrollment** — per-user status showing who has it enabled vs. who hasn't

For most compliance frameworks, **enforcement** at the policy level is the primary evidence requirement. Per-user enrollment gaps should be remediated — Matproof lists non-enrolled users so you can follow up directly.

<Tip>
  Go to **Integrations → Google Workspace → Users** and filter by "MFA: Not enrolled" to get a list of users to chase. Export as CSV to send to your IT team.
</Tip>

***

## Inactive Users

Matproof flags users who have not logged in for 90+ days as an access control risk. These accounts should be reviewed and either:

* Suspended (for employees on leave or contractors no longer active)
* Deleted (for fully departed users)
* Documented as service accounts with a justification

This evidence is mapped to your offboarding and access review controls.

***

## Common Issues

### "Authorization failed — insufficient permissions"

The Google account used to authorize must be a Super Administrator. Delegated admins with custom roles cannot grant the directory API access Matproof needs. Use a Super Admin account and try again.

### "User count doesn't match our actual headcount"

By default, Matproof includes suspended users in the count. Filter by **Status: Active** to see only active users.

### "MFA enforcement shows as not configured"

Go to Google Admin Console → Security → 2-Step Verification and ensure "Allow users to turn on 2-Step Verification" is set to **Enforce**. Simply allowing it (not enforcing) will show as a gap.

***

## Disconnecting

Go to **Settings → Integrations → Google Workspace → Disconnect**. Also revoke app access from your Google Admin Console under **Security → API Controls → App Access Control**.


# Jira Integration
Source: https://docs.matproof.com/integrations/jira

Connect Jira to use it as evidence for change management and incident tracking controls.

## Overview

The Jira integration links your Jira projects to Matproof so that Jira issues and change tickets can serve as evidence for change management, incident management, and corrective action controls.

**What it enables:**

* Map Jira projects to Matproof controls as evidence sources
* Sync Jira issues as incident records or corrective actions
* Use Jira tickets as change management evidence (change requests, approvals, CAB decisions)
* Link specific Jira issues to controls directly from Matproof

***

## Prerequisites

* Jira Cloud account (Atlassian Cloud — Jira Server/Data Center is not currently supported)
* Matproof Admin or Owner role
* Jira project admin or organization admin permissions

***

## Connecting Jira

1. Go to **Settings → Integrations**
2. Click **Connect** next to Jira
3. Enter your Atlassian site URL (e.g., `yourcompany.atlassian.net`)
4. Click **Authorize** — you will be redirected to Atlassian to grant access
5. Select which Jira projects Matproof should have access to
6. Return to Matproof and confirm the connection

<Note>
  Matproof requests read-only access to your Jira issues and project configurations. It cannot create, edit, or delete Jira issues.
</Note>

***

## Configuring Project Mappings

After connecting, configure which Jira projects map to which Matproof functions:

1. Go to **Settings → Integrations → Jira → Configure**
2. For each Jira project, select its purpose in Matproof:
   * **Change Management** — issues used as change request evidence
   * **Incident Tracking** — issues synced to the Incidents module
   * **Corrective Actions** — issues linked to Matproof corrective actions

### Change Management Mapping

Map a Jira project used for change requests to the Change Management function. Matproof will check:

* Change requests have an approval record before implementation
* Emergency changes are documented post-facto
* Change request count and approval rate over the audit period

This provides automated evidence for SOC 2 CC8 (Change Management) and ISO 27001 A.8.32.

### Incident Tracking Mapping

If you track incidents in Jira, Matproof can pull these as incident records:

* Jira issues of a specific type (e.g., "Incident", "Security Incident") sync to the Incidents module
* Severity, status, and resolution data are mapped automatically
* Jira issues appear alongside natively created Matproof incidents

### Corrective Actions Mapping

Link a Jira project to corrective actions so that Jira tickets serve as the remediation tracking mechanism. When an issue in the linked project is closed, the corresponding Matproof corrective action can be updated automatically.

***

## Linking Individual Issues to Controls

Beyond project-level mapping, you can link specific Jira issues to individual controls as point-in-time evidence:

1. Open a control in **Controls**
2. Click **Add Evidence → Link from Jira**
3. Search for the Jira issue by key or title
4. Confirm — the issue title, status, and URL are stored as evidence

This is useful for controls that reference specific decisions or one-time events (e.g., a change approval for a specific system migration).

***

## What Gets Mapped to Which Controls

| Evidence Collected                     | Control Examples                                         |
| -------------------------------------- | -------------------------------------------------------- |
| Change requests with approval records  | Change management controls (SOC 2 CC8, ISO 27001 A.8.32) |
| Incident records with resolution times | Incident response controls                               |
| Security incidents logged and resolved | DORA Art. 17-23, NIS2 incident handling                  |
| Corrective actions tracked to closure  | ISO 27001 Clause 10.1                                    |

***

## Common Issues

### "My Jira Server instance isn't connecting"

Jira Server (self-hosted) and Jira Data Center are not currently supported — only Jira Cloud (atlassian.net). If you need Jira Server support, contact [support@matproof.com](mailto:support@matproof.com).

### "Incidents from Jira are appearing as duplicates"

If you are both logging incidents natively in Matproof and importing from Jira, check the deduplication setting under **Settings → Integrations → Jira → Configure → Incident deduplication**. Set the matching field (e.g., Jira issue key) to prevent duplicates.

### "Change request issues aren't showing approval status"

Matproof looks for Jira workflow transitions named "Approved" or "CAB Approved". If your workflow uses different transition names, map them in **Settings → Integrations → Jira → Configure → Workflow mapping**.

***

## Disconnecting

Go to **Settings → Integrations → Jira → Disconnect**. Also revoke the Matproof OAuth app from your Atlassian account under **Atlassian Account → Security → Connected apps**.


# Integrations Overview
Source: https://docs.matproof.com/integrations/overview

Connect your existing tools to automate evidence collection and reduce manual compliance work.

# Integrations Overview

Matproof integrates with the tools your team already uses. Connecting an integration means evidence is collected automatically — no screenshots, no manual uploads, no spreadsheets. Each integration runs on a 24-hour sync cycle by default (configurable per integration), and the evidence collected is mapped directly to the relevant controls in your active frameworks.

## Available integrations

### Cloud infrastructure

<CardGroup>
  <Card title="AWS" icon="aws" href="/integrations/aws">
    IAM, CloudTrail, S3 encryption, security groups, KMS rotation, GuardDuty status — read-only via cross-account IAM role.
  </Card>

  <Card title="Microsoft Azure" icon="microsoft" href="/integrations/azure-ad">
    Subscription resources, Defender for Cloud findings, encryption settings, audit logs. Includes the Microsoft Entra ID identity surface.
  </Card>

  <Card title="Google Cloud Platform" icon="google" href="/integrations/gcp">
    IAM policies, Security Command Center findings, encryption keys, audit logs.
  </Card>
</CardGroup>

### Identity & workspace

<CardGroup>
  <Card title="Microsoft Entra ID (Azure AD)" icon="microsoft" href="/integrations/azure-ad">
    Identity, MFA, Conditional Access policies, privileged role assignments, risky sign-ins.
  </Card>

  <Card title="Google Workspace" icon="google" href="/integrations/google-workspace">
    User access, MFA enrollment, admin roles, inactive accounts, external sharing policy.
  </Card>
</CardGroup>

### Source control & change management

<CardGroup>
  <Card title="GitHub" icon="github" href="/integrations/github">
    Branch protection, PR review enforcement, MFA, Dependabot alerts, repository access lists.
  </Card>

  <Card title="Jira" icon="jira" href="/integrations/jira">
    Change requests, incident records, corrective-action tracking. Per-project mapping.
  </Card>
</CardGroup>

### AI providers (for EU AI Act evidence)

<CardGroup>
  <Card title="AI Providers" icon="brain" href="/integrations/ai-providers">
    Anthropic, OpenAI, Hugging Face, Weights & Biases — credential storage for automated AI Act compliance checks against your AI training and inference infrastructure.
  </Card>
</CardGroup>

### HR & people

<CardGroup>
  <Card title="Deel" icon="users" href="/integrations/deel">
    Employee directory, contractor records, onboarding/offboarding events. Coming soon — see [/integrations/deel](/integrations/deel).
  </Card>
</CardGroup>

### Security tooling

<CardGroup>
  <Card title="Aikido Security" icon="shield" href="/integrations/aikido">
    Vulnerability findings ingested into the unified [Findings](/features/findings) view.
  </Card>
</CardGroup>

### Custom / programmatic

<CardGroup>
  <Card title="REST API" icon="code" href="/integrations/api">
    Push evidence, sync data, trigger assessments programmatically. For tools without a native integration.
  </Card>
</CardGroup>

## How integrations work

<Steps>
  <Step title="Connect">
    Authorize Matproof with read-only access to your tool — typically via OAuth, sometimes via API key or cross-account IAM role (AWS).
  </Step>

  <Step title="Sync">
    Matproof pulls configuration and activity data on a 24-hour schedule (configurable per integration). The first sync runs immediately on connection.
  </Step>

  <Step title="Map">
    Collected data is automatically matched to the relevant controls in your active frameworks via the [Frameworks](/features/compliance-frameworks) cross-mapping layer.
  </Step>

  <Step title="Surface">
    Passing checks contribute evidence to controls; failing checks raise items in the unified [Findings](/features/findings) view.
  </Step>
</Steps>

You can also trigger a manual sync at any time from **Settings → Integrations → \[Integration] → Sync now**.

## Permissions philosophy

Every integration uses **read-only** access to the third-party system. Matproof can't modify your AWS resources, edit your GitHub branch protection, change Entra ID policies, or close Jira tickets. The only writes Matproof performs are into its own database.

OAuth scopes and IAM permissions are documented per-integration on the individual integration pages.

## What integrations replace

Without integrations, demonstrating access-control compliance means manually exporting user lists, screenshotting MFA settings, and uploading them every quarter. With integrations, this happens automatically.

| Manual task replaced                    | Integration                                                                      |
| --------------------------------------- | -------------------------------------------------------------------------------- |
| Export user list and MFA status         | Google Workspace / Microsoft Entra ID                                            |
| Screenshot branch protection settings   | GitHub                                                                           |
| Export IAM policy and CloudTrail status | AWS                                                                              |
| Document change approval records        | Jira                                                                             |
| Capture Dependabot vulnerability status | GitHub                                                                           |
| List GCP IAM bindings and SCC findings  | Google Cloud                                                                     |
| Demonstrate AI training-data lineage    | Weights & Biases / Hugging Face (via [AI Providers](/integrations/ai-providers)) |

## Custom integrations

For tools not on the list above, use the [Matproof REST API](/integrations/api) to push evidence programmatically from any system — CI/CD pipelines, custom scripts, internal dashboards, or third-party tools.

Common API use cases:

* Upload penetration-test reports directly from your security scanner
* Push deployment records from your CI/CD pipeline as change-management evidence
* Sync vendor data from your procurement system
* Mirror compliance state from a parent-org system into a subsidiary's Matproof tenant

## Requesting an integration

Don't see your tool? Email [support@matproof.com](mailto:support@matproof.com) with the tool name and your use case. We prioritize integration development based on customer demand. Common requests on the roadmap: Slack, Okta, GitLab, Notion, Microsoft Intune, Jamf.


# Introduction
Source: https://docs.matproof.com/introduction

Matproof is the compliance automation platform built for EU financial services and supply chain teams.

## What is Matproof?

Matproof automates compliance programs for EU-regulated companies — covering frameworks like **DORA**, **ISO 27001**, **SOC 2**, **NIS2**, **GDPR**, and **CSRD**.

Instead of managing compliance in spreadsheets and shared drives, Matproof gives you:

* **AI-generated policies** that map directly to your frameworks
* **Automated evidence collection** from your existing tools
* **Continuous monitoring** with real-time control status
* **Vendor risk management** with built-in Art. 28 register
* **CSRD supply chain module** for ESG data collection and ESRS reporting

## Who is Matproof for?

<CardGroup>
  <Card title="Financial Services" icon="building-columns">
    Banks, fintechs, payment institutions, and investment firms subject to DORA, BaFin, and NIS2.
  </Card>

  <Card title="Compliance Teams" icon="shield-check">
    CISOs, DPOs, and compliance officers who need to be audit-ready without manual overhead.
  </Card>

  <Card title="Large Corporates" icon="sitemap">
    Companies subject to CSRD who need to collect ESG data from their supplier base.
  </Card>

  <Card title="SME Suppliers" icon="store">
    Suppliers receiving CSRD questionnaires from corporate customers who need to respond efficiently.
  </Card>
</CardGroup>

## Key capabilities

| Capability           | Description                                                    |
| -------------------- | -------------------------------------------------------------- |
| Framework automation | DORA, ISO 27001, SOC 2, NIS2, GDPR, CSRD/ESRS                  |
| Policy management    | AI-generated, bilingual (DE/EN), version-controlled            |
| Evidence collection  | Automated from connected tools + manual upload                 |
| Risk management      | Asset-linked risks, treatment plans, scoring                   |
| Vendor risk          | Art. 28 register, supplier questionnaires, sanctions screening |
| CSRD module          | Double materiality, Scope 3, ESG questionnaires, ESRS mapping  |
| Data residency       | 100% EU — hosted in German data centers (Hetzner)              |

## Getting started

<CardGroup>
  <Card title="Quickstart" icon="rocket" href="/quickstart">
    Get your first framework set up in minutes.
  </Card>

  <Card title="Core Concepts" icon="book" href="/concepts">
    Understand how Matproof structures compliance programs.
  </Card>
</CardGroup>


# Onboarding
Source: https://docs.matproof.com/onboarding

What happens after you sign up — the setup wizard, your first week, and how to get to a moving compliance score.

# Onboarding

This guide covers what happens after you sign up at [app.matproof.com](https://app.matproof.com): the setup wizard you go through, what the dashboard looks like at the end of it, and the recommended first week of work to get your first compliance score moving.

## What happens at signup

When you sign up, your organization is created with **full Professional access** for a 14-day trial. You can use every feature; no credit card up front. A banner in the app counts the days remaining.

Four actions are gated until a card is on file or you upgrade: exporting compliance reports as PDF, running a penetration test scan, inviting team members, and connecting integrations. Everything else — frameworks, policies, controls, evidence, vendor management, AI policy editor, custom frameworks — works immediately.

After the trial:

* If a card is on file → you continue on Professional
* If no card → access is paused (no data lost; you can upgrade and resume any time)

See [Plans & Pricing](/features/plans) for what each tier includes.

## The setup wizard

Right after signup, the app routes you to `/setup` and walks you through a guided wizard. The wizard's job is to learn enough about your organization to (a) preselect the right controls per framework, (b) generate policies in the right tone and language, and (c) preconfigure your risk register with categories that make sense for your shape of business.

The wizard has roughly **18 steps**, but they fall into four logical groups. Plan for **20–30 minutes** end-to-end; you can save and resume at any point.

### Group 1: Organization basics

* **Organization name** — what appears on generated reports and notifications
* **Website** — used for AI-aided industry classification and to seed the trust portal
* **Description** — a few sentences about what your organization does (informs AI-generated policy tone)
* **Industry** — drives risk-category presets and framework recommendations
* **Team size** — informs control proportionality (small org = lighter formality)
* **Geographic scope** — countries you operate in or sell to (drives jurisdictional add-ons like NIS2 transposition)
* **Work location pattern** — remote / hybrid / on-site (changes which device and access controls are relevant)

### Group 2: Compliance scope

* **Frameworks** — pick one or more from the 16 built-in frameworks (DORA, NIS2, GDPR, ISO 27001, SOC 2, EU AI Act, etc.). You can also create [Custom Frameworks](/features/custom-frameworks) later for national transpositions or industry standards.
* **Infrastructure** — where you host (AWS, Azure, GCP, on-prem, hybrid). Drives cloud-evidence integration recommendations.
* **Software stack** — what tools you use (productivity suite, IdP, source control, ticketing). Drives integration recommendations.
* **Authentication** — how your team logs into systems (SSO yes/no, MFA enforcement). Pre-fills relevant access controls.
* **Devices** — what kinds of devices people use (corporate Macs, BYOD, mobile). Drives device-agent relevance and BYOD policy generation.
* **Data types** — what categories of data you process (personal data, payment cards, health data, AI training data, etc.). Drives GDPR/PCI/HIPAA/AI Act applicability.
* **Shipping** — whether you ship physical products. Affects supply-chain controls (CSRD, supply-chain due diligence).

### Group 3: People & accountability

* **C-suite roster** — who holds CISO / CTO / DPO / CCO / CEO accountabilities (used to prefill "responsible person" fields throughout the program)
* **Report signatory** — who signs off on audit-ready reports

### Group 4: Policy preferences

* **Policy language** — which language to generate baseline policies in (German, English, French, Spanish, Italian, Dutch). You can also opt in to "**also generate English**" so you have parallel EN versions for international audits.
* **Legal acknowledgment** — confirm you accept the Terms of Service and DPA

When the wizard finishes, Matproof seeds your organization with: control library mapped to your framework selection, AI-drafted policies in your chosen language, a preconfigured risk register, and a vendor register skeleton. You land on the **Frameworks dashboard** at `/[orgId]/frameworks`.

## Your first week — day by day

The wizard gets you to a populated workspace. The first week of actual work turns that into a moving compliance score.

<Steps>
  <Step title="Day 1 — Review what was generated">
    From the Frameworks dashboard, click into your primary framework. Skim the controls list and the AI-generated policy library. Reject anything that doesn't fit; edit anything that's close but not right. Don't try to perfect everything — just calibrate the AI's tone for your organization on 2–3 policies.

    **Where to be:** `/[orgId]/frameworks` → click your framework → review controls and policies tabs.
  </Step>

  <Step title="Day 1–2 — Invite your team and assign control owners">
    Compliance work fails without ownership. Go to **People** and invite each person who will own at least one control. Pick from the five built-in roles:

    * **Owner** — everything including billing
    * **Admin** — manages frameworks, evidence, vendors, team (no billing)
    * **Auditor** — read-only; perfect for external auditors
    * **Employee** — submits evidence and completes assigned tasks
    * **Contractor** — same as Employee, flagged separately for audit reporting

    See [Roles & Permissions](/features/rbac-roles) for the full breakdown and how to define custom roles.

    Then go back into your framework and assign each control to a specific owner. Controls without owners do not get evidence and do not move the score.

    **Where to be:** `/[orgId]/people` to invite, then `/[orgId]/frameworks/[id]/controls` to assign.
  </Step>

  <Step title="Day 2–3 — Connect your highest-impact integration">
    One well-chosen integration replaces dozens of manual evidence uploads. Start with the integration that covers the most controls in your framework selection:

    | If you primarily run on…                | Connect first                   |
    | --------------------------------------- | ------------------------------- |
    | Cloud (AWS / Azure / GCP)               | The relevant cloud connector    |
    | Google Workspace or Microsoft 365       | Your IdP integration            |
    | GitHub / GitLab for the engineering org | Your source-control integration |

    **Where to be:** `/[orgId]/integrations` → pick one → follow the OAuth flow.

    After connection, Matproof scans the connected system, populates evidence on the controls it covers, and surfaces any gaps as findings.
  </Step>

  <Step title="Day 3–4 — Publish your top policies">
    Go through the auto-generated policy library and publish the 5–10 highest-priority policies (information security, access control, incident response, BCP, vendor management). For each:

    1. Read it, edit anything wrong, save.
    2. Set a review date (typically annual).
    3. Assign a policy owner.
    4. Click **Publish** — published policies become available for team acknowledgement and for control evidence.

    **Where to be:** `/[orgId]/policies` → open each → edit → publish.
  </Step>

  <Step title="Day 4–5 — Run your first risk assessment">
    With frameworks selected and policies in place, walk through the risk register:

    1. Open `/[orgId]/risks` (or whatever the risks route is in your sidebar).
    2. Work through the preseeded risk categories — Matproof has scoped them to your industry and data types.
    3. For each risk, score likelihood and impact, set treatment (accept / mitigate / transfer / avoid), assign an owner.
    4. Link risks to the controls that mitigate them — this closes the loop between policies, controls, and risk.

    **Where to be:** Risks section in the sidebar.
  </Step>

  <Step title="Day 5+ — Start collecting manual evidence on the gaps">
    After steps 1–5 you'll have a real compliance score with visible gaps. Go to **Findings** to see them in one list, sort by severity, assign owners, and close them out one at a time. Many gaps are closed with a single document upload (existing security training, BCP test results, prior pen-test reports).

    **Where to be:** `/[orgId]/findings` → filter by status: open → close from highest severity down.
  </Step>
</Steps>

## After the first week

By the end of week one, a typical first-time customer has:

* Setup wizard complete, baseline policies generated
* 5–10 policies published with owners and review dates
* 1–2 integrations connected, automated evidence flowing for \~30–50% of controls
* Team invited and at least one control owner assigned per high-priority control
* Risk register reviewed, top 10 risks scored
* First batch of findings triaged

Compliance score on the framework dashboard typically moves from 0% → 40–60% in the first week, with the rest closed over the following 4–6 weeks of evidence collection.

## Recommended order of operations

If you remember nothing else from this guide:

```
1. Frameworks   → know what you're solving for
2. Policies     → establish baseline documentation
3. People       → assign ownership to controls
4. Integrations → automate the boring evidence
5. Risks        → identify what you're protecting against
6. Evidence     → close the remaining gaps manually
7. Findings     → ongoing — triage and remediate
```

Skipping ahead — for example, uploading evidence before assigning control owners — works but creates orphan evidence that nobody maintains. Follow the order above for the cleanest setup.

## What's next

<CardGroup>
  <Card title="Compliance Frameworks" icon="check-circle" href="/features/compliance-frameworks">
    Understand how controls map across frameworks
  </Card>

  <Card title="Policy Management" icon="file-text" href="/features/policy-management">
    Customize and publish your generated policy library
  </Card>

  <Card title="Custom Frameworks" icon="sliders" href="/features/custom-frameworks">
    Build your own frameworks for transpositions or industry standards
  </Card>

  <Card title="Findings" icon="circle-exclamation" href="/features/findings">
    Track and close gaps across every framework
  </Card>
</CardGroup>


# Quickstart
Source: https://docs.matproof.com/quickstart

Get Matproof set up and your first compliance framework running in under 30 minutes.

## 1. Create your account

Sign up at [app.matproof.com](https://app.matproof.com). You can start with a free trial — no credit card required.

After signing up, you'll be guided through the initial setup wizard.

## 2. Select your frameworks

Choose the compliance frameworks your organization needs to address:

* **DORA** — Digital Operational Resilience Act (EU financial services)
* **ISO 27001** — Information security management
* **SOC 2** — US/international trust service criteria
* **NIS2** — Network and Information Security Directive
* **GDPR** — General Data Protection Regulation
* **CSRD** — Corporate Sustainability Reporting Directive

<Tip>
  Start with the framework tied to your nearest audit deadline. You can add more frameworks at any time.
</Tip>

## 3. Generate your policies

Matproof uses AI to generate a complete policy set pre-mapped to your selected frameworks.

1. Navigate to **Policies** in the sidebar
2. Click **Generate policies**
3. Review and customize each policy
4. Publish when ready

Policies are bilingual (German and English) by default.

## 4. Connect your tools

Link your existing tech stack for automated evidence collection:

<CardGroup>
  <Card title="GitHub" icon="github">
    Code security, access controls
  </Card>

  <Card title="Google Workspace" icon="google">
    User management, access logs
  </Card>

  <Card title="Jira" icon="jira">
    Incident tracking, change management
  </Card>
</CardGroup>

<Note>
  Don't have integrations set up yet? You can upload evidence manually using the evidence upload feature while you configure integrations.
</Note>

## 5. Set up vendor risk management

If you have third-party vendors or suppliers:

1. Go to **Vendor Risk** → **Add vendors**
2. Import from CSV or add manually
3. Assign risk categories and questionnaire templates
4. Send questionnaires — vendors respond via a secure portal

## 6. Run your first risk assessment

Navigate to **Risk Management** and run a gap assessment against your selected framework. Matproof will show you:

* Controls that are fully met
* Controls with evidence gaps
* Recommended remediation steps

## What's next?

<CardGroup>
  <Card title="CSRD Module" icon="leaf" href="/csrd/overview">
    Setting up supplier ESG data collection for CSRD/ESRS reporting.
  </Card>

  <Card title="Vendor Risk" icon="truck" href="/features/vendor-risk">
    Managing your supplier base and Art. 28 register.
  </Card>
</CardGroup>


# DORA Quickstart
Source: https://docs.matproof.com/quickstarts/dora

Practical 90-day plan to get from sign-up to DORA-ready in Matproof — covering ICT risk management, third-party register, incident reporting, and operational resilience testing.

# DORA Quickstart

This is the operational companion to [/frameworks/dora](/frameworks/dora) (which explains *what* DORA requires). Here we cover *how* to deliver each obligation in Matproof, week by week.

## Who this is for

* Financial entities (banks, payment institutions, investment firms, crypto-asset service providers, ICT third-party providers) in scope for Regulation (EU) 2022/2554
* Compliance leads, CISOs, ICT risk managers responsible for DORA implementation
* Anyone preparing for their first BaFin / national competent authority (NCA) examination

If you're not sure DORA applies, see [/frameworks/dora](/frameworks/dora#scope) — but if you're reading this in 2026, your competent authority almost certainly already has you on a list.

## Before you start

| Have ready                                                                                   | Why                                                                                 |
| -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Your organization's legal name + entity classification (credit institution, IFM, IORP, etc.) | Drives DORA proportionality (some obligations apply only to "significant" entities) |
| Existing list of ICT third-party providers (cloud, SaaS, fintech infrastructure)             | You'll seed the [Article 28 register](#week-2-3) from this                          |
| Existing risk register (any format — spreadsheet, GRC tool, Confluence)                      | You'll port the relevant entries into Matproof's risk module                        |
| Existing incident-management runbook (if any)                                                | Reference material for the [Article 17 setup](#week-4-6)                            |
| Two key approvers identified — typically CISO and one management-body member                 | DORA Article 5(2) requires management-body sign-off on the ICT risk framework       |

## Phase 1 — Week 1: Foundation

Complete the [Onboarding](/onboarding) flow first; the steps below assume you're past the setup wizard.

### Day 1–2: Platform setup

1. In **Settings → Frameworks**, confirm DORA is active. The control library should be populated (about 70 controls).
2. Go to **Frameworks → DORA**. Skim the controls list to understand the structure: Article 5–6 (governance), Article 8 (asset inventory), Article 9 (ICT security), Article 17–23 (incident management), Article 24–27 (resilience testing), Article 28–30 (third-party).
3. Run the gap assessment if Matproof prompts you to.

### Day 3–5: Team and ownership

1. **People → Invite team.** At minimum invite: CISO, head of ICT/IT, head of compliance, the management-body member who will sign off on the ICT risk framework.
2. Assign control owners: every Article 5–9 control should have a named owner. Don't try to assign every Article 10–30 control yet; do those as you reach each phase.

## Phase 2 — Week 2–3: ICT Asset Inventory + Third-Party Register (Article 8 + Article 28)

### Article 8 — ICT Asset Inventory

DORA Article 8 requires an inventory of every ICT asset that supports business functions. In Matproof:

1. Connect cloud integrations ([AWS](/integrations/aws), [Azure](/integrations/azure-ad), [GCP](/integrations/gcp)) — Matproof auto-imports cloud assets
2. Roll out the [Matproof Device Agent](/features/device-agent) to laptops — populates the endpoint inventory automatically
3. For non-cloud / non-endpoint assets (on-prem servers, network equipment, SaaS without integrations), add manually under **Assets**
4. Tag each asset by **business function** (payments, trading, custody, customer onboarding, etc.) — DORA cares about which assets support which critical/important functions

### Article 28 — ICT Third-Party Register

The single most-asked DORA deliverable. Most NCAs (BaFin, AFM, AMF, Banca d'Italia) request the register format defined in the ESAs' Implementing Technical Standards (ITS) — Matproof's [Vendor Risk module](/features/vendor-risk) produces this directly.

1. **Vendor Risk → Vendors → Bulk import** — upload your existing vendor list as CSV
2. For every ICT vendor, complete the additional DORA fields:
   * **Criticality** — Critical / Important / Standard (use Matproof's classification helper if unsure)
   * **Function supported** — link to which business function the vendor enables
   * **Sub-processor list** — collect via the **DORA ICT Third-Party Assessment** questionnaire (see [Questionnaire AI](/features/questionnaire-ai))
   * **Data location** — where the vendor processes data (relevant for cross-border transfer risk)
   * **Exit strategy** — required for Critical vendors (Article 28(8))
3. Run the **Article 30 contractual checklist** — for each Critical vendor, confirm the contract contains all mandatory clauses (data location, audit rights, sub-contracting limits, security measures, exit support, termination rights, business continuity)
4. Run **concentration risk analysis** in the vendor module — Matproof flags critical functions concentrated on a single provider, region, or parent group

### Output of phase 2

* Article 8 ICT asset inventory complete and tagged by business function
* Article 28 register populated with criticality, sub-processors, contractual checklist
* Article 28 ROI export available (the format ESAs accept for register submission)

## Phase 3 — Week 3–4: ICT Risk Management Framework (Article 5–6)

DORA Article 5 requires a documented ICT risk management framework. Matproof's auto-generated **Risk Management Policy** provides the foundation; customize it.

1. **Policies → ICT Risk Management Policy** — review and customize the AI-generated draft. Specifically tailor: the governance structure (who reports to whom), the risk-tolerance statement, the ICT risk-acceptance criteria
2. **Get management-body sign-off** (Article 5(2)) — submit the policy for review, with an actual member of the management body as the reviewer. Their approval is recorded in the audit trail and serves as evidence
3. **Risks → Risk register** — port your existing top risks. For each, score likelihood × impact, set a treatment, link to the controls that mitigate it, and assign an owner
4. Cross-link risks to assets from phase 2 — Article 6 wants to see the asset → risk → control chain

### Output of phase 3

* ICT Risk Management Policy published, signed off by management body
* Risk register populated with linked controls and treatment plans
* Risk-treatment monitoring scheduled (Matproof reminds owners as treatment dates approach)

## Phase 4 — Week 4–6: Incident Management (Article 17–23)

DORA imposes **strict timelines** on major-incident notification:

| Report                   | Due                                   | What                              |
| ------------------------ | ------------------------------------- | --------------------------------- |
| **Initial notification** | 4 hours after classification as major | First-line notification to NCA    |
| **Intermediate report**  | 72 hours after initial                | Updated facts, status, impact     |
| **Final report**         | 1 month after resolution              | Full root-cause + lessons-learned |

The clock starts on **classification as major**, not on detection. Misclassification (or late classification) is itself a finding.

1. **Incidents → Settings** — confirm your NCA is correct. For German entities, this is BaFin. For others, set the relevant national authority. Matproof pre-fills NCA-specific report templates.
2. **Test the incident flow end-to-end** with a tabletop exercise:
   * Create a synthetic incident in Matproof
   * Step through classification (use one of the actual DORA major-incident criteria — number of clients, duration, geographic spread, data loss, criticality, economic impact)
   * Generate the initial 4h notification report
   * Verify the report meets the ESAs' RTS format (Matproof's templates are aligned by default — confirm any custom fields)
3. **Document your detection sources** — what tools, who's on call, escalation paths. Reference these in the Incident Management Policy
4. **Brief the on-call team** — they need to know the 4-hour clock starts on classification, that classification is a deliberate step they have to perform in Matproof, and where to find the report templates

### Output of phase 4

* Incident Management Policy published with NCA-specific reporting flow
* Tabletop exercise documented (this itself is Article 17 evidence)
* On-call team trained on the 4h/72h/1mo deadlines

## Phase 5 — Week 6–8: Operational Resilience Testing (Article 24–27)

Article 24–25 requires regular testing of operational resilience. Matproof's [Cloud Tests](/features/cloud-tests) module covers the technical side.

1. **Cloud Tests → New test** — set up at minimum:
   * Availability test for each business-function-supporting service (weekly)
   * Recovery test against your stated RTO (monthly)
   * Failover test for any cross-region / cross-AZ redundancy (monthly)
   * Data integrity test after every major release (event-triggered)
2. **Document the testing programme** in the BCP/DR policy
3. For **significant entities**: scope a Threat-Led Penetration Test (TLPT) per Article 26–27 — TLPT requires red-team engagement at least every 3 years. Matproof's [Penetration Tests](/features/penetration-tests) module is for the AI-powered side; TLPT will additionally require an external accredited red-team firm.

### Output of phase 5

* Resilience testing schedule live, first results recorded as control evidence
* BCP/DR policy reflects the testing programme
* TLPT scope and external firm engaged (significant entities only)

## Phase 6 — Week 8–12: Operational rhythm

By week 8 the core deliverables are in place. The remaining work is establishing the operational rhythm:

* **Weekly:** review Findings (vendor questionnaires, Cloud Tests, device-agent CVEs, audit findings) and triage
* **Monthly:** review the risk register, vendor concentration, integration health
* **Quarterly:** rerun the Article 30 contractual checklist on every critical vendor; refresh DPAs; rerun vendor questionnaires
* **Annually:** review the ICT Risk Management Policy; management-body re-affirmation; full BCP test; TLPT planning if significant

## Audit-readiness checklist

Use this when preparing for your first NCA examination or internal audit:

* [ ] **Art. 5–6:** ICT Risk Management Policy published, signed off by management body
* [ ] **Art. 8:** ICT asset inventory complete with business-function tagging
* [ ] **Art. 9:** ICT security policies (access control, encryption, network security) published with named owners
* [ ] **Art. 11:** BCP / DR plans published and tested at least once in the last 12 months
* [ ] **Art. 17:** Incident Management Policy published, on-call team trained on 4h/72h/1mo timeline
* [ ] **Art. 17–23:** At least one incident tabletop exercise documented; report templates verified RTS-compliant
* [ ] **Art. 24–27:** Resilience-testing programme live with at least one quarter of test results
* [ ] **Art. 26–27:** TLPT scope defined (significant entities only); external red-team firm under contract
* [ ] **Art. 28:** Article 28 register complete; all critical vendors have signed contracts with Article 30 mandatory clauses
* [ ] **Art. 28(8):** Exit strategy documented for every critical vendor
* [ ] **Art. 28:** Concentration-risk analysis completed and accepted by management body
* [ ] **Art. 30:** Article 30 contractual checklist passing for every critical vendor

## Common gotchas

* **"We're a small institution — does DORA apply?"** Yes. DORA is broadly scoped. Microenterprise relief exists but the bar is low (under 10 staff and €2M turnover/balance). Don't assume you're out of scope without checking Article 16.
* **The 4-hour clock** isn't 4 business hours. It's 4 calendar hours from classification, including weekends. On-call coverage matters.
* **The Article 28 register** is the single most-likely first thing your NCA asks for. Have it ready before the request lands.
* **TLPT** requires an external accredited firm — TIBER-EU or similar. Matproof's pen-test feature does NOT satisfy TLPT alone. Don't claim it does.
* **Concentration risk** is interpreted broadly: same provider, same region, same parent group, same operating-system family. Be honest in the analysis — a NCA reviewer will probe.

<CardGroup>
  <Card title="DORA framework" href="/frameworks/dora">
    Conceptual overview — what DORA requires
  </Card>

  <Card title="Vendor Risk" href="/features/vendor-risk">
    Article 28 register module
  </Card>

  <Card title="Incidents" href="/features/incidents">
    Article 17 incident reporting flow
  </Card>

  <Card title="Cloud Tests" href="/features/cloud-tests">
    Article 24–27 resilience testing
  </Card>
</CardGroup>


# GDPR Quickstart
Source: https://docs.matproof.com/quickstarts/gdpr

Practical 60-day plan to get from sign-up to GDPR-ready in Matproof — covering Article 30 ROPA, Article 32 security measures, breach notification, DPIAs, and data-subject rights.

# GDPR Quickstart

This is the operational companion to [/frameworks/gdpr](/frameworks/gdpr). GDPR has been in force since 2018 — this guide is for organizations either implementing GDPR for the first time or porting an existing programme into Matproof.

## Who this is for

* Any organization that processes personal data of EU/EEA residents — controllers and processors
* DPOs, privacy leads, compliance officers responsible for the GDPR programme
* Engineering and security leads who need to demonstrate technical/organizational measures (Article 32)

GDPR is largely a documentation regime — most of the obligations are about being able to *show* you've thought about each area. Matproof's job is to make the documentation produce itself from your existing operations rather than being maintained as a parallel set of spreadsheets.

## Before you start

| Have ready                                                                                                      | Why                                                 |
| --------------------------------------------------------------------------------------------------------------- | --------------------------------------------------- |
| A list of personal-data categories you process (employees, customers, prospects, suppliers, special categories) | Drives the ROPA structure                           |
| List of all processors (cloud, SaaS, payroll, marketing tools)                                                  | Article 28 DPA register                             |
| Existing Privacy Notice / Privacy Policy                                                                        | You'll port it; Matproof generates a starting draft |
| DPO designation (if required under Article 37)                                                                  | Named accountable owner                             |
| Knowledge of any cross-border transfers (US-based processors, group companies in third countries)               | Article 44–49 transfer safeguards                   |

## Phase 1 — Week 1: Foundation

Complete [Onboarding](/onboarding) first. Then:

1. **Settings → Frameworks** — confirm GDPR is active (\~25 controls)
2. **People → Invite team:** at minimum the DPO (or the person responsible for privacy if no formal DPO is required), plus a senior engineering or IT lead
3. If you have customers across multiple EU member states with different supervisory authorities, document this in **Settings → Organization** — Matproof references your lead supervisory authority on report templates

## Phase 2 — Week 2: Article 30 Records of Processing Activities (ROPA)

Article 30 is the single biggest GDPR documentation deliverable. Most supervisory authorities ask for the ROPA as the first thing in any inspection.

For each processing activity (e.g. "employee onboarding," "customer support tickets," "marketing email campaigns," "prospect database"), document:

1. **Purpose** of processing
2. **Categories of data subjects** (employees, customers, prospects, etc.)
3. **Categories of personal data** processed (contact info, employment data, financial data, special categories)
4. **Recipients** — internal teams, processors, third countries
5. **Retention periods** for each category
6. **Technical and organizational security measures** in place (cross-link to relevant Matproof controls)
7. For transfers outside EU/EEA: the transfer mechanism (SCCs, adequacy decision, BCR)

In Matproof:

* Open **Privacy → Records of Processing Activities** (or via the GDPR framework view)
* Create one ROPA entry per processing activity — Matproof's template prompts for each Article 30 field
* Cross-link to the relevant controls and policies so the security-measures section auto-populates

For most organizations, 8–15 ROPA entries cover everything. SaaS companies typically have around 12.

## Phase 3 — Week 2–3: Article 28 — Processor DPAs

Every processor that handles personal data on your behalf needs a signed DPA under Article 28(3). Matproof's [Vendor Risk module](/features/vendor-risk) has a dedicated **Article 28 register** view.

1. **Vendor Risk → Vendors → Import** your processor list (cloud providers, SaaS, payroll, marketing automation, support tools)
2. For each, mark **processes\_personal\_data: yes** and complete the Article 28 fields:
   * Categories of personal data the processor handles
   * Purpose of processing
   * Sub-processor list (collected via the **GDPR Article 28 Data Processor Assessment** questionnaire)
   * Transfer mechanism if non-EU
   * DPA file (uploaded; if not yet signed, mark as **pending**)
3. For any processor without a signed DPA, send the questionnaire + a request for their DPA template — track to closure
4. Schedule annual reassessment for every processor in the register

Output: an Article 28 register exportable as PDF or Excel for your DPO or supervisory authority.

## Phase 4 — Week 3–4: Article 32 — Security Measures

Article 32 requires "appropriate technical and organizational measures" — proportionate to the risk. Matproof's auto-generated policies cover the policy side; the controls and integrations cover the evidence side.

Concrete deliverables:

1. **Publish the Information Security Policy** (auto-generated, customize, publish)
2. **Publish the Data Protection Policy** (auto-generated, customize, publish)
3. **Connect cloud integrations** ([AWS](/integrations/aws) / [Azure](/integrations/azure-ad) / [GCP](/integrations/gcp)) — populate evidence on encryption-at-rest, audit-log enablement, access controls
4. **Connect identity integrations** ([Entra ID](/integrations/azure-ad) / [Google Workspace](/integrations/google-workspace)) — MFA evidence, access-review evidence
5. **Roll out the [Device Agent](/features/device-agent)** — endpoint encryption, screen-lock, antivirus, vulnerable-app evidence

The above produces enough evidence to populate \~80% of Article 32 controls automatically.

## Phase 5 — Week 4–5: Article 33–34 — Breach Notification

Article 33: notify the supervisory authority within **72 hours** of becoming aware of a personal-data breach (unless the breach is unlikely to result in a risk to data subjects' rights and freedoms).

Article 34: notify affected data subjects **without undue delay** if the breach is likely to result in a high risk.

In Matproof, the [Incidents module](/features/incidents) handles both:

1. **Incidents → Settings** — confirm your supervisory authority is correct (e.g. BfDI for German federal organizations, BayLDA for Bavaria, CNIL for France)
2. **Test the flow** with a tabletop:
   * Create a synthetic personal-data-breach incident
   * Step through the breach-notification classifier (does it meet the Article 33 threshold? Article 34?)
   * Generate the supervisory-authority notification template
   * If Article 34 applies, generate the data-subject communication
3. **Document detection sources** in the Incident Response Policy — what tools surface a potential breach (Aikido findings, device agent CVEs, employee reports)

## Phase 6 — Week 5–6: Article 35 — DPIAs

Article 35 requires a Data Protection Impact Assessment (DPIA) for processing "likely to result in a high risk to the rights and freedoms of natural persons" — typical triggers are large-scale processing of special-category data, systematic monitoring, automated decision-making with significant effect.

In Matproof:

1. **Privacy → DPIAs → New DPIA** — for each high-risk processing activity, run the guided DPIA workflow
2. The workflow walks through Article 35(7) requirements: systematic description of processing, necessity/proportionality assessment, risk assessment, measures envisaged
3. If the DPIA shows residual high risk, Article 36 requires **prior consultation** with your supervisory authority before the processing starts. Matproof generates the prior-consultation request template

For SaaS organizations using AI features, an EU AI Act–DPIA combined assessment is now expected — see [/quickstarts/dora](/quickstarts/dora) cross-references and the [EU AI Act framework](/frameworks/eu-ai-act) for the AI module.

## Phase 7 — Week 6–8: Data-Subject Rights

Articles 15–22 give data subjects rights: access, rectification, erasure ("right to be forgotten"), restriction, portability, objection, automated-decision-making safeguards.

You must respond to most requests within **one month** (extendable by two months if complex).

1. **Privacy → Data Subject Requests** — configure intake (an email alias like `privacy@matproof.com` that creates a ticket in Matproof, plus a public web form on your site that posts to Matproof's API)
2. **Document the workflow** for each right type — who fulfils, how identity is verified, what's exported, how the response is communicated
3. **Test it** — submit a synthetic access request and walk it end-to-end. The result is your evidence of an operational DSR programme

## Audit-readiness checklist

Use this for an audit by your supervisory authority or as part of a vendor-due-diligence response:

* [ ] **Art. 30:** ROPA complete and current; covers every processing activity; reviewed in last 12 months
* [ ] **Art. 32:** Information Security Policy and Data Protection Policy published; technical measures evidenced via integrations
* [ ] **Art. 28:** DPA register complete; every processor has a signed DPA on file
* [ ] **Art. 33:** Breach-notification flow tested via tabletop in last 12 months; on-call team trained on 72h timeline
* [ ] **Art. 34:** Data-subject notification template ready; criteria for triggering Article 34 documented
* [ ] **Art. 35:** DPIAs completed for every high-risk processing activity
* [ ] **Art. 36:** Prior-consultation process documented (even if not yet triggered)
* [ ] **Art. 37:** DPO appointed if required; DPO contact details in privacy notice
* [ ] **Art. 13–14:** Privacy notice published; reflects current ROPA
* [ ] **Art. 15–22:** Data-subject-rights workflow tested end-to-end; response time ≤ 1 month
* [ ] **Art. 44–49:** Cross-border transfer mechanism documented for every non-EU processor
* [ ] **Art. 5(2):** Records of compliance with the principles (accountability) are maintainable from Matproof's exports

## Common gotchas

* **The ROPA isn't optional** even for smaller organizations. The Article 30(5) exemption for under-250-employee orgs is narrower than people think (it doesn't apply when processing is regular, occasional, or includes special-category data — which covers basically every business).
* **Most processors aren't equally critical.** Don't try to send a 200-question DPA assessment to every SaaS vendor — use [Matproof's vendor classification](/features/vendor-risk) and risk-based the depth of assessment.
* **The 72-hour clock** starts on **awareness**, not investigation. If your detection produces possible-breach signals at 6pm Friday, the 72-hour clock runs through Monday morning — out-of-hours coverage matters.
* **DPIA ≠ DPA.** DPIAs (Article 35) are your internal risk assessment for processing activities. DPAs (Article 28) are contracts with processors. Different docs, different obligations.
* **Right to be forgotten has limits** — Article 17(3) lists exceptions (legal claims, public-interest archiving, etc.). Don't promise unconditional erasure; document your exceptions in the DSR workflow.

<CardGroup>
  <Card title="GDPR framework" href="/frameworks/gdpr">
    Conceptual overview — what GDPR requires
  </Card>

  <Card title="Vendor Risk" href="/features/vendor-risk">
    Article 28 DPA register
  </Card>

  <Card title="Incidents" href="/features/incidents">
    Article 33 breach-notification flow
  </Card>

  <Card title="Roles & Permissions" href="/features/rbac-roles">
    Configuring the DPO role
  </Card>
</CardGroup>


# NIS2 Quickstart
Source: https://docs.matproof.com/quickstarts/nis2

Practical 60-day plan to get from sign-up to NIS2-ready in Matproof — covering Article 21 risk-management measures, Article 23 incident reporting, and management-body accountability.

# NIS2 Quickstart

This is the operational companion to [/frameworks/nis2](/frameworks/nis2). NIS2 is structurally simpler than DORA (one core article — Article 21 — covers most of the technical obligations), but the management-body accountability under Article 20 and the supply-chain reach are real bite-points.

## Who this is for

* **Essential entities** under NIS2 Annex I (energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure, ICT service management, public administration, space)
* **Important entities** under NIS2 Annex II (postal/courier, waste management, manufacture/production/distribution of chemicals, food, manufacture of certain products, digital providers, research)
* Compliance leads, CISOs, IT directors of medium/large entities (>50 staff or >€10M turnover)

If you're not sure NIS2 applies, check your country's national transposition — NIS2 was transposed into national law by member states with their own scope clarifications. Germany: BSI-Gesetz (NIS2UmsuCG); Netherlands: Cyberbeveiligingswet; etc.

## Before you start

| Have ready                                                     | Why                                                                                                                |
| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Confirmation of essential vs important entity classification   | Drives the audit/inspection regime — essential entities get proactive supervision; important entities are reactive |
| Existing list of suppliers (especially ICT/security suppliers) | You'll seed the supply-chain register                                                                              |
| Existing incident-management runbook (if any)                  | Reference for the 24h/72h/1mo Article 23 setup                                                                     |
| Management-body member identified for accountability           | Article 20 is a personal-liability article — name them now                                                         |

## Phase 1 — Week 1: Foundation

Complete [Onboarding](/onboarding) first. Then:

1. **Settings → Frameworks** — confirm NIS2 is active
2. **Frameworks → NIS2** — review the Article 21 control library (typically 35–50 controls covering the 10 measures)
3. If you operate in multiple member states, also activate the relevant national transposition layer (e.g. German NIS2UmsuCG mappings via [Custom Frameworks](/features/custom-frameworks))
4. **People → Invite team:** CISO, head of IT, head of compliance, and the management-body member who will be the named accountability owner

## Phase 2 — Week 2–3: Article 21 Risk-Management Measures

Article 21(2) lists **ten measures** every entity must implement. They map roughly to ISO 27001 control families but with NIS2-specific phrasing. Walk through each in Matproof:

| Measure (Art. 21(2))                                                                                     | What to do in Matproof                                                                                                                                                                                                      |
| -------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **(a)** Risk analysis + InfoSec policies                                                                 | Publish the auto-generated **Information Security Policy** + populate the [risk register](/features/risk-management) with your top risks                                                                                    |
| **(b)** Incident handling                                                                                | Configure the [Incidents module](/features/incidents) with your national CSIRT as the reporting authority                                                                                                                   |
| **(c)** Business continuity (BCP, DR, crisis management)                                                 | Publish the auto-generated BCP and DRP; schedule the first test                                                                                                                                                             |
| **(d)** Supply-chain security                                                                            | Build the supplier register in [Vendor Risk](/features/vendor-risk); for ICT/security suppliers, run the questionnaire and assess sub-processors                                                                            |
| **(e)** Security in network/info-system acquisition, development, maintenance + vulnerability management | Connect [GitHub](/integrations/github) and [Aikido](/integrations/aikido); ensure CVE management runs via [Device Agent Tier 3A](/features/device-agent)                                                                    |
| **(f)** Policies/procedures to assess effectiveness                                                      | Schedule [Audit Programs](/features/audit-programs) — at least one annual internal audit                                                                                                                                    |
| **(g)** Cyber hygiene + training                                                                         | Roll out [security awareness training](/features/people) to every employee/contractor; track acknowledgements                                                                                                               |
| **(h)** Cryptography policies + procedures                                                               | Publish the auto-generated Cryptography Policy; confirm encryption-at-rest and TLS evidence flows from cloud integrations                                                                                                   |
| **(i)** Human resources security, access control, asset management                                       | Connect HR ([Deel](/integrations/deel) if relevant) and IdP ([Entra ID](/integrations/azure-ad), [Google Workspace](/integrations/google-workspace)); the [People](/features/people) module produces access-review evidence |
| **(j)** MFA, secure communication, secure emergency communication                                        | Confirm MFA enforcement evidence from your IdP integration; document emergency channels in the BCP                                                                                                                          |

Each measure becomes one or more controls in the framework view. Assign each control to a specific owner.

## Phase 3 — Week 3–4: Article 23 Incident Reporting

NIS2 Article 23 has its own reporting timeline — different from DORA's:

| Report            | Due                        | What                               |
| ----------------- | -------------------------- | ---------------------------------- |
| **Early warning** | 24 hours after awareness   | "Significant" incident detected    |
| **Notification**  | 72 hours after awareness   | Initial assessment, including IOCs |
| **Final report**  | 1 month after notification | Full root-cause + lessons learned  |

A **significant incident** is one that has caused or is capable of causing severe operational disruption or financial loss, or has affected or is capable of affecting other natural or legal persons.

1. **Incidents → Settings** — set your CSIRT as the reporting authority. For Germany: BSI's CERT-Bund. Netherlands: NCSC-NL. France: CERT-FR. Etc.
2. **Test the flow:** create a synthetic significant incident, step through classification, generate the early-warning report. Verify the report format matches your CSIRT's expectations
3. **Brief on-call:** the 24-hour clock starts on **awareness**, not classification. This is stricter than DORA. On-call needs to escalate fast, not investigate first.

## Phase 4 — Week 4–6: Management-Body Accountability (Article 20)

Article 20 is the article that makes NIS2 different from its predecessor: management-body members are personally accountable for the entity's compliance, including potential personal sanctions.

Concrete steps:

1. **Identify the accountable member** — typically the CEO, CIO, or designated board member. Document the name and role in **Settings → Organization → Compliance Roles**
2. **Publish the InfoSec policy with their sign-off** — the policy approval is recorded in the audit trail with their name and timestamp
3. **Brief them annually** — provide a NIS2 cyber-risk briefing to the management body at least once per year. Matproof's framework dashboard supports this — export the dashboard PDF for the briefing pack
4. **Document training they've received** — Article 20 explicitly says management-body members must follow training to gain knowledge to assess cybersecurity risks. Track this in [People → Training](/features/people)

## Phase 5 — Week 6–8: Supply-Chain Security (Article 21(2)(d))

NIS2 requires assessment of "the overall quality and resilience practices of products and services" of every supplier and service provider.

In Matproof:

1. **Vendor Risk → Vendors → Import** your full supplier list
2. Classify each vendor by criticality (Critical / Important / Standard)
3. For Critical and Important vendors, run the **NIS2 supplier security questionnaire** ([Questionnaire AI](/features/questionnaire-ai))
4. For ICT/security suppliers, additionally:
   * Verify their own NIS2 / ISO 27001 / SOC 2 status (request certificates)
   * Document any sub-processor disclosures
   * Schedule annual reassessments
5. **Findings** raised on supplier non-responses or red flags surface in the unified [Findings](/features/findings) view

## Audit-readiness checklist

Use this when preparing for an audit by your national competent authority (BSI, NCSC, ANSSI, CSIRT, etc.):

* [ ] **Art. 20:** Accountable management-body member named, briefed, trained
* [ ] **Art. 21(2)(a):** Information Security Policy published; risk register populated
* [ ] **Art. 21(2)(b):** Incident Management Policy published; incident-handling team named
* [ ] **Art. 21(2)(c):** BCP, DRP, crisis-management plan published; tested in last 12 months
* [ ] **Art. 21(2)(d):** Supply-chain register complete; ICT suppliers reassessed in last 12 months
* [ ] **Art. 21(2)(e):** Vulnerability-management process documented; CVE evidence current
* [ ] **Art. 21(2)(f):** Internal audit completed in last 12 months
* [ ] **Art. 21(2)(g):** Awareness training rolled out; acknowledgement rate > 95%
* [ ] **Art. 21(2)(h):** Cryptography policy published; encryption evidence current
* [ ] **Art. 21(2)(i):** Access controls in place; access reviews completed quarterly
* [ ] **Art. 21(2)(j):** MFA enforced; emergency comms channels documented
* [ ] **Art. 23:** Incident reporting flow tested via tabletop; on-call team briefed on 24h/72h/1mo timeline

## Common gotchas

* **Important vs essential entity classification** — important entities have a lighter audit regime but the same Article 21 obligations. Don't read "important = less work" — read it as "less surveillance, same compliance."
* **National transpositions vary.** Germany's NIS2UmsuCG, Netherlands' Cyberbeveiligingswet, France's transposition all add national specifics. Check your country's transposition; build a [Custom Framework](/features/custom-frameworks) for the delta if needed.
* **Article 20 is personal.** Management-body sanctions are explicitly contemplated in NIS2. Don't have someone "agree" to sign off the policy without actually walking them through it.
* **24-hour early warning** is much faster than people expect. It needs an on-call rota that can classify and notify, not investigate.
* **"Significant incident"** is broadly defined. When in doubt, notify — better to over-report than to face an Article 32 fine for late notification.

<CardGroup>
  <Card title="NIS2 framework" href="/frameworks/nis2">
    Conceptual overview — what NIS2 requires
  </Card>

  <Card title="DORA Quickstart" href="/quickstarts/dora">
    For financial entities; pairs with NIS2 for many DACH banks
  </Card>

  <Card title="Vendor Risk" href="/features/vendor-risk">
    Supply-chain register module
  </Card>

  <Card title="Incidents" href="/features/incidents">
    Incident-reporting flow
  </Card>
</CardGroup>


# Roles and Permissions
Source: https://docs.matproof.com/roles-and-permissions

Understand the four Matproof roles and how to invite team members and external auditors.

## Overview

Matproof uses four roles to control what team members can see and do. Roles are assigned per user when they are invited and can be changed later by an Admin or Owner.

## Role comparison

| Permission                               | Owner | Admin | User | Auditor |
| ---------------------------------------- | :---: | :---: | :--: | :-----: |
| View controls, evidence, policies, risks |  Yes  |  Yes  |  Yes |   Yes   |
| Edit controls, evidence, policies, risks |  Yes  |  Yes  |  Yes |    No   |
| Manage vendors                           |  Yes  |  Yes  |  Yes |    No   |
| View integrations                        |  Yes  |  Yes  |  No  |    No   |
| Manage integrations                      |  Yes  |  Yes  |  No  |    No   |
| Invite / remove users                    |  Yes  |  Yes  |  No  |    No   |
| View and edit settings                   |  Yes  |  Yes  |  No  |    No   |
| Manage billing                           |  Yes  |   No  |  No  |    No   |
| Delete organization                      |  Yes  |   No  |  No  |    No   |

## Role descriptions

### Owner

Full access to everything including billing and the ability to delete the organization. There is exactly one Owner per organization. Ownership can be transferred to another user in **Settings → Team**.

Use this role for the founder or the accountable executive sponsor of the compliance program.

### Admin

Full access to all compliance features and team management. Admins can invite and remove users, manage integrations, and configure settings. They cannot touch billing or delete the organization.

Use this role for the compliance manager or IT security lead who runs the day-to-day compliance program.

### User

Can view and edit all compliance content — controls, evidence, policies, risk register, and vendors. Cannot manage users, view integrations, or change settings.

<Note>
  User is the right role for most team members — engineers, department leads, and anyone who contributes to the compliance program without needing administrative access.
</Note>

### Auditor

Read-only access to controls, evidence, and policies. Auditors have a dedicated view optimized for audit work and are redirected to the auditor dashboard on login. They cannot see settings, integrations, or the People module.

Use this role for external auditors and certification bodies during an audit engagement.

<Tip>
  Always invite external auditors as Auditors, not Users. The Auditor role keeps them out of internal settings and gives them a cleaner view focused on what they need.
</Tip>

## Inviting team members

1. Go to **Settings → Team**
2. Click **Invite member**
3. Enter their email address
4. Select a role
5. Click **Send invite**

The invitee receives an email with a link to create their account. If they already have a Matproof account on another workspace, they can accept the invite with their existing login.

### Changing a role

1. Go to **Settings → Team**
2. Find the team member
3. Click the role dropdown next to their name
4. Select the new role

Role changes take effect immediately.

### Removing a user

1. Go to **Settings → Team**
2. Click the three-dot menu next to the user
3. Select **Remove from workspace**

Removing a user revokes their access immediately. Their past contributions (evidence uploads, control edits) are preserved.

## Inviting external auditors

External auditors need access to review your compliance posture. The Auditor role gives them what they need without exposing internal settings.

<CardGroup>
  <Card title="Auditor portal" icon="magnifying-glass">
    Auditors land on a dedicated dashboard showing controls, evidence status, policy documents, and risk register — organized for efficient audit review.
  </Card>

  <Card title="Read-only guarantee" icon="lock">
    Auditors cannot modify any records. They can download evidence files and export reports, but cannot create, edit, or delete anything.
  </Card>
</CardGroup>

**Recommended audit workflow:**

1. Invite your external auditor via **Settings → Team** with the Auditor role
2. Share the link to your workspace
3. The auditor accesses the auditor dashboard and reviews evidence at their own pace
4. Remove the auditor's access after the audit is complete

<Warning>
  Remember to remove external auditor access after the engagement ends. Leaving auditor accounts active is both a security risk and a potential finding in subsequent audits.
</Warning>

## Feature flags

Some advanced features are controlled by feature flags at the organization level. These are not self-serve — contact Matproof support to enable them.

| Feature flag              | What it enables                                                     |
| ------------------------- | ------------------------------------------------------------------- |
| `ai-vendor-questionnaire` | AI-assisted vendor questionnaire filling and response analysis      |
| `advancedModeEnabled`     | Advanced mode with additional configuration options for power users |

If a feature you expect to see is missing from your workspace, it may be behind a feature flag. Reach out to support with your organization name to check.


# Settings
Source: https://docs.matproof.com/settings

Configure your Matproof workspace, API access, integrations, and AI context.

## Overview

Settings is split into personal settings (per user) and organization settings (admin only). Access it via the gear icon in the sidebar or by navigating to `/settings`.

<CardGroup>
  <Card title="Personal settings" icon="user">
    Profile, notifications, language — applies only to your account.
  </Card>

  <Card title="Organization settings" icon="building">
    Company info, team members, billing — admin only, applies to the whole workspace.
  </Card>
</CardGroup>

## Profile

**Settings → User**

Update your personal details:

* Display name and profile photo
* Email address (used for notifications)
* **Notification preferences** — choose which events trigger email or in-app notifications (evidence expiry alerts, task assignments, access review reminders)
* **Language** — switch the Matproof interface between English (EN) and German (DE)

## API Keys

**Settings → API Keys**

Generate API keys to access Matproof programmatically — useful for CI/CD pipelines, custom dashboards, or internal tooling.

### Key scopes

| Scope        | What it allows                                                           |
| ------------ | ------------------------------------------------------------------------ |
| `read`       | Read all workspace data: controls, evidence, vendors, people, risks      |
| `read_write` | Read and write — create/update controls, upload evidence, modify records |

<Warning>
  Never commit API keys to source code. Use environment variables or a secrets manager. Read-only keys are sufficient for most integrations — only use read/write when your pipeline needs to push data back to Matproof.
</Warning>

### Creating a key

1. Go to **Settings → API Keys**
2. Click **New API key**
3. Give it a descriptive name (e.g. `ci-evidence-uploader`)
4. Select the scope
5. Copy the key — it is only shown once

### Using the API

Pass the key in the `Authorization` header:

```bash theme={null}
curl https://api.matproof.com/v1/controls \
  -H "Authorization: Bearer YOUR_API_KEY"
```

See the [API Reference](/api-reference) for full endpoint documentation.

## Secrets

**Settings → Secrets**

Store sensitive credentials for use in integrations — API keys, passwords, OAuth tokens. All secrets are encrypted at rest.

Secrets are referenced by name in integration configurations rather than pasting raw credentials. This means credentials are stored once and never exposed in logs or configuration UIs.

**When to use Secrets:**

* Integration credentials that cannot use OAuth
* Webhook signing secrets
* External scanner API keys

<Note>
  Secrets are scoped to your organization. Only Admins and Owners can create or view secrets. Regular users cannot access stored secret values.
</Note>

## Browser Connection

**Settings → Browser Connection**

The Matproof browser extension lets you capture evidence directly from web applications — useful when there is no native integration available.

### Setup

1. Install the [Matproof browser extension](https://chrome.google.com/webstore) from the Chrome Web Store
2. Go to **Settings → Browser Connection**
3. Click **Connect** — this generates a connection token
4. Paste the token in the extension settings

### Capturing evidence

Once connected, navigate to any web app in your browser, click the Matproof extension, and select **Capture screenshot** or **Capture page data**. The evidence is attached to a control of your choice.

<Tip>
  Use the browser extension for SaaS tools that don't have a native Matproof integration — for example, capturing access control settings from a legacy HR system or exporting a compliance report from a third-party tool.
</Tip>

## Context Hub

**Settings → Context Hub**

The Context Hub is where you tell Matproof about your organization. This context is used by Matproof's AI to generate relevant policies, suggest control implementations, and write accurate risk assessments.

### What to add

The more specific you are, the better the AI output:

| Section                  | What to include                                          |
| ------------------------ | -------------------------------------------------------- |
| Company description      | What your company does, industry, size, customer types   |
| Tech stack               | Cloud providers, databases, languages, SaaS tools in use |
| Compliance history       | Past audits, certifications held, known gaps             |
| Data types               | What personal or sensitive data you process              |
| Organizational structure | Team structure, key departments                          |

### Example entry

```
We are a 35-person B2B SaaS company building HR software for mid-market companies
in the DACH region. We process employee personal data (names, salaries, performance
reviews) for around 200 business customers. We run on AWS (eu-central-1), use
PostgreSQL on RDS, deploy via GitHub Actions, and use Slack, Notion, and Linear
internally. We completed a voluntary ISO 27001 readiness assessment in 2024.
```

<Tip>
  Fill in the Context Hub before generating your first policies. A well-described context hub dramatically improves the relevance of AI-generated policy drafts.
</Tip>

## Organization Settings

**Admin only**

| Setting        | Description                                                 |
| -------------- | ----------------------------------------------------------- |
| Company name   | Displayed on exported reports and auditor-facing documents  |
| Logo           | Used on policy documents and the auditor portal             |
| Timezone       | Affects timestamps on evidence and scheduled task reminders |
| Data residency | Choose where your compliance data is stored (EU / US)       |

Changes to organization settings take effect immediately across the workspace.