Building a HIPAA & SOC 2 Compliant Webhook Architecture: An Enterprise Guide

B2B event logging
B2B SaaS compliance
B2B webhook security
BYOD webhook encryption
compliance-driven webhooks
encrypted webhook payloads
end-to-end webhook encryption
enterprise API security
enterprise event architecture
enterprise webhook ingestion
enterprise webhooks
HIPAA compliance for webhooks
HIPAA compliant APIs
HIPAA compliant architecture
HIPAA compliant event logging
HIPAA compliant infrastructure
HIPAA compliant SaaS
HIPAA compliant webhooks
HIPAA data pipeline
HIPAA webhooks
mTLS authentication
mTLS webhook security
payload encryption
PHI data security
PHI webhook security
secure API integration
secure API webhooks
secure data ingestion
secure webhook gateway
secure webhook infrastructure
secure webhook ingestion
secure webhook management
secure webhook storage
SOC2 audit logging best practices
SOC2 audit preparation
SOC2 audit trail
SOC2 compliance for webhooks
SOC2 compliance guide
SOC2 compliant webhooks
SOC2 event logging
SOC2 Type 2 compliance
SOC2 webhook logging
SOC2 webhooks
webhook architecture
webhook audit logging
webhook authorization
webhook compliance
webhook compliance guide
webhook encryption at rest
webhook encryption in transit
webhook ingestion layer
webhook payload protection
webhook payload storage
webhook replay protection
webhook security architecture
webhook security best practices
webhook security checklist
webhook security standards
webhook signature verification
zero trust webhooks
Building A HIPAA SOC 2 Compliant Webhook Architecture An Enterprise Guide
Building a HIPAA & SOC 2 Compliant Webhook Architecture: An Enterprise Guide
In modern enterprise B2B SaaS, webhooks are no longer just an HTTP POST notification mechanism — they're a critical data pipeline carrying mission-critical payload events across organizational boundaries. When your application processes electronic Protected Health Information (ePHI) or operates inside enterprise-grade security controls, a standard webhook implementation becomes a significant audit liability.

Default webhook setups expose platforms to real audit risk:

Unencrypted payloads in third-party log aggregators (Datadog, CloudWatch, etc.) that end up holding ePHI they were never meant to see.
Man-in-the-middle exposure from insufficient identity validation at the edge.
Non-repudiation failure — no tamper-evident trail to show an auditor during a SOC 2 Type II examination.
Unbounded data retention, which cuts against HIPAA's Minimum Necessary standard and data-destruction expectations.
This guide walks through designing a zero-trust webhook ingestion and delivery architecture built around HIPAA-aligned controls, SOC 2 event logging, and secure webhook storage — and includes an update on where HIPAA and SOC 2 requirements actually stand as of mid-2026, since both are mid-change.

1. High-Level Compliant Architecture Overview A compliant webhook system decouples ingress, validation, payload handling, and asynchronous processing. Raw HTTP request bodies should never land in application database tables or unencrypted logs.

Code example
Copy code
EDGE INGRESS LAYER
External Sender --( mTLS / TLS 1.3 )--> Load Balancer / API Gateway
|
v
INGESTION SERVICE (stateless)

1. Verify HMAC signature / client cert fingerprint
2. Strip PII from headers before anything is logged
3. Assign an immutable event ID | +---------------+----------------+ | | (payload) (audit metadata) v v ENVELOPE ENCRYPTION MODULE SOC 2 AUDIT LOG PIPELINE
4. Fetch/derive a DEK via KMS 1. Extract non-PHI metadata only
5. Encrypt payload (AES-256-GCM) 2. Append to a hash chain | 3. Stream to WORM storage / SIEM v | SECURE QUEUE & STORAGE v
6. SQS/Kafka (encrypted at rest) S3 Object Lock (Compliance Mode)
7. Encrypted DB record (BYOK) | | v v SIEM (Splunk, Panther, etc.) WORKER SERVICE
8. Decrypt DEK via KMS
9. Process payload in memory

