Skip to content

Compliance Cookbook — HIPAA, GDPR, SOX, FRCP

Cesivi Archive Variant A — v1.5
Audience: Compliance officers, legal counsel, IT security auditors

How to Use This Cookbook

Each regulation section below contains:

  1. Citation table — maps specific regulatory clauses to the Cesivi feature that satisfies them.
  2. Worked example — shows a concrete deployment scenario with configuration snippets.

Important disclaimer: This cookbook describes Cesivi's technical controls and maps them to regulatory clauses. It is not legal advice. The mapping tables cite regulations by clause number only and do not paraphrase legal text — consult the authoritative sources (HHS for HIPAA, EUR-Lex for GDPR, eCFR for SOX, US courts for FRCP). Worked examples describe Cesivi configuration, not legal opinion.

Full audit-trail documentation: every Cesivi feature cited here has an operator guide cross-referenced in the "See also" section.

HIPAA — Health Insurance Portability and Accountability Act

Citation Table

Clause Requirement (brief summary) Cesivi feature
§164.316(b)(1) — Policies and Procedures retention Covered entities must retain documentation for 6 years from the date of creation or last effective date. ARCHIVE_RETENTION.md — default 7-year window (2555 days) set at import time. The retention gate unconditionally blocks deletion until window expires.
§164.308(a)(1)(ii)(D) — Information System Activity Review Implement procedures to regularly review records of IS activity (audit logs, access reports, security incident tracking reports). ARCHIVE_AUDIT.md — WORM audit log records all archive lifecycle events. ControlCenter /Archive/AuditLog provides filter, paginate, CSV export, and live-tail.
§164.310(d)(2)(iv) — Data Backup and Storage Address the final disposition of ePHI and hardware/electronic media on which it is stored. Covers data backup and integrity. ARCHIVE_INTEGRITY.md — SHA-256 hash at import; continuous background walker; on-access integrity gate (HTTP 451 on mismatch).
§164.312(b) — Audit Controls Implement hardware, software, and/or procedural mechanisms that record and examine activity in IS containing ePHI. ARCHIVE_AUDIT.md — DurableAuditEventSink (WORM substrate); SignalR live-tail in ControlCenter; REST endpoint GET /_api/archive/audit-events for automated log review.
§164.312(c)(1) — Integrity Implement policies to protect ePHI from improper alteration or destruction. ARCHIVE_MODE.md — write-rejection gate (all protocols). ARCHIVE_RETENTION.md — hard gate, no admin bypass. ARCHIVE_LEGAL_HOLD.md — legal hold supersedes retention.

Worked Example: Medical Practice Retiring Its SP Intranet

Scenario: A small HIPAA-covered medical practice is decommissioning its SharePoint 2016 intranet. The intranet contains six years of policies, procedures, and patient-access audit records. Retention obligation: 6 years minimum; practice chooses 7 years for safety.

Configuration:

  1. Run Setup Wizard with Archive Mode enabled.
  2. Set Retention Defaults: DefaultWindowDays = 2555 (7 years), anchor = ImportDate.
  3. Run archive-import to import the SP intranet: 
    dotnet run -- archive-import \
  --source "https://intranet.medical-practice.local" \
  --username "DOMAIN\administrator" \
  --password "Password1!" \
  --target  "http://localhost:15020" \
  --target-user "admin" \
  --target-password "admin"
  4. After import: verify ControlCenter /Archive/Retention shows retention windows assigned.
  5. Apply a site-scope legal hold for any active litigation: 
    POST /_api/archive/legalhold
{"Scope":"site","ScopeId":"medical-intranet","CaseNumber":"HIPAA-AUDIT-2026","AppliedBy":"privacy-officer@practice.local"}
  6. Schedule a quarterly integrity walk review: ControlCenter /Archive/Integrity → Export mismatches report.

