SOC 2 — HDS compliance-matrix

`CC1.1` CC1.1 — Commitment to integrity and ethical values draft

The service organization demonstrates a commitment to integrity and ethical values as a foundation for its system of internal control.

Pryv platform out-of-scope

Integrity + ethics are a management-and-culture matter. Pryv has no software role at the values / code-of-conduct layer; your audit log can later evidence whether workforce behaviour matched the stated values, but the commitment itself is yours to make and document.

HDS documented USCH

Integrity and ethical values are a matter of organizational culture, not software. HDS maintains a written code of conduct and information-security policy that set the ethical baseline for its own workforce operating the platform; the service organization building on HDS sets and documents its own. The platform contributes only after the fact: the per-user audit log can evidence whether workforce behaviour matched the stated values.

detail

HDS holds this as an operator governance artefact rather than a platform feature. Its commitment to integrity is expressed in a documented code of conduct and the umbrella information-security policy referenced throughout this matrix; both are reviewed periodically. A partner attesting under SOC 2 cannot inherit HDS's culture controls — they author their own — but may cite the audit log as the substrate that holds individuals accountable to whatever ethical baseline they set.

🔒 hipaa/policies/information-security-policy available on request

Implementer

service-organization documented

Establish and document your own code of conduct and ethical-values baseline; this is a management and culture obligation HDS cannot carry for you.

user-entity out-of-scope

subservice-organization documented

Maintain your own integrity and ethics programme for the workforce that operates any downstream service.

`CC1.2` CC1.2 — Board independence and oversight draft

The board of directors operates independently of management and oversees the development and performance of internal control.

Pryv platform out-of-scope

Board governance is organizational. No software contribution; this matrix + the audit log feed the oversight pack the board reviews, but the oversight function is yours.

HDS documented USCH

Board governance and oversight are organizational structures with no software role. HDS documents its own governance and oversight arrangements internally; the service organization documents its own board's independence and oversight function. This matrix and the audit log can feed the oversight pack a board reviews, but the oversight function itself is a governance obligation.

detail

HDS treats board-level oversight as an operator governance artefact, held privately and available on request. Where HDS operates the platform, this matrix doubles as a control inventory the partner's own board can review, and the audit log supplies control-operation evidence. The independence and oversight obligation cannot be inherited; each attesting organization carries its own.

🔒 soc2/policies/governance-and-oversight available on request

Implementer

service-organization documented

Document your own board's independence and its oversight of internal control; a governance obligation outside the platform.

user-entity out-of-scope

subservice-organization documented

Document the equivalent oversight arrangements for your own organization.

`CC1.3` CC1.3 — Management structures, reporting lines, and authorities draft

Management, with board oversight, establishes structures, reporting lines, and appropriate authorities and responsibilities in pursuit of the entity's objectives.

Pryv platform out-of-scope

Org structure + authority assignment are management artefacts. Pryv enforces the *technical* half of "appropriate authorities" once you've decided them (see CC6.3 least-privilege), but the reporting-line design itself is yours.

HDS documented USCH

Organizational structure and authority assignment are management artefacts. HDS documents the reporting lines and authorities for its own platform operation, including the named security official accountable for the programme. The platform enforces the technical half of "appropriate authorities" once they are decided (least-privilege access, see CC6.3), but the structure design itself is management work.

detail

HDS holds its own management structure, reporting lines and authority assignments as documented operator artefacts. The technical realisation of authority — who may exercise which permissions — is carried by the access-token model and recorded in the audit log; the design of the reporting lines and the assignment of responsibilities are governance decisions each attesting organization makes for itself.

🔒 hipaa/policies/access-control available on request
🔒 soc2/policies/governance-and-oversight available on request

Implementer

service-organization documented

Define and document your own reporting lines and authority assignments; map the resulting authorities onto least-privilege access grants.

user-entity out-of-scope

subservice-organization documented

Document your own management structure and authorities for the service you operate downstream.

`CC1.4` CC1.4 — Commitment to competence draft

The entity demonstrates a commitment to attract, develop, and retain competent individuals in alignment with its objectives.

Pryv platform out-of-scope

Hiring + training + retention is an HR programme. No software role.

HDS documented USCH

Hiring, training and retention of competent staff is an HR programme with no software role. HDS runs and documents its own competence programme for the workforce operating the platform; formal, verified security-awareness training is a known gap being matured. The service organization runs its own.

detail

HDS treats workforce competence as an operator governance artefact. Its documented programme covers role-relevant skills for staff operating the platform. The platform makes no contribution at this layer. HDS is honest that formal verified training delivery is still being formalised; a partner attesting under SOC 2 maintains its own competence programme.

🔒 soc2/policies/workforce-competence available on request

Implementer

service-organization documented

Run and document your own hiring, training and competence programme; HDS cannot carry this for you.

user-entity out-of-scope

subservice-organization documented

Maintain a competence programme for your own downstream workforce.

`CC1.5` CC1.5 — Accountability for internal control responsibilities draft

The entity holds individuals accountable for their internal control responsibilities in pursuit of its objectives.

Pryv platform facilitated

Pryv gives you the technical accountability substrate: every API call is attributable to an access (accessId + accessSerial) in the per-user audit log, so "who did what, when" is recoverable when you need to hold an individual to account. Defining the responsibilities and the consequence process is your management activity; Pryv supplies the evidence trail.

HDS facilitated USCH

The platform HDS operates supplies the technical accountability substrate: every API call is attributable to a specific access identity in the per-user audit log, so "who did what, when" is recoverable when an individual must be held to account. HDS layers its own sanction and accountability policy on top and documents it; defining responsibilities and the consequence process is each organization's management activity.

detail

Accountability has two halves. The evidence half is platform-native — the audit log attributes each action to an access identity, giving an objective record against which responsibilities can be enforced. The policy half (which responsibilities, what consequences) is governance; HDS documents the accountability and sanction policy it operates for its own workforce. A partner inherits the audit substrate but authors its own accountability framework.

🔒 hipaa/policies/audit-controls available on request
🔒 soc2/policies/accountability-and-sanctions available on request

Implementer

service-organization documented

Define the internal-control responsibilities and the consequence process; use the per-user audit log as the accountability evidence trail.

user-entity out-of-scope

subservice-organization documented

Hold your own workforce accountable using the audit substrate and your own sanction policy.

`CC2.1` CC2.1 — Quality information to support internal control draft

The entity obtains or generates and uses relevant, quality information to support the functioning of internal control.

Pryv platform facilitated

Pryv produces two streams of control-relevant information: the per-user audit log (application-level activity, attributable to an access) and observability metrics (operational + security KPIs via the pluggable provider). What you monitor and how you act on it is your programme; Pryv supplies the quality data.

HDS facilitated USCH

The platform produces two streams of control-relevant information that HDS operates: the per-user audit log (application-level activity, attributable to an access identity) and operational monitoring (security and operational KPIs across both data-residency options). What to monitor and how to act on it is each organization's programme; HDS supplies the quality data and runs its own monitoring over the platform.

detail

Quality information for internal control comes from the audit log and HDS's operational monitoring, which is wired end to end with alerting before any component is treated as in production. HDS documents the monitoring it operates. A partner consumes the same substrate to feed its own control-monitoring process and defines its own thresholds and review cadence.

🔒 hipaa/policies/audit-controls available on request
🔒 soc2/procedures/control-monitoring available on request

Implementer

service-organization documented

Define what control-relevant information you collect and how you act on it, drawing on the audit log and monitoring substrate HDS exposes.

user-entity out-of-scope

subservice-organization documented

Operate your own monitoring and information-quality process over the substrate you run downstream.

`CC2.2` CC2.2 — Internal communication of objectives and responsibilities draft

The entity internally communicates information, including objectives and responsibilities for internal control, needed to support its functioning.

Pryv platform out-of-scope

Internal communication of objectives is a management activity. No software role at the communication-content layer.

HDS documented USCH

Internal communication of objectives is a management activity with no software role at the communication-content layer. HDS documents how it communicates security objectives and responsibilities to its own workforce; the service organization runs its own internal-communication programme.

detail

HDS holds this as an operator governance artefact: its information-security policy and internal communication channels convey control responsibilities to staff. The platform contributes nothing at the content layer. Each attesting organization authors and operates its own internal communication of objectives and responsibilities.

🔒 hipaa/policies/information-security-policy available on request

Implementer

service-organization documented

Communicate internal-control objectives and responsibilities to your own workforce; a management obligation outside the platform.

user-entity out-of-scope

subservice-organization documented

Communicate the equivalent objectives and responsibilities to your own downstream workforce.

`CC2.3` CC2.3 — External communication on internal control matters draft

The entity communicates with external parties about matters affecting the functioning of internal control.

Pryv platform facilitated

For the slice of external communication that concerns the Pryv platform itself, open-pryv.io's public release process is the channel: tagged releases, CHANGELOG-v2 + CHANGELOG-v2-back, and (when shipped) the vulnerability-disclosure programme. You layer your own customer / subprocessor / auditor communications on top.

HDS facilitated USCH

For the slice of external communication that concerns the platform itself, the public release process is the channel: tagged releases and published change notes communicate what changed in the substrate. HDS layers its own external-communication programme (customer, subprocessor and auditor communications) on top and documents it. The service organization runs its own.

detail

External communication about internal control has a platform half and an operator half. The platform half rides on the public open-source release process. The operator half — how HDS communicates security and incident matters to its customers and subprocessors — is documented as an operator artefact and backed by the subprocessor register. A partner attesting under SOC 2 authors its own external-communication programme.

🔒 hipaa/policies/information-security-policy available on request
🔒 hipaa/registers/subprocessor-register available on request

Implementer

service-organization documented

Author your own external communications about internal control to customers, subprocessors, regulators and auditors.

user-entity out-of-scope

subservice-organization documented

Communicate control matters to the parties you serve and to your own upstream service organization.

`CC3.1` CC3.1 — Objectives specified with sufficient clarity draft

The entity specifies objectives with enough clarity to enable the identification and assessment of risks relating to them.

Pryv platform out-of-scope

Objective-setting is your management exercise. Pryv has no role in authoring objectives; the matrix supports the downstream risk-to-control mapping once your objectives exist.

HDS documented USCH

Objective-setting is a management exercise; the platform has no role in authoring objectives. HDS documents the security and availability objectives it sets for its own platform operation. This matrix supports the downstream risk-to-control mapping once an organization's objectives exist.

detail

HDS holds its own service objectives (confidentiality, integrity, availability targets for the operated platform) as documented operator artefacts that anchor its risk assessment. A partner cannot inherit these — it specifies its own objectives — but can use this matrix to map identified risks onto the platform controls that address them.

🔒 soc2/policies/system-description available on request

Implementer

service-organization documented

Specify and document your own service objectives with enough clarity to drive your risk assessment.

user-entity out-of-scope

subservice-organization documented

Specify your own objectives for the service you operate downstream.

`CC3.2` CC3.2 — Identification and analysis of risk draft

The entity identifies risks to the achievement of its objectives across the entity and analyzes them as a basis for deciding how they should be managed.

Pryv platform facilitated

Your risk-assessment methodology and the specific findings are yours. Pryv contributes the inventory of technical controls (this matrix, particularly the CC6 access + CC6.6/6.7 boundary + cryptography rows) — when you identify a confidentiality / integrity / availability risk, the matrix surfaces which Pryv primitive addresses it, so control applicability is mechanical rather than judgemental.

HDS documented USCH

