OYA-S 2000:2027 (Draft) — Sensitive Data, Encryption, Member-Key Control, and Erasure

The organization SHALL classify Layer 4 sensitive personal information into a distinct "Restricted" data tier, separate from ordinary account and profile data, before that information is stored.

A classification boundary is the precondition for every other control in this standard — encryption mode, access logging, and erasure mechanics can only be applied consistently if the organization first knows which records are Restricted-tier.

a. Data classification policy naming the Restricted tier.
b. Data map or schema showing which fields/record types are tagged Restricted.
c. Sample record demonstrating the tag is enforced at storage time, not applied retroactively.

Documentation review and technical sampling of the data schema.

The Restricted Vault MUST:

• Encrypt content at rest and in transit.
• Use per-record or per-vault data encryption keys.
• Separate identity information from vault ciphertext.
• Require member re-authentication to view vault content.
• Use a member-controlled secret for the highest protection mode (see §6, §7).
• NOT expose vault content to other users, matches, partners, advertisers, or ordinary customer-support tools.
• Maintain a member-readable access record (see §12).

These are the minimum technical and access controls that make the word "vault" meaningful rather than decorative — content stored without them is not distinguishable from ordinary encrypted-at-rest data and should not be marketed as a Restricted Vault.

a. Architecture diagram showing key separation from identity data.
b. Access-control configuration excluding ordinary support tooling.
c. Re-authentication flow test result.
d. Sample entry from the member-readable access record (§12).

Technical test and architecture-diagram review.

Before or at the point a member's content is placed in a given vault mode, the organization SHALL disclose which of the four modes applies, using the terms defined above — not a general statement that data is "encrypted."

"Encrypted" alone does not tell a member whether the company can still read their content. The four-mode distinction is the specific piece of information a member needs to make an informed choice.

a. UI copy or disclosure text shown at the relevant point in the product.
b. Mapping from each Restricted content type to its declared mode.

Member-journey observation and documentation review.

The organization SHALL maintain documented practice and evidence for each of the eight lifecycle stages above, for every key that protects Restricted-tier content. A conformity claim that only addresses Generation and Storage, without Rotation, Compromise, Erasure, and Recovery, does not satisfy this requirement.

NIST guidance treats key management as a full lifecycle covering generation, establishment, storage, use, and destruction; OYA-S 2000 requires evidence across that lifecycle rather than relying on a broad claim that a system is "encrypted."

a. Key-management policy covering all eight stages.
b. Key-rotation schedule and most recent execution log.
c. Documented incident-response procedure for key compromise.

Technical test and documentation review.

The organization MUST disclose which vault mode applies to a given category of content, using one of the following three labels:

• Company-Managed Protected Vault
• Member-Key Vault with Recovery
• Zero-Knowledge Member-Key Vault

and, for each, clearly state:

• Whether the company can decrypt the member's content.
• Whether recovery is available.
• What happens if the member loses the recovery phrase.
• Whether backups remain ciphertext after key destruction.
• The expected deletion/erasure timeline.
• Legal-retention exceptions, if any.

Each of the six disclosure items answers a question a member would reasonably ask before trusting a "vault" label. Omitting any one of them (most commonly: what happens to backups after key destruction) is the most common way encryption claims become misleading without being technically false.

a. Disclosure copy for each vault mode in use.
b. Technical confirmation that the backup-ciphertext claim in the disclosure matches the actual backup architecture.

Documentation review and technical test against the backup system.

Where an organization labels content "Zero-Knowledge," it SHALL implement client-side key generation such that the organization never receives or stores the unwrapped vault key or an equivalent recovery path, and it MUST NOT offer an email-reset or support-initiated recovery for that content.

"Zero-knowledge" is a specific, testable architectural claim, not a UI description. An organization that can reset a member's access through a support workflow does not have a zero-knowledge system, regardless of what its interface says.

a. Independent cryptographic architecture review confirming no server-side recovery path exists.
b. Source or configuration review of the key-generation flow.
c. Support-tooling audit confirming no reset capability for Zero-Knowledge content.

Independent technical review — this requirement is not satisfiable by policy documentation alone.

For every vault mode offering any recovery path, the organization SHALL disclose precisely who can recover access, what factors are required, and what specifically cannot be recovered. For Zero-Knowledge Vault content, the organization MUST state plainly that forgetting the recovery phrase results in permanent, unrecoverable loss of that content — by the member and by the company alike.

A recovery claim that is vague about "who" and "what factors" is functionally the same failure mode as a vague deletion claim (§10) — it lets an organization imply stronger member control than the architecture actually provides.

a. Recovery-disclosure copy for each vault mode.
b. Support-flow documentation showing the recovery path matches the disclosure.