What auditors can verify: - All documents accessible via browser, exactly as they appeared in SP. - Audit log shows ItemImported events for every item. - Retention windows visible in /Archive/Retention dashboard. - Any deletion attempt (e.g., by a former employee whose credentials still work) is blocked and logged.

GDPR — General Data Protection Regulation

Citation Table

Clause Requirement (brief summary) Cesivi feature
Art. 5(1)(e) — Storage Limitation Personal data shall not be kept longer than necessary for the processing purposes. ARCHIVE_RETENTION.md — expiry heatmap in ControlCenter; WormSegmentReaper deletes segments after retention window. Items can be deleted immediately after retention expiry (if no hold is active).
Art. 17(3)(e) — Right to Erasure Exception Erasure obligation does not apply when processing is necessary for the establishment, exercise, or defence of legal claims. ARCHIVE_LEGAL_HOLD.md — hold prevents erasure until released. Release requires explicit POST /_api/archive/legalhold/release/{holdId} with reason. Both events are WORM-audited.
Art. 30 — Records of Processing Activities Controllers must maintain records of processing activities. ARCHIVE_AUDIT.md — WORM log captures ItemImported, IdentitySnapshotCaptured, AclFrozen events. CSV export produces Art. 30 records on demand.
Art. 32 — Security of Processing Appropriate technical measures for integrity and confidentiality of personal data. ARCHIVE_INTEGRITY.md — SHA-256 walker + on-access gate. ARCHIVE_AUDIT.md — WORM hash chain detects tampering.
Art. 17(1) — Right to Erasure Data subjects may request erasure of their personal data. ARCHIVE_RETENTION.md — deletion is permitted after retention expiry (if no hold). ARCHIVE_LEGAL_HOLD.md — if a hold conflicts, the REST API returns HTTP 423; officer must release the hold first.

Worked Example: EU Corporation Parking Employee Records

Scenario: A German company is retiring a SharePoint 2019 intranet that holds HR documents (employment contracts, performance reviews) for former employees. GDPR requires retaining these for the duration of limitation periods (typically 3–10 years depending on document type), but the live farm must be decommissioned.

Data Protection consideration: The company's DPA has an approved lawful basis (legal obligation under German labour law) for retaining these records. The archive is restricted to HR compliance use — no general-access browsing.

Configuration:

  1. Run Setup Wizard with Archive Mode and Snapshot-only federation (no live AD lookup — the AD will be decommissioned; snapshots are the authoritative identity source).
  2. Set Retention Defaults: DefaultWindowDays = 3650 (10 years, per German ArbZG + limitation), anchor = ItemCreated.
  3. Import the intranet. After import, restrict WebUI access to the HR compliance officer user group.
  4. For subject-access requests (SAR): use ControlCenter /Archive/AuditLog → filter by principalIds containing the data subject's login. Export CSV provides the SAR package.
  5. For erasure requests after retention expiry: confirm in ControlCenter that the item's retention window has lapsed (status = EXPIRED). Check for active holds. If no hold, delete via DELETE /_api/web/lists/getbytitle('...)/items({id}) — the retention gate allows it.
  6. Record the deletion in your Art. 30 register (link to the ItemDeleted event in the audit log CSV).

What auditors can verify: - Art. 30 records: WORM audit log + CSV export. - Erasure requests: audit trail of every deletion attempt (blocked or permitted). - SAR: audit-log filter by subject identity.

SOX — Sarbanes-Oxley Act

Citation Table

Clause Requirement (brief summary) Cesivi feature
§103 — Retention of audit and work-paper records Public accounting firms must retain audit work papers and records for 7 years. ARCHIVE_RETENTION.md — 7-year default window (2555 days). Hard gate, no admin bypass.
§404 — Management assessment of internal controls Management must assess internal controls over financial reporting. ARCHIVE_LEGAL_HOLD.md + ARCHIVE_AUDIT.md — hold prevents record alteration; WORM hash chain proves tamper-evidence.
§802 — Criminal penalties for altering documents Willful alteration or destruction of records subject to investigation is a federal crime. ARCHIVE_AUDIT.md — WORM substrate: once sealed, segments are set read-only; any alteration breaks the SHA-256 hash chain. WormChainVerificationService runs a 6-hourly check and raises WormConfigChanged event (kind=chain_break) on detection.

