SECTION 1: THE AMERICAN BLIND SPOT — HOW LAX THE US ACTUALLY IS

Before we can talk about how to do this correctly, we need to establish context. The United States does not have a comprehensive federal data protection law. That statement alone should stop you.

Every other major economy in the world — the European Union, the United Kingdom, Canada, Brazil, Japan, South Korea, India — has enacted or is in the process of enacting comprehensive, unified, national-level data protection legislation. The EU's General Data Protection Regulation (GDPR) sets the global standard. It requires informed, explicit, opt-in consent before data is collected. It gives individuals the right to access their data, correct it, delete it, and object to how it is used. It requires organizations to notify regulators of breaches within 72 hours. It levies fines up to €20 million or 4% of global annual turnover — whichever is higher — for serious violations.

The United States, by contrast, operates on a sector-specific, opt-out, fragmented patchwork of regulations. There is no single federal law that governs how a business must handle a customer's personal data. What exists instead is:

• HIPAA — covers health data only, for specific entity types
• GLBA — covers financial data for banks and financial institutions
• COPPA — covers data collected from children under 13
• CCPA/CPRA — California's state law, currently the strongest in the US
• State laws — 19+ states have enacted or are enacting their own privacy laws, each with different rules, thresholds, and enforcement mechanisms
• FTC Act Section 5 — covers "unfair or deceptive practices," which the FTC interprets to include some data misuse

What this patchwork means in practice:

A business in any US state other than California can, right now, legally:

• Collect personal data from website visitors with no meaningful disclosure
• Sell that data to third-party data brokers
• Track browsing behavior across the internet without explicit consent
• Use customer data for purposes not disclosed at the time of collection
• Retain data indefinitely without a deletion obligation

Most US businesses are doing some version of all of these things simultaneously — not because they are malicious, but because no one told them they shouldn't, and no federal law stops them.

This is the American Blind Spot. And it creates two serious problems.

Problem One: Complacency. Because the floor is so low in the US, most businesses have set their data practices to "whatever the tools do by default." Whatever Google Analytics tracks by default. Whatever Meta Pixel sends by default. Whatever the CRM imports by default. The default settings of every major marketing tool were designed to maximize data collection — because that data is valuable to the platform, not to you. Businesses that use these tools on default settings are collecting and transmitting far more than they realize, and often far more than their customers ever consented to.

Problem Two: The Floor Is Rising — Fast. The opt-out, default-on era of American data collection is ending. Enforcement is accelerating at the state level. Private lawsuits are multiplying. New state privacy laws are passing every legislative session. And the businesses that built their infrastructure to the permissive federal floor are going to be forced to rebuild it — reactively, expensively, under legal pressure — when those floors rise to meet them. The businesses that build to the highest available standard today will not need to touch their infrastructure when that day comes. Everyone else will be scrambling.

The global business reality: If you have any ambition to do business nationally across all US states, or internationally — in Canada, the UK, the EU, Australia, or any other major market — the data practices you build today determine whether you can operate in those markets at all. GDPR is not a European problem. It is a global standard that applies the moment a European resident visits your website, regardless of where your business is incorporated or where your servers live. Building to the highest standard is not overcompliance for a small business. It is the prerequisite for being a business that can scale without rebuilding its foundation every time a new jurisdiction passes a law.

SECTION 2: CUSTODIAN OF RECORDS — THE CONCEPT YOUR BUSINESS IS MISSING

The legal concept of a Custodian of Records originated in evidence law. When a document must be introduced in court, someone must testify to its authenticity — that it is what it claims to be, that it has not been altered, that it was maintained in the ordinary course of business. That person is the Custodian of Records. They do not just keep the files. They vouch for them. They are accountable for them. They can be called to testify about them.

Most businesses have records. Almost none of them have a Custodian.

Here is what that means in the modern digital business context:

Your business collects data continuously:

• Every form submission: a record
• Every email exchange: a record
• Every purchase transaction: a record
• Every appointment booked: a record
• Every website visit, when logged: a record
• Every automated workflow output: a record
• Every CRM entry: a record

