SOC 2 and HIPAA for link tracking: a procurement answer

A URL shortener seems like a small surface in a procurement review. Two paragraphs in the vendor security questionnaire, a quick attestation, a checkbox. Then the security team opens the architecture diagram and finds the shortener sits on the request path of every campaign URL, every transactional email link, every QR-code redirect. The two-paragraph review becomes three weeks of follow-up.

This post answers the questions enterprise procurement teams actually ask about SOC 2 Type II and HIPAA when they evaluate a link-tracking vendor. It is written for the person filling out the questionnaire and the person reviewing the answer.

The short version#

Elido has ISO 27001 certification. SOC 2 Type II is in progress with a target completion in the second half of 2026 — the audit window started in February 2026, evidence collection runs through July, and the Type II report is expected by the end of Q4. HIPAA is supported on Business and Enterprise plans with a signed Business Associate Agreement; the underlying controls are the same ones used for SOC 2.

GDPR compliance posture is separate from SOC 2 and HIPAA and covered in the GDPR for URL shorteners cornerstone. This post focuses on the US-style attestation frameworks that drive enterprise procurement reviews.

What SOC 2 actually says about a URL shortener#

SOC 2 is a report, not a certification. An independent auditor (a CPA firm in the US, or a recognised auditing body in the EU) examines a service organisation against the AICPA's Trust Services Criteria and issues an opinion. Type I documents that controls are designed appropriately at a point in time; Type II documents that they operated effectively over a period — typically six to twelve months.

The Trust Services Criteria fall into five categories. Every SOC 2 report covers Security; the other four (Availability, Processing Integrity, Confidentiality, Privacy) are included at the service organisation's election based on what the customer base needs.

Security — the always-included category#

The Security criteria cover access control, change management, monitoring, incident response, and risk assessment. For a URL shortener, the controls that matter most are:

CC6.1 Logical access: who can create, modify, or delete a short link, and how that access is granted and revoked. The audit will trace specific users from the HR onboarding record through the IdP (Ory Kratos for Elido) through workspace role assignment, and verify their access was removed within the policy window after termination.
CC6.6 External access: how external users (custom-domain owners, API consumers, partner integrations) authenticate and what scopes they receive. The API token model with idempotency keys and per-workspace scoping is the artefact the auditor wants to see.
CC7.2 Monitoring: what gets logged, where logs go, and how anomalies surface. For a redirect service, the relevant signals are unusual redirect volume per workspace, rate-limit triggers at the edge, and authentication failures.
CC8.1 Change management: code changes from pull request through deployment, with separation of duties between the engineer who wrote the change and the reviewer who approved it. The audit will sample pull requests and walk through the approval and deployment record.

The Security criteria are also where SOC 2 expects a documented incident response plan. For a redirect service, the relevant incidents are unauthorised link creation, redirect destination tampering, and data exfiltration through the analytics export endpoints. The runbook at /docs/runbooks/ covers the playbook for each.

Availability — the second-most-common category#

Availability covers uptime commitments, capacity planning, and disaster recovery. For a URL shortener, the relevant artefacts are:

A documented service-level objective. Elido's published SLO is 99.95% redirect availability per quarter, with separate SLOs for the dashboard (99.9%) and the analytics API (99.5%).
Capacity testing evidence. The edge-redirect service runs continuous load tests in staging; the audit looks for evidence that the production capacity envelope is known and monitored against the SLO.
Backup and restore evidence. Postgres runs Patroni HA with point-in-time recovery; ClickHouse exports daily to object storage; the audit wants the restore drill log showing the restore time-objective is achievable.
Multi-region failover documentation. The three POPs (Frankfurt, Ashburn, Singapore) are active-active for redirects; the auditor will read the failover runbook and the post-mortem of the most recent regional event.

Confidentiality and Privacy — selectively included#

Confidentiality and Privacy add categories that overlap with GDPR posture. Most enterprise customers in the EU prefer to address privacy through GDPR documentation (Article 28 processor agreements, transfer impact assessments, the public DPA) rather than through SOC 2 Privacy. Elido's current SOC 2 audit scope includes Security, Availability, and Confidentiality. Privacy is addressed separately through the GDPR documentation suite at /trust.

The reason for the split: SOC 2 Privacy maps to the AICPA's Generally Accepted Privacy Principles, which were designed for US-style privacy frameworks. GDPR is a separate legal framework with its own controls. Conflating the two in a single attestation tends to weaken both.

What HIPAA actually says about a URL shortener#

