DSMM's Five Levels, One by One: What Each One Reviews and What Evidence It Wants

The five levels at a glance

Start with the whole picture. The way to use this table is not to "pick the row that looks suitable", but to compare it against what you can actually open and actually export, and see which row's evidence focus overlaps with your current state. If nothing overlaps, that level has not been reached yet.

What follows takes the levels one by one. Each level is covered with the same four questions: what is reviewed, who it fits, how to organize the evidence (policy / process records / technical means / data records), and common return reasons. Each section opens with what has been added compared with the level below — that sentence carries the weight of the section, because the whole difference between levels sits there.

Level 1Informal execution: activity, but not yet shaped

What is reviewed

Level 1 is not "nothing has been done" but activity without a settled shape. The assessment does not start by asking for policy documents; it follows one real data flow downwards: who collected this data, who approved it, which channel it travelled on, which table it landed in, who can query it, and how it is handled when it expires. If every answer points to a specific person and that person's memory, this is the typical state at Level 1.

Three things are looked at. First, dependence on individuals: the same task done by someone else is done differently, and nobody may know how the previous round was done. Second, occasional traces: emails, chat records and temporary tickets can be found, but they do not form a sequence and it is unclear which round was the "standard way". Third, repeatability does not hold: a project went well because that person was on it, and the next project is back to square one. What the assessment judges here is whether capability has grown out of the people; usually the answer is not yet.

One point is easily misunderstood: Level 1 does not require you to go and write a policy set. Writing out a policy that does not exist is more trouble than not writing it — in the on-site interview, once the question "who last followed this clause" cannot be answered, other material starts to be doubted as well.

Who it fits

Organisations with a small data volume, a relatively simple business, or data security work just starting; units whose group or superior has asked them to "get the current state clear first"; and companies that use Level 1 as a coordinate for gap analysis to justify an internal project. The value of this level is internal: lay out what exists across the six stages and the weak spots surface by themselves.

It is not suited to being used as proof to the outside. At Level 1 the persuasive weight externally is limited in tender and regulatory settings, and many parties receiving it do not look at this level. If the only reason for starting is a bid, confirm first which level the tender document names, and do not spend the budget on a level that is not accepted.

How to organize the evidence

• Policy: usually there is no written policy, only operating notes, go-live documents or verbal agreements. Put them into a one-page statement of current state, writing "present / partly present / absent" stage by stage and noting what each judgement rests on — this is more honest and more usable than forcing a policy set into shape.
• Process records: scattered emails, approval screenshots, temporary tickets. Group them by stage and mark the dates; they show that something was done, but do not dress them up as "a system in place".
• Technical means: scattered tools and default configurations, permissions remembered by people, logs largely generated by the systems themselves, stored locally, with short retention. Write this column as it is, and do not count a vendor's platform as your own capability.
• Data records: event records at individual points in time, with no periodic statistics. A few real handling processes are worth more than a stack of blank forms.

Common return reasons

• Using a generic policy template to force Level 2. The actions written in the policy cannot be found as nodes in the system, and the interview cannot say "who did it last time", which instead exposes that the preparation went in the wrong direction.
• Being unable to say "who is doing it". Across the six stages the answer is always "the IT department handles it", with no position, no name and no date. This is a frequent hard fault in Level 1 material.
• Writing the vendor's capability as your own. The tools are run by the supplier, the configurations are changed by the supplier, and operating records cannot be produced — which means this cell is not yours.
• Writing only plans, not the current state. Pages of "will be built" and "planned for go-live", with not one record of something already done. The assessment looks at the present, not at a roadmap.

Level 2Planned and tracked: from ad-hoc handling to a plan with someone watching

What is reviewed

Level 2 looks at three things. Whether a plan exists: which stages it covers, when the work happens, who is responsible, and what state counts as done. Whether tracking exists: how often it is reviewed, what is recorded when it is, and how a deviation is handled. Whether plan and reality line up: the work the plan schedules for a quarter should have a matching round in the register.

It is worth stressing that Level 2 allows partial coverage. Starting with three or four of the six stages is a normal path, and the assessment will not reject the whole because "destruction is not yet done". But the stages claimed as covered must really be running — the assessment will pick a stage you have already written into the plan and go one layer deeper: where is this month's activity, who signed, was the problem that was found corrected. If the stage being probed does not hold up, the credibility of the whole plan drops.