A formal risk assessment is each organization's own methodology and findings. HDS is honest that its own formal risk assessment is not yet conducted — a known gap being matured. What HDS contributes is the inventory of technical controls (this matrix, especially the CC6 access and CC6.6/6.7 boundary and cryptography rows), so when a confidentiality, integrity or availability risk is identified, the control that addresses it is mechanical to locate.

detail

HDS treats its own risk assessment as an operator obligation in progress and states the gap plainly rather than claiming a completed assessment. Its contribution to a partner's risk assessment is the control inventory in this matrix plus the audit and monitoring substrate that surfaces emerging risk signals. The risk-assessment methodology and the specific findings are each attesting organization's own.

🔒 soc2/procedures/risk-assessment available on request

Implementer

service-organization documented

Conduct and document your own risk assessment; use this matrix to map identified risks onto the platform controls that mitigate them.

user-entity out-of-scope

subservice-organization documented

Conduct your own risk assessment for the service you operate downstream.

`CC3.3` CC3.3 — Consideration of the potential for fraud draft

The entity considers the potential for fraud when assessing risks to the achievement of its objectives.

Pryv platform facilitated

Pryv's audit log + observability metrics are the detection substrate for insider-misuse and anomalous-access fraud scenarios (every access is attributable; unusual read/write patterns surface). The fraud-risk analysis itself — which scenarios matter, what thresholds trigger review — is your assessment.

HDS facilitated USCH

The audit log and operational monitoring are the detection substrate for insider-misuse and anomalous-access fraud scenarios — every access is attributable, and unusual read or write patterns surface. HDS operates this substrate; the fraud-risk analysis itself (which scenarios matter, what thresholds trigger review) is each organization's assessment.

detail

HDS contributes the technical means to detect the fraud scenarios an assessment identifies: attributable audit records and anomaly signals from monitoring. The analytical step — deciding which fraud risks are in scope and how to respond — is governance and depends on the formal risk assessment (see CC3.2, a known gap on the HDS side). A partner runs its own fraud-risk analysis over the same substrate.

🔒 hipaa/policies/audit-controls available on request
🔒 soc2/procedures/risk-assessment available on request

Implementer

service-organization documented

Analyze fraud risk as part of your risk assessment; use the audit log and monitoring as the detection substrate for the scenarios you identify.

user-entity out-of-scope

subservice-organization documented

Consider fraud risk for the service you operate downstream.

`CC3.4` CC3.4 — Identification and assessment of changes affecting internal control draft

The entity identifies and assesses changes that could significantly affect its system of internal control.

Pryv platform facilitated

For changes to the Pryv platform, open-pryv.io's CHANGELOGs + tagged releases announce what changed; the audit log shows when config-driven behaviour changed observably in your deployment. The change-impact assessment process is yours.

HDS facilitated USCH

For changes to the platform substrate, the public release notes announce what changed, and the audit log shows when config-driven behaviour changed observably in a deployment. HDS assesses substrate changes as part of its own operations. The change-impact assessment process for an organization's wider control system is its own.

detail

Change identification on the platform half is supported by published change notes and the audit log's record of observable behaviour change. HDS folds these into its own change handling. A partner uses the same signals to feed its change-impact assessment over its broader control system, which it authors itself. HDS's own formalised change-management programme is still being matured (see CC8.1).

🔒 hipaa/policies/audit-controls available on request
🔒 soc2/policies/change-management available on request

Implementer

service-organization documented

Identify and assess changes affecting your control system; use platform release notes and the audit log as inputs.

user-entity out-of-scope

subservice-organization documented

Assess control-affecting changes in the service you operate downstream.

`CC4.1` CC4.1 — Ongoing and separate evaluations draft

The entity selects, develops, and performs ongoing and/or separate evaluations to ascertain whether the components of internal control are present and functioning.

Pryv platform facilitated

Pryv supplies the data an ongoing evaluation samples: the audit log evidences control-effectiveness (e.g., that access scoping actually blocks out-of-scope reads), observability evidences operational health. You define the evaluation cadence and the sampling method.

HDS facilitated USCH

The platform supplies the data an ongoing evaluation samples: the audit log evidences control effectiveness (e.g. that access scoping actually blocks out-of-scope reads), and operational monitoring evidences operational health. HDS runs its own periodic evaluation over the platform and documents it. The evaluation cadence and sampling method for an organization's own controls are its own.

detail

HDS performs a periodic evaluation of its security programme drawing on audit samples, monitoring data and this matrix as the control inventory, and documents the cadence and findings. A partner consumes the same substrate to sample its own controls and defines its own evaluation programme. This matrix doubles as the control inventory an evaluation assesses against.

🔒 hipaa/procedures/periodic-evaluation available on request
🔒 soc2/procedures/control-monitoring available on request

Implementer

service-organization documented

Define and run your own ongoing and separate evaluations of internal control, sampling the audit and monitoring substrate HDS exposes.

user-entity out-of-scope

subservice-organization documented

Evaluate the controls of the service you operate downstream.

`CC4.2` CC4.2 — Evaluation and communication of deficiencies draft

The entity evaluates and communicates internal-control deficiencies in a timely manner to the parties responsible for taking corrective action.

Pryv platform facilitated

Pryv-side deficiency signals (audit anomalies, observability alerts) feed your deficiency-tracking process. CAPA-style records can themselves ride on Pryv events on a dedicated stream. The evaluation + communication workflow is your procedure.

HDS facilitated USCH

Deficiency signals from the platform side — audit anomalies, monitoring alerts — feed a deficiency-tracking process. HDS operates its own deficiency-evaluation and corrective-action flow and documents it; corrective records can themselves ride on the platform as events on a dedicated stream. The evaluation and communication workflow is each organization's procedure.

detail

HDS runs a documented process for evaluating and communicating deficiencies it observes in its own operation, fed by audit and monitoring signals and tied to its incident and periodic-evaluation procedures. A partner authors its own deficiency workflow over the same substrate. The platform can host the corrective-action records themselves as attributable events.

🔒 hipaa/procedures/periodic-evaluation available on request
🔒 soc2/procedures/control-monitoring available on request

Implementer

service-organization documented

Define how you evaluate, track and communicate control deficiencies and their corrective actions.

user-entity out-of-scope

subservice-organization documented

Operate your own deficiency-tracking and communication process downstream.

`CC5.1` CC5.1 — Selection and development of control activities draft

The entity selects and develops control activities that contribute to mitigating risks to the achievement of objectives to acceptable levels.

Pryv platform facilitated

Several of your control activities ARE Pryv primitives: permission-scoped access tokens (purpose limitation), system streams (privileged-data isolation), encryption of operator secrets at rest. You select which to deploy against which risk; Pryv provides the activities ready-made rather than as something you build.

HDS facilitated USCH

Several control activities are platform primitives HDS operates ready-made: permission-scoped access tokens (purpose limitation), system-level isolation of privileged data, and encryption of operator secrets at rest. An organization selects which to deploy against which risk; HDS provides the activities as shipped controls rather than something to build, and documents the configuration it runs.

detail

The control-activity selection step is governance, but a meaningful subset of the activities themselves are platform-native: least-privilege access grants, privileged-namespace isolation, and at-rest encryption of operator secrets. HDS operates these and documents its access-control configuration. A partner selects and operates the activities appropriate to its risk assessment over the same primitives.

🔒 hipaa/policies/access-control available on request
🔒 soc2/procedures/control-monitoring available on request

Implementer

service-organization documented

Select the control activities appropriate to your risks; deploy the platform primitives (scoped access, isolation, secret encryption) that implement them.

user-entity out-of-scope

subservice-organization documented

Select and operate control activities for the service you run downstream.

`CC5.2` CC5.2 — General control activities over technology draft

The entity selects and develops general control activities over technology to support the achievement of its objectives.

Pryv platform facilitated

The technology general controls SOC 2 examines — logical access, authentication, encryption in transit + at rest for secrets, audit logging, secure inter-core transport — are shipped Pryv primitives, enforced at the API surface rather than left to your configuration discipline. The CC6 + CC7 rows below detail each. Your role is selecting and operating them.

HDS implemented USCH

The technology general controls SOC 2 examines — logical access, authentication, encryption in transit, audit logging, secure inter-core transport — are shipped platform controls HDS operates, enforced at the API surface rather than left to configuration discipline. The CC6 and CC7 rows detail each. An organization's role is selecting and operating them; the mechanisms are in place.

detail

General IT controls are where the platform contribution is strongest: access control and authentication are enforced on every request, transmission is TLS by default, the audit log is always-on, and inter-core transport is mutually authenticated. HDS operates this stack across both data-residency options. At-rest encryption of bulk event data is the one general control not yet shipped (see CC6.7) and is noted honestly. A partner selects, configures and operates these controls; it does not build them.

🔒 hipaa/policies/access-control available on request
🔒 hipaa/policies/audit-controls available on request
🔒 hipaa/policies/transmission-security available on request

Implementer

service-organization documented

Select, configure and operate the platform general IT controls; document the configuration and assess the at-rest encryption gap in your risk analysis.

user-entity out-of-scope

subservice-organization documented

Operate equivalent general IT controls for the service you run downstream.

`CC5.3` CC5.3 — Deployment of control activities through policies and procedures draft

The entity deploys control activities through policies that establish what is expected and procedures that put those policies into action.

Pryv platform out-of-scope

Policy + procedure authoring is your editorial work. Pryv enforces what the policies decide (access rules, encryption), but the policy text and the operating procedures are yours.

HDS documented USCH

Policy and procedure authoring is editorial governance work. HDS maintains its own information-security policy set and the operating procedures that put it into action over the platform; the platform enforces what the policies decide (access rules, encryption in transit), but the policy text and procedures are an organization's own.

detail

HDS's documented policies and procedures are referenced throughout this matrix as the administrative backing for the technical controls, and they are reviewed periodically. The platform enforces the decisions those policies make but does not author them. A partner attesting under SOC 2 keeps its own policy and procedure set; it cannot inherit HDS's, though it can cite HDS's programme where HDS operates the underlying system.

🔒 hipaa/policies/information-security-policy available on request
🔒 soc2/procedures/control-monitoring available on request

Implementer

service-organization documented

Author and maintain your own policies and operating procedures that deploy your selected control activities.

user-entity out-of-scope

subservice-organization documented

Maintain your own policies and procedures for the service you run downstream.

`CC6.1` CC6.1 — Logical access security over protected information assets draft

The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events.

Pryv platform implemented

Logical access is enforced by Pryv at the API surface: every read/write is checked against the access's per-stream + level permissions, token-based authentication is the default, and MFA is available via the mfa.* methods when you enable it. System streams isolate privileged data (credentials, MFA state). No plaintext transport path ships. You define who gets which access; Pryv enforces it.

HDS implemented USCH

Logical access is enforced by the HDS-operated platform at the API surface: every read or write is checked against the access's per-stream and per-level permissions, token-based authentication is the default, multi-factor authentication is available, and privileged data is held on a separately controlled namespace. No plaintext transport path is served. An organization defines who gets which access; HDS operates the enforcement.

detail

Logical access security is a technical property of the API boundary, not a downstream policy layer. Each request must present a valid access token whose per-stream, per-level permissions are checked before any data is touched; credentials and privileged state live on a separately controlled namespace; MFA strengthens the login where configured. HDS operates this stack across both data-residency options and documents its access-control and authentication policy. The implementer configures which grants its application mints.

🔒 hipaa/policies/access-control available on request
🔒 hipaa/policies/authentication available on request

Implementer

service-organization documented

Configure least-privilege per-stream access grants for your application and document your access-authorization rules; decide whether to require MFA.

user-entity out-of-scope

