Guide
OSCAL in practice: What machine-readable evidence actually demonstrates
Distinguish requirements, implementation, observations and findings. An example shows how OSCAL structures assessments and where expert judgement remains necessary.
A file passes schema validation. It says a control is satisfied. Does that already demonstrate secure operation of your system? No. The file can be technically valid while referring to the wrong system scope, outdated evidence or an unjustified assessment.
OSCAL enables structured exchange of security information. Its value emerges when you can trace the path from requirement to assessment. Our introduction to OSCAL covers the fundamentals. This article addresses the substantive quality of the data.
What kind of statement do you have?
NIST’s OSCAL model distinguishes requirements, documented implementation and assessment. A catalogue describes controls. A profile selects requirements and adapts them to a context. A System Security Plan describes implementation in a particular system. Separate models support assessment.
This separation prevents a common mistake: describing a safeguard does not demonstrate that it has been implemented. An observation is also not the final assessment of an entire requirement.
When reviewing your next export, first ask which type of information it contains. A complete requirements catalogue answers a different question from a report on systems actually examined.
Example: MFA for administrative access
Our fictional assessment question is whether multifactor authentication is effective for every administrative access path to a particular application. This is our example, not a verbatim ISO control or an importable OSCAL file.
The system owner describes how MFA is enforced. The assessor examines the affected accounts, configuration and an appropriate sign-in test. They discover a local administrator account that does not use the central identity service.
| Level | Content in our example |
|---|---|
| Requirement | Administrative sign-in requires MFA |
| Implementation description | Sign-in through the central identity service |
| Observation | A local administrator account bypasses that route |
| Finding | The assessment objective is not fully met for the scope examined |
| Risk | An additional access path remains without the intended protection |
| Treatment | Remove the account or decide on a protected exception, then verify again |
The discovery does not make the original description worthless. It shows where it is incomplete. If an export transfers only “MFA: enabled”, this crucial information disappears.
Keep observations, findings and risks distinct
The Assessment Results Model describes assessment subjects, activities, observations, findings and risks, among other elements. It can record what was examined and how the assessment was reached. Results sit in the context of an Assessment Plan.
For our example, we recommend three separate statements: observed, assessed, decided. An additional sign-in path was observed. Its significance to the assessment objective is evaluated. The organisation decides how to address it. Automated configuration retrieval can support the first part; it does not automatically replace the other two.
This also matters when reusing evidence. A configuration export can support several assessments if its scope fits each one. Attaching the same file to several controls does not make the relationship correct. See using one piece of evidence for several audits.
An open finding needs a next step
NIST’s Plan of Action and Milestones Model describes tracking risks and their treatment. In practice, an assessment report should connect unresolved points to the responsible people, beyond merely exporting them.
In our example, the local account receives an owner and deadline. After the change, the team verifies whether the additional access path has actually been closed. If it remains as an exception, risk acceptance needs a decision-maker, reasoning and a next review trigger.
Consider changes after the test too. A new sign-in path or system may fall outside the original scope. The old finding remains historically correct, but no longer describes the whole current situation.
Five questions before exchanging data
Use one sanitised record to check:
- Scope: Which systems, accounts and versions does the statement concern?
- Time: When was the evidence collected, and what has changed since?
- Origin: Who or which process produced it?
- Assessment: Which question did it answer, and what limitation remains?
- Follow-up: Who handles an open finding, and what evidences completion?
Larger-scale automation becomes worthwhile once sender and recipient understand these questions consistently. Also test whether references and permissions work after transfer. A link the recipient cannot open is not a usable handover.
In Kopexa, evidence is attached to measures, which are mapped to controls. This working relationship connects supporting records with implementation. It is not a claim of a native OSCAL interface. Data model, format and mapping need separate assessment for any exchange.
Sources
- NIST: OSCAL Layers and Models [Accessed ]
- NIST: Assessment Results Model [Accessed ]
- NIST: Plan of Action and Milestones Model [Accessed ]