Another way to read this level: Level 2 proves that "someone is managing it"; it does not yet prove that "it is under control". The two statements differ by one word, and that word is a whole level.

Who it fits

Companies with a clear external deadline but no system yet in shape: a tender closing date, a regulatory inspection, a group appraisal. Situations where "something has to be produced before a certain month" usually start at Level 2. It also suits organisations that have just appointed a coordinator who cannot yet move the business and legal departments — getting the plan, the register and the regular meeting running is the practical way to bring other departments into role.

Companies that have already done ISO 27001 start this level more lightly: the policy, document control and internal audit skeleton is already there, and the risk assessment method can be reused. Note, though, that ISO 27001 controls are organised by risk domain while DSMM is organised by data stage — the two coordinate systems have to be aligned once, and documents copied across directly will be caught in the on-site interview.

How to organize the evidence

• Policy: written rules begin to appear, but usually as single-point rules — only an approval method for permissions, only a sharing process. What is missing is the per-stage detail and the cross-references between documents — policy A says "execute according to B" and B does not exist, which is common at Level 2.
• Process records: this is the core form of evidence at Level 2: annual or dedicated plans, responsibility assignment tables, meeting minutes, progress tracking sheets, stage registers. What the assessment looks at is not whether the form looks good, but whether it has been updated continuously.
• Technical means: tools begin to be purchased and configured, but usually take effect in one system or one scenario, with rules configured and watched by hand. This column is not a hard threshold at Level 2, but you must be able to say where it is used and who uses it.
• Data records: monthly or quarterly statistics begin, with each department defining its own basis, so they are not comparable across the company. A comparable statistical basis is a Level 3 problem; at Level 2 it is enough that "there are numbers and the numbers can be produced".

Common return reasons

• The plan is only a target, with no tracking trace. An annual plan exists, but not one set of meeting minutes, not one progress update, not one corrected deviation. The probative value of a plan lies entirely in the tracking.
• The owner exists only in the document. The person asked in the interview does not know they have been written down as the owner of a stage. This one can hardly be repaired on site.
• The register is maintained by one person. When that person takes leave, changes role or leaves, the records stop. This shows tracking has not entered the process and is still short of Level 2.
• Claiming full coverage while the spot check finds only storage. The material says "all six stages are covered", and when exchange and destruction are followed up, both are completely blank. Declaring wider coverage than you have is worse than declaring less.

Level 3Well defined: defined and repeatable, same result with a different person

What is reviewed

Four things. Whether the definition covers all six stages — not "is there an overall framework document", but does each of Data collection, Transmission, Storage, Processing, Exchange and Destruction have an executable rule; whether the process is standard — the same action follows the same path in different departments, rather than each department editing its own version; whether execution is recorded — every round run to the process has left a trace; whether departments use the same language — business, legal and IT describe the same thing, not three different versions of it.

The core action of the assessment here is sampling plus tracing back: pick one real data item, trace from the classification tag to the collection approval, from the sharing register to the recipient, from the destruction record to the disposal of the medium. If any link in the chain is blank, that stage cannot be pushed up. In practice this usually goes further than asking "do you have policies": the engineer is asked to open the system on the spot and show whether the tag exists, whether the log can be exported, whether the approval flow can be opened.

There is also a gap that is often overlooked: between a policy written down and a policy actually followed sits the system node. Whether the approval runs in the system, or a form is signed afterwards, makes an entirely different kind of proof. The assessment looks at this point.

Who it fits

Many companies take Level 3 as the target, because it is the watershed between "the system is really running" and "people are still pushing it along". Typical matching scenarios: a government or enterprise tender that lists data security capability as a qualification condition; an industry regulatory inspection that asks for self-assessment material; a counterparty doing security due diligence before external data sharing, an open interface or joint modelling. These three needs are clear and have fixed dates, and they are common triggers for starting.

Companies whose data has reached a certain scale, and whose business departments have begun asking "which data can I use, and how far can I use it", also tend to be at this level. Because what Level 3 does — classification and grading, narrowing of permissions, sharing approval — exists precisely to answer those questions; the assessment only fixes them in place.

How to organize the evidence