subservice-organization documented

Apply the same logical-access controls to the service you run downstream.

`CC6.2` CC6.2 — Registration, credential issuance, and de-provisioning draft

Before issuing credentials and granting access, the entity registers and authorizes new users; credentials are removed when access is no longer authorized.

Pryv platform implemented

The full credential lifecycle is Pryv primitives: registration mints an account; accesses.create issues a scoped credential; accesses.update modifies scope (writing the prior version to history); accesses.delete revokes; system.users.delete removes the account entirely. Each stage lands in the audit log. The authorization decision (who may register, what scope is appropriate) is your policy; the mechanism is shipped.

HDS implemented USCH

The full credential lifecycle is platform-native and HDS-operated: registration mints an account, a scoped access token issues a credential, updating an access modifies its scope (writing the prior version to history), and revocation or account deletion removes it. Each stage lands in the audit log. The authorization decision (who may register, what scope is appropriate) is an organization's policy; the mechanism is shipped.

detail

Registration, issuance, modification and de-provisioning are all first-class operations: an access token is the credential, its scope is adjustable with full version history, and revocation takes effect immediately. Account deletion removes the identity entirely. Every step is audited. HDS operates this lifecycle and documents the access-authorization and termination procedures it follows for its own workforce; the implementer applies the same primitives to its users.

🔒 hipaa/policies/access-authorization available on request
🔒 hipaa/procedures/access-termination available on request

Implementer

service-organization documented

Document who may register and authorize users and at what scope, and tie de-provisioning to immediate access revocation.

user-entity out-of-scope

subservice-organization documented

Operate the same registration and de-provisioning lifecycle downstream.

`CC6.3` CC6.3 — Role-based access, least privilege, and segregation of duties draft

The entity authorizes, modifies, and removes access based on roles and the system design, applying least privilege and segregation of duties.

Pryv platform implemented

Least privilege is native: an access carries only the stream+level tuples it needs (none / create-only / read / contribute / manage), so a credential cannot touch out-of-scope data. Segregation of duties is expressed by issuing distinct narrow accesses per role, with system streams isolating privileged functions. accesses.update / .delete cover modify + remove; access version history is the review-evidence layer. Role definitions live in your IdP / policy; Pryv records and enforces the resulting access state.

HDS implemented USCH

Least privilege is native to the HDS-operated platform: an access carries only the per-stream, per-level permissions it needs, so a credential cannot touch out-of-scope data. Segregation of duties is expressed by issuing distinct narrow accesses per role, with privileged functions isolated on a separate namespace. Modification and removal are audited operations with version history as the review-evidence layer.

detail

The permission model makes least privilege the default rather than an aim: each access lists exactly the streams and levels it may exercise. Distinct roles map to distinct narrow accesses, giving segregation of duties; privileged namespaces isolate sensitive functions. Access updates and revocations are audited and version-history-tracked. Role definitions live in an organization's identity system or policy; HDS records and enforces the resulting access state and documents its own access-review cadence.

🔒 hipaa/policies/access-control available on request
🔒 hipaa/procedures/access-review available on request

Implementer

service-organization documented

Define your role model and least-privilege scopes, map them onto access grants, and run a periodic access review over the version history.

user-entity out-of-scope

subservice-organization documented

Apply role-based least-privilege access and segregation of duties downstream.

`CC6.4` CC6.4 — Physical access to facilities and protected assets draft

The entity restricts physical access to facilities and protected information assets to authorized personnel.

Pryv platform out-of-scope

Physical access control (data-center entry, badge systems, media vaults) is facility scope, outside Pryv's software boundary. Your hosting provider carries this — an HDS- or ISO 27001-certified hoster typically inherits it from the underlying CSP and provides the attestation you reference.

HDS facilitated USCH

Physical access control (data-centre entry, media handling) is facility scope, outside the platform software boundary. HDS carries this layer by selecting certified hosting providers for each region (EU/Switzerland and US data-residency options) and holding their facility-control attestations on file, so an organization inherits a vetted physical posture for the server tier rather than sourcing it itself.

detail

HDS does not operate its own data centres; it deploys the platform onto certified infrastructure whose physical access controls are independently attested, and records which attestation backs each region in its hosting-provider register. The server-tier physical-access obligation is satisfied by inheritance; an organization's own facilities (offices where workforce access the service) remain its responsibility.

🔒 hipaa/registers/hosting-provider-attestations available on request

Implementer

service-organization documented

Inherit the server-tier facility controls from the HDS hosting region and reference the attestation; control and document physical access to your own premises.

user-entity out-of-scope

subservice-organization documented

Document the physical controls for any facilities you operate downstream.

`CC6.5` CC6.5 — Protections over data and software on disposed assets draft

The entity removes logical and physical protections over physical assets only after the ability to read or recover the data and software from them has been diminished and is no longer required.

Pryv platform configurable

Logical destruction is per-user: system.users.delete removes the user's data from the live store; event- and stream-level deletion cover per-record needs. Whether destruction extends to backups is engine-dependent — SQLite stores one file per user (unlink = gone), PostgreSQL deletes rows but historical pg_dump artefacts retain them until rotated. Choose the engine that matches your destruction policy; physical media sanitisation is your hosting procedure.

HDS configurable USCH

Logical destruction is per-user on the HDS-operated platform: account deletion removes a user's data from the live store, and event- and stream-level deletion cover per-record needs. Whether destruction extends to backups is storage-engine-dependent, so the engine is chosen to match the destruction policy. Physical media sanitisation at the server tier is the certified hosting provider's procedure.

detail

Per-user erasure gives a clean logical-destruction path; backup reach depends on the configured storage engine (a per-user file model unlinks cleanly, a shared relational store retains rows in historical dump artefacts until rotated). HDS documents the engine posture it operates and relies on the hosting provider's attested media-sanitisation for physical disposal. An organization selects the engine matching its disposal commitment.

🔒 hipaa/registers/hosting-provider-attestations available on request

Implementer

service-organization configurable

Choose the storage engine that matches your destruction policy and document how backup-resident copies are aged out.

user-entity out-of-scope

subservice-organization configurable

Make the same engine and sanitisation choices for the service you run downstream.

`CC6.6` CC6.6 — Boundary protection against external threats draft

The entity implements logical access security measures to protect against threats originating outside its system boundaries.

Pryv platform implemented

The external boundary is the TLS-terminating HTTPS API: TLS 1.3 in transit with the built-in ACME integration (auto-renewal + cluster-replicated rotation), token-gated access on every request, no plaintext path. Inter-core traffic in a cluster runs over mTLS on a private CA, separating the control plane from the user-facing plane. Edge controls (WAF, firewall, rate limiting) sit in your reverse proxy by design — see context/rate-limiting-and-dos-protection.md.

HDS implemented USCH

The external boundary is the TLS-terminating HTTPS API HDS operates: TLS in transit with automated certificate renewal, token-gated access on every request, and no plaintext path. Inter-core traffic in a cluster runs over mutually authenticated transport, separating the control plane from the user-facing plane. Edge controls (WAF, firewall, rate limiting) sit in the operator's reverse proxy by design.

detail

Boundary protection is enforced technically: every request crosses a TLS boundary and presents a valid access token before reaching data, and cluster-internal transport is mutually authenticated on a private CA. HDS operates the certificate lifecycle and the edge controls (rate limiting, firewalling) at the reverse proxy in each region. An organization inherits this boundary and configures any additional edge policy its risk analysis requires.

🔒 hipaa/policies/transmission-security available on request
🔒 hipaa/policies/access-control available on request

Implementer

service-organization documented

Inherit the TLS and token boundary; configure and document any additional edge controls (WAF, rate limits) your risk analysis calls for.

user-entity out-of-scope

subservice-organization documented

Operate equivalent boundary protection for the service you run downstream.

`CC6.7` CC6.7 — Restriction and protection of information in transmission and movement draft

The entity restricts the transmission, movement, and removal of information to authorized users and processes, and protects it during transmission, movement, or removal.

Pryv platform implemented

Transmission is TLS 1.3 end-to-end (client ↔ core direct, no Pryv-shipped intermediary that could log or cache). Movement is restricted by the permission model — a credential only moves the data its scope permits. Operator secrets at rest use AES-256-GCM (HKDF-derived per-key); bootstrap bundles for core-to-core movement are AES-256-GCM (scrypt). Bulk event-data at-rest encryption is an operator-side storage-layer choice (LUKS / SSE-KMS / customer keys).

HDS implemented USCH

Transmission is protected by TLS end to end (client to core direct, with no HDS-shipped intermediary that could log or cache), and movement is restricted by the permission model — a credential only moves the data its scope permits. Operator secrets at rest and bootstrap bundles for core-to-core movement are encrypted with authenticated encryption. Bulk event-data at-rest encryption is an operator-side storage-layer choice and is not yet platform-provided.

detail

The transmission half is default-on TLS with no plaintext path; the movement half is bounded by the access permission model, so data only moves where a scope permits and there is no out-of-band dump path. Operator secrets and core-to-core bootstrap material use authenticated encryption at rest. HDS is honest that platform-managed at-rest encryption of bulk event data is not yet shipped — at-rest protection is applied at the infrastructure/storage layer in each region, and an organization assesses the residual gap in its risk analysis.

🔒 hipaa/policies/transmission-security available on request
🔒 hipaa/policies/encryption available on request
🔒 hipaa/risk/at-rest-encryption-gap available on request

Implementer

service-organization configurable

Rely on default-on TLS and the permission-bounded movement model; apply infrastructure at-rest encryption and assess the bulk-data at-rest gap in your risk analysis.

user-entity out-of-scope

subservice-organization configurable

Make the same transmission and at-rest choices for the service you run downstream.

`CC6.8` CC6.8 — Prevention and detection of unauthorized or malicious software draft

The entity implements controls to prevent, or detect and act upon, the introduction of unauthorized or malicious software.

Pryv platform facilitated

Anti-malware / endpoint protection is a host-and-network control, not shipped in Pryv. Pryv's contribution is detection-adjacent: server-side event-type validation rejects malformed payloads at ingest, the dependency-audit pipeline guards the software supply chain, and audit + observability surface anomalous behaviour. AV + application-allowlisting on the hosts is your operator scope.

HDS facilitated USCH

Anti-malware and endpoint protection are host-and-network controls, not platform features. HDS operates malware protection and patching at the hosting layer for the environments it runs, documented internally. The platform contributes detection-adjacent properties: server-side payload validation rejects malformed input at ingest, and the audit and monitoring substrate surfaces anomalous behaviour.

detail

HDS carries malware protection as operator-side infrastructure hardening for the environments it runs; the platform software itself ships no antivirus. Its indirect contribution is structural input validation at ingest and the anomaly signal from audit and monitoring. An organization protects its own endpoints and any infrastructure it operates outside HDS, and operates application-allowlisting on its hosts.

🔒 hipaa/policies/malware-protection available on request

Implementer

service-organization documented

Operate and document anti-malware and application-allowlisting on your own endpoints and any infrastructure you run outside HDS.

user-entity out-of-scope

subservice-organization documented

Operate equivalent malware controls for the infrastructure you run downstream.

`CC7.1` CC7.1 — Detection of configuration changes and vulnerabilities draft

The entity uses detection and monitoring procedures to identify configuration changes that introduce new vulnerabilities and susceptibility to newly discovered vulnerabilities.

Pryv platform facilitated

Pryv-side substrate-vulnerability detection today is partial + passive: committed package-lock, Dependabot alerts on open-pryv.io master, CHANGELOG announcements of relevant fixes, and a config-validation step that fails fast on malformed configuration at master start. Observability + audit surface runtime anomalies. Your own vulnerability-scanning cadence (when to upgrade, how to verify) sits on top.