These records are stored across tools, platforms, databases, and cloud services. They pass through automation workflows. They are processed by AI. They are sent to ad platforms. They exist in email threads, spreadsheets, CRM records, and backup files distributed across a dozen vendors — many of which the business owner could not name if asked.

Who is responsible for all of that data? In most businesses: no one specific. There is no designated person who knows where every piece of data lives, how it was collected, where it has traveled, who has accessed it, and what will happen to it when the business relationship ends or the data is no longer needed.

The Custodian of Records is the designation that solves this. Assigning this role means establishing:

1. WHO is responsible for the integrity of business records and data
2. WHERE every category of data is stored
3. HOW it was collected — with or without consent, under what terms
4. WHO has accessed it — the access audit trail
5. WHERE it has traveled — which systems, which vendors, which third parties
6. HOW LONG it will be retained — documented retention schedules
7. HOW it will be destroyed when the retention period ends

This is not bureaucracy. It is accountability. And it is exactly what regulators, courts, and increasingly, customers demand.

The absence of a named Custodian is one of the most consistent findings in regulatory investigations and civil litigation involving data. When a regulator or plaintiff's attorney asks "who in your organization is responsible for ensuring this data was handled properly?" — the answer "we don't have a designated person for that" is not neutral. It signals institutional negligence. It eliminates the "we had reasonable policies and followed them" defense. It is the organizational gap that turns a manageable compliance issue into an enforcement action.

For all businesses: The designation of a Custodian of Records is a signal to clients, partners, regulators, and courts that your organization has answered the question most organizations avoid: Who is responsible for the data? It is also the internal mechanism that ensures someone is watching — that new tools get evaluated, that access gets reviewed, that retention schedules get enforced — instead of assuming that the infrastructure manages itself.

SECTION 3: CHAIN OF CUSTODY — DATA HAS A LIFE CYCLE

Chain of Custody is the documented, traceable record of how data moves from its point of creation or collection through every system, process, handler, and destination — and ultimately to its final disposition.

In criminal law, a broken chain of custody makes evidence inadmissible. In data protection, a broken chain of custody creates compliance gaps — points in the data's journey where accountability is unclear, where consent may have lapsed, or where the data may have been accessed, modified, or transmitted without authorization.

For a digital business, every piece of data collected from a customer or prospect has a chain of custody whether you document it or not. The question is whether you control that chain — or whether your vendors do.

A typical undocumented chain of custody for a business website form submission:

1. Visitor fills out contact form on website
2. Form plugin stores submission in WordPress database
   (Who can access this database? Unknown. Is it encrypted? Probably not.)
3. Form plugin sends data to Mailchimp or HubSpot
   (Under what terms? Have you read their data processing agreement? Did you even know it was sending data there?)
4. Email notification triggers with full form data
   (Sent via which email provider? Is it encrypted in transit?)
5. Data sits in Mailchimp/HubSpot CRM indefinitely
   (For how long? Is it ever deleted? Whose terms govern it?)
