Security and confidentiality
Written for the person asked to review whether live deal data can go into this. What follows is what is architecturally true today, and what is not yet in place.
A separation is not one organisation
Most software treats access control as an organisational question: you work here, so you can see our data. That model does not survive contact with a carve-out.
A single separation programme involves the seller's team and the buyer's team, who must not see each other's commercial positions. It involves external advisors and counsel, whose access should end when their engagement does. It often involves a transaction that has not been announced, inside a company where most employees should not know it exists at all.
Access control here is scoped to the programme, not the organisation, because that is the only model that matches how a deal actually works.
Programme-scoped access by default
Being a member of the customer's organisation does not grant visibility of a programme. Membership is granted per programme, explicitly, and every access path in the system enforces that boundary at the database level rather than in application code.
Row-level security policies govern every table. A query that should not return a row does not return it, regardless of which part of the application issued it. That boundary has been reviewed directly — including an audit of database privileges beyond the row-level policies themselves, because row-level security is only one edge of the permission surface and the others are easy to leave open by accident.
External access, time-bounded and logged
Advisors, counsel and vendors need access to run a deal, and that access should not outlive the engagement.
External participants are granted access to specific programmes with a defined scope, and that access is logged. Privileged vendor access is brokered and recorded rather than handed over as a standing credential. When an engagement ends, access ends with it — not as a policy someone is expected to remember, but as a property of how the access was granted.
Deals that are not public yet
A programme can run under a code name. The people working on it see the code name; the real identity of the target is not scattered across the system for anyone with incidental access to find.
Exports are watermarked with the identity of the person who generated them. A document that leaves the platform carries a record of who took it out, which changes the calculation for anyone considering forwarding it.
Unusual access is surfaced, not filed
An audit log nobody reads is not a control. Access patterns are monitored for anomalies — unusual volume, unusual timing, access to programmes outside a user's normal pattern — and surfaced to the people who would need to act on them.
The audit record itself is append-only. Corrections supersede rather than overwrite, and records supporting the evidentiary trail cannot be deleted by design, including by the organisation that owns them.
Where the data lives
Data is held in the European Union, in Frankfurt. The application runs on managed infrastructure with encryption in transit and at rest as provided by the platform layer.
Tenant isolation is enforced in the database rather than by convention. There is no shared table without a policy governing who can read from it.
What is not in place yet
MeridianCogent is in development and pre-revenue. The following do not exist, and it would be misleading to imply otherwise:
- No SOC 2 report. A Type II requires an observation window and an audit; neither has begun.
- No ISO 27001 certification.
- No third-party penetration test has been commissioned.
- No SSO or SCIM integration. Both require an enterprise identity provider to configure and test against, which requires a customer.
- No data processing agreement executed with any customer, because there is no customer yet.
These are sequencing, not position. They are on the path to a first customer, and a prospective customer's requirements should shape which come first. If your review requires any of them before a pilot, that is a reasonable position and worth telling us early.
If you are reviewing this
Security questionnaires, architecture questions and specific control requirements are welcome, and answering them honestly is more useful to both sides than a page like this one.
Write to hello@meridiancogent.com.
Early access
MeridianCogent is in development. Join the list for updates as we open access.