Documentation review and member-journey observation.

The organization SHALL rotate encryption keys under documented conditions (scheduled rotation, suspected compromise, or personnel change) without weakening any member-set access restriction, and SHALL support immediate key revocation and incident investigation in response to a suspected compromise.

Key rotation is routine good practice, but a rotation process that silently resets a member's restriction settings (for example, re-exposing content a member had locked) would defeat the purpose of the restriction itself.

a. Key-rotation schedule and procedure.
b. Test result confirming member restrictions survive a rotation event.
c. Documented incident-response runbook for suspected key compromise.

Technical test and documentation review.

The organization SHALL provide an eligible member with a mechanism to initiate cryptographic erasure of Covered Vault Content. The mechanism MUST:

• Require recent authentication.
• Require the vault recovery phrase or an equivalent high-assurance factor.
• Use explicit confirmation, not a single accidental tap.
• Destroy the member-wrapped key material.
• Destroy or revoke service-side wrapped-key references where applicable.
• Queue cryptographic-erasure verification across replicas.
• Record a signed erasure event (see §12).
• Show the member a completion state and any exceptions.

Key destruction may make covered ciphertext infeasible to decrypt when the architecture correctly separates and protects the relevant key material. This requirement exists precisely to prevent the version of this claim that isn't true: "the moment a member changes their encryption code, the company loses all access to every copy of their data," stated without the recent-authentication, replica-verification, and exception-disclosure steps above, is not a safe claim for most products to make.

a. Architecture diagram.
b. Key-management configuration sample.
c. Erasure workflow test result.
d. Replica-verification result.
e. Member-facing confirmation and exception notice.
f. Tamper-evident ledger entry.

Technical test, documentation review, and member-journey observation.

The organization SHALL distinguish, for every erasure event, between: original protected content; generalized private summaries; account-linked derived profile data; de-identified aggregate research data; and logs, backups, caches, embeddings, and analytics artifacts. Key destruction of original vault content does NOT automatically mean all authorized derivatives disappear, and the organization MUST NOT represent it as doing so.

This is the single most common way a "we deleted your data" claim becomes misleading: the primary record is gone, but a backup, a log line, or a derived summary survives on a separate retention schedule. Disclosure of the distinction is the fix, not a promise that every category disappears simultaneously.

a. Backup and replication architecture documentation, including retention class per backup type.
b. Sample member-facing disclosure listing each data location and its status (see §12's copy inventory).
c. Test result confirming a Physically Sanitized claim (§10 table) is only made where the documented sanitization method has actually run and been verified — not asserted from the UI alone.

Technical test against the backup system and documentation review.

The organization SHALL maintain a member-readable Access Provenance Ledger covering all 16 required fields and all 22 required event types listed above, for every item of Restricted-tier content. The ledger MUST NOT reveal security-sensitive implementation details, unsafe employee names, other members' data, or confidential fraud controls.

This is the record that shows every time the data was pulled and accessed, and whether copies were made — the specific accountability mechanism requested alongside the erasure control itself.

a. Ledger schema covering all 16 fields.
b. Sample ledger entries covering at least five distinct event types.
c. Tamper-evidence mechanism test result.
d. Member-facing ledger UI walkthrough.

Technical test, schema review, and member-journey observation.

For protected records, the organization SHALL provide a member-readable inventory of: active primary record; encrypted replicas; backup retention class; member-created exports; approved external processors, by category; derived private summaries; and research status (account-linked, identity-separated, or not used). The inventory MUST use clear categories and avoid false precision.

This is the member-facing counterpart to §11's backup-disclosure requirement — it turns "we have copies in several places" into a specific, checkable list instead of a general reassurance.

a. Sample copy-inventory screen for a real record.
b. Backend mapping confirming every listed location actually exists and every existing location is listed.

Technical test and member-journey observation.

OYA Gold conformance to this standard requires:

• Annual assessment by an approved independent assessor.
• Technical test of access controls, logging, key management, and the erasure workflow.
• Review of the data map, retention rules, derivative handling, and member controls.
• Sampled evidence of remediation.
• A public certificate stating validity date and scope.
• A suspension/revocation process for material nonconformance.

A company may not self-certify for OYA Gold.

Every requirement in this document — the vault controls, the disclosure language, the erasure mechanics, the ledger — is only as credible as the process that checks it stays true over time. Annual, independent, non-self-administered assessment is what keeps a "Cryptographically erased" or "Zero-Knowledge" claim honest a year after launch, not just on day one.

a. Assessor engagement letter and independence attestation.
b. Completed technical test report.
c. Remediation-tracking record for any findings.
d. Published certificate with scope, validity date, and assessor name.

Independent third-party assessment — no other conformity method satisfies this requirement.