• Policy: a policy set covering the six stages, a classification and grading method, emergency plans and responsibility documents. Version numbers, effective dates, release and briefing records must be visible, and the department and system names must be this company's own. Documents must reference each other without clauses pointing at nothing.
• Process records: collection approval, permission provisioning and revocation, sharing approval, destruction approval — each with initiation, approval, conclusion and date closed. A result slip with no intermediate approval chain does not count as a completed process.
• Technical means: classification and grading lands as tags in the system, de-identification has a rule library and job logs, encryption has configuration notes and key rotation records, audit logs are centralised and searchable, and the permission matrix is written by role and by system. This column is the watershed of Level 3 and cannot be made up with words.
• Data records: logs spanning a continuous period, alert handling, drill reports, training and assessment records, consistent in basis from period to period. A single period of data, or two places that contradict each other, carries little weight.

Common return reasons

• The policy is an external template. Department names and system names still belong to someone else, or refer to systems already retired. This is visible at a glance and drags down the credibility of the rest of the material.
• Policy without a system node. The policy requires approval, but it is done by email and verbally, and records are filled in afterwards. This is a typical "execution gap", harder to close than a policy gap.
• Classification and grading stops at the table header. There is a grading method and a graded inventory, but the system fields are not tagged, and picking one data item gives no level. This is a frequent place where Level 3 loses points.
• Two or three of the six stages are blank. Usually exchange and destruction. Storage encryption and permissions are done in detail, but external provision happens by sending a file through a chat app, and the chain breaks at that cell.

For the stage-by-stage evidence detail across the six stages, see how a DSMM assessment is actually run: the six stages one by one; for the difference from the data management side, see DCMM's five levels, one by one.

Level 4Quantitatively controlled: from "done as defined" to "how well is it done"

What is reviewed

Four points. Whether an indicator can be recalculated: given the raw data, another person using your written formula arrives at the same number — if not, the indicator is only a cell in a report. Whether there is a baseline: was the threshold set from historical fluctuation, or is it a target someone picked. Whether an alert is followed by handling: configuring a rule does not count; how many times it fired, how it was handled and what the review said is the evidence. Whether an indicator has ever actually changed anything: an indicator that never affects a decision and never triggers an action is decoration.

Level 4 also carries an implicit requirement: measurement must be able to drill down. When an indicator is abnormal, it must be possible to click from the summary number down to the specific log, the specific person and the specific point in time. Quantification that cannot drill down only shows that "a number is moving"; it does not show that "we know where the problem is".

The investment profile at this level differs from the three below. The first three levels are mainly about doing the actions correctly and keeping the records; Level 4 needs historical data before baselines and thresholds can even be discussed. This is why "pushing straight to Level 4 without several years of operating data does not hold up" — it is not a question of money but of time, because data cannot be conjured.

Who it fits

Sectors with large data volumes and heavy supervision: finance, healthcare, telecom, vehicle data and similar settings, where inspections often ask for trends and anomaly handling rather than one policy. Groups that compare subsidiaries also belong here — if grading results are to be compared, there must be one measurement basis.

One more group is easily overlooked: companies that have run Level 3 stably for some time and have begun to use data internally to argue their case. Once the security department starts being asked "what did this year's investment buy", Level 4 becomes an internal need, not only an external requirement. Conversely, if you still cannot answer "which of the six stages loses the points", Level 3 is not running smoothly yet.

How to organize the evidence

• Policy: an indicator management method, a definition of the measurement basis (formula, data source, statistical period and owner for each indicator), thresholds and alert rules, and a mechanism for periodic indicator review. The definition of the basis is the centre of gravity of policy at this level; if the basis is unclear, everything downstream tilts.
• Process records: minutes of periodic indicator review, anomaly reviews, approval records for threshold changes, initiation and acceptance of improvement items. A threshold change needs a reason; it cannot be loosened because "the number looks bad".
• Technical means: measurement and reporting platforms, monitoring and alert rule configuration, logs and indicators connected. Drill-down is the key: from the indicator down to the raw log without manual export and assembly in between.
• Data records: indicator data for several consecutive periods, baseline values and normal fluctuation ranges, alert and handling records, before-and-after comparison. A single period's number does not constitute a baseline.

Common return reasons

