IT Auditor Verification Guide

This guide explains how IT auditors can independently verify that the data and rulesets used in an MTC Skopos analysis were not altered between extraction and analysis, so that the results faithfully reflect the source system.

What MTC Skopos records

Every analysis log (.log) captures cryptographic evidence at two key moments:

Moment	What is recorded	Where
Data extraction	SHA-256 checksum, row count, file path, and timestamp for each downloaded table	download.log (signed)
Analysis execution	SHA-256 checksum, row count, and file path for each data source table; ruleset checksum and row count	analysis.log (signed)

Both files are Ed25519-signed, making any post-hoc modification detectable.

Step-by-step verification

1. Verify the signatures

Before trusting any recorded checksums, confirm that the log files themselves have not been tampered with.

• Open the analysis result in MTC Skopos. A green lock icon confirms a valid signature
• Or perform independent signature verification using openssl or Python

If the signature is invalid (red shield icon), the file has been modified and should not be trusted.

2. Compare extraction vs. analysis checksums

Open the analysis log file and locate these sections:

Extraction record: in the download log (download.log), each entry records the SHA-256 checksum computed at the moment data was extracted from the source system:

{
  "history": [{
    "date": "2026-03-15T09:30:00.000Z",
    "tables": [
      {
        "name": "AGR_1251",
        "file": "AGR_1251.txt",
        "checksum": "sha256:a3f8c0...",
        "rows": 1042102
      }
    ]
  }]
}

Analysis record: in the analysis log, each data source table has its checksum recomputed during import:

{
  "datasources": [{
    "name": "production-system",
    "tables": {
      "AGR_1251": {
        "checksum": "sha256:a3f8c0...",
        "rows_count": 1042102,
        "file": "/data/AGR_1251.txt"
      }
    }
  }]
}

If the checksums match, the file was not modified between extraction and analysis. If they differ, the data was altered.

3. Verify the ruleset

The analysis log records the ruleset's SHA-256 checksum, row count, and last modification date:

{
  "ruleset": {
    "name": "standard-sod",
    "checksum": "sha256:7455f2...",
    "rows_count": 98631,
    "last_modified_at": 1725974400
  }
}

To confirm the ruleset was not modified:

• Compare the recorded checksum against a known-good copy of the ruleset (e.g., your organization's approved version)
• Verify the row count matches expectations
• Check the last_modified_at timestamp predates the analysis execution

4. Independently hash the source files

For maximum assurance, recompute SHA-256 checksums directly on the source files and compare them against both the download log and the analysis log:

Linux / macOS:

sha256sum AGR_1251.txt
# Output: a3f8c0...  AGR_1251.txt
# Compare with the checksum values in both logs

Windows (PowerShell):

Get-FileHash AGR_1251.txt -Algorithm SHA256
# Compare Hash value with the checksum values in both logs

If all three checksums match (download log, analysis log, and independent computation), the file integrity is confirmed end-to-end.

5. Verify analysis scope and criteria

The analysis log also records the exact parameters used:

Section	What it proves
about.version / about.build	Which version of MTC Skopos was used
about.licensed_to	Which organization ran the analysis
analysis.started_on / analysis.completed_on	When the analysis was executed
analysis_criteria	Which users, roles, risk types, and business processes were in scope
simulation_criteria	Whether any what-if simulations were applied (role additions/removals)

Review the analysis_criteria to confirm the analysis scope matches what was agreed, for example that all user types were included and no risks were excluded.

Summary checklist

1. Signature valid? Green lock in MTC Skopos, or independent verification passes
2. Data checksums match? Download log checksums = analysis log checksums for each table
3. Ruleset checksum matches? Recorded checksum matches your approved ruleset version
4. Row counts plausible? No unexpected drops in row count between extraction and analysis
5. Analysis scope correct? Criteria match the agreed audit scope (no excluded users or risks)
6. Timestamps consistent? Extraction date precedes analysis date; analysis date falls within the audit window
7. BYOK signature valid? (if applicable) Non-repudiation signature confirms organizational authorization