Worked Example: Public Company Retiring an Accounting Team SP Site

Scenario: A Nasdaq-listed company is shutting down a SharePoint 2016 site used by the accounting team (budget models, board meeting minutes, audit work papers). The site must be retained for 7 years under SOX §103.

Configuration:

  1. Run Setup Wizard with Archive Mode and File System WORM backend (NTFS volume, ReadOnly immutability).
  2. Retention Defaults: DefaultWindowDays = 2555 (7 years), anchor = ImportDate.
  3. Import the accounting site: 
    dotnet run -- archive-import \
  --source "https://accounting-sp.corp.local" \
  --username "CORP\svc-archive" \
  --password "Passw0rd!" \
  --target  "http://cesivi-archive.corp.local:15020" \
  --target-user "admin" \
  --target-password "P@ssword1"
  4. After import, apply a site-scope legal hold to preserve all items regardless of any retention window edge cases: 
    POST /_api/archive/legalhold
{"Scope":"site","ScopeId":"accounting-sp","CaseNumber":"SOX-FY2026","AppliedBy":"controller@corp.local"}
  5. Configure WormChainVerificationService interval (default: 6 hours). Review ControlCenter /Archive/AuditLog → filter event_type=WormConfigChanged weekly.
  6. Export full audit log monthly: ControlCenter /Archive/AuditLog → Export CSV. Store CSV in your internal GRC system as the SOX §103 retention record.

What auditors can verify: - WORM segment manifest (index.json) shows sealed segments with SHA-256 hashes and prev-hash chain. - WormChainVerificationService last-run timestamp in ControlCenter. - Every deletion attempt blocked and logged (retention gate + hold gate). - Site accessible via browser for auditor review.

Cloud WORM Backends — Compliance Posture Notes

Introduced v1.5 (PLAN-1652). Cesivi now ships three WORM storage backends. The compliance posture differs slightly depending on which you choose:

Backend Immutability guarantee Regulatory suitability
FileSystem OS-level ReadOnly attribute / chattr +i (Linux). An OS administrator can clear it. Hash-chain detection provides auditability but not physical prevention. Suitable for most HIPAA/GDPR/SOX scenarios when the server OS is hardened and the audit subfolder is on a WORM-capable NAS.
S3 Object Lock (COMPLIANCE mode) AWS-level guarantee — cannot be overwritten or deleted by any principal, including root, until the lock window expires. Strongest AWS durability. Suitable for SEC 17a-4(f), CFTC 1.31, FINRA retention mandates that require hardware-independent WORM.
Azure Blob Immutability (time-based, Locked) Azure platform enforces immutability on sealed blobs. Provides strong WORM guarantee for Azure-native deployments. Suitable for HIPAA/SOX/GDPR in Azure deployments. Check that the Azure region and storage account type support the SetImmutabilityPolicy API (General Purpose v2 / Premium Block Blob required).

Migrating an existing FileSystem chain to S3 or Azure

If your archive was initially deployed with the FileSystem backend and you now need a cloud WORM guarantee, use WormChainMigrator:

# FileSystem → S3 (AWS or MinIO-compatible)
dotnet run --project Cesivi.StorageConverter -- convert \
  --migrate-worm-chain \
  --source "C:\CesiviData" \
  --farm-id "my-farm" \
  --s3-bucket "cesivi-worm" \
  --s3-region "eu-west-1" \
  --access-key "AKIA..." \
  --secret-key "..."

# FileSystem → Azure Blob
dotnet run --project Cesivi.StorageConverter -- convert \
  --migrate-worm-chain \
  --source "C:\CesiviData" \
  --farm-id "my-farm" \
  --azure-conn-str "DefaultEndpointsProtocol=https;AccountName=...;AccountKey=...;" \
  --azure-container "cesivi-worm"

