Adequate is not the same as sufficient
Organizations preparing for an assessment usually ask whether they have the right evidence. That is the first question, and it is not the one that most often goes wrong. The second question is whether they have enough of it.
Both assume a prior question has been settled: whether the artifact is believable in the first place. An artifact that nobody trusts fails before adequacy and sufficiency are reached. What follows applies to evidence that has already cleared that bar.
The two are worth separating, because an organization can answer the first perfectly and still fail the second.
Adequacy: does this artifact answer the requirement?
Evidence is adequate when it addresses what the requirement actually says.
This is where the obvious failures live. A requirement about enforcing a setting is not answered by a policy stating that the setting will be enforced; that is a claim, not evidence of the claim. A requirement about reviewing something is not answered by a tool's capacity to produce a report, but by a report someone produced and acted on. A completed checklist is evidence that a checklist was completed.
Adequacy also covers the unglamorous properties of an artifact. Is it dated? Does it identify the system it came from? Can someone tell who produced it, and when? A screenshot with no timestamp, no hostname, and no context is a picture of a screen. It may be entirely truthful and still not demonstrate anything.
Sufficiency: does it cover the scope?
Evidence is sufficient when there is enough of it, drawn from the right places, to support a conclusion about everything the requirement applies to.
This is the harder standard, and it is where well-prepared organizations are caught out, because sufficiency is not a property of the artifact. It is a relationship between the artifact and the scope. The same screenshot can be sufficient for an organization with four identical laptops and badly insufficient for one with four hundred mixed systems.
Consider a configuration requirement at an organization running both Windows and Linux. Evidence from the Windows fleet may be adequate—correct in kind, properly dated, clearly sourced—and still insufficient, because it says nothing about the Linux systems. Meeting a control on one platform is not evidence of meeting it on another. The sample has to reach both.
The same reasoning applies to every division that matters: servers against workstations, on-premises against cloud, employees against contractors, managed devices against the ones that were never enrolled. Each is a place where a control can be met in one population and missed in another.
Scope comes from the inventory
Sufficiency cannot be judged without knowing what the population is, which means it rests entirely on the inventory.
This has an uncomfortable consequence. An organization with an incomplete inventory cannot demonstrate sufficiency even if every control is genuinely implemented everywhere, because there is no defensible statement of what "everywhere" includes. The work may be done and still not be demonstrable.
It has a second consequence worth stating plainly: sampling from an incomplete inventory produces evidence that looks sufficient and is not. The sample covers the known population, the unknown population is not represented, and nothing in the artifacts reveals the difference.
Preparing for both
The practical exercise is to take a requirement and ask two questions in order. Does this artifact answer what the requirement asks? Then: what is the full population this requirement applies to, and does the evidence reach all of it?
The second question usually generates the work. It surfaces the platform nobody sampled, the group of contractors outside the normal account process, the office that does things differently, and the system that was never on the list. Finding those during preparation is ordinary remediation. Finding them during an assessment is a finding.
Neither standard is a bureaucratic hurdle. An organization that can show adequate evidence across a scope it can defend is one that actually knows the state of its own environment, which is the thing the assessment is trying to establish.
At Kenneth Ingham Consulting, we test evidence against both standards during readiness work, which is considerably cheaper than having an assessor do it.