How do risk and compliance teams use resimate?

The short answer

resimate does the dependency mapping regulations now require and nobody can keep current by hand: end to end, from critical functions to processes, ICT assets and third parties. On that connected view, risk and compliance teams meet regulatory requirements, spot concentration risk and check recovery objectives against reality. The evidence comes from the same view the teams use to run resilience.

Evidence that passes the audit and still misses reality

Resilience has been measured by documentation for too long. Plans exist, audits pass, and still nobody can say what actually breaks when a dependency fails. When the supervisor asks which ICT assets and third parties support a critical function, the answer gets assembled by hand from a CMDB export, a supplier list and last year's BIA.

Regulators ask for outcomes: identified critical functions, tolerances for disruption, realistic testing and evidence that holds. The binder interpretation is self-inflicted. The evidence is stronger when it comes from the view people use to run resilience every day.

The hard part: an end-to-end dependency map

Regulations like DORA now require what used to be optional: dependency mapping from critical functions to the ICT assets and third parties behind them, and the identification of concentration risk. Doing that by hand once is painful. Keeping it current by hand is impossible.

resimate takes that off your plate. We map the full chain with you, from critical functions to processes, applications and suppliers, using the practitioner method we built running these programs ourselves. The map then stays current as the organization changes.

See your full regulated scope

Classify a service once as a Critical Function, an Important Business Service or NIS2-relevant, and the label flows down the chain to every process, system, site and supplier behind it, color-coded. Your own internal classifications work the same way. You see the full regulated scope, including the assets nobody listed.

The same view shows which ICT third-party providers support which critical function, and where several critical functions depend on the same provider. That is the starting point for third-party and concentration risk. *\[Link: What goes down if your cloud provider fails?\]*

Check whether recovery claims hold

A documented RTO is a claim. The RTO feasibility view checks it against the recorded recovery times of every dependency in the chain, third parties included. It shows where targets conflict, where tested recovery is too slow and where evidence is missing entirely. You find the gap before the supervisor or the incident does. *\[Link: Are your RTOs realistic?\]*

Report against the frameworks you answer to

resimate maps the connected view to the standards and regulations you report against, wherever you operate. Typical examples:

• Global standards (ISO 22301, ISO 27001, ISO 27031, NIST Cybersecurity Framework, IEC 62443)
• European Union (DORA, NIS2, CER Directive)
• Germany, Austria and Switzerland (KRITIS-DachG, FINMA operational resilience requirements, Swiss ICT minimum standard)
• United Kingdom (PRA and FCA operational resilience rules)
• United States (Interagency sound practices for operational resilience, NERC CIP, HIPAA, CMS emergency preparedness)
• Asia-Pacific (APRA CPS 230, MAS business continuity guidelines, HKMA operational resilience)

Your internal policies can be mapped the same way. We work out that mapping together with you, so it reflects how your organization reports. Resilience capabilities can be mapped to asset types and regulations, with their maturity and coverage tracked over time. The report reflects the current state of the organization, because it draws on the same data the teams maintain.

Turn risk appetite into decisions

The Impact-Preparedness Matrix shows where impact is high and preparedness is low. That gives leadership a concrete choice: what gets funded now, what can wait, what the organization accepts. Every capability improvement is recorded with an owner, and an accepted gap stays visible as a decision. *\[Link: How do you prioritize resilience investment?\]*

From the field

Acorn Life, an insurer, had a clear trigger: DORA required dependency mapping and the identification of concentration risks. resimate got that done, starting from its existing process maps and dependency analysis. First dependency map in two weeks, live in 4 to 6 weeks. The bigger change came after: from spreadsheets to dynamic continuity plans.

"I can understand the impact, and I'll be able to explain it to the business and the regulators." Andrea Manning, CISO, Acorn Life

What your own vendor review will ask

resimate holds sensitive data about your critical services, so expect your third-party risk process to check us too. The short version:

• Every customer runs in its own dedicated Google Cloud project, single-tenant.
• Hosting in Zurich or Frankfurt, chosen at contract.
• TLS 1.3 in transit, AES-256 at rest, keys in Google Cloud KMS.
• CSA STAR Level 1 published. The infrastructure runs on Google Cloud, which holds ISO 27001 and SOC 2 Type II.
• Exit: export as CSV or XLSX, deletion within 60 business days, confirmed in writing.
• The full detail is in our CAIQ v4.1.

Your first six weeks

1. Week 1: scope your regulated critical functions and the sources you have: CMDB exports, supplier lists, BIAs, DR test results.
2. Week 2: first dependency map, from the critical function down to ICT assets and third parties.
3. Weeks 3 to 4: regulatory labels across the chain, Minimum Viable Company and recovery checks for your first scenario.
4. Weeks 4 to 6: reporting set up against your frameworks, team trained.

Spreadsheets and exports work on day one. You keep your GRC tool.

See it on your own data

Bring one critical function and the exports you already have. We map it with you and show you its full regulated scope, its third parties and whether its recovery objective holds. Evidence you can explain beats evidence you can file.