10. Zero out key material on completion
    Regulatory Requirements Mapping
    Architecture Feature HIPAA Security Rule Alignment SOC 2 Common Criteria
    mTLS & TLS 1.3 at the edge §164.312(e)(1) — Transmission Security CC6.6 — Restricting access from outside the system's boundaries
    Envelope encryption (AES-256-GCM) §164.312(a)(2)(iv) — Encryption and Decryption CC6.1 — Logical access controls, including encryption
    BYOK / customer-held keys §164.312(c)(1) — Integrity CC6.3 — Access authorization and least privilege
    Hash-chained WORM audit stream §164.312(b) — Audit Controls CC7.2 — Monitoring for security events and anomalies
    Stateless, hardened ingestion gateway §164.308(a)(1)(ii)(B) — Risk Management CC6.8 — Preventing and detecting malicious/unauthorized code
    One important caveat, covered in detail in Section 7: under the current HIPAA Security Rule, several of these — including encryption itself — are technically "addressable" rather than strictly "required," meaning a documented risk analysis can substitute an equivalent control. A proposed rule that has been working through HHS since January 2025 would eliminate that distinction entirely. It isn't final yet, but it changes how you should be scoping this work today.

    1. Layer 1: Edge Ingress & Verification (mTLS + HMAC) Standard webhook implementations rely on a shared-secret HMAC signature or, worse, a static API key. That's adequate for low-sensitivity event streams. A zero-trust posture for ePHI-bearing traffic adds mutual TLS (mTLS) at the transport layer in addition to payload signature verification — the two solve different problems.

Code example
Copy code
mTLS Handshake & Verification Sequence

Client Ingestion Gateway
|--- Client Hello ------------------------>|
|<-- Server Hello + Cert Request -----------|
|--- Client Cert + Certificate Verify ----->|
| | verify against trusted CA / CRL
| | extract SAN / serial for audit log
|<== TLS 1.3 session established ==========>|
|--- POST /webhooks (HMAC header) --------->|
| | validate HMAC digest
| | check nonce + timestamp window
Why HMAC alone isn't enough
HMAC proves the sender holds the shared secret and that the payload wasn't altered in transit. It does not authenticate the network path — a DNS hijack or a compromised upstream proxy can still present itself as a legitimate peer to a system that only checks HMAC. mTLS closes that gap by requiring both sides to present a certificate chained to a trusted CA before any payload is exchanged.

Example: ingestion middleware with mTLS + signature verification (Node.js/Express)
Code example
Copy code
import crypto from 'crypto';
import { Request, Response, NextFunction } from 'express';

interface SecureWebhookRequest extends Request {
rawBody?: Buffer;
clientCertFingerprint?: string;
}

export function validateEnterpriseWebhook(secretKey: string) {
return (req: SecureWebhookRequest, res: Response, next: NextFunction) => {
// 1. mTLS peer certificate check (terminated at NGINX/Envoy, enforced here)
const clientCert = req.socket.getPeerCertificate();
if (!req.client.authorized || !clientCert || !clientCert.raw) {
return res.status(401).json({ error: 'mTLS client certificate authentication failed' });
}

// Capture the fingerprint for the SOC 2 audit trail
req.clientCertFingerprint = clientCert.fingerprint256;

// 2. Extract signing headers
const signature = req.headers['x-signature-256'] as string;
const timestamp = req.headers['x-timestamp'] as string;
const nonce = req.headers['x-nonce'] as string;

if (!signature || !timestamp || !nonce) {
  return res.status(400).json({ error: 'Missing security headers' });
}

// 3. Reject stale requests to blunt replay attacks
const currentTime = Math.floor(Date.now() / 1000);
const requestTime = parseInt(timestamp, 10);
if (Math.abs(currentTime - requestTime) > 300) {
  return res.status(401).json({ error: 'Request timestamp outside acceptable window' });
}

// 4. Recompute HMAC SHA-256 over the canonical string
const rawPayload = req.rawBody || Buffer.from('');
const canonicalPayload = `${timestamp}.${nonce}.${rawPayload.toString('utf8')}`;

const expectedSignature = crypto
  .createHmac('sha256', secretKey)
  .update(canonicalPayload)
  .digest('hex');

const signatureBuffer = Buffer.from(signature, 'utf8');
const expectedBuffer = Buffer.from(expectedSignature, 'utf8');

// Constant-time comparison to avoid timing attacks
if (
  signatureBuffer.length !== expectedBuffer.length ||
  !crypto.timingSafeEqual(signatureBuffer, expectedBuffer)
) {
  return res.status(403).json({ error: 'Invalid HMAC payload signature' });
}

next();

};
}
Don't roll a bespoke scheme — align to Standard Webhooks
A custom x-signature-256 / x-timestamp / x-nonce header scheme like the one above works fine, but it forces every consumer to write a bespoke verifier. The industry has largely converged on the Standard Webhooks specification — an open, HMAC-SHA256-based signing convention (with webhook-id, webhook-signature, and webhook-timestamp headers, replay protection, and support for signature rotation) with reference libraries in TypeScript, Python, Go, Rust, Ruby, PHP, C#, Java, and Elixir. It's steered by a technical committee spanning Zapier, Twilio, Mux, ngrok, Supabase, Svix, and Kong, and it's been adopted by a growing list of API providers, including Anthropic, OpenAI, Google Gemini, Vanta, and Drata. If you're standing up a new webhook signing scheme in 2026, adopting (or closely mirroring) this spec instead of inventing your own headers buys you interoperability and lets you use audited, off-the-shelf verification code rather than maintaining your own.

