ITLedger is a CMDB and IT operations platform with a ready structure, optional onboarding, connected service work, Sentinel and Richard AI assistance.

How does ITLedger onboarding work?

Customers send only the spreadsheets, exports or documentation they want loaded into ITLedger. We import that material, create relationships where the supplied information supports them, and let the customer review the result in the application.

What does ITLedger Sentinel show?

Sentinel brings findings from deliberately enrolled assets and active checks into one explainable attention queue. It supports certificate expiry, licence compliance, vulnerability exposure, external monitoring signals, source freshness, and explicitly mapped custom checks. Severity, thresholds, evidence, and operational impact remain visible.

Is onboarding credited when we subscribe?

Eligible paid onboarding can be credited against the first year of a qualifying annual subscription. Scope, eligibility, timing, and any non-creditable custom work are defined in the commercial proposal.

Is ITLedger always better than broad CMDB platforms?

No. Broad platforms may be better for deep global workflow customisation and organisations with dedicated platform teams. ITLedger is strongest when a lean team wants a working model and migration outcome without designing a large platform programme.

ROPA and NIS2 questions policies can't answer - records can

Short answer

ROPA and NIS2 questions sound different until you write them down: which systems process personal data, who owns them, which suppliers touch them, and what evidence proves the controls exist? A Record of Processing Activities (ROPA) under GDPR article 30 and the duty-of-care expectations in NIS2 both collapse into those same operational questions - and the answers change every month, which is why a policy document can't hold them. ITLedger ships with a ROPA-ready configuration: processing activities, systems, owners and evidence exist as connected data objects in the same CMDB your team already uses, so the register answers from live records instead of a spreadsheet someone updates once a year.

Key takeaways

ROPA (GDPR article 30) and NIS2 ask operational questions, not policy questions - and the answers change constantly.
The honest unit of compliance is a data object: a processing activity, a system, an owner, a piece of evidence - each linked, each current.
A ROPA-ready configuration means the structure already exists; your team fills it with reality rather than designing it.
Software supports the register. The organisation remains responsible for data quality, legal assessment and compliance decisions.

The moment the questions arrive

Every IT manager recognises the moment. A DPO asks for an updated processing register before the annual review. An enterprise customer's security questionnaire lands with 140 rows. The Dutch Cyberbeveiligingswet - in force since 15 August 2026 - asks in-scope organisations to show they know their assets, risks and incident handling. Suddenly, three people spend a week reconstructing answers from memory, old exports and inbox archaeology.

The questions are not exotic. They are the same ones, every time:

Which systems process personal data? Not which ones did last year - which ones do today.
Who owns each system? A name, a team, a deputy - not "IT".
Which suppliers and processors touch the data? Including the SaaS tool marketing adopted without asking.
What depends on each system? Because an incident's blast radius is a compliance question too.
What evidence exists for each measure? Documents, reviews, approvals - linked, not buried.
When was this answer last true? A register nobody can date is a claim, not a record.

Why policies can't answer these questions

Policies describe intent. They are written once, approved once, and they age silently. The questions above are not about intent - they are about the current state of systems, people and data flows. That state changes with every new SaaS subscription, every offboarded admin, every replaced server.

This is why so many ROPA exercises degrade into an annual spreadsheet ritual: the questions are operational, but the tool is documentary. By the time the register is "finished", a quarter of it is historical fiction.

What a ROPA-ready configuration looks like

ITLedger includes a ROPA-ready configuration out of the box. That phrase means something specific: the data objects a processing register needs already exist in the model - processing activities, the systems and applications they run on, the teams and owners responsible, the suppliers involved, and the documents and evidence attached. They are connected records in the same CMDB that drives your daily operational work, not a parallel register in a second tool.

The practical effect:

A processing activity is a record, linked to the systems that carry it out - so "which systems process personal data" is a query, not a project.
Ownership is structural - the same owner records your incidents and changes already use.
Evidence is attached - documents, reviews and approvals hang off the record they support, with history.
Freshness is visible - you can see which records were recently confirmed and which are quietly ageing.

Because the register shares one operating context with service work, it inherits the updates that happen anyway: a system is replaced, an owner changes, a supplier is added - the compliance picture moves with it.

What this changes in practice

Audit and DPO reviews stop being reconstructions. The register is already there; the work is verification, not archaeology.

Customer security questionnaires become answerable from records: system lists, owners, supplier involvement and evidence, exported instead of reinvented.

NIS2 incident expectations get easier to reason about. Reporting duties assume you know what is affected. When systems, dependencies and owners are linked, scoping an incident is measured in queries, not meetings. For the Dutch legal timeline and sector scope, see our NIS2 Netherlands readiness guide.

Governance reviews gain a starting point: the records that look stale, unowned or undocumented stand out on their own.

The boundary we won't blur

ITLedger supports the register and the evidence trail. It does not determine whether your processing is lawful, whether NIS2 applies to your organisation, or whether your measures are sufficient. Those are organisational and legal judgements, and they belong with you, your DPO and your advisors. What the software removes is the excuse that the answers were impossible to find.

If your processing landscape still lives in spreadsheets, the fastest route is the bounded CMDB onboarding: you send the sources, we map and import them under review, and the open questions stay visible instead of being guessed away.

FAQ

What is a ROPA under GDPR?

A Record of Processing Activities is the register required by GDPR article 30, documenting which personal data an organisation processes, for what purposes, on which systems, with which recipients and suppliers, and under which safeguards. It must reflect current reality, not last year's state.

Does NIS2 require a ROPA?

No - ROPA is a GDPR obligation. But NIS2's duty-of-care and incident expectations presuppose the same operational knowledge: which assets you run, who owns them, what depends on them, and what evidence supports your measures. Teams that maintain one connected record set answer both regimes from the same source.

What does "ROPA-ready configuration" mean in ITLedger?

The data objects a processing register needs - processing activities, systems, owners, suppliers, documents and evidence - already exist in the ITLedger model and connect to the same CMDB records used for daily service work. Your team fills the structure with reality instead of designing the register from scratch.

Does ITLedger make us GDPR compliant?

No. ITLedger supports the register, the links and the evidence history. Lawfulness of processing, NIS2 applicability, and adequacy of measures remain organisational and legal responsibilities.