Event schema governance
An event payload is also a data disclosure
Publishing a field creates another accessible copy. Review subscribers, replay tools and retention before adding personal or commercially sensitive information.
In this article
Follow the payload beyond the broker
A customer event may travel into analytics storage, a search index, a dead-letter queue and an engineer's diagnostic export. Restricting the primary application does not automatically restrict these copies.
List the destinations that receive the payload and the identities that can subscribe or replay it. Include operational tooling. A support role that can download failed messages may see more information than the ordinary application screen exposes.
Treat topic access as a real data boundary. A general integration topic is a poor place for sensitive fields intended for one specialised consumer.
Ask why each field must travel
For a delivery notification, the receiving service may need a contact destination and shipment reference. It probably does not need the customer's full account history. Prefer a contract that matches the action being performed.
Replacing data with an identifier can reduce exposure, but only if the lookup endpoint enforces appropriate authority. An unrestricted lookup service simply moves the disclosure elsewhere. It also introduces availability and historical-consistency dependencies that must be understood.
Where historical values are essential, preserve the minimum relevant versioned facts. Explain why the event must carry them and which consumers are authorised to retain them.
Separate useful diagnostics from raw content
Log event identity, contract version and a bounded failure reason by default. Keep full payload inspection behind a controlled workflow with a defined retention period.
A schema validation error can accidentally include the rejected value. Test error messages using synthetic sensitive content and inspect logs, alerts and tracing exports. Redacting the main payload is insufficient if the exception reproduces it elsewhere.
Encrypted transport and storage are useful protections, but they do not answer who can read a message after decryption. Review service permissions and human access separately.
Include the older copies in change planning
Removing a field from future events does not remove it from retained topics, backups or consumer databases. Record those locations and the applicable deletion or retention process.
When access is revoked, check whether replay credentials, exports and derived views remain usable. The review should end with named controls and owners for the actual copies, rather than a statement that the event bus is secure.
Use the relevant privacy and contractual requirements for the specific data involved. Do not assume one retention period is appropriate for every event simply because they share the same platform.
Primary sources
OWASP: authorisation guidanceOWASP: logging guidanceReferences checked 11 September 2026.