Asset Management and Data Registries: Every Record Mapped to the Obligations It Triggers

The asset inventory is where most compliance programs quietly go stale.

Someone exports a spreadsheet before an audit. Columns for system name, owner, data type, maybe a "sensitivity" tag filled in from memory. It is accurate for about a week. Then a repository moves, a processor is swapped, a database starts holding a new category of personal data, and the sheet no longer describes the organization. Nobody notices until a supervisory authority asks for the record of processing and the answer is a file last touched four months ago.

The problem is not that teams are careless. It is that the inventory and the obligations live in different places. The spreadsheet knows what you have. The regulation knows what you owe. Nobody keeps the join current.

Aigis closes that gap by making the asset the anchor. Every asset and every data registry carries, as a live property, the obligations it triggers, the controls those obligations require, and the evidence that satisfies them. Change the asset and the obligations recompute. The inventory is not a description you maintain alongside compliance. It is the compliance record.

The asset is the single anchor

In an asset-first model, the asset is the one object everything else hangs off. Its risks, its controls, its evidence, and its regulatory obligations all resolve from it rather than being tracked in parallel systems that drift out of agreement.

This matters because the alternative is what most organizations actually run: a risk register in one tool, a control library in another, an evidence store in a third, and an asset list in a spreadsheet that ties none of them together. Each is internally consistent and collectively wrong, because no single object reconciles them.

When the asset is the anchor, a question like "what protects this database and why" has one answer, derived at read time from the asset's own attributes. There is no second copy to fall out of sync, because there is no second copy.

Data registries as first-class records

A data registry - in Hebrew, a מאגר - is not just another asset. It is a distinct kind of record with its own regulatory weight, and Aigis models it as a first-class entity rather than folding it into a generic system list.

Each registry carries a security level: basic, intermediate, or high. That level is not a label. It binds the controls that level requires. A registry classified at the high level surfaces the stricter access, logging, and protection obligations that come with it; a basic registry surfaces the baseline set. Raise the level and the additional controls appear as requirements against that specific registry, tied to it, not to a general policy nobody reads.

This is the same principle as the asset anchor, applied to the record that regulators most often ask to see. The registry knows its own level, and the level knows its controls. You are not maintaining a separate matrix of "which registry needs what." The registry carries it.

The database-registration regimes that many jurisdictions operate - the registry concept sits at the center of several national data-protection frameworks - reward exactly this structure. When the registry is a real object with a security tier and bound controls, producing a registration or answering a regulator's question about a specific מאגר is a query against a live record, not a reconstruction from memory.

ROPA membership, derived from the asset

The record of processing activities is where the asset-first model earns its keep, and GDPR Article 30 is the clearest illustration.

Article 30 requires each controller to maintain a record of processing activities under its responsibility, and it specifies what that record must contain: the purposes of the processing, the categories of data subjects and personal data, the categories of recipients, transfers to third countries where applicable, the envisaged time limits for erasure where possible, and a general description of the technical and organizational security measures. Processors carry a parallel record duty for the categories of processing they carry out on behalf of controllers. Both records must be in writing, including electronic form, and made available to the supervisory authority on request.

Article 30 also carries a conditional exemption: the record obligation does not apply to an organization employing fewer than 250 persons, unless the processing is likely to result in a risk to the rights and freedoms of data subjects, is not occasional, or includes special categories of data or data relating to criminal convictions and offences. That "unless" is why a headcount check alone never settles whether the duty applies.

So whether a given asset belongs in the ROPA is not a flag someone toggles. It is derived, per asset, from three questions the asset can answer about itself:

→ Does the record-of-processing duty apply to this organization at all, once the Article 30 exemption and its carve-outs are resolved? → Does this asset actually hold personal data? → Is the asset still in use, or has it been disposed?

Membership falls out of those facts. Dispose of a system and it leaves the ROPA. Reclassify a database as holding personal data and it joins. The Article 30 record stops being a document you rebuild before each audit and becomes a view over assets that already know their own status. Every line traces to the asset attribute and the source obligation that put it there, so when a supervisory authority asks, the answer is defensible down to the regulation text.