HIPAA — the Health Insurance Portability and Accountability Act, as updated by HITECH and the 2013 Omnibus Rule — regulates how Protected Health Information (PHI) is handled by covered entities (healthcare providers, payers, clearinghouses) and their Business Associates.

A URL shortener becomes a Business Associate when the short link or the data behind it carries PHI. The interesting question is whether it ever does, and the answer is more nuanced than most procurement reviews assume.

When PHI flows through a redirect#

A short link itself — s.elido.me/abc123 — is not PHI. The destination URL, the workspace metadata, and the campaign tags also are not PHI in the general case.

The PHI question lives in three specific places:

Destination URLs that contain identifiers: a short link redirecting to https://provider.example/patient/12345/results contains a patient identifier in the URL path. That destination URL is stored by the shortener and is therefore PHI in the strict sense — even though the link works perfectly without anyone at the shortener interpreting the patient identifier.
Custom parameters appended at click time: if a redirect appends a session identifier or a user identifier as a URL parameter and that identifier is later joinable to PHI, the click event becomes part of the PHI chain.
Click events with referrer data: a click event includes the referrer URL. If a referrer happens to include a patient identifier (a deep-linked patient portal page that referred the user out to the shortened link), the referrer field is PHI.

Most healthcare marketing use cases do not generate PHI through any of these channels. A health-system marketing department running campaigns for flu shots, wellness events, or general health content produces redirects with PHI-free destinations and PHI-free referrers. For that workload, the BAA is precautionary, not architecturally necessary.

For workloads that do route through PHI destinations — patient portals, appointment confirmation links, lab-result delivery URLs — the BAA is required, and the architectural controls described below need to be in place at the shortener.

The HIPAA Security Rule mapped to a redirect service#

The HIPAA Security Rule (45 CFR Part 164, Subpart C) prescribes administrative, physical, and technical safeguards. For a redirect service handling PHI in destinations:

Access controls (164.312(a)): unique user identification, automatic logoff, encryption of ePHI in transit and at rest. Elido enforces unique IdP-assigned user identifiers, configurable session timeout per workspace, TLS 1.3 on all external endpoints, and AES-256 envelope encryption at rest for the relevant data stores.
Audit controls (164.312(b)): recording and examining activity in systems that contain or use ePHI. Elido emits audit logs for link creation, link modification, destination changes, and analytics export to a tamper-evident append-only store. Audit log retention defaults to 24 months on Business+ plans.
Integrity controls (164.312(c)): protecting ePHI from improper alteration. Destination URLs are stored with row-level history; any modification is logged with the actor identity and timestamp, and the previous value remains in the history table.
Transmission security (164.312(e)): protecting ePHI in transit over open networks. TLS 1.3 on all redirect endpoints; HSTS preload; certificate pinning available on custom domains.

The administrative and physical safeguards (workforce training, sanction policies, facility access controls) overlap heavily with the SOC 2 Security controls. The same evidence supports both audits, which is why we run them on a shared evidence schedule.

What the BAA does and does not cover#

A Business Associate Agreement is a contract under HIPAA 164.504(e). It commits the Business Associate to specific safeguards, breach notification timelines, and subcontractor flow-down obligations. It does not change the underlying architecture; it commits the vendor to operating the architecture in a HIPAA-compliant manner.

Elido's standard BAA, available on Business and Enterprise plans, covers:

The four HIPAA Security Rule safeguard categories applied to all data the customer routes through the redirect service.
Breach notification within 60 days of discovery, with detailed incident response timelines covered in the BAA and the corresponding /docs/runbooks/incident-response runbook.
Subcontractor flow-down to the named sub-processors (Hetzner, OVH, Postmark, Cloudflare, monobank Plata) under their own BAAs where applicable. The current sub-processor list is at /legal/subprocessors and is the same list used for the GDPR Article 28 documentation.
Return or destruction of PHI at contract termination, with a 30-day window for the customer to export data before deletion.

What the BAA does not do: it does not make a non-HIPAA-eligible plan tier eligible. Free and Pro plans do not include BAA execution. The infrastructure is the same on all paid tiers; the legal commitments are not.

The procurement questionnaire — answers you can paste#

Most enterprise procurement questionnaires ask the same set of questions. The answers below are the ones we provide directly, with links to the artefacts.

Do you have a current SOC 2 Type II report? ISO 27001 certified; SOC 2 Type II audit in progress, Type II report targeted for Q4 2026. Bridge letters and the current ISO 27001 certificate are available under NDA via /trust. SOC 2 Type I was completed in November 2025; the Type I report is also available under NDA.

