Find out whether you can prove why you email people

What: Using Breeze Assistant to run a consent and lawful basis readiness audit across your portal: whether HubSpot's privacy features are actually switched on, whether every subscription type maps to a documented purpose, which contacts have no recorded basis for being marketed to, where consent looks inconsistent or has been quietly overwritten, and which forms are collecting personal data without proper consent options. The output is a prioritised gap list, not legal advice, and every genuinely legal decision is flagged for a human.

Consent is the part of compliance that everyone assumes was handled by somebody else, at some point, probably around 2018. The forms have a tick box, the emails have an unsubscribe link, and so the subject quietly drops off the agenda. Then one day a specific question arrives about one specific person, why are you emailing me, when did I agree to this, and on what basis are you holding my data, and the answer has to come out of the CRM in minutes rather than out of a meeting in a fortnight. That is the moment you find out whether your consent is evidence or just decoration.

There is a detail about HubSpot that catches a surprising number of portals out. The GDPR features are not enabled by default. Lawful basis tracking, the privacy settings, the consent options on forms, all of it has to be deliberately switched on, and enabling GDPR functionality is effectively a one-way decision that changes how contact records behave. Plenty of teams believe they are covered because the platform is capable of it, without anyone ever having turned it on. Capability is not compliance, and the gap between the two is invisible until somebody asks.

Even in portals where it is switched on, the same handful of problems recur with remarkable consistency. One catch-all consent tick box standing in for what should be several granular subscription types, so you cannot show what each person actually agreed to. Imported lists sitting in the database with no recorded basis at all, because the spreadsheet did not carry one. Subscription states changed by hand, for reasons nobody documented. Integrations writing over an opt-out because a sync did not respect it. Forms collecting personal data with no consent options attached. Individually each looks minor. Together they mean you cannot evidence your right to contact a large part of your own database.

So this week's prompt turns Breeze into the auditor. It works through your portal's consent posture layer by layer, from the settings, to the subscription types, to the contacts themselves, to the forms feeding new people in, and produces a prioritised list of the gaps that would matter if you were asked to defend them. One important boundary, stated plainly in the prompt itself: this is a readiness assessment, not legal advice. Breeze can tell you where the evidence is missing. Deciding which lawful basis applies, or whether a record should be deleted, stays with you and your legal adviser or data protection officer, which is exactly where it belongs.

Prompt structure

Paste this into Breeze Assistant and make sure CRM data access is enabled in your AI settings so Breeze can reference your contacts, subscription types, consent and lawful basis properties, form submissions, original sources, and import history:

Role: You are a CRM data governance analyst who audits HubSpot

portals for consent and lawful basis readiness. You know HubSpot's

GDPR features are not enabled by default and must be deliberately

switched on, that lawful basis is tracked per subscription type for

marketing communications, and that a platform being capable of

compliance is not the same as a portal being compliant. You produce

evidence-based findings, and you never pretend to give legal advice.




Task: Audit our consent and lawful basis posture and tell me where we

could not currently evidence our right to contact someone. Work

through the settings, the subscription types, the contact records, the

sources those contacts came from, and the forms collecting new data.

Give me a prioritised gap list, ordered by risk, with the specific fix

for each. Flag every decision that needs a human or legal judgement

rather than making it yourself.




Context:




- Company: [COMPANY NAME]




- Industry: [INDUSTRY], and any sector rules that apply:

[e.g. financial services, healthcare, education / none]




- HubSpot tier: [Marketing Hub edition]




- Where our contacts are based: [e.g. UK and EU, or global], since

it determines which rules bite hardest




- Roughly how many marketable contacts we hold: [NUMBER]




- Main ways contacts enter the database: [forms / imports / manual

entry / integrations, and name the integrations]




- Do we know if GDPR functionality is switched on in this portal?

[yes / no / UNKNOWN]




- Who owns privacy internally: [role or name, or "nobody formally"]




Audit the following, in this order:




1. SETTINGS AND FOUNDATIONS




Establish what is actually turned on, rather than what could be:




- Is GDPR functionality and lawful basis tracking enabled in this

portal, and is it being used in practice rather than just

switched on?




- Are cookie and consent banners configured for HubSpot-hosted

pages?




- Is there a documented owner for privacy, and does anything in

the portal reflect that ownership?




- Flag clearly where you cannot see a setting from the data

available, so it can be checked manually




2. SUBSCRIPTION TYPES AND PURPOSES




This is where lawful basis actually lives for marketing:




- List our subscription types and, for each, the communication

purpose it represents




- Flag any that are vague, overlapping, or doing the work of

several purposes at once, since a single catch-all subscription

cannot evidence what someone specifically agreed to




- Identify purposes we clearly communicate about but have no

matching subscription type for




- For each type, note whether a lawful basis is recorded and

