Reports Your Compliance Officer Will Sign Off

A marketing report your compliance officer will sign off contains aggregate performance, an explicit account of what data left your systems and where it went, and evidence rather than assurances, and it contains no patient identifiers, no procedure-level detail tied to individuals, and no screenshots of ad platform interfaces holding either. Curve is the HIPAA-compliant tracking, attribution, and analytics platform for healthcare, and it produces the forwarding logs, mapping coverage, consent records, and PHI-pattern monitoring that turn a marketing report into something reviewable. A signed BAA is included on every plan.

Why marketing reports get rejected

Compliance officers do not block marketing reports because they dislike marketing. They block them because a report is a disclosure in its own right, and because it is often the first document that reveals a tracking configuration nobody in compliance had ever seen.

Three failure patterns account for most rejections.

The report contains data that should not be in it. A lead export with names and email addresses attached to a service line. A conversion table where the event name is the procedure. A call log with transcript snippets. Any of these makes the report itself a record containing protected health information, circulating by email to a distribution list.

The report asserts compliance without evidence. "All tracking is HIPAA compliant" is not a finding, it is a claim. A compliance officer's job is to ask what was checked, when, and against what. A sentence with no artifact behind it is worse than nothing, because it creates a documented assertion the organization now has to defend.

The report is silent about data flows. The performance section is detailed and the section describing what is sent to Meta, Google, and every other connected vendor does not exist. Compliance cannot approve a data flow it cannot see, so it approves nothing.

The line that matters most

Before structure, get the substantive rule right, because it determines everything else.

In marketing measurement, the thing that turns ordinary analytics into protected health information is the combination of an identifier and a health context. A page view is not PHI. A page view of your bariatric surgery page tied to an email address, a phone number, or a persistent identifier attributable to a person is a different object entirely.

Aggregate counts are generally safe territory. "The knee replacement page received 4,200 sessions" describes no one. "This list of 63 people visited the knee replacement page" describes 63 patients' health interests.

Your report should live on the aggregate side of that line without exception, and should describe rather than reproduce anything on the other side.

What belongs in the report

Aggregate performance

Spend, impressions, clicks, cost per click, conversions by type, cost per conversion, and trend against prior periods. Broken out by channel, campaign, and where relevant by location or service line at an aggregate level. No individual rows, ever.

An explicit data flow section

This is the section most reports omit and the one compliance actually reads. It should name every destination receiving conversion data, state exactly which fields go to each one, confirm identifiers are hashed before transmission, and state that event names are neutral rather than clinical.

"We forward hashed email and hashed phone to Meta CAPI and Google Ads Enhanced Conversions under neutral event aliases, and no other fields" is a sentence a compliance officer can evaluate. "We use server-side tracking" is not.

Vendor and BAA status

A list of every vendor touching marketing data, and for each one whether a BAA is in place. Include the uncomfortable entries. Meta and Google do not sign BAAs for their advertising products, and a report that pretends otherwise fails on its first read. The correct framing is that no BAA exists with those platforms, and therefore only de-identified hashed identifiers under neutral event names are forwarded.

Consent posture

Whether a consent mechanism is live, which categories it governs, how declines are handled, and whether records are retained. If your reporting excludes sessions where analytics consent was declined, say so, because otherwise a year-over-year comparison looks like a performance change when it was a policy change.

Monitoring evidence

What was checked during the period and what it found. Mapping coverage, unmapped events, destination delivery outcomes, PHI-pattern detection hits and how each was handled. A period with zero findings is fine if you can show the monitoring ran. A period with findings and documented remediation is stronger than a period with no monitoring at all.

Changes made during the period

New tracking scripts, new destinations, new fields mapped, new vendors, new landing pages with forms. Change is where exposure enters, and an undisclosed change discovered later damages trust in every previous report.

Open issues and owners

Anything unresolved, with a name and a date. Compliance officers are far more comfortable with a known issue that has an owner than with a clean report that turns out to be incomplete.

What must never appear

• Patient names, emails, phone numbers, or addresses. Including in an appendix, including in an attached export, including in a screenshot.
• Individual-level rows of any kind. If a row describes one person, it does not belong in a marketing report.
• Event or campaign names that state a condition or procedure alongside identifiable data. Aggregate campaign names are usually fine. A conversion event named for a diagnosis, attached to a person, is not.
• Call recordings, transcripts, or excerpts. These are PHI. Reference the existence of call data, keep the content in BAA-covered systems.
• Session replay clips. Same reasoning. Reference findings, do not embed footage of someone completing an intake form.
• Screenshots of ad platform audience tools. These frequently reveal targeting criteria and list details that should not circulate.
• Unqualified compliance claims. Describe controls and evidence, not conclusions about legal status. Legal conclusions belong to counsel.

How Curve produces the evidence

Curve is HIPAA-compliant ad tracking, attribution, and analytics for healthcare, and the reason it can support a compliance-ready report is architectural. The tracking script installs in place of the Meta Pixel and Google tag, events go to Curve's US-hosted infrastructure rather than directly to ad platforms, and Curve controls what leaves. Because everything passes through one place, there is a record of it.

