Map and review one control result

This guide takes one test result, such as a recovery rehearsal, and shows how to:

• connect it to the control it supports;
• read its evidence in the Platform;
• hand a reviewer enough to check the claim without learning how the evidence was captured.

It uses only actions the Platform supports today. Where a step you might expect does not exist, the guide says so, and tells you where to keep that information instead.

What this establishes. A mapped result supports a scoped claim about one control: this test, on this subject, passed or failed under this policy at this time. It does not establish that the whole control, or any framework, is satisfied. It does not establish that an auditor has accepted the claim.

What is available

Check this before you set anything up.

FedRAMP 20x key security indicators are the exception: they have an assessor review state and a separate assessor role. They are outside this guide.

Before you start

• A recovery test recorded with CI/lock, and a signed policy that evaluates it. Follow Keep the result of a recovery rehearsal, then Make a recovery requirement executable. Record a passing and a failing run, so the reviewer sees the policy refuse a bad result.
• That policy published in the Platform, and bound to the product and repository the test belongs to.
• The control catalog loaded in your deployment. Catalogs are shared reference data that an operator loads; a tenant cannot upload its own.
• To bind: a tenant owner or administrator session. An API token also needs the supplychain:admin scope.

Keep the four kinds of record apart. Each answers a different question:

A control mapping uses the first two. It needs no push.

1. Find the control and record the catalog version

1. Open Controls (/controls) and choose the catalog.
2. Open the control, for example cp-10 in NIST SP 800-53.
3. Note the catalog title shown on the page.

The page does not show the catalog version. To get it, read version from the oscalCatalogs query in the Platform API.

Record both the catalog title and its version. A control identifier means different things in different revisions of a catalog.

2. Bind the policy to the control

1. Open Test plans (/test-plans) and choose the policy that evaluates the recovery test.
2. Under Controls this policy covers, add the control.

The Bind a policy link on an empty control page goes to the same list.

Only a tenant owner or administrator can bind or unbind. Other members see the section read-only.

The control counts the policy's verdicts only where the policy's binding to the product or repository is active, and a person activates that binding. Until then its verdicts are listed as inactive and left out of the control's counts.

The binding stores three things: the policy, the catalog and the control. It does not store why the policy supports the control, what part of the control it covers, or who reviewed it. Write those down now, in your review record (section 5):

• Rationale. Which requirement of the control this test exercises, and how.
• Scope. Which system, data set and environment the test covered, and which it did not.
• Period. The window of evaluations you are claiming.

3. Read the evidence

Open the control again. Evidence lists every policy bound to the control, and for each one a verdict per bound product and repository:

• Verdict: passed, failed, pending (no decision yet), no verdict, or no verdict because AI evaluation is turned off.
• Product and repository the verdict is about.
• Commit: the default-branch head the verdict was taken at. A verdict for another commit is marked as not the default-branch head.
• Evidence link to the attestation behind the verdict, with its attestation types.
• Inactive: the binding is not active. An inactive verdict is listed but not counted.

The Controls list shows each control's verdict counts and when it was last evaluated.

Freshness is yours to judge. The Platform shows when each control was last evaluated, but it does not mark evidence as stale. Decide how old a passing result may be for this control. Rehearsals that run every quarter cannot support a monthly claim. Record the window in your review record.

Read failures and gaps as findings. A failed verdict means the result did not meet the policy. A pending one means no decision exists yet. A product or repository with no verdict at all is not covered by this mapping. Do not count it as passing.

Record the status decision with its reason. On the product's system security plan, open the control and use Set control status. The reason is required. Each change writes an append-only audit entry with the previous and new status, who made the change, when, and why. This is the one place in the Platform where your rationale is stored next to the control. The same rationale still belongs in your review record, because the entry does not reference the policy's verdicts.

4. Hand the result to a reviewer

Choose the route that matches what the reviewer needs.

A frozen package: auditor share

An owner or administrator can create an auditor share from the product's settings. A share does the following:

• Snapshots the product's latest system security plan, with redaction, and only the evidence and documents you choose.
• Optionally limits the snapshot to one framework view: SOC 2 or NIST SP 800-171.
• Signs the snapshot, and gives you a link that opens it at /audit/<token>. The reviewer needs no account.
• Can expire after a set number of days, and can be revoked.

A share needs a generated system security plan for the product. If your plan does not include system security plans, use one of the routes below, or ask your account team.

The snapshot does not include the control page's verdicts. It carries the system security plan: its frameworks, controls and their statuses, narratives, the evidence items and documents it includes, and the signature details. The per-product and per-repository verdicts from section 3 are not part of it, so put them in the review record you send with the link.

Revocation. Revoking a share stops the link from opening. It does not delete the signed snapshot from storage, and it cannot recall anything the reviewer already downloaded.

Other exports. The system security plan's FedRAMP 20x export is available in the interface. An OSCAL system security plan, an assurance bundle and a POA&M can be exported through the Platform API only, with no button in the interface. The Platform has no PDF, CSV or ZIP export of a control record.

Original records: evidence files and an audit bundle

• The evidence link on the control page opens the attestation behind each verdict. A signed-in user of the tenant can download an attestation by its identifier.
• For an engineering reviewer, Build an audit evidence bundle produces a manifest, the verification report, the attestations and a replay script. The reviewer can re-verify the result offline.

Downloaded files cannot be revoked. Share them only with people entitled to keep them.

Live access: not read-only

A tenant has three roles: owner, administrator and member. There is no read-only role. Inviting a reviewer as a member gives them write access to the workspace, not a view of it. A member can:

• create products and other records in the tenant;
• change and delete the tenant's records, except where an action is reserved for owners and administrators (binding policies to controls, managing integrations, creating auditor shares).

Do not use a member invitation as a substitute for read-only access. To end live access, an owner or administrator removes the user from the tenant, and revokes any invitation link or API token they were given.

5. Write the review record

The Platform does not hold rationale or review state for a mapping, so keep one record per claim alongside the share or bundle. The example below is sanitized; every value in it is fictional.

claim: >-
  Backups of the orders database restore completely within the stated
  recovery time, for the production cluster.
control:
  catalog: NIST SP 800-53
  catalog_version: "5.1.1"
  id: cp-10            # System recovery and reconstitution
rationale: >-
  The rehearsal restores the latest nightly backup into an isolated instance
  and compares row counts per table; a nonzero exit is a failure. It
  exercises recovery of one service's data, not the whole system.
scope:
  covered: [orders-db, production backups, nightly snapshots]
  not_covered: [object storage, cross-region failover, other databases]
period: 2026-07-01 to 2026-09-30
evidence:
  policy_release: recovery-policy v3 (release id and digest from the Platform)
  verdicts:
    - commit: 4f2a91c
      verdict: passed
      evaluated: 2026-09-28
      attestation: sha256:… (from the evidence link)
    - commit: 9be07d1
      verdict: failed      # rehearsal missed writes after the backup
      evaluated: 2026-08-14
      attestation: sha256:…
  freshness_window: 95 days
producer: CI/lock in the recovery job, signed as the job's workload identity
gaps:
  - Failed rehearsal on 2026-08-14 is a finding; fix verified on 2026-09-28.
  - Object storage and failover are not covered by this test.
review:
  state: accepted for scope above
  reviewer: (name, role)
  date: 2026-10-02
handoff: auditor share, expires 2026-11-01; audit bundle attached

6. Review it: a guide for the reviewer

You do not need to know how the evidence was captured. Check these in order:

1. Claim. Is it about one control, and narrow enough for the test to support?
2. Control. Are the catalog, its version and the control identifier stated?
3. Scope. Do the covered systems match the claim? Is anything the claim implies listed under not covered?
4. Period and freshness. Do the evaluations fall inside the period? Is the newest result inside the freshness window?
5. Original records. Do the attestation identifiers open, through the share, the download or the bundle? In a bundle, does the verification report match them?
6. Provenance. Is the producer the expected workload, and the policy release the one named?
7. Failures. Are failed and pending verdicts listed and explained, not left out?
8. Limits. Does anything suggest the whole control or framework is satisfied? A mapped result cannot show that.

Page ledger