HDS facilitated USCH

Substrate-vulnerability detection on the platform side is partial: a committed dependency lockfile, dependency alerts on the open-source codebase, published fix announcements, and a config-validation step that fails fast on malformed configuration at start. Operational monitoring and the audit log surface runtime anomalies. HDS operates this and layers its own patching cadence; an organization's own vulnerability-scanning cadence sits on top.

detail

The platform contributes passive detection (lockfile, dependency alerts, fail-fast config validation) plus the runtime anomaly signal from monitoring and audit. HDS operates a patching and update process over the platform and documents it. A partner defines its own vulnerability-scanning and configuration-drift detection cadence over the same substrate.

🔒 hipaa/policies/audit-controls available on request
🔒 soc2/procedures/control-monitoring available on request

Implementer

service-organization documented

Define your own vulnerability-scanning and configuration-drift detection cadence over the platform and your own infrastructure.

user-entity out-of-scope

subservice-organization documented

Operate equivalent vulnerability detection for the service you run downstream.

`CC7.2` CC7.2 — Monitoring for anomalies indicative of security events draft

The entity monitors system components for anomalies indicative of malicious acts, natural disasters, and errors, and analyzes them to determine whether they represent security events.

Pryv platform facilitated

The pluggable observability provider gives system-level anomaly signal (latency, error rate, request volume); the per-user audit log gives application-level activity, attributable to an access. Anomaly-detection logic on the audit stream itself is a natural extension you build; the raw signal is shipped.

HDS facilitated USCH

HDS's operational monitoring gives system-level anomaly signal (latency, error rate, request volume) across both data-residency options, wired end to end with alerting before any component is treated as in production; the per-user audit log gives application-level activity attributable to an access. HDS operates this monitoring; deciding which anomalies are security events is an organization's analysis.

detail

Two signal sources back anomaly monitoring: HDS's infrastructure monitoring and the audit log. HDS treats end-to-end alert wiring as a precondition for treating any component as in production, so silent failures are caught. The analytical step — classifying an anomaly as a security event — is governance and is each organization's own, fed by the raw signal HDS exposes and operates.

🔒 hipaa/policies/audit-controls available on request
🔒 hipaa/procedures/login-monitoring available on request

Implementer

service-organization documented

Define your anomaly thresholds and the analysis that classifies an anomaly as a security event, drawing on the monitoring and audit substrate.

user-entity out-of-scope

subservice-organization documented

Operate equivalent anomaly monitoring for the service you run downstream.

`CC7.3` CC7.3 — Evaluation of security events draft

The entity evaluates security events to determine whether they could result, or have resulted, in a failure to meet its objectives, and takes action.

Pryv platform facilitated

Event-vs-incident classification is your decision. Pryv supplies the evaluation inputs — audit row patterns, observability anomalies — but the categorisation rule and the response trigger are your policy.

HDS facilitated USCH

Event-versus-incident classification is each organization's decision. The platform and HDS monitoring supply the evaluation inputs — audit-row patterns and monitoring anomalies — but the categorisation rule and the response trigger are policy. HDS operates its own event-evaluation step as part of its incident-response procedure and documents it.

detail

HDS evaluates the security events it observes in its own operation using audit and monitoring inputs, against the criteria in its incident-response procedure. A partner authors its own classification rule and response triggers over the same inputs. The substrate is operated; the judgement is governance.

🔒 hipaa/procedures/security-incident-response available on request

Implementer

service-organization documented

Define how you classify a security event as an incident and what response it triggers.

user-entity out-of-scope

subservice-organization documented

Operate your own event-evaluation step for the service you run downstream.

`CC7.4` CC7.4 — Incident response program draft

The entity responds to identified security incidents through a defined program to understand, contain, remediate, and communicate them.

Pryv platform facilitated

Pryv contributes the technical halves of incident response: detection + scoping (audit + observability) and containment (accesses.delete revokes a compromised credential immediately). The incident-response program itself — roles, escalation, communications, lessons-learned — is yours to define and rehearse.

HDS facilitated USCH

The platform contributes the technical halves of incident response: detection and scoping (audit log plus monitoring) and containment (immediate revocation of a compromised access). HDS runs its own incident-response programme as operator — roles, escalation, communications — and documents it; that programme feeds the notification obligations a partner carries. The partner defines and rehearses its own programme.

detail

HDS operates an incident-response procedure: detection draws on audit and monitoring, containment uses immediate access revocation or scope reduction, and a documented flow governs escalation and communication. The procedure is held internally and shared on request, and feeds breach-notification timing a partner must honour. A partner authors and rehearses its own incident-response programme over the same technical substrate.

🔒 hipaa/procedures/security-incident-response available on request
🔒 hipaa/procedures/incident-mitigation available on request

Implementer

service-organization documented

Define and rehearse your own incident-response programme — roles, escalation, containment, communication, lessons learned — over the platform detection and containment primitives.

user-entity out-of-scope

subservice-organization documented

Run your own incident-response programme and notify your upstream service organization of incidents affecting their data.

`CC7.5` CC7.5 — Recovery from identified security incidents draft

The entity identifies, develops, and implements activities to recover from identified security incidents.

Pryv platform facilitated

Recovery primitives: bin/backup.js + --restore rebuild a user from backup; a multi-core cluster gives in-line Raft replication + cluster-replicated TLS certs so a surviving core keeps serving when a peer fails. The recovery-objective targets (RTO / RPO) and the drill cadence are your policy.

HDS facilitated USCH

Recovery primitives ship and HDS operates them: per-user backup and restore rebuild a subject from backup, and a replicated multi-core topology with cluster-replicated certificates keeps a surviving core serving when a peer fails. HDS documents the recovery objectives and runbook it operates; the recovery-objective targets and drill cadence for an organization's own service are its own.

detail

Recovery rests on two layers HDS operates: cold restore from per-user backups as the canonical path, and live replication across cores so a single-region failure does not lose live data. HDS documents the recovery objectives it targets; verified, regularly tested recovery drilling is being matured (see CC4.1 evaluation). A partner sets its own recovery-objective targets and drill cadence over the same primitives.

🔒 hipaa/procedures/disaster-recovery-plan available on request
🔒 hipaa/procedures/incident-mitigation available on request

Implementer

service-organization documented

Set your recovery-objective targets and drill cadence, and document the recovery runbook over the platform backup and replication primitives.

user-entity out-of-scope

subservice-organization documented

Operate your own recovery activities for the service you run downstream.

`CC8.1` CC8.1 — Authorized changes to infrastructure, data, software, and procedures draft

The entity authorizes, designs, develops or acquires, configures, documents, tests, approves, and implements changes to infrastructure, data, software, and procedures.

Pryv platform facilitated

Pryv-side change evidence: tagged releases, SHA-pinned Docker images, CHANGELOG-v2 + CHANGELOG-v2-back per release, an engine-agnostic forward-only schema-migration framework (bin/migrate.js, with autoRunOnStart), and a public CI test matrix (PostgreSQL + SQLite). Separate dev / test / prod environments are supported via independent core deployments. The audit log records config-driven behaviour changes in your deployment. Your change-approval workflow (windows, sign-off, rollback) sits on top.

HDS documented USCH

Platform-side change evidence is strong: tagged releases, SHA-pinned images, per-release change notes, a forward-only schema-migration framework, and a public CI test matrix; separate environments are supported via independent deployments, and the audit log records config-driven behaviour change. HDS is honest, though, that its own formalised change-management programme (windows, sign-off, rollback) is still being matured — a known gap.

detail

The substrate supplies the raw change artefacts an auditor samples. What is not yet fully formalised is HDS's own change-approval workflow as a documented, verified programme — HDS states this gap plainly rather than claiming an implemented change-management control. HDS documents its current change handling and is maturing it. A partner authors its own change-management programme over the platform's change-evidence substrate.

🔒 hipaa/policies/audit-controls available on request
🔒 soc2/policies/change-management available on request

Implementer

service-organization documented

Author and document your own change-management workflow — authorization, testing, approval, rollback — using the platform change-evidence artefacts.

user-entity out-of-scope

subservice-organization documented

Operate your own change-management programme for the service you run downstream.

`CC9.1` CC9.1 — Risk mitigation for business disruptions draft

The entity identifies, selects, and develops risk-mitigation activities for risks arising from potential business disruptions.

Pryv platform facilitated

Disruption-mitigation inheritance: multi-core HA + Raft replication, backup-restore, cluster-replicated TLS certificates, and a clean cloud-exit path (re-issue the cluster onto new infrastructure from a bootstrap bundle). The business-continuity objectives and the insurance / contractual mitigation choices are yours.

HDS facilitated USCH

Disruption-mitigation primitives are inherited and HDS-operated: multi-core high availability with replication, per-user backup and restore, cluster-replicated certificates, and a clean cloud-exit path (re-issue the cluster onto new infrastructure from a bootstrap bundle). HDS documents the continuity posture it operates; the business-continuity objectives and any insurance or contractual mitigation choices are an organization's own.

detail

HDS operates the technical continuity substrate — HA replication, backup and restore, replicated TLS certificates, portable cluster re-issue — across both data-residency options and documents it. The non-technical mitigation choices (continuity objectives, insurance, contractual risk transfer) are governance and belong to each attesting organization. HDS's own formal risk assessment that would prioritise these mitigations is a known gap (see CC3.2).

🔒 hipaa/procedures/disaster-recovery-plan available on request
🔒 hipaa/procedures/data-backup-plan available on request

Implementer

service-organization documented

Set your business-continuity objectives and choose your non-technical mitigations over the platform HA and backup substrate HDS operates.

user-entity out-of-scope

subservice-organization documented

Operate equivalent disruption mitigation for the service you run downstream.

`CC9.2` CC9.2 — Vendor and business-partner risk management draft

The entity assesses and manages risks associated with its vendors and business partners.

Pryv platform facilitated

Where Pryv is your vendor (open-pryv.io as a third-party, BSD-licensed platform), the public release process + CHANGELOGs + this compliance matrix are the vendor-monitoring artefact set you reference. Your broader vendor-risk programme (assessment criteria, SLA reviews, subprocessor inventory) sits on top.

HDS documented USCH

Where the platform is an organization's vendor, the public release process, change notes and this compliance matrix are the vendor-monitoring artefact set it references. HDS maintains a subprocessor register for its own downstream vendors. HDS is honest that a formalised vendor-management programme (assessment criteria, SLA reviews) is still being matured — a known gap.

detail

HDS's contribution has two parts. As a vendor it exposes a transparent release process and this matrix for monitoring. As an operator it holds a subprocessor register listing its own downstream vendors, available to partners for their due diligence. HDS states plainly that its full vendor-risk programme — assessment criteria, periodic reassessment, SLA review — is not yet formalised. A partner runs its own vendor-risk programme, treating HDS as one assessed vendor.

🔒 hipaa/registers/subprocessor-register available on request
🔒 soc2/policies/vendor-management available on request

Implementer

service-organization documented 📄 subprocessor

Run your own vendor-risk programme; assess HDS as a vendor using its release process, this matrix and its subprocessor register.

user-entity out-of-scope

subservice-organization documented 📄 subcontractor

Manage the risk of your own downstream vendors and flow obligations through to them.

`A1.1` A1.1 — Capacity management draft

The entity maintains, monitors, and evaluates current processing capacity and use of system components to manage capacity demand and to enable additional capacity in support of its objectives.

Pryv platform facilitated