Will you sign our BAA? We sign our standard BAA on Business and Enterprise plans. Customer-paper BAAs are reviewed on Enterprise plans; common modifications (expanded breach notification windows, additional safeguard attestations, customer-specified subcontractor controls) are accepted. Contact [email protected] for the standard text or to start a customer-paper review.

Where is data stored? EU customers default to Frankfurt (Hetzner FRA1, EU region). US customers can elect Ashburn (Hetzner ASH). Singapore (OVH SGP) is available for APAC customers. Cross-region replication is opt-in per workspace; without it, all customer data remains in the elected region. The data residency post covers the residency architecture in detail.

What encryption is in use? TLS 1.3 in transit on all external endpoints (redirect, API, dashboard, analytics). AES-256 envelope encryption at rest for the Postgres primary, ClickHouse cluster, and object storage. Customer-supplied KMS is supported on Enterprise plans through the BYO KMS integration.

How is access provisioned and de-provisioned? Single sign-on through SAML or OIDC via WorkOS; SCIM provisioning for user lifecycle. Workspace-level role-based access control with custom roles available on Enterprise. The SCIM and SSO post covers the integration and the lifecycle controls.

What is your incident response process? Documented runbook with a 60-minute initial response SLA, 24-hour technical update SLA, and named incident commander rotations. Breach notifications follow the timelines in our BAA and our DPA. The full runbook index is at /docs/runbooks/.

Who are your sub-processors? Five named sub-processors: Hetzner (infrastructure, EU), OVH (infrastructure, APAC), Postmark (transactional email), Cloudflare (DDoS protection on public marketing surfaces; not on the redirect data plane), monobank Plata (billing for the EU customer base). The full list with contact details is at /legal/subprocessors.

How long do you retain customer data? Click events retained for the term of the contract plus the 30-day export window at termination, then deleted. Link configuration retained for the term of the contract plus the export window. Aggregate metrics (counts of links per workspace, counts of clicks per day, no PII) retained beyond the contract for billing and internal capacity planning.

The evidence file an auditor wants to see#

If you are an enterprise customer running your own SOC 2 audit and Elido is a vendor in scope, your auditor will likely ask for evidence under your CC9.2 (vendor management) and CC1.4 (commitments) controls. The vendor file should contain:

Our current ISO 27001 certificate (renewable annually).
Our SOC 2 Type I report and the SOC 2 Type II bridge letter (available under NDA).
Our signed DPA and BAA where applicable.
Our sub-processor list and the dates of any changes.
Our public security page snapshot at /trust and the most recent privacy policy version.
Our breach notification history (the public history is empty — the internal log is reviewed during procurement under NDA).

The evidence file is built once per customer engagement and refreshed annually. The list above is the standard set; auditor-specific additions are handled case-by-case.

What is genuinely hard#

Two things are genuinely hard about SOC 2 and HIPAA for a redirect service, and we mention them because the procurement conversation usually surfaces them eventually.

Continuous monitoring evidence for the edge POPs is non-trivial. The redirect data plane processes high volumes of traffic across three regions, and the auditor wants evidence that monitoring is operating continuously, not just sampling. The current approach uses synthetic redirects from each region every minute, with the alerting state captured in a tamper-evident log. The cost of this monitoring is real and the design has gone through three iterations to get the signal-to-noise ratio right. The observability guide in the docs covers the current configuration; the underlying ADR is at /docs/adr/0024-sla-monitoring.md.

HIPAA breach notification timelines are tighter than GDPR. HIPAA requires notification of affected individuals within 60 days of discovery; for breaches affecting 500+ individuals, additional notifications to HHS and to media are required. GDPR allows 72 hours to the supervisory authority but the affected-individual notification timeline is "without undue delay". For a multi-jurisdiction breach, the HIPAA timeline often dominates. We commit to the HIPAA timeline by default for any incident touching US-routed customer data, and our incident response runbook reflects that.

GDPR for URL shorteners: what your DPO actually wants to see — the cornerstone for the compliance cluster.
EU data residency for marketing analytics — the residency architecture and pinning options.
Schrems II and your tracking pixels — transfer impact assessment context.
SCIM and SSO for marketing tools — the access-control controls that satisfy CC6.1.
Click attribution after Safari ITP — adjacent post on browser-side privacy restrictions.
Operational walkthrough: the SOC 2 evidence guide in the docs — how the evidence collection runs in practice.
Product surface: /solutions/compliance and /solutions/enterprise for plan-tier eligibility and feature mapping.