Compliance Controls

CoreSDK is designed with the structural requirements of enterprise compliance frameworks in mind. Its audit trail, PII masking, access control, and data residency features map directly onto the controls evaluated under SOC 2 Type II, the HIPAA Security Rule, GDPR, and PCI DSS.

Phase note. Formal certification artifacts — SOC 2 audit reports, HIPAA Business Associate Agreements, GDPR Data Processing Agreements, and PCI DSS Attestations of Compliance — are planned for Phase 3. The features described on this page are aligned with the principles of these standards and are designed to satisfy the underlying technical controls. They do not by themselves constitute certified compliance. Engage your compliance officer and a qualified assessor to determine what additional organisational and process controls your programme requires.

Audit trail

Tamper-evident hash chaining

Every audit event CoreSDK writes is chained to the event that preceded it using a SHA-256 HMAC. The chain root is anchored at SDK initialisation and each event carries the HMAC of the previous event's canonical JSON blob. Any deletion or modification of a stored event breaks the chain, which is detectable during log verification.

This design satisfies the immutability and non-repudiation requirements common to all four frameworks:

Enabling full policy input logging

By default, CoreSDK writes the policy decision (allowed/denied), the action, the user ID, and the tenant ID to the audit log. To capture the complete input document — including request body fields passed to the policy evaluator — set audit_include_input:

audit:
  enabled: true
  audit_include_input: true   # write full policy input document to each event
  sink: s3
  s3:
    bucket: "my-audit-logs"
    prefix: "coresdk/"
    region: "us-east-1"

With audit_include_input: true, each audit event includes a verbatim snapshot of the JSON object that was passed into the Rego evaluator. This is the recommended setting when regulators or internal auditors require evidence that policy decisions were made on the basis of specific attribute values.

Scoping PII with audit_input_fields

Full input logging can capture fields that contain personally identifiable information — email addresses, IP addresses, patient identifiers, or payment card metadata. Use audit_input_fields to allowlist only the fields that are required for audit evidence, leaving all others out of the log:

audit:
  enabled: true
  audit_include_input: true
  audit_input_fields:
    - "user.id"
    - "user.role"
    - "resource.type"
    - "resource.id"
    - "action"
    # Fields NOT listed here (e.g. user.email, request.body) are omitted

This field-level scoping lets you satisfy the audit completeness requirement of SOC 2 and HIPAA while honouring the GDPR principle of data minimisation (Art. 5(1)(c)) — logging only what is necessary to demonstrate that access decisions were made correctly.

If audit_input_fields is omitted entirely and audit_include_input is true, the full input document is written. If audit_input_fields is set to an empty list, no input fields are written regardless of audit_include_input.

Log export and retention

Audit events can be streamed to S3-compatible storage, a SIEM, or a webhook endpoint. Retention policies are configured on the sink, not in CoreSDK itself, so you can apply whatever retention period your compliance programme mandates (e.g. 12 months for PCI DSS Req. 10.7, 6 years for HIPAA).

audit:
  enabled: true
  sink: s3
  s3:
    bucket: "my-audit-logs"
    prefix: "coresdk/"
    region: "us-east-1"
    # Server-side encryption — satisfies PCI DSS Req. 10.5 and HIPAA § 164.312(a)(2)(iv)
    sse_algorithm: "aws:kms"
    kms_key_id: "arn:aws:kms:us-east-1:123456789012:key/mrk-..."

PII masking in policy evaluation

PII that reaches the policy evaluator is never persisted by CoreSDK itself beyond the current request lifecycle unless you explicitly include it in the audit log via audit_input_fields. However, PII often arrives in JWT claims or request attributes that must be evaluated by the policy.

Use the pii_mask block to hash or redact fields before they are made available to the policy evaluator, the audit log, and OTEL spans:

pii_mask:
  strategy: hash           # "hash" | "redact" | "truncate"
  hash_algorithm: sha256
  fields:
    - "input.user.email"
    - "input.request.ip"
    - "input.patient.ssn"

With strategy: hash, the original value is replaced with its SHA-256 hex digest before any downstream processing. The policy can still enforce rules based on a known hash (e.g. a blocklist of hashed email addresses) without the plaintext ever appearing in logs or spans.

With strategy: redact, the field value is replaced with the string [REDACTED]. This is the safest option for fields that have no legitimate downstream use in policy evaluation.

Access control alignment