Capacity signal comes from per-core observability metrics (memory, CPU, latency, request volume); capacity grows by adding cores to the cluster (each serves its bound users behind the shared rqlite control plane). The capacity-planning cadence and provisioning automation are yours.

HDS facilitated USCH

HDS runs the platform on a topology that scales horizontally (cores added to a cluster), and operates infrastructure-level monitoring of memory, CPU, latency and request volume across both the US and Switzerland data-residency options. The capacity-planning cadence — thresholds, provisioning triggers — is an operator procedure HDS documents; the user-entity inherits the headroom rather than sizing it.

detail

Capacity signal comes from the platform's observability metrics plus HDS's own infrastructure telemetry. HDS evaluates utilisation against headroom on a defined cadence and adds capacity by extending the cluster. The written capacity-management procedure HDS operates is held internally and shared on request; a user-entity running its own deployment performs its own capacity planning.

🔒 soc2/procedures/capacity-management available on request

Implementer

service-organization documented

Define and document your own capacity-planning thresholds and the provisioning workflow if you operate your own deployment; otherwise rely on the HDS-operated capacity posture and reference it.

user-entity out-of-scope

subservice-organization documented

Where a hosting subservice carries the underlying compute, its capacity commitments back this control; record the reliance.

`A1.2` A1.2 — Environmental protections, backup, and recovery infrastructure draft

The entity authorizes, designs, implements, operates, maintains, and monitors environmental protections, software, data back-up processes, and recovery infrastructure to meet its objectives.

Pryv platform facilitated

Backup + recovery infrastructure ships: bin/backup.js produces per-user backups, multi-core topology gives in-line Raft replication, TLS certs replicate across the cluster so a surviving core stays user-facing. Environmental protections (power, cooling, fire suppression) are facility-side — your hoster's certification covers them. Backup cadence, retention, and offsite policy are yours.

HDS facilitated USCH

The platform ships per-user backup and restore and a replicated multi-core topology, and HDS operates these on a schedule with cluster-replicated TLS so a surviving core stays user-facing. Environmental protections (power, cooling, fire suppression) are inherited from the certified hosting provider per region. Automated, regularly verified backups are still being formalised, so this is facilitated rather than fully implemented.

detail

HDS runs the backup primitive on a schedule, relies on multi-core replication for hot redundancy, and documents the recovery infrastructure it operates. Environmental controls at the facility tier are covered by the hosting provider's attestation, which HDS records. Verified, automatically tested backups are a known gap being matured; the backup-and-recovery plan as it stands is cited as an internal document. A user-entity running its own deployment defines its own schedule.

🔒 hipaa/procedures/data-backup-plan available on request
🔒 hipaa/procedures/disaster-recovery-plan available on request

Implementer

service-organization documented

Document your backup schedule, retention and offsite policy, and confirm restorability; if you operate your own deployment, run the backup and replication primitives yourself.

user-entity out-of-scope

subservice-organization documented

The hosting subservice carries environmental protections at the facility tier; obtain and retain its attestation.

`A1.3` A1.3 — Recovery plan testing draft

The entity tests recovery plan procedures supporting system recovery to meet its objectives.

Pryv platform facilitated

Pryv gives you a testable recovery path (restore a user from a backup file into a clean core; fail a core and confirm a peer keeps serving). The recovery drill — scheduling it, evidencing the result, feeding gaps back into the plan — is your operating procedure.

HDS facilitated USCH

The platform provides a testable recovery path (restore a user from a backup into a clean core; fail a core and confirm a peer keeps serving), and HDS documents the intended recovery-test cadence. Regular, verified execution of the drill is a known gap being matured, so HDS facilitates this rather than evidencing a fully operated test programme.

detail

Restore and failover are exercisable against the platform primitives. HDS documents the recovery-test procedure it intends to run and feeds gaps back into the plan; scheduled, verified drills with retained evidence are being formalised and are stated plainly as a gap. A user-entity runs and evidences its own recovery tests for its workload.

🔒 hipaa/procedures/contingency-plan-testing available on request

Implementer

service-organization documented

Schedule, run and document recovery-plan tests for the parts of the system you operate, and revise the plan from the results.

user-entity out-of-scope

subservice-organization out-of-scope

`C1.1` C1.1 — Identification and maintenance of confidential information draft

The entity identifies and maintains confidential information to meet its objectives related to confidentiality.

Pryv platform facilitated

Pryv lets you identify + isolate confidential data by stream layout: dedicate subtrees per confidentiality tier and gate each with a distinct permission scope, so confidential streams are reachable only by credentials granted them. System streams add a privileged tier independent of your scheme; clientData / event type can carry machine-readable classification labels. Masking is by projection (stream + permissions), not value transformation — see context/data-masking-projection-vs-transformation.md.

HDS implemented USCH

Confidential data is identified and isolated structurally on the HDS-operated platform: subject data is per-user isolated, and confidential streams are reachable only by access tokens granted the matching per-stream permission, with privileged namespaces (credentials) separately controlled. HDS operates this access-controlled isolation and documents its confidentiality and access-control posture.

detail

Identification and maintenance of confidential information is enforced by stream layout plus the permission model rather than left to downstream policy: a credential can reach only the confidential streams it was granted, at the level granted, on every API call. HDS operates this stack and documents the access-control and minimum-necessary policies behind it. The user-entity decides which streams carry which confidentiality tier and which grants its application mints.

🔒 hipaa/policies/access-control available on request
🔒 hipaa/policies/minimum-necessary available on request

Implementer

service-organization documented

Classify your confidential data, map it to a stream layout, and grant least-privilege per-stream access; document the classification scheme.

user-entity out-of-scope

subservice-organization out-of-scope

`C1.2` C1.2 — Disposal of confidential information draft

The entity disposes of confidential information to meet its objectives related to confidentiality.

Pryv platform configurable

Confidential-data disposal uses the same per-user erasure path as CC6.5: system.users.delete for whole-account, event/stream deletion for per-record. Backup reach is engine-dependent (SQLite per-user file vs PostgreSQL row + pg_dump rotation) — pick the engine that matches your disposal commitment.

HDS facilitated USCH

The platform provides per-user erasure (whole-account deletion, plus event- and stream-level deletion) from the live store, which HDS operates. Whether disposal reaches backups is storage-engine-dependent, and formal, scheduled data-disposal automation is not yet shipped — so HDS facilitates this and documents the boundary rather than claiming full disposal.

detail

Logical destruction in the live store is concrete: account deletion removes a user's data, and event/stream deletion covers per-record needs. Backup reach depends on the configured engine, and a documented retention-and- disposal schedule with verified backup pruning is a known gap being matured. HDS documents the disposal path and its limits; the user-entity chooses the engine that matches its disposal commitment and applies media sanitisation at the hosting tier.

🔒 hipaa/policies/minimum-necessary available on request
🔒 soc2/procedures/data-retention-and-disposal available on request

Implementer

service-organization documented

Define your disposal schedule and triggers, choose a storage engine whose backup behaviour matches it, and document the procedure.

user-entity out-of-scope

subservice-organization documented

The hosting subservice carries physical media sanitisation; obtain and record its attestation.

`PI1.1` PI1.1 — Quality information about processing objectives draft

The entity obtains or generates, uses, and communicates relevant, quality information regarding the objectives related to processing, including definitions of data processed and service specifications.

Pryv platform facilitated

The canonical event-type schemas (class/format JSON Schemas in the data-types repo) are the machine-readable definition of "data processed" — what each event type means and what shape it takes. You extend the catalogue with your own types via the service.eventTypes URL. The processing-objective specifications themselves are your product definitions.

HDS facilitated USCH

The platform's canonical event-type schemas are the machine-readable definition of what data each processing path handles, and the HDS-operated deployment serves these consistently. Authoring the processing-objective specifications — what the service does with the data and to what end — is the service organization's product definition; HDS facilitates by supplying the data-definition substrate.

detail

Event-type schemas define the shape and meaning of data processed, and a deployment can extend the catalogue with custom types. HDS operates the deployment so these definitions are applied uniformly. The processing objectives and service specifications themselves remain the implementer's editorial work; HDS documents the data-quality posture it operates.

🔒 soc2/policies/data-quality available on request

Implementer

service-organization documented

Define and communicate your processing objectives and service specifications; declare the event types your application processes.

user-entity out-of-scope

subservice-organization out-of-scope

`PI1.2` PI1.2 — Completeness and accuracy of inputs draft

The entity implements controls over system inputs, including controls over completeness and accuracy, to result in services that meet its objectives.

Pryv platform facilitated

Input accuracy is enforced structurally at ingest: events.create and events.update run every payload through the event type's JSON Schema (ajv-draft-04) — unknown types and schema violations are rejected with HTTP 400, no silent truncation or downgrade. This is the structural-accuracy layer; semantic accuracy (is this the *right* blood-pressure reading) stays in your application. Tighten structural strictness by declaring min/max/pattern in a custom catalogue — see context/data-accuracy-structural-vs-semantic.md.

HDS facilitated USCH

Input accuracy is enforced structurally at ingest on the HDS-operated platform: every payload is validated against its event-type schema and schema violations are rejected outright, with no silent truncation. This is the structural-completeness-and-accuracy layer; semantic correctness of a value remains the service organization's application logic.

detail

Creates and updates run each payload through the event type's JSON Schema; unknown types and violations are rejected with an error rather than stored partially. HDS operates this validation by default and documents the data-quality and integrity posture. Tighter structural constraints (min/max/pattern) are available via a custom catalogue. Judging whether a structurally valid value is the right value stays with the implementer.

🔒 hipaa/policies/integrity available on request
🔒 soc2/policies/data-quality available on request

Implementer

service-organization documented

Define your event types and any tighter structural constraints, and own the semantic-validation logic your application applies on top.

user-entity out-of-scope

subservice-organization out-of-scope

`PI1.3` PI1.3 — Completeness and accuracy of processing draft

The entity implements controls over system processing to result in services that meet its objectives.

Pryv platform facilitated

Pryv's processing model is deterministic + attributable: events are immutable-when-written (history-only append for audit/consent/attestation), events.update snapshots prior state into version history, and every mutation is authorised by the permission model and recorded in the audit log. The business-logic processing your application performs on top is your control responsibility.

HDS facilitated USCH

The platform's processing model is deterministic and attributable: writes are authorised by the permission model, updates snapshot the prior state into version history, and every mutation is recorded in the per-user audit log. HDS operates this substrate so processing is traceable; the business-logic processing the application performs is the service organization's own control.

detail

Each mutation is gated by per-stream permissions and recorded with its acting access identity; version history preserves prior states so a processing step can be reconstructed and checked. HDS operates and documents this integrity substrate. The application-level processing the implementer builds on top — calculations, transformations, workflows — is its own completeness-and-accuracy responsibility.

🔒 hipaa/policies/integrity available on request

Implementer

service-organization documented

Implement and document completeness-and-accuracy controls over your own processing logic; rely on the platform substrate for traceability.

user-entity out-of-scope

subservice-organization out-of-scope

`PI1.4` PI1.4 — Completeness, accuracy, and timeliness of outputs draft

The entity implements controls to make available or deliver output completely, accurately, and timely in accordance with specifications to meet its objectives.

Pryv platform facilitated

Output delivery is deterministic: events.get / streams.get return canonical serialisations; the audit log carries an integrity checksum of the affected event when a method mutates one, so output can be tied back to a verified state. Webhooks notify subscribers of change (signal-only — the receiver fetches the authoritative state via authenticated GET, so the delivered output is always the current canonical value). Delivery SLAs to your end recipients are your specification.