consistently applied




3. CONTACT-LEVEL EVIDENCE




The heart of the audit. For our marketable contacts:




- How many have no recorded lawful basis or consent status at all,

and which segments do they cluster in?




- Break the gaps down by how the contact entered the database,

since imports, manual entry and integrations are usually far

worse than form submissions




- Identify contacts whose consent status looks internally

inconsistent, for example marketable with no basis recorded, or

an opt-out that appears to have been overwritten later




- Flag contacts with no engagement for a long period whose basis

rests on consent, since ageing consent is the weakest evidence

of all




4. SOURCES AND ENTRY POINTS




- For each main route into the database, assess whether consent

or basis is captured and recorded at the point of entry




- Flag imports with no accompanying basis, and integrations that

create or update contacts without respecting subscription state




- Identify where an opt-out could be overwritten by a sync or an

import, which is the most damaging failure of the lot




5. FORMS AND COLLECTION




- Which forms collect personal data without GDPR consent options

enabled?




- Where is consent wording vague, bundled, or pre-selected rather

than a clear and separate choice?




- Where should granular options replace a single tick box, based

on the subscription types we actually run?




6. PRIORITISED GAP LIST




- Order every finding by risk: how many people it affects, how

actively it is creating exposure, and how hard it would be to

defend if challenged




- For each, the specific remediation, and whether it is a

configuration fix, a data fix, or a decision for a human




- Separate the fixes that are safe to make now from those that

need legal sign-off first




Constraints:




- This is a readiness assessment, NOT legal advice. Do not decide

which lawful basis applies to a contact or a purpose, do not draft

legal wording, and do not declare us compliant or non-compliant.

Identify evidence gaps and route the judgement to a human




- Never recommend deleting records, changing a consent status, or

altering a lawful basis as an automated action. Every such change

needs a documented reason and an authorised reviewer




- Distinguish clearly between a CONFIGURATION gap (a setting or form

that needs changing), a DATA gap (missing or inconsistent records),

and a DECISION gap (something only a person can determine)




- Order findings by risk, not by ease of fix. The gap affecting the

most people, or actively creating exposure with every send, comes

first




- Where suppression is the safer interim step than deletion, say so.

Stopping contact is reversible; deleting a record is not




- Do not invent counts, consent records, or settings. If something

you need is not visible from the current context, state:

"SIGNAL MISSING: [what needs checking manually]"




Output format:




### I. READINESS SUMMARY




{3 sentences: the state of our consent evidence today, the single

biggest exposure, and an overall readiness rating: NOT DEFENSIBLE /

PARTIALLY EVIDENCED / DEFENSIBLE WITH GAPS}




### II. FOUNDATIONS CHECK




| Setting or Control | Status | What It Means | Check Manually? |




### III. SUBSCRIPTION TYPES AND PURPOSES




| Subscription Type | Purpose It Represents | Basis Recorded? | Issue |




### IV. CONTACT-LEVEL GAPS




| Segment or Source | Contacts Affected | Gap | Risk |




### V. ENTRY POINTS AND FORMS




| Route or Form | Consent Captured? | Overwrite Risk | Fix |




### VI. PRIORITISED GAP LIST




| Priority | Finding | People Affected | Config / Data / Decision | Remediation | Needs Legal Sign-off? |

Why this prompt works, and how to adapt it

Compliance content tends to arrive as a checklist of things you ought to have done, which is useful precisely once and then sits in a drawer. This prompt does something more useful and more uncomfortable: it looks at what your portal actually contains today and tells you which parts of your own database you could not defend. That shift, from a general list of good practice to a specific inventory of your own gaps, is the difference between feeling reassured and actually being ready.

A few things to note about how it is constructed:

It checks what is switched on, not what is possible. The audit starts at the settings layer for a reason. Because HubSpot's privacy features have to be deliberately enabled, and enabling them is effectively permanent, a portal can look modern and capable while tracking almost nothing. Establishing what is genuinely active before looking at any records stops the whole audit resting on an assumption that turns out to be false.

It goes after evidence, not intentions. The question the prompt keeps asking is not whether you believe you have consent, but whether you could show it. That distinction is the entire subject: a tick box someone clicked in 2019, with no record of what they were agreeing to, is a memory rather than evidence. Framing every finding around defensibility is what makes the output useful to the person who would have to answer the question.

It segments the gaps by how contacts arrived. This is where the audit earns its keep, because the failure is almost never evenly spread. Form submissions usually carry decent records; old imports, manual entry, and integrations usually carry none. Breaking the gaps down by entry route turns an intimidating number into a small set of specific, fixable causes, and tells you where to stop the leak rather than just how big the puddle is.

