Skip to content
Reltime
Regulatory rails

Each rail is the same four elements filled for one regulation. Events, proofs, actions and reports. A bank running DORA, AMLR and eIDAS 2 shares one identity layer and one record across all three.

When the rules change, the rail is updated once and the record shows which version applied on which date.

Illustrative workflow
  1. 1

    Events

    What must be recorded

    Vulnerability received, assessed, exploitation confirmed, fix released

  2. 2

    Proofs

    What a third party must see

    Each step signed by an identified person in a defined role, with time and document version

  3. 3

    Actions

    What may only happen once proof exists

    Product release held until the fix is recorded and signed

  4. 4

    Reports

    What the supervisor receives

    Early warning in 24h, notification in 72h, final report within 14 days of a fix

Rail shown · Cyber Resilience Act

Who it reaches · Manufacturers of products with digital elements, including own-brand retailers

Events recorded
Vulnerability received, assessed, exploitation confirmed, fix released
Proofs
Each step signed by an identified person in a defined role, with time and document version
Actions gated on proof
Product release held until the fix is recorded and signed
Reports generated
Early warning in 24h, notification in 72h, final report within 14 days of a fix
Illustrative workflow
Step 1 of 5
  1. Awareness · anchored 09:14
  2. +24h · Early warning
  3. +72h · Notification
  4. Fix available
  5. +14 days · Final report
NIS2, DORA and CRA each have their own reporting stages and deadlines. This example shows CRA.

Supplier evidence before the goods arrive.

From 11 December 2027 every unit placed on the EU market needs complete CRA evidence. Goods without it stay in the warehouse. Suppliers seal their declaration, vulnerability contact point, support period and software bill of materials per product version, once. Every item gets a status before sale. If evidence changes or is withdrawn, the alert goes out at once. The trail is kept for the ten years the CRA requires.

Illustrative workflow
  • Router X2 · v1.4✓ Declaration✓ Contact point✓ Support period✓ SBOMReady
  • Smart plug S · v2.0✓ Declaration✓ Contact point✕ Support period✕ SBOMMissing
  • Laptop L15 · v3.1✕ Declaration✓ Contact point✓ Support period✓ SBOMWithdrawn

Who it reaches · Essential and important entities in 18 sectors

Events recorded
Security measures, incidents
Proofs
Incident owner, classification and every escalation signed with role and time
Actions gated on proof
Access to essential systems
Reports generated
Incident notifications

Who it reaches · Financial entities and their ICT providers

Events recorded
ICT incidents, third-party changes, tests
Proofs
Approval chain with roles and the rule version that applied
Actions gated on proof
Change to critical ICT services
Reports generated
Incident and register reporting

Who it reaches · Providers and deployers of high-risk AI

Events recorded
Training data, consent, model versions
Proofs
Model version and responsible role bound to each decision
Actions gated on proof
Model release
Reports generated
Technical documentation and logs

Who it reaches · Obliged entities under EU AML rules

Events recorded
Customer checks, status changes, alerts
Proofs
Attestations from issuers, checked against their signatures
Actions gated on proof
Transactions above risk thresholds
Reports generated
Ongoing monitoring trail

Who it reaches · Relying parties accepting the EU wallet

Events recorded
Identity verifications per purpose
Proofs
Wallet attestation received, issuer and time of check
Actions gated on proof
Access and onboarding
Reports generated
Verification receipts

Who it reaches · Producers of products, now including software

Events recorded
Product state at release, changes, updates
Proofs
Release and update decisions signed with role, time and version
Actions gated on proof
Release of software and updates
Reports generated
Evidence pack for disclosure

Who it reaches · Lenders and credit intermediaries

Events recorded
Creditworthiness checks, disclosures
Proofs
Each assessment bound to the rule version and the responsible role
Actions gated on proof
Credit decision and payout
Reports generated
Per-decision evidence

One identity layer under every rail. eKYC and self-held identity with continuous monitoring.

See identity as evidence →
The question that comes

7%

A payment instruction is released only when an anchored acceptance exists. Delivery, inspection, approval and payment reference sit in one chain that the payer, the donor and the auditor can each check.

The bank or treasury stays the payer and keeps its own responsibilities. Reltime gates the instruction and holds the proof.

Illustrative workflow
Step 1 of 7
  1. 01

    Delivery recorded

  2. 02

    Inspection signed

  3. 03

    Acceptance anchored

    Anchored
  4. 04

    Approvals

    Two roles

  5. 05

    Payment instruction released

    Released
  6. 06

    Payer executes

Alternative branch · inspection fails

  1. 01

    Inspection failed

    Failed
  2. 02

    Instruction held

    Held
  3. 03

    Alert to the contracting officer

    Alert

ObligationWorkflowControlEvidenceStays with you
NIS2 incident handlingDetection to notificationOwner assigned and escalation enforcedSigned timeline of every stepClassification and reporting decision
DORA ICT third-party riskChange to a critical ICT serviceChange held until approvals are anchoredApproval chain with roles and rule versionRisk appetite and supplier choice
CRA vulnerability reportingVulnerability to fixRelease held until fix is signed24h / 72h / final report drafts from the recordSubmission to the authority
GDPR data minimisationIdentity checksProof shared, copy withheldAttestation receiptLawful basis and retention
AI Act loggingModel decisionModel version bound to each decisionEvent log with inputs reference and versionRisk classification of the system
AMLR ongoing monitoringCustomer relationshipAlert on status change or anomalyAnchored monitoring trailRisk assessment and action

Reltime is designed to support these obligations. Responsibility for compliance remains with your organisation.

For people with protected personal details, a single wrong look-up can put a life at risk. Reltime evaluates the request before the data is released, records the decision and alerts the responsible team when someone without access tries.

Illustrative workflow
Step 1 of 7

Clinician

  • 1 Request record

Local control point

  • 2 Local decision in milliseconds
  • 4 Local log written
  • 7 Branch B · emergency break-glassApproved · flagged

Patient record system

  • 3 Permitted fields only

Reltime network

  • 5 Anchored after the decision

Security team

  • 6 Branch A · access outside roleDenied · alert
Care never waits for the network. The decision is made locally and the evidence is anchored right after.
  • No new register.

    Protection status is read where it already lives, at every check. No list of protected people is ever built.

  • Everything stays with the organisation.

    The full decision record stays in its own log. Only a checksum goes to the network.

  • Safe failure, per flow.

    If the control point does not answer, mailings and invoices are held, referrals go through with contact details masked, and urgent reading is granted as emergency access and flagged for follow-up.