Platform
One record. Every module reads it.
A vendor engagement, a policy clause, an audit finding, and a risk can all point at the same control, because there is only one control library underneath.
Reading the same record
Risk register
scores against it
Architecture
Five layers, one thread
Each layer references the one below it. That is what makes traceability a property of the model rather than a reporting exercise run after the fact.
- 1OrganisationLegal entities, locations, departments, and functions, modelled separately, because regulators care about the legal structure and work happens in the operational one.
- 2Business catalogDomains, capabilities, services, processes, and objectives, so technical findings can be expressed as business impact.
- 3Control libraryJurisdictions, authorities, domains, controls, questions, and maturity descriptors. Every framework is a view onto this layer.
- 4Risk and complianceRegisters, assessments, and indicators that all resolve against the same controls rather than keeping private copies.
- 5Evidence and auditReviewed evidence, findings with dependency-aware remediation, and an append-only platform audit log.
Control library
Frameworks are views, not silos
One control carries mappings to every standard that references it, each graded rather than boolean, with one standard marked primary.
Frameworks and controlsControl
Privileged access is reviewed each quarter by the system owner
PPTDF applicability
One owner · one procedure · one evidence trail
- PaymentsDomain
- Card acquiringCapability3 risks2 policies
- Merchant settlementService4 controls2 assets
- Daily reconciliationProcess1 risk2 controls1 finding
Every level links out to risks, controls, policies, findings, assessments, and assets
Business context
Impact answered structurally
Because every catalog level carries typed links, questions like which objectives depend on this process become queries rather than investigations.
Business catalogDeployment
On your infrastructure, or ours
Both modes are supported and maintained. For organisations with hard data-location requirements, on-premise is a real answer rather than a roadmap item.
Single-tenant, on-premise
One organisation, one deployment, running on infrastructure you control. Where data lives is your decision, not a vendor policy.
- Deployed into your own environment
- Single company record in the database
- No dependency on shared hosted infrastructure
Multi-tenant SaaS
Hosted, with strict row-level isolation by company. Users may hold access to several companies and switch active context explicitly.
- Row-level isolation enforced by company foreign key
- Access validated per company on every request
- No default-company fallback in critical paths
Access model
Permissions per action
Bundles operate on individual lifecycle transitions, which is what makes segregation of duties demonstrable rather than asserted.
Access control and RBAC| Action | asset-viewer | asset-coordinator | asset-approver | asset-admin |
|---|---|---|---|---|
| View | Allowed | Allowed | Allowed | Allowed |
| Create and edit | Not allowed | Allowed | Not allowed | Allowed |
| Submit for intake | Not allowed | Allowed | Not allowed | Allowed |
| Send to review | Not allowed | Allowed | Not allowed | Allowed |
| Send back | Not allowed | Allowed | Allowed | Allowed |
| Approve | Not allowed | Not allowed | Allowed | Allowed |
| Activate | Not allowed | Not allowed | Allowed | Allowed |
| Module settings | Not allowed | Not allowed | Not allowed | Allowed |
Every module ships bundles at this granularity. Segregation-of-duties conflicts are declared as rules, with logged exceptions.
See the platform against your own structure
Bring your entity hierarchy and the frameworks you report against, and we will walk the model end to end.
No commitment required. A typical demo runs 45 minutes.