Overwritten opt-outs are singled out. Of everything the audit looks for, an opt-out that a sync or an import has quietly written over is the most damaging, because it means you are actively contacting somebody who explicitly asked you not to, and the record no longer shows that they did. It is also the failure most likely to generate a complaint rather than merely a finding, which is why the prompt hunts for it specifically.

It separates configuration, data, and decision. These are three completely different kinds of work with three different owners and timescales. A form setting is a five-minute fix by one person. A database of contacts with no recorded basis is a project. Choosing which lawful basis applies to a purpose is a judgement for your legal adviser. Labelling every finding stops the easy fixes waiting on the hard ones, and stops anyone accidentally making a legal decision in a spreadsheet.

It refuses to do the legal thinking, on purpose. The constraints explicitly forbid Breeze from choosing a lawful basis, drafting legal wording, or declaring you compliant, and that is a feature rather than a hedge. An AI that confidently assigns legitimate interest to a segment has not saved you work, it has created a false record you might later have to defend. The prompt is designed to produce excellent inputs for a human decision, and to stop cleanly at the point where the decision begins.

“SIGNAL MISSING” matters unusually much here. In most audits an invented figure is an inconvenience. In this one it is a governance risk, because a confident but wrong statement about consent coverage is exactly the kind of thing that ends up quoted in a document somebody relies on. Breeze can see your properties, subscriptions and sources, but it cannot see a setting it has no visibility of, or a consent captured on paper in a meeting, so the flag marks those for a person to confirm rather than smoothing over them.

Adapting it for your portal:

Not sure whether GDPR features are even on? If nobody knows the answer, start there: “We are unsure whether GDPR functionality is enabled in this portal. Tell me what evidence in the data would indicate it is or is not in use, exactly what to check in settings, and what the implications are of enabling it now given it cannot be reversed.” You get a clear diagnosis before you touch anything irreversible.

Sitting on a large legacy database? If the problem is history rather than process, add: “Most of our gaps are in contacts imported before we had a process. Tell me how to segment those records by how defensible they are, where a re-permission campaign is the right answer, and where suppression pending review is safer than either contacting or deleting them.” The output focuses on triaging the legacy rather than boiling the ocean.

Running several integrations? If data flows in from other systems, add: “We sync contacts with [systems]. Focus on whether subscription and consent states survive those syncs, where an opt-out could be overwritten, and what to check in each integration's field mappings.” The audit treats the integration layer as a first-class source of risk.

Preparing for a client or supplier audit? If somebody external is about to ask, add: “We are being audited by a client on [date]. Tell me which questions about consent and lawful basis we could answer confidently from the CRM today, which we could not, and what to fix or document first.” The output becomes a pre-audit readiness check rather than a general review.

Operating across several regions? If your contacts span jurisdictions, add: “Our contacts are spread across [regions]. Flag where our current single approach to consent may not fit every region, and tell me how to segment the database so region-specific rules can be applied.” It will surface where one global setting is quietly doing several jobs.

Want a quarterly cadence? Save the output and re-run it 90 days later with: “Compare against the output from [DATE]. Tell me which gaps were closed, whether the proportion of contacts with no recorded basis has fallen, and whether any new entry point has started creating unevidenced records.” That turns a one-off audit into ongoing assurance, which is the only version regulators find convincing.

The gap list is the start, not the finish. How you work through it decides whether this becomes genuine assurance or just a document that makes everyone briefly anxious.

Stop the leak before you bail out the boat. Fix the entry points first: the forms without consent options, the import routine with no basis captured, the integration that overwrites subscription states. It is tempting to start with the historic database because it is the biggest number, but every day the entry points stay broken is another day of new records you also cannot defend.

Prefer suppression over deletion while you think. Where a contact's basis cannot be evidenced, stopping contact is the safe, reversible move, and it removes the active exposure immediately. Deletion is permanent and occasionally the wrong answer, since some records must be retained for other legitimate reasons. Suppress now, decide properly later, and let the decision be made by whoever is qualified to make it.

Take the decision items to a human, promptly. The findings labelled as decisions are not a failure of the audit, they are its most valuable output: a short, specific list of questions for your data protection officer or legal adviser, with the underlying numbers already gathered. That is a far better use of professional time than asking someone to review a database from scratch.

Then write down what you concluded, because an undocumented decision is nearly as weak as no decision. Record the purpose behind each subscription type, the basis agreed for each, and the reasoning behind any manual change to a consent state. Documentation is what turns a set of good intentions into the audit trail that answers the awkward question quickly.

Nobody sets out to hold data they cannot justify. It accumulates quietly, through imports made in a hurry, integrations nobody re-checked, and settings switched on by someone who has since left. The point of an audit like this is not to feel guilty about that, it is simply to know. A portal whose gaps are documented and being worked through is in a far stronger position than one that has never looked, and the difference between them is a single honest afternoon.