• The indicators are process counts. Training coverage, number of drills, ticket completion rate — these count "how many times something was done", not "how much was prevented". Process counts can support Level 2 tracking; they cannot carry Level 4 measurement.
• Only one period of data. With no baseline there is nothing to base a threshold on, and the so-called quantification is just this quarter's number typed into a table. This is a frequent problem in Level 4 material.
• The indicator's source cannot be calculated. The formula and the data basis cannot be answered, and another person recalculating gets a different number. Once measurement cannot be recalculated, it cannot be used to judge or to attribute.
• Alerts with no handling. The rules are configured and not one handling record can be found. Either the rules are decorative or handling leaves no trace; both readings are unhelpful.

Level 5Continuously optimizing: seeing it, changing it, and verifying the change

What is reviewed

Four points. Mechanism: does optimisation have a fixed entry point — periodic review, risk-change trigger, event-driven; at least some of these three must be clearly defined, rather than "we change when leadership thinks we should". Trigger: can changes in external risk (new business, new data types, new attack techniques, adjusted regulatory expectations) be identified and turned into capability adjustments. Verification: after the change, was the effect tested, did the indicators move, and by how much. Output: has the method settled into something reusable — explainable externally, usable by other units or by the industry.

Level 5 also looks at an implicit indicator: stability. Optimisation cannot depend on one capable individual. If that person changes role, leaves or retires, is the mechanism still there? Optimisation driven by a capable individual is essentially Level 1 capability growing on people, only the person holds a more senior position.

This level is usually not bid-driven. Few scenarios genuinely require it for a tender; the motive for many organisations is a benchmark position in the industry, a group headquarters publishing methods to subsidiaries, or the company already providing data security services. Where the goal is short-term acceptance, stopping at Level 3 or Level 4 is more practical, and pressing resources into Level 5 is a mismatch.

Who it fits

A small number of organisations. Typically benchmark units in an industry, group or regional headquarters, bodies that publish methodology and services externally, and companies where data security is itself a core competence (data platforms, risk control, industry cloud services, for example).

There is a simple way to judge whether you are at this level: in the past two years, was there ever a capability adjustment that happened because "we measured a problem", rather than because "something went wrong" or "the top asked for it"? If you can give a specific case and explain the difference before and after, you have touched the edge of Level 5.

How to organize the evidence

• Policy: a capability optimisation management mechanism, a capability evolution plan, a review and knowledge capture system, and management requirements for publishing methods. The policy must state "who may initiate optimisation, on what basis the judgement is made, and how it is accepted" — not just the words "continuous improvement".
• Process records: periodic capability reviews, optimisation initiation and acceptance, and cross-organisation experience output (internal and external training, method documents, industry exchange). The reason for initiating an optimisation must trace back to an indicator or a change in risk.
• Technical means: an architecture in which capability configuration can be adjusted, and verification records for introducing new technology (pilot scope, assessment conclusion, decision to roll out or roll back). Records of something tried and then withdrawn are also valuable — they prove the judgement mechanism is working.
• Data records: multi-year indicator trends, before-and-after comparison, cases of adjustment driven by a risk event or an external change. The time span in this column is a hard requirement and cannot be assembled in a short period.

Common return reasons

• Treating routine drills as continuous optimisation. The same drill every year with the same process, the same script and the same participants, and no configuration ever changed as a result. That is repetition, not optimisation.
• Optimisation with no effect verification. Something was changed, but it cannot be said whether the indicators moved or by how much. An improvement without verification is an action, not a capability.
• Driven by an external consultant. The mechanism stops when the consultant leaves and nobody inside has taken it over. The moment the assessment asks "who maintains this method now", the answer gives it away.
• Treating one project's local practice as organisational capability. One project went well, other projects did not copy it, and the process was never fixed in place — that is a bright spot within Level 3, not Level 5 organisational capability.

Evidence shared across levels: one base, used at all five

The five levels review at different depths, but a block of material is looked at at every level. Organizing that block once into a shared base saves far more effort than digging everything out again for each assessment, and it is easier to keep consistent. What changes as you move up is depth and coverage, not a different set of material.

Shared does not mean carried over as-is. There are three rules, and breaking any one of them shows up during the cross-check:

1. One version per data point. Data category names, system names, owners and dates must be identical in the statement of current state, the plan, the policies and the registers. One name that differs means time spent explaining, and the explanation itself raises new questions.
2. Dates must not run backwards. A policy issued later than the execution record it governs, or a version number appearing in a record before it took effect — faults of this kind are hard to smooth over and are visible at a glance as something filled in at the last minute.
3. The same policy must point to the action this level cares about. Level 1 points to the current state, Level 2 to plans and tracking, Level 3 to process nodes, Level 4 to the measurement basis, Level 5 to the optimisation entry point. Writing only "we have this policy" means nothing.

The upgrade path: do not skip levels, and do not treat an upgrade as swapping material

The five levels are five depths of the same capability, not five different sets of material. Once that is clear, the upgrade path follows: what each step pushes up is the part of the capability the level below has not yet grown.

Four judgements about skipping levels are worth remembering:

• A higher level presupposes that the level below is in place. Level 3 evidence is the data source for Level 4 indicators, and Level 4 indicators are the basis for Level 5 optimisation judgements. If the level below is blank, the material for the level above has no origin and can only be invented — and something invented does not survive one round of probing at the sampling stage.
• Material prepared for a skipped level is usually rejected at the sampling point first. Because the higher-level material says "what we measured" and "what we optimised", while sampling asks "what state is this data item in right now". Put the two side by side and the problem shows immediately.
• The target level comes from the party receiving the result, not from self-assessment. Prepare for the level named in the tender document; if only an assessment result is required, prepare for that; a gap analysis report calls for a third mode of preparation. Set the target wrong and the investment will be uniformly too high or too low — both are waste.
• An upgrade is not a new set of material; it is the same material taken deeper. The same project, the same data flow: Level 1 writes the current state, Level 3 writes the process and records, Level 4 writes which indicators it contributed to, Level 5 writes which adjustment it triggered. The material is the same; the depth differs.

Action list: from level to material, in this order

After reading the five levels, the work comes down to a single line. Do not reverse the order — fix the target level, take stock of the current state, close the mechanism gaps, and only then talk about documents. Done the other way round, no matter how tidy the material is, it will not survive the demonstration and sampling on site.

• ⬜Write down the basis for the target level: a tender document, a regulatory requirement or a customer's admission process — which level the original text names, and who needs it by when
• ⬜Draw one complete data flow: from collection to destruction, which system each stage passes through, who owns it, and which rule it rests on
• ⬜Against the five levels, write in one sentence which level the current state sits at, backed by three supporting facts rather than a feeling
• ⬜Lay out a 24-cell table of six stages × four dimensions (Organisation, Policy, Technology, People), and in each cell write three sentences: is there a written rule, is there a matching action in the system, can a record be exported
• ⬜Test each cell in practice instead of asking in a meeting: pick one data item and look at its tag, export yesterday's log, find the execution record of a de-identification job
• ⬜Sort the gaps by nature: policy gap, execution gap, record gap, technical gap. The four are closed in completely different ways; mixed together they become a wish list
• ⬜Close the two or three collapsed cells first, and do not keep adding weight to the stages already done well. Resources pressed onto strengths give a low return
• ⬜Confirm that classification and grading lands as tags in the system — this is the shared precondition for every stage from Level 2 up, and where points are lost
• ⬜Make approval run through the system rather than email, embed the action in process nodes, and rely on the mechanism rather than on goodwill
• ⬜Prepare people who can demonstrate on site: engineers who can query tags, export logs and run de-identification, not a project manager explaining on their behalf
• ⬜Run a cross-check before submitting: pick two data items and retell the whole process from the material alone, checking whether any date runs backwards and whether the definitions contradict each other
• ⬜Decide who maintains it after the certificate is issued: the responsible department, the meeting rhythm, the person updating the register. Validity is about continuous operation, not about swapping the certificate at expiry

Taken this far, the five levels are one sentence at five depths: whether what you say, what runs in the system, and what the records keep are the same thing. The policy says how it should be done, the configuration says how it is actually protected, the logs say that it really was protected that way, and the interview shows that the people doing it know why. String the four together and the capability holds. Miss one and you have to go back to the system on site to fill it in — not back to the documents to edit them.

▍Not sure which level you are at right now? Leave a comment noting "DSMM five levels" and I will send you an evidence comparison table split by level