6. Mailchimp/HubSpot uses aggregate behavioral data for its own platform
   (Is your customer's behavior being used to train their models?)
7. Marketing team exports the list to a spreadsheet
   (That spreadsheet lives where? On whose personal Google Drive?)
8. Spreadsheet shared with a freelancer for an email campaign
   (Under what data processing agreement with that freelancer?)
9. Freelancer's laptop is lost or stolen
   (Your customer's data is now on an unencrypted, lost device)

This is not an invented scenario. This is the ordinary operating reality of most small and mid-sized businesses. At no point in this chain did the customer consent to having their information travel this path. At no point did the business consciously decide this chain was acceptable. It simply happened — because the default settings and default workflows of common tools produced it automatically, invisibly.

A documented, controlled chain of custody for the same scenario — the Proscris model:

1. Visitor fills out contact form on website
2. Form sends data directly to self-hosted n8n via HTTPS POST
   (Website server never stores data. Zero.)
3. n8n validates, formats, and logs the submission
   (n8n is self-hosted on infrastructure we control — not a third-party SaaS)
4. Data appended to Google Sheets CRM
   (Covered by a signed Data Processing Agreement with Google)
5. Email notification sent via Gmail
   (Covered under the same signed agreement with Google)
6. Filtered, non-personally-identifiable conversion signal sent to ad platform
   (Only what is necessary and appropriate — see Section 5 on Signal Filtering)
7. Data retained per documented retention schedule
   (Defined at system setup — not indefinite by default)
8. Access limited to named individuals per documented access table
   (Role-based permissions. MFA required. Quarterly access audit.)
9. Data deleted per retention schedule with documented confirmation

Every step in the second chain is:

• Deliberate — chosen, not defaulted to
• Documented — recorded in a compliance framework
• Covered by appropriate legal agreements — signed Data Processing Agreements with every vendor
• Auditable — logs exist for every action
• Controlled — access is defined, limited, and reviewed

That is chain of custody applied to digital business operations. The first chain exposes the business to liability at every link. The second chain closes every gap.

SECTION 4: THE DATA LANDSCAPE — WHAT IS ACTUALLY BEING COLLECTED

Most business owners have a functional understanding of what their website does and a near-zero understanding of what their website collects. These are very different things.

Every website visitor, at minimum, generates:

The invisible data layer most businesses never see:

Beyond what tools visibly collect, there is a secondary data layer generated by the interactions between tools. When a user arrives at your website from a Meta ad, Meta's fbp (browser ID) cookie is set on their device. When they visit multiple pages, that cookie tracks their path. When they submit a form, the form plugin reads the cookie and transmits it alongside the contact data. The ad platform now has a continuous behavioral record — which pages this specific, identified user visited, in what sequence, for how long — linked to a real name and email address.

This is not a hypothetical privacy concern. It is the mechanism that has generated hundreds of millions of dollars in regulatory fines, class action settlements, and OCR enforcement actions across industries. It is the architecture that most businesses inherit by default without understanding its implications.

The principle that eliminates this exposure: Collect only what you need, store it only where appropriate agreements cover it, and transmit to third parties only what is necessary — stripped of everything that is not. This is data minimization. It is a core principle of GDPR, CCPA, HIPAA, and every other data protection framework that exists or is being written. It is also simply the correct way to handle information that belongs to other people.

SECTION 5: SIGNAL FILTERING — SENDING ONLY WHAT NEEDS TO BE SENT

One of the most overlooked dimensions of data protection in digital marketing is what happens after a conversion — specifically, what gets sent to advertising platforms to attribute that conversion and optimize future campaigns.

The standard implementation of most ad tracking setups sends everything. The default Meta Pixel, firing on every page, transmits the user's IP address, browser fingerprint, URL visited, page title, and all available cookie identifiers — to Meta's servers, on every page load, whether or not the user has taken any action that warrants attribution. When a form is submitted, some implementations transmit the form fields directly — including name, email, and phone — as Advanced Matching parameters, in plaintext, to the ad platform.

This is not a necessary feature of campaign optimization. It is the default behavior of tools that were designed to maximize data collection for the platform's benefit, not yours or your customer's.

The alternative is server-side signal filtering — and it is technically straightforward.

Rather than a browser-side pixel that fires automatically and indiscriminately, you build a server-side workflow that:

1. Receives the conversion event (form submission, purchase, appointment booking)
2. Processes the event through an explicit allowlist — defining precisely what gets sent and what does not
3. Transmits only the permitted fields to the ad platform via its server-side API
4. Logs every transmission with a documented record of what was sent

What a properly filtered conversion signal looks like:

EVENT RECEIVED: Form submission
Lead ID: DD-1234567890-ABCD
Full Name: Jane Smith
Email: jane.smith@email.com
Phone: (555) 000-0000
Message: [content]
Source URL: /contact
UTM Source: facebook
UTM Campaign: spring-2026

↓ FILTER APPLIED ↓

SENT TO AD PLATFORM:
event_name: "Lead" ✅ Generic conversion type — no business context
event_time: 1740000000 ✅ Timestamp — no personal data
event_id: "DD-1234567890" ✅ Our internal ID — for deduplication only
em (hashed): [SHA-256 hash] ✅ Email — hashed before leaving our server
ph (hashed): [SHA-256 hash] ✅ Phone — hashed before leaving our server
lead_source: "facebook" ✅ Attribution metadata — no personal data
lead_campaign: "spring-2026" ✅ Attribution metadata — no personal data

BLOCKED FROM AD PLATFORM:
Full name ❌ Personal identifier — not needed for optimization
Raw email ❌ Plaintext PII — hashed version sent instead
Raw phone ❌ Plaintext PII — hashed version sent instead
Message content ❌ May contain personal or sensitive disclosures
Source URL ❌ May contain business-sensitive context
IP address ❌ Personal identifier — not sent server-side
Any free-text field ❌ Uncontrolled content — never transmitted

Why hashing matters: SHA-256 hashing is a one-way cryptographic transformation. When you hash jane.smith@email.com, you get a fixed-length string of characters that cannot be reverse-engineered back to the original email address. Meta (and other platforms) accept hashed identifiers for audience matching — they hash their own user records and find matches without either party ever exposing plaintext PII. The ad platform gets the matching signal it needs for attribution and optimization. Your customer's actual email address never leaves your server in a form that anyone can read.

What this achieves:

• For your customers:
  • Their personal information is not transmitted in plaintext to ad platforms
  • Their behavioral data is not collected beyond what drives the conversion signal
  • Their consent to "contact us" is not extended to "share my data with Meta"
• For your business:
  • Campaign optimization works — you get attribution and audience signals
  • Legal exposure is dramatically reduced — no plaintext PII to ad platforms
  • Compliance with emerging data protection standards is built into the stack
  • The documented filter is evidence of deliberate, reasonable data practice
• For your compliance posture:
  • GDPR compliant (data minimization principle satisfied)
  • CCPA compliant (no "sale" of personal information to ad platforms)
  • Defensible in any jurisdiction that has enacted or will enact privacy law
  • Future-proof — as regulations tighten, the filter is already there

The principle we derive from the highest compliance standards:

HIPAA taught us to build an explicit, documented, auditable PHI filter — a code-level allowlist that defines, field by field, what passes to third parties and what does not. We apply the same architectural discipline to every client stack, regardless of industry. The name for this principle at the non-medical level is data minimization — and it is the cornerstone of GDPR Article 5, CCPA's proportionality requirements, and the emerging standard in US state privacy law.

SECTION 6: FIRST-PARTY DATA — THE ARCHITECTURE OF INTEGRITY

The concept of first-party data is straightforward: data that you collect directly from your customers, with their knowledge and consent, that you retain and control without selling, sharing, or transmitting to third parties for commercial purposes beyond what is explicitly disclosed.

It is the oldest model of customer relationship management — you know your customers because they chose to give you information, and you use that information to serve them better. No intermediaries. No data brokers. No secondary markets.

The third-party cookie era is ending. Businesses that built their marketing measurement on third-party cookies are losing signal. Businesses that built on first-party data — collected directly, stored on owned infrastructure, transmitted only as necessary — are not. They never depended on that infrastructure to begin with.

The Proscris first-party data architecture:

• DATA COLLECTED FROM: Your customers, via your forms, on your domain
• DATA STORED IN: Systems you own or control (self-hosted infrastructure / Google Workspace under signed Data Processing Agreement)
• DATA PROCESSED BY: Your automation workflows (n8n — self-hosted, not a third-party SaaS)
• DATA TRANSMITTED TO: Only what is necessary, only for explicit purposes (Ad platforms — filtered conversion signals only, hashed identifiers, no plaintext PII)
• DATA SOLD TO: No one. Ever.
• DATA SHARED WITH: Only named vendors under signed agreements. Only for the explicit purpose of serving your clients
• DATA RETAINED FOR: A defined period specified before collection begins
• DATA DELETED: On schedule, with documented confirmation

Why clients trust this and why it matters to them:

There is a meaningful and increasingly recognized difference between a business that says "we take your privacy seriously" in boilerplate footer text — and a business that can demonstrate, architecturally, that customer data never leaves a controlled infrastructure, that it is never sold, that access is limited to named individuals under documented controls, and that it is deleted on a defined schedule. First-party data architecture is a competitive differentiator.

SECTION 7: THE FINE PRINT IS THE EXPOSURE — REAL NUMBERS FROM REAL CASES

This section exists because abstraction does not move people. Numbers do. Here are the documented, verified financial consequences of data protection failures that are happening right now.

7.1 — Cookie and Tracking Violations: The "This Can't Happen to Me" Category

The acceleration that changes everything: In 2023, there were approximately 200 online privacy lawsuits filed in US federal courts. In 2024, there were approximately 4,000. That is a 20x increase in a single year. Courts have ruled that using tracking technologies without proper consent constitutes an actionable violation even without a data breach. The transmission to the third-party platform itself is the violation.

7.2 — HIPAA Violations: The Ceiling That Shows What's Coming

The fine structure under HIPAA is in a category of its own:

Documented enforcement actions:

• BetterHelp: $7,800,000 (Sharing data with Meta/Snapchat)
• New York Presbyterian Hospital: $300,000 (Meta Pixel violations)
• US Healthcare Providers (aggregate): $100,000,000+ (OCR sweep 2023–2024)
• Anthem Inc.: $115,000,000 (Data breach settlement)
• Dental Practice (NC): $50,000 (Google review response revealing patient status)

7.3 — GDPR: The Global Standard You Are Already Subject To

Documented GDPR enforcement actions:

• Meta (Facebook): €1,200,000,000
• Amazon: €746,000,000
• Instagram: €405,000,000
• WhatsApp: €225,000,000
• Google (France): €150,000,000
• H&M: €35,260,000

Total accumulated GDPR fines as of late 2025: over €6 billion.

7.4 — The State Law Cascade: It's No Longer Just California

As of 2026, comprehensive privacy laws are in effect or coming into effect in:

The threshold trap: Texas's TDPSA applies to any business that processes personal data of Texas residents as part of a commercial activity — with no consumer count threshold and no revenue threshold. If you have a website, you almost certainly process the data of Texas residents.

SECTION 8: ADA WEBSITE ACCESSIBILITY — THE LAWSUIT NOBODY SEES COMING

The relevant technical standard is the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA.

What triggers an ADA website lawsuit:

• ❌ Images without descriptive alt text
• ❌ Videos without captions or text transcripts
• ❌ Forms that cannot be navigated by keyboard alone
• ❌ Insufficient color contrast ratios
• ❌ PDFs that are not tagged or structured for screen readers
• ❌ Pop-ups or modals that cannot be closed via keyboard
• ❌ Navigation menus inaccessible to screen reader technology
• ❌ Clickable elements without descriptive accessible labels
• ❌ Time-limited actions with no accessibility accommodation
• ❌ No "skip to main content" link

The accessiBe warning — the overlay widget trap: The FTC fined accessiBe $1 million in 2025 for making false claims that its product provided ADA compliance. Federal courts have consistently ruled that overlay widgets do not provide legal protection.

SECTION 9: HOW WE APPROACH THIS — THE PROSCRIS DATA PROTECTION STANDARD

9.1 — The Compliance Tier We Build Against

• TIER 1 — HIPAA: Healthcare and health-adjacent clients.
• TIER 2 — GDPR-Equivalent: All clients with international ambitions.
• TIER 3 — CCPA/State Laws: All US clients.
• TIER 4 — General Best Practices: Every client, without exception.

9.2 — The Five Questions We Ask Before Any Tool Goes in the Stack

1. CAN THIS TOOL ACCESS OR PROCESS CUSTOMER DATA? If yes: evaluate.
2. DOES THIS TOOL SIGN A DATA PROCESSING AGREEMENT (DPA)? If no: reject tool.
3. WHERE DOES THE DATA THIS TOOL PROCESSES ACTUALLY GO? Check residency and sub-processors.
4. WHAT IS THE MINIMUM DATA THIS TOOL NEEDS TO FUNCTION? Hash, mask, or remove fields.
5. WHAT HAPPENS TO THE DATA WHEN WE STOP USING THIS TOOL? Verify export and deletion capability.

9.3 — The Documented Data Map — What Every Client Receives

SECTION 10: WHAT COMPLIANCE LOOKS LIKE IN OPERATION

• Before a new tool is added: 5-question evaluation + Signed DPA.
• When a team member joins: Data protection training + signed acknowledgment.
• When a team member leaves: Access revoked within 1 hour; logs updated.
• When a customer asks: Current privacy policy, Data Map, and named Custodian ready to respond.
• When a demand letter arrives: Documented consent records, audit logs, and reasonable procedures ready to defend you.

SECTION 11: THE EXPOSURE AUDIT — DO YOU HAVE THESE GAPS?

Use this as a rapid self-assessment. Every "No" or "Unknown" is an active liability.

Privacy and Consent Infrastructure

• ☐ Does your website have a current, accurate privacy policy?
• ☐ Does your privacy policy disclose every third-party tool that collects visitor data?
• ☐ For visitors in California: do you have a "Do Not Sell or Share My Information" link?
• ☐ If you use non-essential cookies: do visitors consent before those cookies fire?
• ☐ Do you have a documented process for responding to data deletion requests?
• ☐ If you have EU-based visitors: do you have a lawful basis documented for every category of data?

Data Collection, Storage and Transmission

• ☐ Do you know where every form submission from your website is stored?
• ☐ Is that storage covered by a signed Data Processing Agreement?
• ☐ Do you know which third-party vendors receive customer data when a form is submitted?
• ☐ Have you signed a DPA with each of those vendors?
• ☐ Are conversion signals sent to ad platforms filtered (hashed identifiers only)?
• ☐ Do you have a documented data retention schedule?
• ☐ Do you have a documented process for deleting data when the retention period ends?

Custodian and Chain of Custody

• ☐ Is there a named individual in your organization designated as responsible for data records?
• ☐ Do you have a documented map of where customer data flows through your systems?
• ☐ Do you have a documented incident response plan?
• ☐ Have all team members who handle customer data completed data protection training?
• ☐ Are training records retained?

Access Controls

• ☐ Is MFA required for every account that contains customer data?
• ☐ Do you have a process for revoking access within 1 hour of a team member departure?
• ☐ Does every person with access to customer data have only the level of access their role requires?
• ☐ Do you have an audit log of who accessed what data and when?

Website Compliance

• ☐ Has your website been audited against WCAG 2.1 AA standards?
• ☐ Is your website served entirely over HTTPS?
• ☐ Do you have a documented process for responding to an ADA demand letter?
• ☐ Are any accessibility overlay widgets installed? (These do not provide legal protection)

SECTION 12: THE STANDARD WE HOLD OURSELVES TO

Everything we build — for every client, in every industry, at every scale — is built against the standard described in this document. The infrastructure we build around that data is a promise to your customers: made not in words, but in architecture.

The regulatory environment is moving toward us. State by state, jurisdiction by jurisdiction, the floor is rising. The businesses we work with will not be scrambling to rebuild their data practices when that floor rises to meet them. They will already be standing on higher ground.

INTERESTING FINDINGS

• The 20x lawsuit explosion: Online privacy lawsuits in US federal courts went from ~200 in 2023 to ~4,000 in 2024.
• AI and ADA Lawsuits: The 40% increase in pro se ADA filings in 2025 is driven by AI tools like ChatGPT reducing the barrier to litigation.
• The accessiBe FTC fine: A $1 million fine in 2025 proved that overlay widgets are compliance theater, not compliance infrastructure.
• Texas TDPSA: A state law with no size threshold means nearly every US website processes regulated data.
• Third-party cookie death: Browsers are dismantling the infrastructure of passive tracking; first-party data is the only durable alternative.
• SHA-256 Hashing: The bridge between optimization and privacy that allows safe conversion tracking.
• GDPR Fines: €6 billion in fines across the EU show the regulatory ceiling US enforcement is moving toward.

Sources

• HHS — HIPAA Tracking Technology Guidance
• CPPA — Healthline $1.55M CCPA Settlement
• IBM — Cost of a Data Breach Report 2024
• LFL Legal — FTC accessiBe $1M Fine
• Meta Developers — Conversions API Documentation