The migrator preserves the hash chain — VerifyChainAsync passes on the destination store after migration.

FRCP Rule 37(e) — eDiscovery Chain of Custody

Citation Table

Clause Requirement (brief summary) Cesivi feature
FRCP 37(e) — Failure to preserve ESI Courts may impose sanctions if a party failed to take reasonable steps to preserve ESI. ARCHIVE_LEGAL_HOLD.md — legal hold provides documented preservation from the moment of hold application.
FRCP 37(e)(1) — Remedies for lost ESI If ESI is lost, courts may order measures no greater than necessary to cure prejudice. ARCHIVE_AUDIT.md — WORM log proves no ESI was destroyed while hold was active (every blocked deletion attempt logged with caller identity).
FRCP 37(e)(2) — Sanctions for intentional destruction Courts may presume unfavorable facts if ESI was intentionally destroyed. ARCHIVE_INTEGRITY.md — SHA-256 walk + hash-chain tamper detection proves content was not modified.
FRCP 26(g) — Preservation obligation Parties must take reasonable steps to preserve relevant ESI. ARCHIVE_MODE.md + ARCHIVE_LEGAL_HOLD.md — archive mode + hold = complete preservation. No modification possible.

Worked Example: Litigation Hold for Retired HR Site

Scenario: A company is served with litigation involving an employment dispute. Outside counsel issues a litigation hold notice covering all HR documents from 2018–2022. The SP 2016 HR site has been migrated to Cesivi archive.

Workflow:

  1. Apply a site-scope legal hold immediately upon receipt of the litigation notice: 

    POST /_api/archive/legalhold
Content-Type: application/json
Authorization: Basic <compliance-officer-credentials>

{
  "Scope": "site",
  "ScopeId": "hr-sp-2018-2022",
  "CaseNumber": "LIT-2026-042",
  "AppliedBy": "general-counsel@corp.local",
  "Reason": "Employment dispute — preservation hold per counsel instruction"
}
    Response: {"HoldId":"hold-abc123", "Status":"Active"}

  2. Verify HoldApplied event in ControlCenter /Archive/AuditLog.

  3. Enable read-access audit logging for the hold (track who reads held items): 

    PATCH /_api/archive/legalhold/policy
{"ReadAccessLogging": "EveryRead"}

  4. Provide counsel with a CSV export of the audit log filtered to this case:

  5. ControlCenter /Archive/AuditLog → filter caseNumber = LIT-2026-042 → Export CSV

  6. The CSV includes every HoldApplied, ReadAccess, and blocked-deletion event.

  7. When the case is resolved and counsel authorizes release: 

    POST /_api/archive/legalhold/release/hold-abc123
Content-Type: application/json
{"Reason": "Case settled 2027-03-15. Hold released per GC instruction."}
    The HoldReleased event is WORM-audited with timestamp, releasing officer, and reason.

What counsel / the court can verify: - HoldApplied event: timestamp, applying officer, case number, scope. - Every blocked deletion attempt during the hold period (attacker cannot destroy ESI). - HoldReleased event: timestamp, releasing officer, reason. - SHA-256 integrity walk confirms content was not silently modified. - Full chain-of-custody exportable as CSV.

Variant B — SPO Local Backup: Compliance Posture

Introduced v1.5 (PLAN-1653). Variant B creates an incremental local backup of a SharePoint Online (SPO) site on your own server. Its compliance posture differs materially from Variant A (on-premises retirement archive) because:

  1. The source of truth remains live in SPO (Variant B is a backup, not an archive); and
  2. The local copy has no WORM substrate — it is a read-write file folder under TargetPath.

What Variant B Is (and Is Not)