1. Layer 2: Payload Envelope Encryption & BYOK Storing raw JSON payloads containing ePHI in database columns — even with disk-level encryption like EBS or RDS TDE — routinely fails SOC 2 Confidentiality expectations and doesn't satisfy the intent of HIPAA's encryption safeguard. Disk-level encryption protects against a stolen physical drive; it does nothing to stop someone with ordinary database read access from querying patient records in the clear.

Secure webhook storage means envelope encryption, and — for enterprise buyers who require it — a real BYOK story.

Code example
Copy code
Envelope Encryption Flow

Raw Webhook Payload (ePHI)
|
| 1. Generate a local, one-time Data Encryption Key (DEK)
v
AES-256-GCM Engine <---- DEK
|
+-------+--------+
| |
v v
Ciphertext Send DEK to KMS
| |
| | 2. KMS encrypts the DEK with the Key
| | Encryption Key (KEK)
| v
| Encrypted DEK
| |
+-------+--------+
v
Stored record: { ciphertext, encrypted_dek,
kms_key_arn, iv, auth_tag }
Key hierarchy
Data Encryption Key (DEK): a fresh AES-256 key generated in memory for each webhook event, used once to encrypt that payload, then discarded.
Key Encryption Key (KEK): a long-lived master key held in a cloud KMS or HSM. It never touches the payload directly — it only wraps DEKs.
BYOK: the enterprise customer supplies the KMS key (or key ARN) used as the KEK. If they revoke access to that key, you lose the ability to decrypt their data going forward.
It's worth being precise about what "BYOK" means in practice, because there are two meaningfully different implementations and the difference matters for a HIPAA/SOC 2 conversation with a customer's security team:

Customer-managed KMS key (the common case, sometimes called "hold your own key"): the customer creates and owns the KMS key in their own AWS account and grants your service role permission to use it. The key material still lives inside AWS-managed HSMs — AWS KMS is FIPS 140-2/140-3 validated — but the customer controls the IAM policy and can revoke your access instantly via CloudTrail-audited grants.
AWS KMS External Key Store (XKS), true BYOK: the key material itself is generated and stored entirely outside AWS, in the customer's own HSM or key manager. Every cryptographic operation is proxied over HTTPS from AWS KMS to the customer's infrastructure in real time (with a roughly 250ms latency budget), and it uses double envelope encryption under the hood. This gives the customer literal, physical control of the root key — but it also means the customer is now responsible for the availability of their own key-management infrastructure, since an outage there cascades into failed decrypt calls on your side.
Most B2B SaaS vendors implement the first pattern; it satisfies the large majority of enterprise security reviews. XKS is worth reserving for customers — typically in finance, defense, or government-adjacent healthcare — who explicitly require key material to never touch multi-tenant cloud infrastructure.

Implementation: envelope encryption module
Code example
Copy code
import crypto from 'crypto';
import { KMSClient, EncryptCommand } from '@aws-sdk/client-kms';

const kmsClient = new KMSClient({ region: 'us-east-1' });

interface EncryptedEnvelope {
ciphertext: string;
encryptedDek: string;
iv: string;
authTag: string;
kmsKeyId: string;
}

