vulkro-sf compliance

The compliance command family turns a Salesforce scan into auditor-ready evidence. It maps every finding into the controls of the framework you ask for, renders the rollup, and bundles the supporting material an assessor expects to see. Like the rest of vulkro-sf, it runs entirely on the local machine: the scan it reads was produced offline, and no finding leaves your laptop.

The family has stable subcommands (bundle, ropa, hipaa-matrix, attest, kpi) and three additions: a framework report, an evidence-export pipeline bundle, and a baa-verify check over a local data-agreements registry.

Synopsis

vulkro-sf compliance <subcommand> [PATH] [flags]

PATH defaults to the current directory and should point at the SFDX project (or retrieved metadata folder) the scan covers. The compliance subcommands re-run the detector pipeline over PATH, then project the findings into the requested framework.

Subcommands

Subcommand	What it produces
bundle	The full compliance evidence bundle across every framework the engine ships.
ropa	A GDPR Article 30 Record of Processing Activities for the Salesforce data surfaces the scan found.
hipaa-matrix	A HIPAA Security Rule safeguard matrix (administrative, physical, technical) mapped to findings.
attest	A signed attestation summary suitable for attaching to a control-owner sign-off.
kpi	Rollup KPIs (open findings by severity, control coverage, trend) for a compliance dashboard.
report --framework <fw>	A single-framework control report: sox, pci, hipaa, or gdpr.
evidence-export	A pipeline-ready evidence bundle for soc2, hipaa, iso, or fedramp assessment workflows.
baa-verify	Checks that every external data processor reached by the org is covered by a Business Associate Agreement entry (finding SF-COMPLIANCE-BAA-001).

Flags

Flag	Type	Default	Description
--framework <fw>	enum	(required for report)	The control framework to project findings into: sox, pci, hipaa, or gdpr. One framework per report invocation.
--profile <name>	enum	(required for evidence-export)	The assessment pipeline to bundle for: soc2, hipaa, iso, or fedramp.
--registry <path>	path	.vulkro-sf/data-agreements.yaml	For baa-verify: the data-agreements registry file that lists each external processor and its BAA status.
--format <fmt>	enum	table	Output format: table (human-readable on the terminal), json (machine-readable), or html (a self-contained report file).
--output, -o <path>	path	stdout	Where to write the report or bundle. Recommended for html and for evidence-export.

What it does

report --framework sox|pci|hipaa|gdpr

Projects the scan's findings into one control framework and renders a control-by-control report. Each control row lists the Salesforce findings that feed it, so a control owner can read straight down the framework and see exactly which findings gate which control.

• sox: access-control and change-integrity controls (separation of duties, privileged-access posture, logging) that map to the financial-reporting control set.
• pci: the PCI DSS requirement groups that the platform-side findings touch (secrets handling, transmission confidentiality, access control, input validation).
• hipaa: the HIPAA Security Rule safeguards. For the full administrative / physical / technical breakdown use hipaa-matrix; report --framework hipaa is the condensed control rollup.
• gdpr: the data-protection obligations the scan can speak to (personal-data exposure surfaces, transmission security, access enforcement). For the Article 30 record specifically, use ropa.

# SOX control report as a self-contained HTML file.
vulkro-sf compliance report . --framework sox -o sox-controls.html

# PCI rollup on the terminal.
vulkro-sf compliance report . --framework pci

# GDPR control report as JSON for a downstream GRC import.
vulkro-sf compliance report . --framework gdpr --format json -o gdpr.json

evidence-export

Bundles a single, pipeline-ready evidence package for one assessment workflow. Where report renders one framework's control view, evidence-export assembles the cross-artifact bundle an assessor's intake pipeline expects: the control mapping, the finding inventory, and the supporting per-finding evidence rows, organized for the named profile.

# SOC2 evidence bundle for a Type II assessment intake.
vulkro-sf compliance evidence-export . --profile soc2 -o soc2-evidence.html

# HIPAA evidence bundle.
vulkro-sf compliance evidence-export . --profile hipaa -o hipaa-evidence.html

# ISO 27001 Annex A evidence bundle.
vulkro-sf compliance evidence-export . --profile iso -o iso-evidence.html

# FedRAMP evidence bundle (built on the NIST SP 800-53 control baseline).
vulkro-sf compliance evidence-export . --profile fedramp -o fedramp-evidence.html

baa-verify

Reads a local data-agreements registry (default .vulkro-sf/data-agreements.yaml) and checks it against the external data processors the scan found the org reaching: Named Credential endpoints, outbound callout hosts, and Connected App callbacks. When the org sends or receives data to a processor that has no covered Business Associate Agreement entry in the registry, baa-verify emits SF-COMPLIANCE-BAA-001.

The registry is a plain YAML file you keep in version control. Each entry names a processor, the host or endpoint it covers, and its agreement status. A minimal registry looks like this:

# .vulkro-sf/data-agreements.yaml
processors:
  - name: Acme Claims API
    host: api.acmeclaims.example
    baa: signed          # signed | pending | none
    effective: 2026-01-01
  - name: Legacy Faxing Service
    host: fax.legacy.example
    baa: none

A processor with baa: signed and an in-window effective date passes. A processor that the scan reaches but the registry does not list at all, or lists with baa: none or baa: pending, triggers SF-COMPLIANCE-BAA-001 so the gap surfaces before PHI flows to an uncovered party.

# Verify against the default registry path.
vulkro-sf compliance baa-verify .

# Point at a registry kept elsewhere.
vulkro-sf compliance baa-verify . --registry config/data-agreements.yaml

Examples

# Full evidence bundle across every shipped framework.
vulkro-sf compliance bundle . -o compliance-bundle.html

# GDPR Article 30 Record of Processing Activities.
vulkro-sf compliance ropa . -o ropa.html

# HIPAA safeguard matrix (administrative / physical / technical).
vulkro-sf compliance hipaa-matrix . -o hipaa-matrix.html

# Dashboard KPIs as JSON.
vulkro-sf compliance kpi . --format json -o kpi.json

Exit codes

• 0 - the report or bundle was produced and no gating finding was raised (for baa-verify: every reached processor is covered).
• 1 - the report was produced and at least one finding gates the requested framework (for baa-verify: at least one SF-COMPLIANCE-BAA-001 was raised).
• 2 - error: bad arguments, an unknown framework or profile, a missing or unparseable registry file, IO failure, or internal crash. The error message names the cause and the next step (for example, a missing registry prints the path it looked for and how to create it).