Attested Record A Security Research Group product
Sign up

Custody procedure, version 0.1, 2026-11-05

How we hold your data

How Security Research Group (SRG) takes, holds, transforms, releases and deletes data, written for a seller's lawyer and a buyer's security reviewer. Your agreement with us governs. Where this page and the agreement differ, the agreement wins.

The short version

  • Your data goes into an isolated clean room in Microsoft Azure that holds one engagement only.
  • Our first processing step seals it with a key created for your engagement in a hardware-backed key vault and deletes the unsealed copy. From then on only a processing job whose hardware passes Azure Attestation, and which runs under the container policy we set, can open it. Until that step runs, your upload is protected by the storage service's encryption and our access controls.
  • No person at SRG has standing access. Every access is approved, time-limited and logged to storage held under a retention policy.
  • Buyers never get a raw download path. They evaluate statistics, previews or vetted samples, and receive only de-identified packages after a signed license.
  • At the end, we destroy the key, delete the data and send you a signed deletion certificate that lists what was deleted.

The Five Safes

We organise the controls by the Five Safes framework.

Safe projects. We take custody only for a named engagement under a signed agreement and a signed rights file. Every manifest, receipt and certificate carries the engagement ID.

Safe people. Two named SRG people handle each deposit and both sign the custody receipt. Nobody holds standing access. Access is just-in-time, needs a second person's approval, and expires on its own. Two emergency accounts for the cloud account itself are held under dual control.

Safe settings. The clean room has no public endpoints and no route to the internet. Processing jobs reach only our own storage, key vault and Azure Attestation, over private connections. Software comes from a package store inside our custody account. Work runs in confidential containers, which receive your key only after their hardware passes attestation.

Safe data. We check every deposit before anything is opened or transformed. We inventory it and you review the inventory. De-identification replaces each real entity with the same stand-in everywhere it appears.

Safe outputs. Nothing leaves without review by two people. A package that fails its release gate is not released.

The engagement, step by step

1. Before deposit

  1. You sign the seller agreement and complete the rights file: what the data is, where it came from, and what rights you hold.
  2. We create an isolated environment for your engagement. We create your engagement key in a hardware-backed key vault. It cannot be exported.
  3. You get a short-lived upload link that reaches only your own container. It can add files, and on the portal's deposit page you can also see and remove what you sent until we receive it. It never reads a file back. A link we send you directly also works only from your network address.
  4. We do not connect to your systems. You export the data yourself and upload the export.

2. Deposit

  1. You upload the export, ideally with your own list of file hashes.
  2. We close your write path. From then on nothing in your container can change.
  3. We produce a deposit verification report: readability, file types and a listing of archives without opening them.
  4. We hash every file (SHA-256) and compute one summary hash over the whole set.
  5. We copy the deposit into the private custody store, confirm the copy matches, and delete the intake copy in the same session.
  6. We send you a custody receipt signed by both custodians. It lists the hashes, sizes, timestamps, storage location and key identifiers. You can recompute the summary hash on your own copy and check the signatures. The receipt says nothing about content, quality or rights.

3. Processing

  1. Processing runs in a temporary confidential container with no public address. It is removed after each run.
  2. Before your key is released, the container proves to Azure Attestation what hardware it runs on and which container policy it runs under. The key vault releases your key only to a job that passes that check. The check covers the container and its policy. The processing code is loaded from our custody storage. Before it runs, the job checks it against a hash fixed in that container policy, so changed code stops the job before your key is requested. The run log records the hash. Each release is logged.
  3. The container image is pinned by digest, and software packages come only from the package store in our custody account. Detection runs inside the clean room. No record is sent to an outside AI service.
  4. Nobody logs in to a machine that holds your data. Operators start processing jobs and read their logs, and starting a job needs just-in-time elevation with approval.
  5. Logs from every component go to an evidence store under a write-once retention policy, so entries cannot be changed or deleted while the policy applies. You can receive an export.

4. Evaluation by buyers

Buyers sign an evaluation agreement first. It bars training on anything they see. We offer, in rising order of exposure:

  1. a datasheet and classification report;
  2. statistics only, computed inside the clean room, with small counts suppressed;
  3. a synthetic or sampled preview, marked so a leak can be traced to the buyer;
  4. a buyer's evaluation program run inside the clean room, with reviewed, aggregate results.

No mode gives a buyer a raw download path. Full delivery happens only after a signed license.

