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.
The problem
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 program 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 program, not the organisation, because that is the only model that matches how a deal actually works.
Access
Program-scoped access by default
Being a member of the customer's organisation does not grant visibility of a program. Membership is granted per program, 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.
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.
Access rules apply to aggregates as well as records. Counts, dashboard figures, and history do not reveal anything a viewer could not read directly at the record level — this is enforced at the same layer as row-level access, not left to the interface to hide.
Multi-factor authentication can be enforced by an organisation for all of its members. Single sign-on (SAML) and SCIM provisioning are available.
What the platform does
- Records you can read
- ABC
- Records you cannot read
- DE
Count shown
3
The count matches what you can actually open.
What this prevents
- Records you can read
- ABC
- Records you cannot read
- DE
Count shown
5
A count of five would tell you two records exist that you are not allowed to read.
A viewer who can read records A, B and C but not records D and E sees a count of three, because the count is subject to the same access rules as the records behind it. The prevented alternative is a count of five, which would disclose that two records exist that the viewer is not allowed to read.
Access scope
- Organisation
- No
- Program
- Yes
- Advisor
- Bounded
External access
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 records, not to a program's contents. Access is explicit, time-bounded and revocable; removing a share or ending the engagement removes access at the authorization layer, not merely from the interface. 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.
Confidentiality
Deals that are not public yet
A program 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.
An audit log nobody reads is not a control. Access patterns are monitored for anomalies — unusual volume, unusual timing, access to programs 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.
Audit history respects the same access boundary as the underlying record. A change log does not reveal a value the viewer could not read directly.
Customers can export their organisation's authentication, administrative and program audit records for their own assurance and investigation.
Continuity and data
Continuity and data
Data location. Hosted in the European Union, in Frankfurt.
Backup. Point-in-time recovery is enabled for the production database, and the restore procedure is tested. Recovery objectives are available on request.
Subprocessors. Supabase — database and authentication, hosted in Frankfurt. Vercel — application hosting. Resend — email delivery. A data processing agreement is part of every plan; a copy is available on request from hello@meridiancogent.com.
Export and exit. Program data — registers, decisions, and audit history — can be exported in a readable form at any point, including when an engagement ends, so continued access to the application is never a precondition for keeping your own record.
Retention. Audit and evidentiary records follow a defined retention schedule, with contractual retention and legal-hold requirements applied without silently deleting the transaction record. Specific retention periods are set out in the data processing agreement, not asserted here as a universal figure.
Erasure and evidence. Where identity data can be removed without destroying a record that must be retained, MeridianCogent can de-identify the actor reference while preserving the integrity of the underlying decision or audit record. This is not automatic in every case — some erasure requests intersect with a legal basis for retention, and the response depends on the record.
If something goes wrong
If something goes wrong
If MeridianCogent confirms a personal-data breach affecting customer data, affected customers are notified without undue delay through a named security contact, with information provided in phases as the investigation develops. The notification identifies what occurred, the data affected where known, the likely consequences, and the containment and remediation steps taken.
Not in place yet
What is not in place yet
The following do not exist or are not yet complete, 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.
These are sequencing, not position. If your review requires any of them, tell us and we will set out how and when we meet it.
Questions
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.