[ HOW-TO GUIDE ]

How to Classify Data Criticality and Risk

Decide which records deserve the strongest controls, instead of applying them everywhere.

What a how-to is not

A how-to is SPEQ’s practitioner method, not a procedure. It does not replace your own SOP, it is not a validated approach, and the judgement calls in it belong to your quality unit.

Data integrity controls cost effort, and applying the same intensity to everything means the controls that matter compete with the ones that do not. Regulators expect a risk-based approach built on two separate questions: how important the data is to a decision about product or patient, and how vulnerable it is to alteration or loss. The answers are independent, and confusing them produces the wrong controls in the wrong places.

THE STEPS
  1. 1

    Map where data is created, processed, stored and used

    You cannot classify what you have not located. Include the informal places — spreadsheets, instrument local drives, printouts kept in folders — because those are usually the least controlled and are frequently missing from the first draft of the map.

  2. 2

    Assess criticality by the decision the data supports

    Criticality is about consequence: does this record support a batch disposition, a patient safety judgement, a specification decision? Data that informs no decision is not critical however voluminous, and data used once in a release decision is critical however small.

  3. 3

    Assess vulnerability separately, as a property of the system

    Vulnerability is about how easily the data could be altered, deleted or lost undetected — manual transcription, shared accounts, a disabled audit trail, local storage with no backup. A highly critical record in a well-controlled system may need less added control than a moderately critical one in a spreadsheet.

  4. 4

    Combine the two to set control intensity

    High criticality with high vulnerability is where controls belong: system remediation, enhanced review, restricted access. Low on both warrants proportionate control and no more, and saying so explicitly is what frees the effort for where it counts.

  5. 5

    Target audit trail review by criticality

    Reviewing every audit trail entry is neither achievable nor useful. Define which entries are reviewed, how often, and by whom, driven by the criticality assessment — a targeted review that happens beats a comprehensive one that does not.

  6. 6

    Record the assessment and revisit it on change

    The assessment is a document with a rationale, reviewed when systems, processes or the data flow change. An assessment made once and never revisited describes a system that has since moved.

USE THE TEMPLATE
Data Criticality and Risk Assessment
Skip the blank page — start from SPEQ’s structured, regulator-aligned template for this procedure. Open the template →
COMMON PITFALLS
  • !Criticality and vulnerability treated as one judgement, producing controls aimed at the wrong risk.
  • !Informal data locations — spreadsheets, local instrument drives, printouts — left off the map.
  • !Uniform control intensity, so effort is spent where it changes nothing and is short where it matters.
  • !Audit trail review defined as comprehensive, which means in practice it does not happen.

How to Classify Data Criticality and Risk: frequently asked questions

Common questions on classify data criticality and risk.

What is the difference between criticality and vulnerability?

Criticality is what the data is used to decide — its consequence. Vulnerability is how easily it could be altered, deleted or lost without detection — a property of the system holding it. They are independent, and the control you need comes from combining them rather than from either alone.

Does risk-based mean some data has no controls?

No. It means control intensity is proportionate and the reasoning is documented. Everything gets the baseline; the enhanced controls go where criticality and vulnerability are both high. What risk-based rules out is the pretence of applying maximum control everywhere, which in practice means applying it nowhere consistently.

How does this change audit trail review?

It makes it achievable. Rather than an unmet commitment to review everything, you define which entries matter — changes to critical results, deletions, changes made outside normal operation — and review those on a stated frequency. A targeted review that actually happens is worth more than a comprehensive one that does not.