HDS facilitated USCH

Output delivery from the HDS-operated platform is deterministic: reads return canonical serialisations of the current authoritative state, and change notifications signal subscribers to fetch that state over an authenticated channel rather than pushing a possibly-stale copy. Delivery SLAs to the implementer's own end recipients are the service organization's specification.

detail

Gets return the canonical value; webhooks notify of change as a signal only, so the receiver always retrieves the current authoritative output. HDS operates this delivery substrate. Defining output specifications and the timeliness commitments to downstream recipients, and verifying they are met, is the implementer's control.

🔒 soc2/policies/data-quality available on request

Implementer

service-organization documented

Define your output specifications and delivery SLAs and verify outputs meet them; the platform supplies the canonical-state delivery substrate.

user-entity out-of-scope

subservice-organization out-of-scope

`PI1.5` PI1.5 — Completeness and accuracy of stored information draft

The entity implements controls to store inputs, items in processing, and outputs completely, accurately, and timely in accordance with system specifications to meet its objectives.

Pryv platform facilitated

Storage integrity: event version history preserves prior states, the audit log can carry a per-event integrity checksum, and backup-restore provides a recoverable copy. Together these give an accuracy + completeness signal for stored data. Tamper-evidence on the audit log itself (hash chaining) is a future primitive — see the CC7.4 chain proposal.

HDS facilitated USCH

Storage integrity on the HDS-operated platform rests on event version history (prior states preserved), the per-user audit log (every change attributed), and operational backup-restore (a recoverable copy). Together these give an accuracy-and-completeness signal for stored data. HDS operates the substrate and the backup schedule; verified backups are a known gap.

detail

Stored data is protected against silent loss by versioning and by the audit trail of every mutation, and against destruction by the backup path HDS operates. Tamper-evidence on the audit log itself (hash chaining) is a future platform primitive, and automatically verified backups are being matured — both stated plainly. HDS documents the integrity posture; the implementer owns the surrounding storage-control procedure.

🔒 hipaa/policies/integrity available on request
🔒 hipaa/procedures/data-backup-plan available on request

Implementer

service-organization documented

Document your storage-integrity controls and retention, and assess the verified-backup gap in your own risk analysis.

user-entity out-of-scope

subservice-organization out-of-scope

`P1.1` P1.1 — Notice of privacy practices draft

The entity provides notice to data subjects about its privacy practices to meet its objectives related to privacy, and updates and communicates the notice in a timely manner when those practices change.

Pryv platform facilitated

Pryv gives you the surface to present notice: app-web-auth3 is the forkable consent / auth web page where notice text is shown at authorization time, and the durable access record (with clientData) can carry the notice version the subject saw. Authoring the notice content and keeping it current is your editorial obligation; Pryv carries it through the consent flow and records what was presented.

HDS facilitated USCH

The platform supplies the surface to present notice at authorization time — a forkable consent/auth web page — and the durable access record can carry the notice version the subject saw. HDS operates this surface; authoring the notice content and keeping it current is the service organization's editorial obligation.

detail

Notice text can be shown in the consent flow, and the granted access can record which notice version was presented, giving an evidentiary link between the subject and the practices disclosed. HDS operates the deployment that carries this. The privacy-notice content, its review cadence and its communication on change are the implementer's; HDS documents the consent- flow substrate it provides.

🔒 soc2/policies/privacy-notice available on request

Implementer

service-organization documented

Author your privacy notice, present it in the consent flow, and keep it current; record the version each subject was shown.

user-entity out-of-scope

subservice-organization out-of-scope

`P2.1` P2.1 — Choice and consent draft

The entity communicates choices regarding the collection, use, retention, disclosure, and disposal of personal information to data subjects and obtains consent, as required, to meet its objectives related to privacy.

Pryv platform implemented

