Residency and Consent Need Shared Controls
Regional infrastructure and product controls support governance, but compliance still depends on customer decisions and implementation.
Residency is an architecture choice
Residency starts with a map of where data actually goes, not with a region named on a commercial plan. The map has to cover content, account records, audit events, logs, backups, administrative access, monitoring, and anything the customer's own integration exports. Regional hosting constrains some of those paths. It does not describe the rest.
A residency claim that names no systems is not a claim about anything.
A content platform holds several classes of data at once. Published interface copy is public by design. Drafts, user accounts, approval records and delivery logs are not. Requests carry locale, environment and targeting inputs chosen by the host application, and an API that accepts a string will accept an identifier nobody meant to send.
Minimise at the boundary. Governing data you did not need to collect is the expensive way round.
Backups are where the tidy primary-region diagram fails. Ask where replicas sit, who can restore one, and what retention does after a deletion request. Ask which engineers can reach production, and under which recorded procedure. None of that is settled by a control in a user interface, which is why a residency claim belongs to named data classes and named services rather than to the product as a whole.
Consent that does not change what the system sends is a record, not a control.
PDPL readiness has limits: the platform supplies controls and records, the customer still owns the obligation.
Map every residency or consent requirement to an owner, a control and an evidence source before production use.
Security controls need configuration
Roles, audit records and environment separation are control points, not controls. They become controls when somebody assigns them narrowly and keeps them that way, and they stop being controls quietly.
A broad administrator role handed to routine publishers cancels every narrower permission underneath it. A shared login makes each audit entry unattributable no matter how complete the log is. A test credential with production reach walks straight past an approval flow that took a quarter to design.
API credentials want the lifecycle you already give production secrets: a secrets store, one environment each, rotation on your own risk schedule. They must not sit in a public client if that exposes privileges meant to stay server side, and an authentication failure should fail closed rather than fall back to something unprotected.
Logs that record whole payloads become the next thing you have to govern.
Publishing governance should follow consequence rather than habit. Campaigns carries named reviewers and will not release a deployment until they have signed; a typo fix does not need that, and a change to a fee explanation or a consent notice does. Classify the surfaces first, then set the roles to match.
Consent has to change behaviour
A consent banner is a screen. The control is what the system does differently once the answer is recorded.
ContentFlow makes that visible in two places. Audiences can read consent state when deciding whether a user is eligible or reachable at all, and Messaging Channels runs a consent gate at send time that splits the list into sent and skipped. Both of them read consent records your application captured. Neither captures consent for you, and neither knows about the purposes you defined outside ContentFlow.
So the dependency map is yours to draw: each purpose to the code, the service and the stored data it touches. Withdrawal has to close every path, not the one the banner knows about. The wording and the runtime behaviour have to describe the same thing, which is testable, and should be tested.
The consent record needs enough context to be readable a year later: the purpose as it was presented, the version of that wording, the choice, and the system that enforced it. More identifying detail than that is another governance burden you have just created for yourself.
Sensors is in preview behind a feature flag and its collection is consent-aware. Consent-aware is not a consent architecture, and a feature flag decides availability, not lawful purpose.
What the platform supplies
Controls and records that exist in ContentFlow once somebody configures them.- Consent-aware eligibilityAudiences can read consent state when deciding who is eligible or reachable.
- A consent gate at send timeMessaging Channels splits a send into consented and skipped.
- Named reviewersCampaigns holds an approval state a deployment cannot leave unsigned.
- Audit recordsPublishing actions are recorded and can be produced as evidence.
- Regional hostingScoped to the workloads and stored data it names, not to every path.
What the customer still owns
None of it moves to the platform because the platform has a control for it.- Capturing consentAnd defining the purposes each recorded choice covers.
- The notice wordingAnd which version of it a given record refers to.
- Opt-out and retentionIncluding what deletion has to mean downstream of the platform.
- Provider accountsCredentials, sender identities, quotas and template approvals.
- The decision to re-askWhether a changed purpose invalidates the choices already held.
Every row on the left is a control somebody has to configure and keep configured. Every row on the right stays with the customer whatever the platform does. The requirements worth finding before production are the ones that map to neither column.
PDPL readiness has limits
Regional infrastructure and product controls can support a PDPL programme. They cannot make an implementation compliant, because compliance lives in purposes, notices, contracts, retention rules and response procedures that no vendor holds on your behalf.
A control that exists and is configured wrongly is indistinguishable from one that does not exist.
Readiness work is a conversion. Every requirement becomes a control with a named owner, a system it lives in, an expected configuration, and an evidence source somebody can produce on the day it is asked for. Some of that evidence comes from the content platform. The rest sits in identity systems, application logs, ticketing and internal policy, and the gaps are almost always at the hand-off between two of them.
Then decide how you would notice a control failing. An audit log proves a notice changed; only a rendered test proves users received the new one. A regional deployment constrains storage while an employee exports content to a laptop. A consent record sits in the database while downstream code carries on processing.
Follow the data to the end of the chain, then write down where the platform's responsibility stops and the customer's starts.