GRC platform
Four modules on one shared core: you enter it once and they all use it
Third parties, continuity, incidents and compliance work on the same inventory, the same evidence and a record of who changed what and when. Whatever you’d rather delegate, our team does as a separate service.
How it’s built
Underneath, what they share; on top, what each module solves
The modules don’t pass copies around: they read and write on the same core. That’s why the supplier you add in Third parties is already in Continuity’s impact analysis, in the incident that affects it and in the risk Compliance reviews.
Third-party risk management
Third parties
You know which supplier has access to what, what they owe you and what is about to expire.
See Third partiesGovernance, risk and compliance (GRC)
Compliance
One control, one piece of evidence, every framework that asks for it. You know what’s missing before anyone asks.
See ComplianceIncident management and reporting
Incidents
You classify what happens and have the report ready, with each regime’s deadline in view.
See IncidentsBusiness continuity
Continuity
You know what depends on what, how long each process can be down and which plan kicks in.
See Continuity
Shared core
One inventory
Suppliers, processes, assets and systems are entered once. Your cloud provider is the same in its assessment, in the impact analysis, in the incident and in the risk.
One evidence repository
Each piece of evidence is stored once, linked to the controls it proves and with its expiry date. You get a warning before it expires, not when the auditor asks for it.
One change log
Every control, risk, piece of evidence and incident records who changed it, when, and which version came before. Your answer to the auditor is a link.
On top, a single sign-in and the same roles across the four modules: everyone sees what concerns them, on the same information.
Who uses it
A working day, role by role
Four people in the same company, each doing their own job on the same data. Nobody copies anything from one place to another.
Illustrative example
Security lead
Starts with what needs attention: a critical supplier with an expired assessment and a piece of evidence that expires on Friday.
Reviews the risk of your cloud provider with its latest incident already on file, without asking anyone.
Pulls the summary for the management committee from today’s data and sends it themselves.
Compliance lead
Sees which evidence expires this month, which controls it leaves unproven and whom to ask for it.
The auditor asks for the backup restore test: it’s attached to its control, with author and date, and it counts for every framework that asks for it.
Exports the statement of applicability (which controls you apply and why) for next week’s review.
Continuity lead
Updates the business impact analysis (how long each process can be down) for the orders process: its suppliers are already in the inventory.
Records the result of the cloud provider outage exercise; it is kept as evidence for the plan.
Checks which critical processes have a plan that hasn’t been tested this year and schedules the test.
Management
Reads the summary prepared by the security lead: what needs attention and what they have to decide.
Accepts a risk that isn’t worth treating; it’s recorded with their name, the date and the reason.
Approves the revised continuity plan. The approval stays in the log, ready for the next audit.
Your suppliers answer for free
The supplier portal has no cost and no licences for them: they receive the questionnaire, answer it and upload their evidence.
Shall we talk about your case?
Tell us what worries you — a supplier, an audit, an untested plan — and we’ll show you the platform on your case.