export async function encryptWebhookPayload(
rawPayload: string,
customerKmsKeyId: string
): Promise {
// 1. Generate a local Data Encryption Key (DEK) - 256 bits
const dek = crypto.randomBytes(32);
const iv = crypto.randomBytes(12); // 96-bit IV for AES-GCM

// 2. Encrypt the raw payload with AES-256-GCM
const cipher = crypto.createCipheriv('aes-256-gcm', dek, iv);
let ciphertext = cipher.update(rawPayload, 'utf8', 'base64');
ciphertext += cipher.final('base64');
const authTag = cipher.getAuthTag().toString('base64');

// 3. Wrap the DEK with the customer's KMS key (the KEK)
const kmsCommand = new EncryptCommand({
KeyId: customerKmsKeyId,
Plaintext: dek,
});

const kmsResponse = await kmsClient.send(kmsCommand);
if (!kmsResponse.CiphertextBlob) {
throw new Error('KMS DEK encryption failure');
}

const encryptedDek = Buffer.from(kmsResponse.CiphertextBlob).toString('base64');

// Zero the plaintext DEK in memory immediately
dek.fill(0);

return {
ciphertext,
encryptedDek,
iv: iv.toString('base64'),
authTag,
kmsKeyId: customerKmsKeyId,
};
}

1. Layer 3: Immutable SOC 2 Event Logging & Audit Trails A common pitfall during SOC 2 audits is mixing application logs with system audit logs, or letting sensitive payload fields leak into the audit stream itself. Under the SOC 2 Security and Confidentiality criteria, audit logs need to be:

Separated from payload content — metadata only, never ePHI fields.
Cryptographically traceable — a tamper-evident chain, not a flat file anyone with write access could edit.
Write-once-read-many (WORM) — locked storage that even a system administrator can't quietly alter.
Code example
Copy code
Audit Logging & SIEM Pipeline

Ingestion Gateway
|
+--(raw webhook)-----> Envelope Encryption --> Secure DB
|
+--(metadata only)--> SOC 2 Audit Logger
|
v
SHA-256 hash chain
|
v
S3 Object Lock (Compliance Mode)
|
v
SIEM stream (Splunk, Panther)
SOC 2 audit event schema
This structure captures SOC 2 Type II evidence without exposing ePHI:

Code example
Copy code
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"title": "SOC2CompliantWebhookAuditEvent",
"type": "object",
"properties": {
"eventId": { "type": "string", "format": "uuid" },
"timestamp": { "type": "string", "format": "date-time" },
"tenantId": { "type": "string" },
"sourceIp": { "type": "string", "format": "ipv4" },
"mtlsSubject": { "type": "string" },
"clientCertFingerprint": { "type": "string" },
"httpMethod": { "type": "string", "enum": ["POST"] },
"endpointPath": { "type": "string" },
"payloadByteSize": { "type": "integer" },
"payloadSha256Digest": { "type": "string" },
"kmsKeyArnUsed": { "type": "string" },
"processingStatus": { "type": "string", "enum": ["ACCEPTED", "REJECTED", "FAILED"] },
"responseStatusCode": { "type": "integer" },
"previousEventHash": { "type": "string" },
"currentLogHash": { "type": "string" }
},
"required": [
"eventId", "timestamp", "tenantId", "sourceIp",
"payloadSha256Digest", "processingStatus", "currentLogHash"
]
}
Hash-chained WORM audit logs
Each entry embeds the SHA-256 digest of the entry before it, producing a tamper-evident chain — the same principle behind a block ledger.

Code example
Copy code
import crypto from 'crypto';

interface AuditLogEntry {
eventId: string;
timestamp: string;
tenantId: string;
sourceIp: string;
payloadDigest: string;
status: string;
previousHash: string;
currentHash?: string;
}

export class SOC2AuditLogger {
private lastHash: string;

constructor(initialChainHash: string) {
this.lastHash = initialChainHash;
}

public createSignedLogEntry(
entry: Omit
): AuditLogEntry {
const fullEntry: AuditLogEntry = {
...entry,
previousHash: this.lastHash,
};

// Deterministic SHA-256 over the sorted entry + previous hash
const serialized = JSON.stringify(fullEntry, Object.keys(fullEntry).sort());
const hash = crypto.createHash('sha256').update(serialized).digest('hex');

fullEntry.currentHash = hash;
this.lastHash = hash;

return fullEntry;

}
}

1. Layer 4: Asynchronous Queueing & Processing Ingestion gateways should acknowledge inbound webhooks (202 Accepted) within milliseconds to avoid sender-side timeouts and connection backpressure. Processing and storage happen asynchronously behind an encrypted queue.