• Per-destination field mapping. Only explicitly mapped fields forward to a given destination and the default is that nothing goes. This is the single most useful thing you can show a compliance officer, because it converts "what do we send to Meta" from a research project into a configuration you can read off a screen.
• SHA-256 identifier hashing. Personal identifiers are hashed per each platform's conversion API requirements before forwarding, so the platform receives a match key rather than a contact record.
• Neutral event aliases. Your team keeps descriptive internal names while the ad platform sees a neutral alias that does not disclose the service line.
• PHI-pattern detection. A monitoring layer that flags PHI-shaped values such as SSNs, MRN-style identifiers, dates, and long numeric sequences arriving in event payloads. It is detection-only by policy, which is the honest description: protection comes from field mapping plus hashing, and detection tells you when a form started sending something new.
• Event logs and destination delivery outcomes. Per-destination delivery attempts and platform responses, so "we sent it" is an auditable fact rather than an assumption.
• Compliance posture reporting. Mapping coverage, unmapped events, verified domains, active destinations, forwarding status, and recent PHI safeguard activity, exportable as a JSON report for a chosen date range. That export is an artifact your compliance officer can retain alongside the narrative report.
• Consent management with audit records. Banner configuration, categories, jurisdiction behavior, consent analytics, and audit logs, so the consent section of your report cites records rather than intentions.
• Signed BAA on every plan. Which is what allows the detailed data to sit inside Curve in the first place.

For the underlying design, see our technical overview of conversion API architecture and why client-side pixels create exposure.

A report structure that gets approved

1. Period and scope. Dates, properties, accounts, and locations covered. Anything excluded, stated explicitly.
2. Performance summary. Aggregate only. Spend, conversions, cost per conversion, trend.
3. Channel and campaign detail. Still aggregate. Neutral event names throughout.
4. Data flow statement. Destinations, fields forwarded to each, hashing, event naming.
5. Vendor and BAA register. Every vendor, BAA status, and the basis on which non-BAA platforms receive anything at all.
6. Consent summary. Mechanism, categories, handling of declines, effect on reported numbers.
7. Monitoring findings. What ran, what it flagged, what was done.
8. Changes this period. Scripts, destinations, fields, vendors, forms.
9. Open items. Issue, owner, target date.
10. Evidence appendix. Exported configuration and monitoring artifacts, containing no individual-level data.

Send the same structure every month. Predictability is most of what makes review fast, and a compliance officer who knows exactly where to look in section four stops treating the whole document as an investigation.

Habits that make sign-off routine

Involve compliance before the campaign, not at the report. A new landing page with a new form is a data flow change. Raising it in advance takes ten minutes. Discovering it in a report takes a week.

Write the data flow section once and maintain it. It should change only when your configuration changes, and when it does change, that is the headline of the report.

Report findings honestly. A period where PHI-pattern monitoring flagged a form and you fixed it is a good report. Suppressing it and having it surface during an audit is the thing that ends the trust relationship.

Keep the artifacts. Exports, screenshots of configuration, delivery logs. Not because anyone reads them monthly, but because in an inquiry the question is always what you could show, not what you said.

Use one vocabulary. If your compliance officer says disclosure and your report says data sharing, the two of you will spend the meeting reconciling language instead of reviewing controls.

Frequently asked questions

Can a marketing report include a list of leads?

No. An individual-level list from a healthcare marketing funnel ties identifiers to health interest, which makes the report itself a record containing protected health information circulating on an email thread. Report counts, not people.

Do we need a BAA with Google and Meta to report on their performance?

You cannot get one for their advertising products, and reporting on aggregate performance does not require one. What matters is that only hashed identifiers within explicitly mapped fields, under neutral event names, ever reach them, and that your report says so plainly.

Is aggregate data always safe to include?

Generally, but use judgment with very small counts. A single conversion at a one-provider location for an unusual service can be effectively identifying in a small community. Suppress or combine cells that get small enough to point at a person.

What evidence should sit behind a compliance section?

Configuration exports showing which fields map to which destinations, delivery logs showing what was actually sent, monitoring output showing what was flagged and remediated, and consent records. Artifacts a reviewer can open, not summaries of them.

How often should this report go out?

Monthly for performance and controls, with an immediate note whenever a data flow changes. The out-of-cycle change note matters more than the monthly rhythm, because change is when new exposure enters.

Who should actually sign off?

Whoever owns HIPAA compliance for the organization, with marketing named as the preparer. Both names on the document is the point: it records that the data flows were reviewed by someone qualified to review them.

Our agency prepares the report. Does that change anything?

It raises the bar. An agency handling identifiable healthcare data is a business associate and needs a BAA with you, and its subprocessors matter too. The vendor register in your report should list the agency and the tools it uses on your behalf.

Where to start

Write the data flow section first, before any performance numbers. Listing every destination and the exact fields going to each one is the exercise that usually surfaces the real problem, and it is the section that determines whether the rest of the report gets read or returned.

Curve gives healthcare marketers the evidence that section requires: per-destination field mapping with a default of nothing forwarded, SHA-256 hashed identifiers, neutral event aliases, PHI-pattern monitoring, per-destination delivery logs, exportable compliance posture reporting, consent records with audit logs, and a signed BAA on every plan. Run our free compliance scanner to see what your site is currently sending, or visit curvecompliance.com to build a reporting pack your compliance officer will approve. Related reading: compliant conversion tracking setup across Google, Meta, and Microsoft.

Reviewed August 2026. Regulatory guidance, ad platform terms, and healthcare advertising policies change frequently. This is not legal advice. Verify current requirements with your own counsel before implementation.