5. Release

  1. Every package passes a deterministic scan of every output byte for the values detected in your deposit, four characters or longer. Any hit blocks release.
  2. One reviewer inspects the report and gate results and approves. A second reviewer, with separately approved access, issues the buyer's download link. Neither can do both.
  3. Each package ships in the buyer's format with a signed manifest of hashes and a de-identification report.
  4. The buyer confirms the manifest hashes on receipt.

6. Close-out

Close-out follows the timing in your agreement.

  1. We delete the custody copy and the working copies of your engagement. The deletion certificate names each store we deleted, so you can see what it covers.
  2. We destroy the engagement keys. The key vault holds a deleted key for a fixed recovery period before final purge. Your certificate shows the purge date and is marked provisional until the purge is done.
  3. We destroy any mapping table, or deliver it to you encrypted and destroy ours, as your agreement elects. Either way SRG keeps no re-identification secret.
  4. We export the access log for your engagement and deliver it to you.
  5. We send a deletion certificate signed by two SRG people. It lists the deposit by summary hash, the stores deleted and when, the keys destroyed, the records we keep and for how long, the access-log export with its hash, and any exceptions.

What we keep. The de-identification report, package manifests and hashes, the custody receipt, the rights file, access-log exports, your seller statements, buyer agreements, and records the law or our auditors require. We keep them for the period stated in your agreement, or as long as law requires. We never keep the deposit, the mapping table, or package content beyond hashes and sampled statistics.

What we never do

  • Clone your repositories to a laptop or copy your data into a shared bucket.
  • Deliver your raw data, or anything not de-identified, to a buyer or any other third party.
  • Export the engagement key or give any part of the mapping table to a buyer.
  • Try to re-identify anyone, except to test our own de-identification inside the clean room.
  • Tell a buyer who you are without your written consent.
  • Keep any re-identification secret after close-out.

What you can ask for at any time

  • Access-log export. Every access to your deposit, with the hash of the export.
  • Custody receipt check. Our public signing keys and their fingerprints, so you can verify the receipt and its summary hash yourself.
  • Deletion certificate check. The same keys verify the certificate. The certificate cites your custody receipt.
  • Attestation evidence. For each processing run: the attestation token, the key vault release entry, the attestation policy in force, the container policy and its hash, and the run log with the hash of the processing code.
  • Our written security program, as your agreement provides.

If something goes wrong

If we confirm unauthorised access to, or loss of, your deposit or the mapping table, we notify you within the period in your seller agreement and cooperate with your response. Buyers must report security incidents and suspected identification of a person to us within the periods in their agreements, and must quarantine or delete affected content on our instruction. We tell you in writing of any change that materially reduces the protections on this page.

Our public de-identification commitment

Security Research Group processes the data it licenses so that it cannot reasonably be linked to a particular person or household. We commit to maintain and use that data only in de-identified form, and we will not attempt to re-identify it, except to test whether our own de-identification works. We require every recipient of that data, by contract, to make and keep the same commitment and to pass it on to anyone they share the data with. For data that is protected health information, we process it only as a business associate under a written agreement, through either the HIPAA Safe Harbor method or an Expert Determination by a qualified expert, and every delivery states which. For data subject to the GDPR or UK GDPR, we describe our output as pseudonymised. Every delivery includes a signed report stating the methods used, what was measured, and the residual risk.

What this procedure does not claim

SRG does not yet hold an ISO 27001 certificate or a SOC 2 report for this service. We are scoping ISO 27001 to the clean room and its procedures, and we will link the certificate here when it exists. Microsoft Azure runs the data centres, hardware and platform services underneath the clean room. Microsoft's own audit reports cover those, and ours will not. We do not claim that any package is anonymous, that de-identification finds every personal detail, or that this procedure makes you or a buyer compliant with any law. The de-identification report states what we measured and what we could not.

The setup described here does not include, and this page does not claim:

  • a malware scan of deposits;
  • connections into your systems, or outbound connections to any outside host;
  • interactive or recorded sessions for our staff, or supervised sessions for buyers;
  • a hardware measurement of the processing code itself: the hardware measures the container policy, the policy fixes the code's hash, and the job checks the code against that hash before it asks for your key;
  • a retention lock that our administrators cannot lift, until we lock the evidence store's policy and say so here;
  • a scan for detected values shorter than four characters.

Questions: info@securityresearch.us

Back to the home page