Database inventory and registration before the SIC

First: whether the company is required to register

Not every controller has to register. The obligation depends on criteria the regulations set around the nature and size of the controller, and checking it is the first step, because registering without needing to creates updating and reporting duties that then have to be sustained over time. We deliver that check in writing, with the criterion applied, the conclusion and what changes if the company grows or changes its legal form.

The inventory is the real work

The registry is not filled in: it is built from an inventory. The hard question is not which fields the form asks for, but how many databases genuinely exist and where the line between one and another is drawn. Lumping everything into a single database is convenient and describes nothing; splitting it into twenty makes the registry impossible to maintain.

• Scoping. Customers, employees, candidates, suppliers, visitors, camera footage, app users, commercial contacts, inherited databases.
• Purpose of each database. Worded so that it matches the processing policy and what was actually authorised.
• Data categories. With sensitive data and data of children and adolescents identified separately.
• Origin. The channel the information came through and how the individual's authorisation is evidenced.
• Processors. Who handles each database on the company's behalf and where the infrastructure sits.
• Security and retention. The measures applied and how long the information is kept.

That inventory is useful well beyond the filing: it is the same input needed to answer a complaint, to respond to an information request from the authority and to know who must be told if there is an incident. In most companies it is also the first document that shows, on a single page, how many places the same personal data has been copied to.

The procedure before the Superintendence

1. Review of the corporate information and of the controller details that will be recorded.
2. Consolidation of the inventory with the teams that actually run each database, not only with legal or IT.
3. Completion and filing of the registration for each identified database.
4. Handling of any observations or requests raised during the procedure.
5. Delivery of the registration records and an explanation of exactly what was filed.

Registration is not a one-off

It changes when the operation changes, and there are updates and periodic reports attached to the information filed. That is why the deliverable does not end with the receipt. We put in writing which events require going back to the registry and who inside the company should notice they happened.

• A new database, a new channel or a new business line.
• A change of processor, cloud provider or infrastructure location.
• New purposes of use or material changes to the processing policy.
• Security incidents, reported through the same channel once the company is registered.
• Complaints from data subjects, which also feed into the information reported.

What the client receives

• A written opinion on whether the company must register and from when.
• The full database inventory, on a sheet the responsible team can maintain in-house.
• The registration filed with the Superintendence of Industry and Commerce, with its records.
• A short set of instructions on which events trigger an update and how to do it, with an internal owner assigned.
• Adjustments to the processing policy where the inventory shows the two do not match.

Typical situations we handle

• A company that grew, crossed the thresholds of the obligation and had not noticed.
• A registration made years ago that no longer describes the current operation and nobody has updated.
• A group that needs to sort out who registers what when several companies share systems.
• A business that needs its registration current to bid for a tender or close a contract with a large client.