The access IS the durable, versioned consent record: it carries the granted permissions (the scope the subject agreed to), and its clientData holds the consent text / purposes / lawful basis. CMC carries cross-account consent state transitions via typed consent/* events. app-web-auth3 is the choice-presentation UX, and the audit chain proves the consent state at any moment. You design the choices; Pryv records and enforces them.

HDS implemented USCH

On the HDS-operated platform the access token IS the durable, versioned consent record: it carries the permissions the subject agreed to, its metadata holds the consent text and lawful basis, and the audit trail proves the consent state at any moment. The subject's own credentials let them grant and revoke directly. HDS operates this user-centric consent substrate; the service organization designs the choices presented.

detail

Consent is enforced, not merely recorded: a grant authorises exactly the scope the subject chose and nothing more, and revocation takes effect immediately. The consent-presentation UX is the forkable consent web page, and cross-account consent transitions are captured as typed events. HDS operates and documents this stack as part of its access-control and consent posture. Designing the choice set is the implementer's product decision.

🔒 hipaa/policies/access-control available on request
🔒 soc2/policies/privacy-notice available on request

Implementer

service-organization documented

Design the choices you present and the consent text, and map each choice to the access scope it grants; the platform records and enforces it.

user-entity out-of-scope

subservice-organization out-of-scope

`P3.1` P3.1 — Collection consistent with objectives draft

Personal information is collected consistent with the entity's objectives related to privacy.

Pryv platform facilitated

Collection scope is bounded by the access's permissions — an app can only write to the streams + levels it was granted (e.g. create-only on a specific subtree), so collection cannot silently exceed the agreed purpose. Defining the purpose and the minimal stream set is your data-model design; the boundary is enforced.

HDS facilitated USCH

Collection scope is bounded technically by the access token's permissions on the HDS-operated platform: an application can only write to the streams and levels it was granted, so collection cannot silently exceed the agreed purpose. HDS operates this enforcement; defining the purpose and the minimal stream set is the service organization's data-model design.

detail

A create-only grant on a specific subtree means an app collects only into that subtree at that level — over-collection is structurally prevented rather than policed after the fact. HDS operates and documents this minimum-necessary posture. The implementer designs which streams and grants correspond to which collection purpose.

🔒 hipaa/policies/minimum-necessary available on request
🔒 hipaa/policies/access-control available on request

Implementer

service-organization documented

Define each collection purpose and the minimal stream set it needs, and grant only that scope; document the mapping.

user-entity out-of-scope

subservice-organization out-of-scope

`P3.2` P3.2 — Explicit consent for sensitive personal information draft

Explicit consent for the collection, use, retention, disclosure, and disposal of sensitive personal information is obtained from data subjects or other authorized persons, if required.

Pryv platform facilitated

Sensitive data can be isolated in dedicated streams gated by a distinct access whose clientData records the explicit-consent basis; consent/* events capture the state transition with a timestamp. The "explicit" UX (a separate, affirmative consent step) is yours to present; Pryv records it as a distinct, auditable grant rather than folding it into general consent.

HDS facilitated USCH

Sensitive data can be isolated in dedicated streams gated by a distinct access whose metadata records the explicit-consent basis, with the consent state transition captured as a timestamped, auditable event. HDS operates this isolation; presenting the separate, affirmative consent step is the service organization's UX obligation.

detail

The platform records explicit consent as a distinct, auditable grant rather than folding it into general consent, so a sensitive-data grant is separable in evidence. HDS operates and documents the access-control substrate. The "explicit" step — a separate affirmative action — is the implementer's to present; the platform records it discretely.

🔒 hipaa/policies/access-control available on request
🔒 soc2/policies/privacy-notice available on request

Implementer

service-organization documented

Present a separate affirmative consent step for sensitive data and gate that data behind a distinct access; document the explicit-consent flow.

user-entity out-of-scope

subservice-organization out-of-scope

`P4.1` P4.1 — Use limited to identified purposes draft

The entity limits the use of personal information to the purposes identified in its objectives related to privacy.

Pryv platform facilitated

Purpose limitation is the permission model's core job: a credential issued for purpose A (scoped to stream A) cannot read or write purpose-B data. The audit log evidences that uses stayed within scope. Mapping purposes to streams + accesses is your design; the enforcement is technical, not policy-on-paper.

HDS implemented USCH

Purpose limitation is the core job of the permission model HDS operates: a credential issued for one purpose, scoped to one set of streams, cannot read or write data for another purpose, and the audit log evidences that uses stayed within scope. Enforcement is technical, on every API call, not policy-on-paper. Mapping purposes to streams and accesses is the service organization's design.

detail

A purpose-A credential is mechanically incapable of touching purpose-B data, and every use is recorded against its acting access identity so adherence is auditable. HDS operates and documents this minimum-necessary and access-control posture. The implementer decides which purposes exist and how they map to scopes.

🔒 hipaa/policies/minimum-necessary available on request
🔒 hipaa/policies/access-control available on request

Implementer

service-organization documented

Map each identified purpose to a distinct access scope and document the mapping; the platform enforces the boundary.

user-entity out-of-scope

subservice-organization out-of-scope

`P4.2` P4.2 — Retention of personal information draft

The entity retains personal information consistent with its objectives related to privacy.

Pryv platform facilitated

Retention metadata (period, basis, scheduled disposal date) can ride on event / access clientData so each record carries its own retention contract. Pryv ships no automatic TTL / expiry primitive — enforcement of the retention schedule is an operator job today (a scheduled sweep calling events/streams delete). The retention policy itself is yours; treat the absence of auto-expiry as an operator responsibility when you attest P4.2.

HDS facilitated USCH

Retention metadata (period, basis, scheduled disposal date) can ride on each record so it carries its own retention contract, but the platform ships no automatic expiry primitive — enforcing the schedule is an operator job today. HDS documents this gap honestly: automated retention enforcement is not yet shipped, so the control is facilitated and the absence of auto-expiry is called out.

detail

Each record can record its retention terms, but a scheduled sweep that deletes expired records must be operated rather than relied on as a platform feature. HDS treats formal, automated data-retention as a known gap being matured and documents the retention posture and its limit. The retention policy itself, and its enforcement, are the implementer's responsibility when attesting this criterion.

🔒 soc2/procedures/data-retention-and-disposal available on request

Implementer

service-organization documented

Define your retention schedule, record retention terms on each record, and operate the enforcement sweep yourself; document the absence of platform auto-expiry as your responsibility.

user-entity out-of-scope

subservice-organization out-of-scope

`P4.3` P4.3 — Disposal of personal information draft

The entity securely disposes of personal information to meet its objectives related to privacy.

Pryv platform configurable

Disposal uses the per-user erasure path: system.users.delete for whole-account, event/stream deletion for per-record. Backup reach is engine-dependent (SQLite per-user file unlink vs PostgreSQL row + pg_dump rotation) — choose the engine that matches your disposal commitment, same as GDPR Art.17.

HDS facilitated USCH

Disposal uses the platform's per-user erasure path (whole-account deletion, plus event- and stream-level deletion) from the live store, which HDS operates. Backup reach is storage-engine-dependent and scheduled disposal automation is not yet shipped, so HDS facilitates this and documents the boundary rather than claiming full secure disposal.

detail

Logical erasure from the live store is concrete; whether it reaches backups depends on the configured engine, and a documented, verified disposal schedule is a known gap. HDS documents the disposal path and its limits, and relies on the hosting provider for physical media sanitisation. The implementer chooses the engine that matches its disposal commitment.

🔒 soc2/procedures/data-retention-and-disposal available on request
🔒 hipaa/policies/minimum-necessary available on request

Implementer

service-organization documented

Define your disposal procedure, choose a storage engine whose backup behaviour matches it, and document how disposal reaches all copies.

user-entity out-of-scope

subservice-organization documented

The hosting subservice carries physical media sanitisation; obtain and record its attestation.

`P5.1` P5.1 — Data subject access to personal information draft

The entity grants identified and authenticated data subjects the ability to access their stored personal information for review and, on request, provides copies to meet its objectives related to privacy.

Pryv platform implemented

Subject access is subject-runnable: the data subject holds their own credentials, so events.get / streams.get return their data directly, and the pryv-account-backup CLI produces a complete portable export — account, profiles, app profiles, streams, accesses (incl. revoked / expired + opt-in per-access version history), events (chunked + incremental), audit log, HF series data points, webhooks, and attachments, with a per-file sha256 integrity manifest — with no operator dependency for routine requests. The browser-based webapp flavour covers the read-side text resources only; route subjects who need attachments / HF series / webhooks to the CLI. See context/account-backup-coverage.md.

HDS implemented USCH

Subject access is user-centric and subject-runnable on the HDS-operated platform: the data subject holds their own credentials, so reads return their data directly, and an account-backup export produces a complete, portable copy with a per-file integrity manifest — with no operator dependency for routine requests. HDS operates this substrate; the service organization owns the identity-verification step for any operator-assisted request.

detail

Because the subject is the holder of their own access, review and export are self-service. The export covers account, streams, accesses (including revoked/expired with version history), events, audit log, and attachments, with a sha256 manifest per file. HDS operates the deployment and documents the access posture. Packaging a non-routine request and verifying the requester's identity is the implementer's workflow.

🔒 hipaa/policies/access-control available on request

Implementer

service-organization documented

Surface the self-service access and export paths to subjects, and document your identity-verification step for any operator-assisted request.

user-entity out-of-scope

subservice-organization out-of-scope

`P5.2` P5.2 — Correction, amendment, or appending of personal information draft

The entity corrects, amends, or appends personal information based on data subject input and communicates such changes to third parties, as committed or required, to meet its objectives related to privacy.

Pryv platform implemented

Correction is events.update (which snapshots the prior value into version history, preserving the amendment trail) and account.update for profile fields; the audit log records who amended what, when. Propagation to third parties who hold a shared/CMC access can use webhooks to signal the change. Judging the correctness of a correction request is your process.

HDS implemented USCH

Correction is a first-class operation on the HDS-operated platform: an update snapshots the prior value into version history (preserving the amendment trail) and the audit log records who amended what, when. Propagation to third parties holding a shared access can be signalled via change notification. Judging whether a correction request is valid is the service organization's process.

detail

Amendments preserve, rather than overwrite, the record's history, so the correction trail is intact and attributable. Third parties who hold a shared grant can be notified of the change and fetch the corrected state. HDS operates and documents the integrity and access substrate. Deciding the correctness of a request and committing to third-party communication is the implementer's.

🔒 hipaa/policies/integrity available on request
🔒 hipaa/policies/access-control available on request

Implementer

service-organization documented

Define your process for assessing correction requests and your commitments to notify third parties of amendments.

user-entity out-of-scope

subservice-organization out-of-scope

`P6.1` P6.1 — Disclosure to third parties for identified purposes with consent draft

The entity discloses personal information to third parties for the purposes identified in its objectives related to privacy and with the explicit consent of the data subject, if required.

Pryv platform facilitated

Third-party disclosure happens by issuing a scoped shared / CMC access — the disclosure is exactly the permissions granted, nothing more, and the access's clientData records the purpose + consent basis. There is no out-of-band data-dump path; disclosure is always a tracked, revocable grant. Deciding the lawful purpose is yours.

HDS facilitated USCH

Third-party disclosure on the HDS-operated platform happens by issuing a scoped, revocable shared access — the disclosure is exactly the permissions granted, nothing more, with the purpose and consent basis recorded in the access metadata. There is no out-of-band data-dump path; every disclosure is a tracked, revocable grant. Deciding the lawful purpose is the service organization's.

detail

Disclosure being a grant rather than a copy means the recipient's reach is bounded and reversible, and the grant itself carries the why. HDS operates and documents this access-control posture. The implementer decides the lawful purpose and obtains any required explicit consent before issuing the grant.

🔒 hipaa/policies/access-control available on request
🔒 hipaa/policies/minimum-necessary available on request

Implementer

service-organization documented

Decide the lawful purpose, obtain any required explicit consent, and issue a scoped shared access for each disclosure; document the basis.

user-entity out-of-scope

subservice-organization out-of-scope

`P6.2` P6.2 — Record of authorized disclosures draft

The entity creates and retains a complete, accurate, and timely record of authorized disclosures of personal information to meet its objectives related to privacy.

Pryv platform implemented

Every disclosure is a read against a shared / CMC access, and the per-user audit log records each access invocation with the accessId + accessSerial that made it — a complete, attributable record of who accessed what, when. The audit-event-stream can surface the same record into the subject's own streams. This is the technical disclosure register; how long you retain it is your policy.

HDS implemented USCH

Every disclosure is a read against a shared access, and the per-user audit log records each invocation with the access identity that made it — a complete, attributable record of who accessed what, when. HDS operates and retains this disclosure register; how long it is retained is set per the service organization's policy.

detail

The authorized-disclosure register is computable directly from the audit log plus the list of granted accesses, with no separate logging to maintain. HDS operates the substrate and documents the access and audit-controls posture. The implementer sets the retention period for the register consistent with its privacy objectives.

🔒 hipaa/policies/access-control available on request

Implementer

service-organization documented

Set and document the retention period for the disclosure register and the cadence at which you review it.

user-entity out-of-scope

subservice-organization out-of-scope

`P6.3` P6.3 — Record of detected unauthorized disclosures draft

The entity creates and retains a complete, accurate, and timely record of detected or reported unauthorized disclosures, including breaches, to meet its objectives related to privacy.

Pryv platform facilitated

The audit log captures access patterns (including failed / out-of-scope attempts), and observability surfaces anomalies, so a detected unauthorized disclosure has a contemporaneous evidentiary record. Detecting that a disclosure was unauthorized (vs authorized) is your assessment; Pryv supplies the raw trail.

HDS facilitated USCH

The audit log captures access patterns including failed and out-of-scope attempts, and HDS's infrastructure monitoring surfaces anomalies, so a detected unauthorized disclosure has a contemporaneous evidentiary record. Determining that a disclosure was unauthorized, and maintaining the formal record, is the service organization's assessment. Note that logs may contain PII, which HDS documents as a known handling consideration.

detail

HDS operates the audit and monitoring substrate that gives an unauthorized disclosure a timestamped trail, and runs alerting end to end before any component is treated as production. Classifying an event as unauthorized and keeping the breach record is the implementer's process. HDS documents the detection posture and the gap that log content is not yet PII-minimised.

🔒 hipaa/procedures/security-incident-response available on request

Implementer

service-organization documented

Classify detected events as authorized or not, and create and retain the unauthorized-disclosure record within your incident process.

user-entity out-of-scope

subservice-organization out-of-scope

`P6.4` P6.4 — Third-party commitments for privacy draft

The entity obtains privacy commitments from vendors and other third parties who have access to personal information to meet its objectives related to privacy.

Pryv platform out-of-scope

Vendor / subprocessor privacy commitments are contractual artefacts (DPAs, BAAs). No software role — though when the third party's technical access is a Pryv shared/CMC access, the permission scope is a concrete, enforced bound on what they were given, which your DPA can reference.

HDS facilitated USCH

Vendor and subprocessor privacy commitments are contractual. HDS obtains such commitments from its own subprocessors and tracks them in a register, and where a third party's technical access is a shared access, its permission scope is a concrete, enforced bound the implementer's agreement can reference. Executing the implementer's own third-party agreements is its responsibility.

detail

HDS maintains a current subprocessor register with privacy commitments flowed down, available to the implementer for its own due diligence. The access scope of any third party that holds a platform grant is a technical, auditable limit that complements the contractual commitment. The implementer obtains and retains its own vendor commitments.

🔒 hipaa/registers/subprocessor-register available on request

Implementer

service-organization documented 📄 subprocessor

Obtain and retain privacy commitments from your own vendors and third parties; reference the enforced access scope where applicable.

user-entity out-of-scope

subservice-organization documented

Provide your privacy commitments to the service organization and flow them to any of your own downstream parties.

`P6.5` P6.5 — Third-party unauthorized disclosure response draft

The entity obtains commitments from vendors and third parties to notify it of actual or suspected unauthorized disclosures, and responds to such notifications, to meet its objectives related to privacy.

Pryv platform out-of-scope

The third-party notification commitment is contractual and the response is your incident process (see CC7.4). No software role at the vendor-commitment layer.

HDS facilitated USCH

The third-party notification commitment is contractual, and HDS commits to notifying its implementers of incidents affecting their data, backed by its monitoring and incident-response programme. Obtaining the same commitment from the implementer's own third parties, and responding to notifications, is the service organization's process.

detail

HDS flows a notification obligation to its own subprocessors and carries one to its implementers; the detection and forensic evidence behind it comes from the audit and monitoring substrate. The implementer obtains equivalent commitments from its vendors and runs its own response when notified (see CC7.4-equivalent incident handling).

🔒 hipaa/procedures/security-incident-response available on request
🔒 hipaa/registers/subprocessor-register available on request

Implementer

service-organization documented 📄 subprocessor

Obtain notification commitments from your third parties and run your response process when notified.

user-entity out-of-scope

subservice-organization documented

Commit to notify the service organization of suspected unauthorized disclosures and flow the same down your chain.

`P6.6` P6.6 — Notice of breaches and incidents to affected parties draft

The entity provides notification of breaches and incidents to affected data subjects, regulators, and others to meet its objectives related to privacy.

Pryv platform facilitated

Pryv contributes the scoping evidence a breach notice needs — the audit log ties a compromised access to the users + data it touched. Today that reverse-index is manual; the breach-scope tool proposal automates "which subjects were affected, how many records, which streams". Drafting and sending the notifications within the regulatory deadline is your process.

HDS facilitated USCH

The platform supplies the scoping evidence a breach notice needs — the audit log ties a compromised access to the users and data it touched — and HDS operates the monitoring and incident-response programme that detects and scopes the event. Drafting and sending the notifications within the regulatory deadline is the service organization's process.

detail

HDS operates the detection-and-scoping substrate (audit plus monitoring, with alerting wired end to end) so a breach has a contemporaneous, attributable record of who was affected. Today the reverse-index from a compromised access to affected subjects is a manual step. The implementer drafts and sends the breach notices and meets the regulatory clock; HDS's incident procedure governs the report it produces.

🔒 hipaa/procedures/security-incident-response available on request

Implementer

service-organization documented

Own the breach-notification workflow — assess scope, draft and send notices to subjects and regulators within the applicable deadlines.

user-entity out-of-scope

subservice-organization out-of-scope

`P6.7` P6.7 — Accounting of disclosures to data subjects draft

The entity provides data subjects, on request, with an accounting of the personal information held and the disclosures of their personal information, to meet its objectives related to privacy.

Pryv platform implemented

The accounting-of-disclosures answer is computable from the audit log (which accesses read which data, when) plus the accesses list (who holds a grant). The audit-event-stream can expose this to the subject directly. Packaging it into a subject-facing report on request is your workflow; the underlying record is complete and attributable.

HDS implemented USCH

The accounting-of-disclosures answer is computable from the audit log (which accesses read which data, when) plus the list of granted accesses (who holds a grant) on the HDS-operated platform. HDS operates the substrate; packaging it into a subject-facing report on request is the service organization's workflow.

detail

Because every disclosure read and every grant is recorded, the underlying accounting record is complete and attributable without separate bookkeeping. HDS operates and documents the audit and access posture. The implementer formats the accounting into a subject-facing response and verifies the requester's identity.

🔒 hipaa/policies/access-control available on request

Implementer

service-organization documented

Package the audit-derived accounting into a subject-facing report on request and verify the requester's identity.

user-entity out-of-scope

subservice-organization out-of-scope

`P7.1` P7.1 — Data quality — accuracy, completeness, relevance draft

The entity collects and maintains accurate, up-to-date, complete, and relevant personal information to meet its objectives related to privacy.

Pryv platform facilitated

Structural data quality is enforced at ingest by event-type schema validation (HTTP 400 on malformed input); subjects keep their data up-to-date via events.update / account.update (with version history). "Relevant" — collecting no more than the purpose needs — is bounded by the permission scope you grant. Judging semantic accuracy of a specific value is your application's responsibility.

HDS facilitated USCH

Structural data quality is enforced at ingest by event-type schema validation (malformed input rejected), subjects keep their data current via updates with version history, and "relevant" is bounded by the access scope granted. HDS operates these primitives; judging the semantic accuracy of a specific value is the service organization's application responsibility.

detail

Completeness and structural accuracy are enforced by validation; relevance is enforced by minimum-necessary scoping; currency is supported by subject-driven updates that preserve history. HDS operates and documents the data-quality posture. Semantic correctness — is this the right value — stays with the implementer's application logic.

🔒 soc2/policies/data-quality available on request
🔒 hipaa/policies/minimum-necessary available on request

Implementer

service-organization documented

Own semantic-accuracy validation in your application, surface update paths to subjects, and scope collection to what each purpose needs.

user-entity out-of-scope

subservice-organization out-of-scope

`P8.1` P8.1 — Privacy complaint management and compliance monitoring draft

The entity implements a process for receiving, addressing, resolving, and communicating the resolution of privacy inquiries, complaints, and disputes, and periodically monitors compliance, taking timely corrective action on identified deficiencies, to meet its objectives related to privacy.

Pryv platform facilitated

The complaint-handling workflow is yours, but Pryv supplies the monitoring evidence (audit + observability) and can host the complaint / resolution records themselves as events on a dedicated stream with an attributable trail. This compliance matrix doubles as the periodic control-inventory you monitor against.

HDS facilitated USCH

The complaint-handling workflow is the service organization's, but the HDS-operated platform supplies the monitoring evidence (audit plus infrastructure monitoring) and can host the complaint and resolution records themselves as events on a dedicated stream with an attributable trail. This compliance matrix doubles as the periodic control inventory the implementer monitors against.

detail

HDS operates the audit and monitoring substrate that evidences ongoing compliance, and the platform can store complaint/resolution records as first-class, attributable data. HDS documents the monitoring posture. The receiving, addressing, resolving and communicating process — and the periodic compliance review with corrective action — is the implementer's.

🔒 soc2/policies/privacy-notice available on request

Implementer

service-organization documented

Run your complaint-handling and periodic-compliance-monitoring process, and take timely corrective action; the platform can host the records.

user-entity out-of-scope

subservice-organization out-of-scope

SOC 2 — AICPA Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) SOC 2

CC1.1 CC1.1 — Commitment to integrity and ethical values draft

CC1.2 CC1.2 — Board independence and oversight draft

CC1.3 CC1.3 — Management structures, reporting lines, and authorities draft

CC1.4 CC1.4 — Commitment to competence draft

CC1.5 CC1.5 — Accountability for internal control responsibilities draft

CC2.1 CC2.1 — Quality information to support internal control draft

CC2.2 CC2.2 — Internal communication of objectives and responsibilities draft

CC2.3 CC2.3 — External communication on internal control matters draft

CC3.1 CC3.1 — Objectives specified with sufficient clarity draft

CC3.2 CC3.2 — Identification and analysis of risk draft

CC3.3 CC3.3 — Consideration of the potential for fraud draft

CC3.4 CC3.4 — Identification and assessment of changes affecting internal control draft

CC4.1 CC4.1 — Ongoing and separate evaluations draft

CC4.2 CC4.2 — Evaluation and communication of deficiencies draft

CC5.1 CC5.1 — Selection and development of control activities draft

CC5.2 CC5.2 — General control activities over technology draft

CC5.3 CC5.3 — Deployment of control activities through policies and procedures draft

CC6.1 CC6.1 — Logical access security over protected information assets draft

CC6.2 CC6.2 — Registration, credential issuance, and de-provisioning draft

CC6.3 CC6.3 — Role-based access, least privilege, and segregation of duties draft

CC6.4 CC6.4 — Physical access to facilities and protected assets draft

CC6.5 CC6.5 — Protections over data and software on disposed assets draft

CC6.6 CC6.6 — Boundary protection against external threats draft

CC6.7 CC6.7 — Restriction and protection of information in transmission and movement draft

CC6.8 CC6.8 — Prevention and detection of unauthorized or malicious software draft

CC7.1 CC7.1 — Detection of configuration changes and vulnerabilities draft

CC7.2 CC7.2 — Monitoring for anomalies indicative of security events draft

CC7.3 CC7.3 — Evaluation of security events draft

CC7.4 CC7.4 — Incident response program draft

CC7.5 CC7.5 — Recovery from identified security incidents draft

CC8.1 CC8.1 — Authorized changes to infrastructure, data, software, and procedures draft

CC9.1 CC9.1 — Risk mitigation for business disruptions draft

CC9.2 CC9.2 — Vendor and business-partner risk management draft

A1.1 A1.1 — Capacity management draft

A1.2 A1.2 — Environmental protections, backup, and recovery infrastructure draft

A1.3 A1.3 — Recovery plan testing draft

C1.1 C1.1 — Identification and maintenance of confidential information draft

C1.2 C1.2 — Disposal of confidential information draft

PI1.1 PI1.1 — Quality information about processing objectives draft

PI1.2 PI1.2 — Completeness and accuracy of inputs draft

PI1.3 PI1.3 — Completeness and accuracy of processing draft

PI1.4 PI1.4 — Completeness, accuracy, and timeliness of outputs draft

PI1.5 PI1.5 — Completeness and accuracy of stored information draft

P1.1 P1.1 — Notice of privacy practices draft

P2.1 P2.1 — Choice and consent draft

P3.1 P3.1 — Collection consistent with objectives draft

P3.2 P3.2 — Explicit consent for sensitive personal information draft

P4.1 P4.1 — Use limited to identified purposes draft

P4.2 P4.2 — Retention of personal information draft

P4.3 P4.3 — Disposal of personal information draft

P5.1 P5.1 — Data subject access to personal information draft

P5.2 P5.2 — Correction, amendment, or appending of personal information draft

P6.1 P6.1 — Disclosure to third parties for identified purposes with consent draft

P6.2 P6.2 — Record of authorized disclosures draft

P6.3 P6.3 — Record of detected unauthorized disclosures draft

P6.4 P6.4 — Third-party commitments for privacy draft

P6.5 P6.5 — Third-party unauthorized disclosure response draft

P6.6 P6.6 — Notice of breaches and incidents to affected parties draft

P6.7 P6.7 — Accounting of disclosures to data subjects draft

P7.1 P7.1 — Data quality — accuracy, completeness, relevance draft

P8.1 P8.1 — Privacy complaint management and compliance monitoring draft

`CC1.1` CC1.1 — Commitment to integrity and ethical values draft

`CC1.2` CC1.2 — Board independence and oversight draft

`CC1.3` CC1.3 — Management structures, reporting lines, and authorities draft

`CC1.4` CC1.4 — Commitment to competence draft

`CC1.5` CC1.5 — Accountability for internal control responsibilities draft

`CC2.1` CC2.1 — Quality information to support internal control draft

`CC2.2` CC2.2 — Internal communication of objectives and responsibilities draft

`CC2.3` CC2.3 — External communication on internal control matters draft

`CC3.1` CC3.1 — Objectives specified with sufficient clarity draft

`CC3.2` CC3.2 — Identification and analysis of risk draft

`CC3.3` CC3.3 — Consideration of the potential for fraud draft

`CC3.4` CC3.4 — Identification and assessment of changes affecting internal control draft

`CC4.1` CC4.1 — Ongoing and separate evaluations draft

`CC4.2` CC4.2 — Evaluation and communication of deficiencies draft

`CC5.1` CC5.1 — Selection and development of control activities draft

`CC5.2` CC5.2 — General control activities over technology draft

`CC5.3` CC5.3 — Deployment of control activities through policies and procedures draft

`CC6.1` CC6.1 — Logical access security over protected information assets draft

`CC6.2` CC6.2 — Registration, credential issuance, and de-provisioning draft

`CC6.3` CC6.3 — Role-based access, least privilege, and segregation of duties draft

`CC6.4` CC6.4 — Physical access to facilities and protected assets draft

`CC6.5` CC6.5 — Protections over data and software on disposed assets draft

`CC6.6` CC6.6 — Boundary protection against external threats draft

`CC6.7` CC6.7 — Restriction and protection of information in transmission and movement draft

`CC6.8` CC6.8 — Prevention and detection of unauthorized or malicious software draft

`CC7.1` CC7.1 — Detection of configuration changes and vulnerabilities draft

`CC7.2` CC7.2 — Monitoring for anomalies indicative of security events draft

`CC7.3` CC7.3 — Evaluation of security events draft

`CC7.4` CC7.4 — Incident response program draft

`CC7.5` CC7.5 — Recovery from identified security incidents draft

`CC8.1` CC8.1 — Authorized changes to infrastructure, data, software, and procedures draft

`CC9.1` CC9.1 — Risk mitigation for business disruptions draft

`CC9.2` CC9.2 — Vendor and business-partner risk management draft

`A1.1` A1.1 — Capacity management draft

`A1.2` A1.2 — Environmental protections, backup, and recovery infrastructure draft

`A1.3` A1.3 — Recovery plan testing draft

`C1.1` C1.1 — Identification and maintenance of confidential information draft

`C1.2` C1.2 — Disposal of confidential information draft

`PI1.1` PI1.1 — Quality information about processing objectives draft

`PI1.2` PI1.2 — Completeness and accuracy of inputs draft

`PI1.3` PI1.3 — Completeness and accuracy of processing draft

`PI1.4` PI1.4 — Completeness, accuracy, and timeliness of outputs draft

`PI1.5` PI1.5 — Completeness and accuracy of stored information draft

`P1.1` P1.1 — Notice of privacy practices draft

`P2.1` P2.1 — Choice and consent draft

`P3.1` P3.1 — Collection consistent with objectives draft

`P3.2` P3.2 — Explicit consent for sensitive personal information draft

`P4.1` P4.1 — Use limited to identified purposes draft

`P4.2` P4.2 — Retention of personal information draft

`P4.3` P4.3 — Disposal of personal information draft

`P5.1` P5.1 — Data subject access to personal information draft

`P5.2` P5.2 — Correction, amendment, or appending of personal information draft

`P6.1` P6.1 — Disclosure to third parties for identified purposes with consent draft

`P6.2` P6.2 — Record of authorized disclosures draft

`P6.3` P6.3 — Record of detected unauthorized disclosures draft

`P6.4` P6.4 — Third-party commitments for privacy draft

`P6.5` P6.5 — Third-party unauthorized disclosure response draft

`P6.6` P6.6 — Notice of breaches and incidents to affected parties draft

`P6.7` P6.7 — Accounting of disclosures to data subjects draft

`P7.1` P7.1 — Data quality — accuracy, completeness, relevance draft

`P8.1` P8.1 — Privacy complaint management and compliance monitoring draft