dpdp.storeevidence workbenchRESOURCE LIBRARY

Home / Workflows / Technical evidence chain

WORKFLOW 03 / 4 REVIEW STAGES

SBOM triage → owner interview → updated data-flow map

Turn bounded software metadata into testable questions, gather human and technical evidence, then update the inventory with confirmed facts.

Start with the scenarioOpen the toolbench
LOCAL TOOLS / HUMAN CONFIRMATION REQUIRED

Outcome to assemble

A version-linked triage export, an owner interview record and an updated inventory row that distinguishes confirmed flows from rejected hypotheses.

Reviewed
2026-08-26
Legal status
editorial analysis
Source/method records
dpdp-store-method-0.2
Changelog
0.5.0 — first public static working guide.
FICTIONAL PRACTICE SCENARIO

A fictional application SBOM contains package names associated with identity, logging, storage and networking. Some are inactive dependencies, while one configured logger sends operational records to a provider.

STAGED HANDOFF

Follow the evidence, not a score.

WORKFLOW 0.5
  1. 01

    Verify the software evidence boundary

    Tie the CycloneDX or SPDX document to an application version and trusted build process, then parse it locally with the SBOM triage tool.

    Handoff
    A parser record, component count and bounded set of transparent heuristic questions.
    Stop and review
    Reject malformed or provenance-unknown files; never weaken parser safeguards just to obtain a result.
  2. 02

    Prepare the owner interview

    Group questions by component and category, then ask where it runs, whether it is active, what configuration applies, what data enters and where output goes.

    Handoff
    An interview plan that names the evidence needed for each answer.
    Stop and review
    Do not present a package-name match as a finding about actual processing.
  3. 03

    Gather evidence outside the toolbench

    Have authorised owners reconcile runtime configuration, architecture, logs, provider terms and code paths in approved systems.

    Handoff
    Confirmed, rejected and unresolved hypotheses with controlled evidence references.
    Stop and review
    The site does not crawl, message owners, inspect source code or store interview answers.
  4. 04

    Update and version the data-flow map

    Add confirmed data categories, recipients or processors, locations, owners and evidence links to the inventory. Record the reviewed application and SBOM versions.

    Handoff
    A refreshed inventory export and an issue list for unresolved technical questions.
    Stop and review
    Repeat after material build or configuration changes; the updated map is still a reviewable claim, not automated proof.

Before the pack moves on

  • The SBOM and application versions are traceable.
  • Every accepted match has runtime, configuration or architecture evidence.
  • Rejected hypotheses remain documented so the same question is not repeatedly rediscovered.
  • Confirmed facts are reflected in the current inventory and provider records.
WORKFLOW LIMIT

This workflow does not infer runtime behaviour from package names, conduct interviews, crawl systems or establish legal compliance.