Classification drives which obligations surface

An asset's classification - whether it holds personal data, and how sensitive that data is - is the input that decides which obligations and which controls appear against it.

This is the opposite of the universal checklist, where every asset inherits every control and teams spend their time marking rows "not applicable." When classification drives surfacing, a system holding no personal data does not raise personal-data obligations, and a registry holding special-category data raises the stricter set. The controls that appear against an asset are the controls that asset's own classification demands, and the framework controls - the Annex-A style control set - surface the same way, gated by what the asset is rather than hand-mapped by someone guessing.

Change the classification and the obligation set recomputes. The requirement to describe technical and organizational security measures, which Article 30 puts on the record for personal-data processing, attaches to the asset that holds the data, not to a policy binder.

Asset, risk, control - resolved at read time

The join that ties an asset to its risks and those risks to their controls is resolved when you read it, not stored as a frozen mapping that someone has to remember to update.

This is the quiet difference between an inventory that stays honest and one that rots. A stored mapping is correct at the moment it is written and decays from there. A read-time edge is computed from the asset's current attributes every time, so it reflects what the asset is now. Swap a control, retire a risk, reclassify the data, and the edges reflect it on the next read. There is no reconciliation job, because there is nothing persisted to reconcile.

Let your own agents build the inventory

The hardest part of any inventory is discovery: finding the assets, and finding what connects to what. This is exactly the tedious, continuous labor that goes undone, which is why spreadsheets rot.

Aigis is built so you can point your own agents at your own systems to do that discovery. Through an open interface - over MCP or the API - an agent running inside your perimeter can enumerate systems, identify which hold personal data, map the connections between them, and submit what it finds. Bring your own agent: Claude Code, or any MCP client. The agent runs under your identity, your logging, your data-loss controls. Aigis never receives a credential to your stack. It receives attested signal, and that signal lands on a record where every obligation still traces to verbatim regulation text.

That is the whole point of the model. The engine is deterministic - obligations and controls are grounded in source law, not generated from a model's memory - which is what makes it safe to let agents do the discovery. Your agents do the work. The engine keeps it honest. Automation without the standing third-party access into your systems that a 2026 CISO is being told to shut down.

The result is an inventory that maintains itself and stays defensible: a living, source-cited record where every asset and every מאגר carries the obligations it triggers, instead of a spreadsheet that was accurate the day you exported it and wrong ever since.

See how the asset-first model handles registries and ROPA membership at agrc.ai/data-registries.

FAQ

Does GDPR Article 30 require every organization to keep a record of processing? Not automatically. Article 30 exempts organizations employing fewer than 250 persons, but the exemption falls away if the processing is likely to result in a risk to the rights and freedoms of data subjects, is not occasional, or involves special categories of data or data relating to criminal convictions and offences. Because those carve-outs are common, many smaller organizations still carry the duty. An asset-first model resolves the condition per organization rather than relying on a headcount check alone.

What does "first-class data registry" mean in practice? It means the registry (מאגר) is a real record with its own security level - basic, intermediate, or high - and that level binds the controls it requires. Raising a registry's level surfaces the additional controls against that specific registry, rather than leaving them in a policy document detached from the data they protect.

How is ROPA membership decided? It is derived per asset from three facts the asset already holds: whether the record-of-processing duty applies to the organization, whether the asset holds personal data, and whether the asset is still in use. Membership changes when those facts change, so the Article 30 record stays current without a rebuild.

How can agents build the inventory without giving a vendor access to our systems? The agent runs inside your perimeter, under your IAM, logging, and data-loss controls, and connects to Aigis over MCP or the API. It submits attested findings - which systems exist, which hold personal data, what connects to what - and Aigis never receives a credential to your environment. Bring your own agent: Claude Code, or any MCP client.

Map your assets and registries to the obligations they actually trigger at agrc.ai.