What the Register Cannot Tell You

A register that answers everything asked of it is answering some things badly. Naming the limits keeps it credible on the rest.

Whether an application is worth what it costs

Why not: the register holds cost and usage, not value. A tool used by four people may be worth more than one used by four hundred.

Use instead: ask the owner what would happen without it, and what the alternative would cost in effort.

Whether someone should have access

Why not: the register records who does, not who ought to. Entitlement design is a separate discipline.

Use instead: role definitions, reviewed with the business, with the register showing the gap between design and reality.

Whether a vendor is secure

Why not: you cannot verify what a vendor tells you, and an assessment records that you asked.

Use instead: minimise what data goes in, federate authentication, limit integration scopes, and keep the ability to export and leave.

What data is actually in an application

Why not: classification is an assertion by the owner, and usage drifts upward.

Use instead: periodic sampling, and where it matters genuinely, discovery scanning within the application.

Whether a saving was real

Why not: a reduced seat count is not a reduced bill until the contract changes.

Use instead: the finance ledger. A claimed saving that does not appear there is an opportunity, not a saving, and conflating them destroys credibility with finance.

Whether shadow IT has decreased

Why not: you can only count what you discover. Improved discovery looks like a rise; better concealment looks like a fall.

Use instead: the proportion of new applications arriving through the request path, which is measurable and not subject to the same distortion.

What will break if we remove this

Why not: integration dependencies are partially recorded at best, and undocumented automations are common.

Use instead: announce, wait, and watch. Suspension before deletion exists precisely because this question has no reliable answer.

Total cost of IT

Why not: the register covers software and hardware. It does not cover people, infrastructure, or the effort spent operating any of it.

Use instead: the register as one input to a finance exercise, clearly labelled as partial.

How to decline

Say what the register does support, which is usually adjacent and useful.

Say what would answer the question, and roughly what it would cost.

Do not produce a number with a caveat. The caveat is dropped, the number is quoted, and the whole register is discredited when it turns out to be wrong.

A register trusted on eight questions is worth more than one distrusted on twelve.

Saying no to a number

The specific skill that keeps a register credible, and it is a communication problem rather than a data one.

Name what you can answer, which is usually adjacent and useful.

Name what the question would actually require — a survey, a sampling exercise, a scan — and roughly what it would cost.

Offer a range where a range is honest, with the basis stated.

Do not produce a precise number with a caveat attached. The caveat is dropped in the second retelling and the number is quoted in the third.

Write the limitation into the report itself, not into the covering email, because the report is what circulates.

What the register is genuinely good for

Worth stating positively, after a list of limitations, because the credible claims are substantial.

What exists, to the extent your discovery sources reach.

Who owns it and who to ask.

What it costs and when it renews, which is where the money is.

Who has access, and who has access who should not.

What a leaver holds, across devices and accounts.

What data classification applies, as asserted by the owner.

What can reach what, if the integration map is maintained.

Seven things answered reliably is a register worth maintaining, and defending the boundary is what keeps those seven trusted.