Property Variant A (On-Prem Archive) Variant B (SPO Backup)
Source SharePoint 2013–2019 On-Premises SharePoint Online (M365)
Purpose Retirement archive — source decommissioned Operational backup — source stays live
Local data WORM-protected, retention-enforced Plain files under TargetPath — mutable
Round-trip write-back v1.6+ v1.6+
HIPAA/SOX/GDPR archive tool? ✅ Yes (with WORM backend configured) ❌ Not as a standalone compliance control

Compliance Role for Variant B

Variant B is an operational resilience control, not a compliance archive. It satisfies:

Use case Supported
Recover from accidental deletion or ransomware (SPO-side) ✅ — local copy is independent of SPO
GDPR Art. 32 "appropriate technical measures" — backup ✅ — you control the backup location and access
Business continuity / DR planning (SPO service outage) ✅ — offline access to list data and files
HIPAA §164.310(d)(2)(iv) — data backup for operational ePHI ✅ with proper access controls on TargetPath
SOX §103 / HIPAA retention enforcement ❌ — no WORM substrate; content is mutable
FRCP 37(e) evidence preservation ❌ — no legal hold; no tamper-evident hash chain
GDPR Art. 17 Right to Erasure request Manual — operator must delete from TargetPath separately after erasing in SPO

Data Residency

All SPO content enumerated and downloaded by the incremental sync job is written to TargetPath on your server. No content transits a Cesivi cloud service. This means:

  • Content stays inside your network perimeter.
  • Data sovereignty requirements (e.g., data must remain in a specific country) are met as long as your server satisfies them.
  • The sync job uses OAuth2 tokens issued by Entra ID — the token request goes to Microsoft's token endpoint, but no Cesivi data is transmitted to Cesivi infrastructure.

Access Controls

The local backup folder (TargetPath) inherits NTFS/OS permissions only — Cesivi does not apply additional ACLs to the backup folder. Operators are responsible for:

  • Restricting read access to authorised backup operators.
  • Encrypting the backup volume if content is sensitive (PII, PHI, financial records).
  • Monitoring the _checkpoints/ folder (do not delete — holds change-token watermarks).

When You Need Variant A Instead

If your compliance obligation requires any of the following, deploy Variant A with an appropriate WORM backend (FileSystem WORM, S3 Object Lock, or Azure Blob Immutability):

  • Tamper-evident, immutable storage (WORM)
  • Legally defensible retention enforcement (deletion blocked until window expires)
  • Legal hold (deletion blocked indefinitely for litigation)
  • Full audit trail (who read, who tried to delete, when)

See the HIPAA / GDPR / SOX sections above, ARCHIVE_AUDIT.md, and TUTORIAL_G_ARCHIVE_ONPREM_RETIREMENT.md.

Variant B and Variant A can coexist on the same Cesivi instance: use Variant B for day-to-day operational backup and Variant A for the long-term compliance archive.

What Cesivi Does NOT Claim

The following are outside the scope of Cesivi Archive Variant A v1.2 compliance claims:

Claim Status
FedRAMP Authorization Not applicable — Cesivi is on-premises software. FedRAMP applies to cloud services. The customer's server infrastructure is their compliance domain.
C5 / BSI IT-Grundschutz certification Not certified. Cesivi's technical controls (WORM, integrity, retention) are documented and audit-ready, but the certification of the deployment environment is the customer's responsibility.
FIPS 140-2 cryptographic modules Cesivi uses .NET 10 runtime SHA-256 (a FIPS-approved algorithm). However, the Cesivi process is not configured in FIPS mode by default. If FIPS mode is required, configure the Windows/Linux host for FIPS compliance and test against the Cesivi deployment.
GDPR Data Protection Officer role Cesivi provides tools for DPOs (audit log, CSV export, retention + hold management), but Cesivi itself is not a legal entity under GDPR. The controller is always the customer.
SOX external auditor opinion Cesivi satisfies technical controls for record retention and tamper-evidence. Whether these controls are sufficient for a specific SOX audit opinion is determined by the external auditor, not by Cesivi.

See also