CoreSDK's RBAC and ABAC policy layers provide the technical access controls that underpin the "minimum necessary access" principles in HIPAA (§ 164.312(a)(1)), GDPR (Art. 25 — data protection by design), PCI DSS (Req. 7), and SOC 2 (CC6.3).

Every policy decision is:

• Evaluated locally — no external call is made during the decision; latency does not affect access control correctness.
• Logged atomically — the audit event is written in the same synchronous path as the decision, so there is no window in which a decision is made but not recorded.
• Scoped by tenant — in multi-tenant deployments, a user from one tenant cannot evaluate policy against another tenant's resource space.

For a full description of policy authoring, see Authorization with Rego.

Data residency

Organisations subject to GDPR Chapter V (transfers outside the EEA), HIPAA geographic controls, or data sovereignty requirements imposed by national regulators can use CoreSDK's region-specific routing configuration to ensure that all processing — auth, policy evaluation, and audit writes — occurs within a designated region.

Pinning processing to a region

# coresdk.yaml — EU deployment
region: eu-west-1

audit:
  enabled: true
  sink: s3
  s3:
    bucket: "my-eu-audit-logs"
    region: "eu-west-1"           # data never leaves the EEA
    sse_algorithm: "aws:kms"

# Disable CoreSDK Cloud sync if not using cloud-managed policies
policy:
  source: local
  path: "/etc/coresdk/policies"
  sync_enabled: false             # no outbound policy fetch

When policy.source is set to local and sync_enabled is false, CoreSDK operates entirely within the host environment. No policy data, audit events, or request metadata is transmitted outside the process. This configuration is also used for air-gapped deployments.

Multi-region deployments

For applications that serve traffic from multiple regions, deploy one CoreSDK sidecar per region and route each sidecar's audit sink to a bucket in the same region. Do not share a single audit sink across region boundaries if your data residency obligations prohibit cross-border data transfers.

# coresdk.yaml — US deployment (separate instance)
region: us-east-1

audit:
  enabled: true
  sink: s3
  s3:
    bucket: "my-us-audit-logs"
    region: "us-east-1"

Framework mapping summary

The table below maps CoreSDK features to specific controls in each framework. This is provided for orientation during implementation and gap analysis — it is not a substitute for a formal assessment.

SBOM and dependency audit

CoreSDK generates a Software Bill of Materials (SBOM) for each release and provides CI tooling to audit your dependency tree for known CVEs.

Generated SBOMs

Each CoreSDK release ships an SBOM in CycloneDX 1.5 format covering the Rust crate workspace, all language SDK packages, and the sidecar binary. Download from the release assets on GitHub or via the CLI:

core sbom download --version 1.2.0 --format cyclonedx --output coresdk-1.2.0.sbom.json
core sbom download --version 1.2.0 --format spdx --output coresdk-1.2.0.spdx.json

CI dependency audit

Add the CoreSDK audit step to your CI pipeline to block on known CVEs in your own dependency tree:

# GitHub Actions
- name: CoreSDK dependency audit
  run: core audit --fail-on high
  # Exits non-zero if any HIGH or CRITICAL CVE is found in the dependency graph.
  # Advisory database is fetched from the CoreSDK advisory mirror (updated daily).

Severity levels: low, medium, high, critical. The --fail-on flag sets the minimum severity that causes a non-zero exit.

Ignoring false positives

# .coresdk-audit.yaml
ignore:
  - id: GHSA-xxxx-xxxx-xxxx   # CVE-2025-xxxxx — not reachable via our code path
    reason: "We do not call the affected function"
    expires: "2026-06-01"

Ignore entries without an expires date generate a warning in the audit output to prompt periodic review.

What is not covered

The features above address the technical controls layer of each framework. A complete compliance programme also requires organisational controls that CoreSDK cannot provide:

• SOC 2: a qualified CPA firm conducting a Type II audit over an observation period.
• HIPAA: a signed Business Associate Agreement (BAA) with any service provider that processes PHI, plus workforce training, risk analysis, and contingency planning.
• GDPR: a Data Processing Agreement (DPA) with processors, a Data Protection Impact Assessment (DPIA) for high-risk processing, and a designated Data Protection Officer if required.
• PCI DSS: a Qualified Security Assessor (QSA) conducting a formal assessment, network segmentation, vulnerability scanning, and penetration testing.

CoreSDK's Phase 3 roadmap includes formal certification artefacts — SOC 2 Type II report, standard DPA and BAA templates, and a PCI DSS Responsibility Matrix — that your compliance team can use directly in assessments.