Common-control superset
One governed library per domain; each framework projects off it.
The governed control library: every framework, every control, and the common controls between them, read through one API.
ControlRegistry is the shared substrate: a superset control library where each framework's controls project from common controls, with graded STRM credit between them. Approve evidence once and the equivalent control is credited across every framework it maps to.
It is served as a governed, versioned asset: the backbone every product inherits. The only way to read the data is the ControlRegistry API.
The moment a second standard arrives, the same control is answered twice in two vocabularies. A shared library is what stops that becoming two programmes.
The library is served through an API, so a platform team can build against a governed control substrate instead of maintaining a spreadsheet that ages.
A common-control view across client estates, with the mapping strength stated rather than assumed.
One governed library per domain; each framework projects off it.
Full, partial or no inheritance, each with a strength; never an automatic pass.
Scenarios, risks and real-world incidents, readable per control.
The only way in is the ControlRegistry API. That is the differentiator.
Rather than fifteen separate libraries, there is one governed set of common controls, and each framework's controls project from it. That projection is the structure everything else depends on.
Where two controls relate, the relationship carries a strength: full, partial or none. A partial relationship is recorded as partial rather than rounded up into a pass.
Scenarios, the risks the control addresses, and real incidents where its absence mattered. This is what makes a rating or a piece of evidence a judgement rather than a guess.
The library is released as a signed, versioned snapshot. A consumer knows exactly which version it holds, and a control set cannot change underneath a programme mid-audit.
Stated deliberately. A product that only lists what it can do leaves the reader to discover the boundary themselves, usually at the worst moment.
A mapping shows that two controls are related. Whether your evidence satisfies either of them is a judgement made by an auditor, and no library can make it for them.
Credit reduces duplicated work. It does not mean an ISO 27001 control being satisfied causes a SOC 2 criterion to be satisfied, and any product implying otherwise is selling a shortcut that does not exist.
The library is the control substrate. Evidence lives in EvidenceEdge, where it can be graded, sealed and released to an auditor.
A single number across frameworks reads as an assurance level and is treated as one. The library reports relationships and their strength, and leaves the conclusion where it belongs.
ControlRegistry is the substrate the family reads. That is why it sits alone at the top of the product list rather than among the others.
They carry a signed snapshot rather than calling a live service. That keeps each product able to run offline, independently versioned, and separable from the rest, which matters more than the convenience of a live call.
Through the API. That is the route for a platform team building on the library rather than using one of our products, and it is how the library is bought on its own.
AssessEdge rates the controls the library defines; EvidenceEdge grades evidence against them. Both inherit the same control set, which is why a position established in one is intelligible in the other.
| Feature | Milestone | Scope |
|---|---|---|
| Dark library UI (framework + control wiki) | v1.0 | In MVP v1.0 |
| AC pilot cross-framework maps | v1.0 | In MVP v1.0 |
| Library asset + snapshot pipeline | v1.1 | Planned |
| Live pull-credit UX | v1.1 | Planned |
| The Vault + public API | v2.0 | Planned |
| Governance model (SoD / four-eyes) | v2.0 | Planned |
Milestones are roadmap targets rather than shipped dates. Target for MVP v1.0: Live since Aug 2026. Provisioning is white-glove, never self-serve.
Every SecureEdge Advisory product prepares you for a certification, an audit or an assessment. None of them awards one. A certificate is issued by an accredited certification body, an attestation opinion by an independent auditor, and a regulatory finding by a regulator. We prepare the position and facilitate the process; the affirmation is made by someone else, and we do not blur that line.
Everything a product reports is derived from information supplied by your organisation, or by the person representing it. Ratings, maturity levels, readiness figures, mappings between frameworks and any monetary exposure are calculated from those inputs. Where an input is incomplete, out of date or optimistic, the output carries that forward faithfully. A result is therefore a structured statement of the position you have described, not an independent verification that the position is true.
An assessment is a documented position at a point in time. It is useful precisely because it is explicit about what it rests on, and it should be read that way rather than as a proof. Nothing here is a substitute for an audit, and no output should be presented to a regulator, a customer or a board as one.
Part of a family of ten products sharing one governed control library. Provisioning is white-glove and scope follows a due diligence review.