Access traceability

Pro feature

Requires a MIA Pro subscription.

Traceability keeps the history of every access, decision by decision: which one was opened, when, why, through which channel, and above all who closed it — MIA, or somebody straight inside the application. This is the evidence an ISO 27001 auditor asks for under controls A.5.18 (access rights) and A.8.15 (logging).

How it works

1. MIA records an entry for every decision taken on an access: opening, closing, failed closing, unlinking, access review, access request, orphan account, mass-deletion arbitration, removal of an application.
2. Every entry carries its origin: manual action, schedule, leaver cascade, application kit, access request, synchronisation, initial inventory, and so on.
3. The Traceability screen lets you filter by application, event, origin and period, then export to CSV exactly what you see — the format an auditor needs to draw a sample and cross-check it.
4. Every night the day's entries are sealed in batches and chained to the previous batch, then the whole chain is verified — batch by batch, seal by seal. The "Integrity" panel shows the result of that verification and the date it was run.

An inventory is not a grant

Connecting an application of two hundred accounts does not produce two hundred access grants: MIA is discovering what already existed, and records it as an inventory. The same holds when an application changes the way it identifies accounts, or when a manual application becomes an automatic one. Changing the scope an application synchronizes follows the same principle: the accounts you remove from it leave the inventory, those you add enter it, and no access was granted or revoked on the application. Two further situations follow the same principle: importing a shadow application scan, which brings into MIA accounts your people had opened themselves long before, and attaching an orphan account, which says who an already existing access belongs to without opening any. Without that distinction your register would announce hundreds of revocations on a Monday morning — which an auditor does not read as a journal, but as an incident.

A closing that fails

When MIA fails to close an access, the failure is written to the journal: at every attempt when a user or an access is deleted and when an access request is closed immediately, once for a scheduled closing, when its automatic retries run out. The entry carries the application's error code (HTTP status and technical code), never its message, which often quotes the account it refused.

If the application refuses the deletion but the account is already missing from its list, MIA records the access as closed outside MIA rather than as a failure: it already was.

A closing done by hand at MIA's request

On an application where MIA cannot close accounts, you close the account, on the date MIA reminds you of. That closing follows MIA's process: it is recorded as closed by MIA, with a manual closing mentioned in the details, as soon as you delete the access confirming the closing, or as soon as the synchronisation finds the account gone. Without an end date, deleting such an access records it only as unlinked.

Removing an application

Removing an application from MIA closes no account on the application. The journal records each of its accesses as unlinked and each of its orphan accounts as resolved, with the "Application removed" origin. Connecting the application again inventories them anew.

Rectifying the journal

The journal is never modified: an entry stays as it was written. When an entry turns out to be wrong, MIA's support writes, at your request, a rectification: a new entry with the "MIA support" origin, citing the entry concerned, in one of three forms.

• Correction: the entry states something false, and the rectification gives the actual facts (event, origin, actual time, actor type).
• Cancellation: the event never happened.
• Late entry: a real event was never recorded.

A rectification is dated the day it is written, never backdated: the actual time of the event is one of the facts it carries. On screen, the rectified entry keeps its original label and carries a "Rectified" chip giving the detail and the reason. In the export, two columns added at the end of each line, "Entry ID" and "Rectification", link the two lines. Filters and counts read what was written: a rectification never passes for the event it corrects.

The reason of a rectification is written in clear, for you and your auditors, and never names a person: it stays readable even after an identity has been erased.

Searching for a person, erasing a person

The identity written into the journal is encrypted with a key belonging to that person alone. Two consequences follow:

• searching by person uses an exact email address: no partial search, no alphabetical sort;
• erasing somebody under the GDPR means destroying their key. Their rows stay in place and still count — their date, application, type and origin remain readable — but the identity becomes permanently unreadable. That is what reconciles the right to erasure with a register that has to stay verifiable.

Erasure is triggered from the Traceability screen, never from deleting a user: it is a rare and irreversible action, and it must not be reachable out of habit.

MIA refuses it while the person is still among your users, or while an orphan account still carries their address on one of your applications: the hourly synchronisation would find it and write the address back into the journal, which would make the erasure fictional. The confirmation window then tells you what to clear first.

If the same address comes back later — a rehire, for instance — the person is journalled under their name again, normally. Their rows from before the erasure stay permanently unreadable: an erasure covers what was written up to that point, never what comes after. Searching the address brings back both: the older rows as "Erased person", the "Identity erased" entry carrying its date and author, then the newer ones.

Link with access reviews

Every individual decision of an access review campaign is written to the journal at the moment it is taken. Closing a campaign resets the statuses, but the proof of the recertification stays — which is exactly the evidence expected under A.5.18.

Good to know

• The journal is kept for 36 months, a fixed duration that cannot be configured: a setting would let somebody lower the retention and destroy the very evidence the feature exists to produce.
• It is written for every account, free ones included. An account upgrading to Pro therefore finds its history already there.
• The past cannot be back-filled: the journal starts when it goes live.
• The chain verification runs every night, not on each opening of the screen: it re-reads and recomputes the fingerprint of every retained entry. The verdict on screen is therefore dated — and an alteration is detected within 24 hours even if nobody looks at the screen.
• Sealing detects an alteration that does not recompute the chain — a direct write to the database, a bug, a script. It does not protect against MIA itself, which would require depositing the evidence outside MIA. And it proves the integrity of the register, never the truthfulness of what was written into it.
• An orphan account with no email address is identified by its remote identifier: an erasure driven by an email address will not reach it.