A rep cannot see another rep's leads.Not even by guessing the address.
Most systems hide a record in the interface and leave it reachable underneath. Here the boundary is enforced by the database, which means it holds even when somebody goes looking around the interface.
These are product controls. They are not a claim of certification, of grant approval, or of a completed independent vulnerability assessment and penetration test. Those are separate gates and they are not being implied here.
6 things, and what each one is for.
Organisation and row-level isolation
A salesperson with owner-only access who types a colleague's record ID straight into the address bar is denied at the server, not shown an empty page that still loaded the record. The same boundary separates one company on the system from another: a known record ID from another organisation returns nothing, not a near miss.
A hidden button is never the security boundary.
Organisation scope · row-level security · cross-tenant tests
Roles, teams and permissions
Role, team, business-unit and resource scopes apply to reads and to actions, and sensitive workflows are checked on the server rather than in the browser.
People reach only what their operating responsibility requires.
Roles · teams · resource scopes · server-side enforcement
A recorded reason for every personal data field
When a field or a capture source is configured, its purpose, its lawful or operational basis, its sensitivity, its retention class and who can see it are all recorded together in a catalogue.
It is the document you will want on the day somebody asks what personal data you hold and why.
Purpose · basis · sensitivity · retention class · visibility
Audit and provenance
Administrative changes, AI actions, exports, deletions, sign-ins and integration activity each write an append-only audit event carrying who did it, what they did, what it touched, whether it succeeded and when. The event records the action without storing the personal data or any secret inside it.
An administrator can reconstruct what changed, who started it and how it ended.
Actor · action · resource · outcome · correlation · append-only
Retention and hard deletion
Retention classes, and the delete or anonymise action attached to each, are configured with you during implementation rather than fixed by us. When a hard deletion runs against an approved request with no legal hold, the records, the generated files and the searchable copies go, and the receipt proves it without reprinting what was deleted. If a record was linked to something outside the system, the receipt states plainly what remains under somebody else's control.
Data leaves through a deliberate process, not just off a screen.
Retention classes · legal hold · hard deletion · receipt · residue checks
Fail-closed AI and integrations
Missing configuration stops the action rather than quietly weakening the control. Provider readiness, permission-filtered context and a human approval are all required before anything sensitive reaches the outside world.
The failure mode is a stop, not a silent downgrade.
Readiness check · permission filter · human gate · terminal failure
Four steps, in this order, every time.
- 01
Authenticate
Establish the user and the organisation.
- 02
Authorise
Check role, team, resource and action scope first.
- 03
Execute
Run the bounded operation at the database boundary.
- 04
Evidence
Write the outcome without writing the secret.
The next three questions.
Thirty minutes, and you leave with three answers.
Which package fits, what we would migrate and how, and what the fixed fee would be. Written down, so you can put it in front of a partner or a board.