Code example
Copy code
HTTP Gateway --(202 Accepted)--> SQS / Kafka (KMS-encrypted)
|
v
Worker Node Pool
1. Decrypt DEK via KMS
2. Process in memory
3. Wipe key material
|
+-------------------+-------------------+
| failure success |
v v
Dead Letter Queue Primary encrypted DB
(exponential backoff) (partitioned per tenant)
Queue encryption: SQS/Kafka messages should use customer-managed KMS keys in transit and at rest, not the default service key.
Payload-free queuing (recommended for ePHI): don't put the encrypted envelope on the queue at all — write it to the encrypted database first and pass only the event_id through the queue. This limits blast radius if the queue itself is ever misconfigured.
DLQ strategy: retries should use exponential backoff with jitter to avoid a thundering-herd retry storm; events that fail repeatedly move to an isolated, access-restricted dead letter queue rather than looping indefinitely.

1. Standard vs. Compliant Architecture Dimension Standard Unsecure Architecture HIPAA & SOC 2–Aligned Architecture Transport layer TLS 1.2 with server-side validation only mTLS over TLS 1.3, certificate pinning Ingestion authentication Shared API key or bare HMAC HMAC-SHA256 + nonce + mTLS cert fingerprint (or Standard Webhooks) Encryption at rest Default disk encryption (EBS/TDE) only Per-payload envelope encryption (AES-256-GCM) + BYOK Application logging console.log(req.body) into Datadog/CloudWatch Zero-ePHI telemetry; metadata only, routed to WORM storage Audit trail Mutable log files Hash-chained ledger written to S3 Object Lock Tenant isolation Shared multi-tenant tables Row-level security + tenant-specific KMS keys Key revocation Vendor access can't be cut off cleanly Customer revokes KMS access; data becomes unreadable immediately
2. Where HIPAA and SOC 2 Actually Stand in 2026 Both frameworks referenced throughout this guide are in flux, and it's worth being precise about what's settled versus proposed before you scope a compliance roadmap around them.

HIPAA Security Rule: a major update is proposed, not yet final
HHS's Office for Civil Rights published a Notice of Proposed Rulemaking on January 6, 2025 — the first substantial rewrite of the HIPAA Security Rule since 2013. The comment period closed March 7, 2025, and OCR has been working through roughly 4,700–4,800 public comments since. As of mid-2026, no final rule has been issued. OCR's own regulatory agenda had targeted a spring 2026 finalization; that date passed without action, and the Office of Management and Budget's Unified Agenda now lists a July 2027 target for final action. A coalition of more than 100 healthcare organizations, led by CHIME, formally asked HHS to withdraw the proposal outright in a December 2025 letter. In short: the current HIPAA Security Rule remains the law in force, and the proposed changes could still be delayed, revised, or dropped.

That said, the direction of the proposal is exactly what this guide's architecture already assumes, which is worth knowing if you're building a business case for the engineering investment:

Elimination of "addressable" safeguards. Today, encryption and several other controls are "addressable" — you can substitute an equivalent alternative if you document why, based on a risk analysis. The proposed rule removes that flexibility for most controls, including encryption of ePHI at rest and in transit, making them mandatory with only narrow, tightly documented exceptions.
Mandatory multi-factor authentication across every system that touches ePHI, including admin access to the ingestion gateway, KMS console, and audit log pipeline.
A 72-hour breach/incident reporting window, tighter than current practice for many organizations.
Annual penetration testing and more frequent vulnerability scanning, which webhook ingestion endpoints — as externally reachable attack surface — would be squarely in scope for.
An estimated $9 billion in first-year compliance costs industry-wide, according to HHS's own impact analysis, which gives a sense of how substantial the proposal is.
If a final rule does publish, the current proposal calls for a roughly 240-day compliance window (60 days to an effective date, 180 more to compliance), so the architecture in this guide is a reasonable target to build toward regardless of whether the rule lands as written.

SOC 2: the criteria haven't changed, but auditor expectations have
Unlike HIPAA, there's no pending SOC 2 rewrite. The AICPA's core 2017 Trust Services Criteria are still the operative framework, and the last substantive change was a 2022 refresh of the Points of Focus — supplementary guidance under each criterion, not new criteria themselves. Practically, that means:

The CC6/CC7 mappings in this guide (boundary protection, encryption, access authorization, security monitoring) remain accurate as written.
Auditors are increasingly expecting evidence of modern controls — MFA everywhere, network segmentation, documented least-privilege access reviews — even though SOC 2 doesn't name "zero trust" as a requirement outright. A webhook gateway that can't produce dated, signed evidence for access reviews and MFA enforcement is a common source of exceptions in Type II audits, independent of anything webhook-specific.
CC9.2 (vendor risk management) is drawing more scrutiny for any pipeline that touches third-party LLM or SIEM tooling — relevant if your audit log stream feeds an external analytics platform.
Practical takeaway
Build to the "required, not addressable" bar now — mandatory encryption, mandatory MFA on every administrative path, tamper-evident logging, tight retention — rather than waiting for the HIPAA rule to finalize. It's already what SOC 2 auditors expect in practice, it's the direction OCR has committed to even amid delay, and it removes the risk-analysis paperwork trail that "addressable" currently requires you to maintain and defend.

1. Audit Preparedness Checklist When an auditor reviews your webhook architecture for SOC 2 Type II or HIPAA, they'll ask for specific evidence artifacts. Use this during engineering reviews:

Code example
Copy code
[ ] 1. BUSINESS ASSOCIATE AGREEMENTS (BAA)
[ ] Signed BAAs in place for every cloud service touching webhook
queues or storage (AWS, GCP, Datadog, your SIEM, etc.)

[ ] 2. BOUNDARY PROTECTION & TRANSPORT SECURITY (SOC 2 CC6.6)
[ ] TLS 1.2 minimum enforced; TLS 1.3 prioritized
[ ] Weak cipher suites disabled (CBC-mode ciphers, RC4)
[ ] mTLS certificate revocation checked dynamically (CRL/OCSP)

[ ] 3. KEY MANAGEMENT & DATA PROTECTION (SOC 2 CC6.1, CC6.3)
[ ] Automatic KMS key rotation enabled (annual minimum)
[ ] Per-tenant key separation enforced via BYOK/KMS policy
[ ] Verified, monitored proof of zero ePHI in application logs

[ ] 4. IMMUTABLE LOGGING & SIEM INTEGRATION (SOC 2 CC7.2)
[ ] S3 Object Lock configured in Compliance Mode (WORM)
[ ] Alerting on failed HMAC signatures / mTLS handshake errors
[ ] Continuous log ingestion into a central SIEM

[ ] 5. RETENTION & DATA DESTRUCTION
[ ] Lifecycle rules purge processed payloads on a defined schedule
[ ] Documented cryptographic erasure procedure (deleting the
DEK/KEK renders backup copies permanently unreadable)

[ ] 6. ACCESS & AUTHENTICATION (anticipating the HIPAA NPRM)
[ ] MFA enforced on every admin path touching ePHI or key material
[ ] Dated, signed quarterly access reviews for privileged accounts
[ ] Annual penetration test scoped to include webhook endpoints
Conclusion
A HIPAA-aligned, SOC 2–ready webhook architecture goes well beyond signature verification on an HTTP POST. Decoupling ingestion from processing, enforcing mTLS at the edge, wrapping every payload in per-event envelope encryption with a real BYOK story, and generating a tamper-evident audit trail eliminates most of the compliance risk before it ever reaches an auditor's desk — and it holds up whether or not the pending HIPAA Security Rule update finalizes as written.

For B2B software selling into healthcare, finance, and other regulated sectors, this isn't just risk reduction — a documented zero-trust webhook pipeline is something you can put directly in front of a prospective customer's security team, and it materially shortens both the enterprise security review and the SOC 2 Type II audit cycle.

Sources & further reading
HHS OCR, HIPAA Security Rule Notice of Proposed Rulemaking — Federal Register, Jan. 6, 2025
Medcurity, "2026 HIPAA Security Rule Update" and "HIPAA Security Rule 2026: What to Expect When OCR Finalizes"
Compliancy Group, "The Proposed HIPAA Security Rule Update"
RubinBrown, "HIPAA Security Rule Changes: 2025 & 2026 HIPAA Updates"
AICPA, 2017 Trust Services Criteria with Revised Points of Focus (2022)
Standard Webhooks specification — standardwebhooks.com / GitHub
AWS Security Blog, "Demystifying AWS KMS key operations, BYOK, custom key store, and ciphertext portability" and "Announcing AWS KMS External Key Store (XKS)"
This article reflects the regulatory landscape as of August 2026. The HIPAA Security Rule update discussed in Section 7 is still a proposed rule — check OCR's published rule status before treating any specific proposed requirement as binding.