Running a Compliance Profile

A compliance profile is a list of items — scan templates, API scenarios, UI test suites, performance scenarios — each carrying the controls it satisfies (e.g. PCI-DSS 11.2, ISO 27001 A.8.8). Running a profile dispatches every item against the targets you select, then aggregates the per-item pass/fail into control evaluations.

This page covers the run dialog at app.proofarc.ai/compliance — what each picker does, what gets skipped vs. failed, and how to read the execution-history row.

The picker, top to bottom

1. Project selector

Top of the page. Drives everything below it — only environments linked to the selected project appear in the run dialog. If you switch projects mid-flight, the open dialog's environment list refreshes accordingly.

2. Environment

In the run dialog. Lists environments that the active project has explicitly linked. If the project has no environments linked, the picker is empty and a helper text tells you to link one in the project's settings first.

This is intentional — running a PCI-DSS profile against the wrong environment's targets (e.g. accidentally scanning a customer's prod box from a dev project) is the failure mode the project scope prevents.

3. Targets — multi-select

Once an environment is picked, the dialog shows every target configured for it as a checkbox list. Pick which ones the run should cover; the Execute (N) button shows the selected count.

Two shortcuts:

• Select all — every target in the environment.
• Clear all — start over.

The run goes against only the targets you check. The previous behavior (resolve a single "best" target by priority) is gone — explicit selection means the profile's coverage matches the audit story you tell.

Smart tool routing

For each (profile item, selected target) pair, the executor decides whether to actually run the item. The decision rules:

• Scan templates (NMAP, ZAP, Nikto, Nuclei, SQLMap, …) are routed by target type. Only the combinations below run; everything else is skipped.
• API scenarios, UI test suites, and performance scenarios run against every selected target unconditionally — these are end-user flows that count as evidence for any target type, per the patent claim.

Target-type → compatible tools

Target type	Tools that will run
WEB_APP	ZAP, Nikto, Nuclei
REST_SERVICE	Nuclei, ZAP, Nikto, SQLMap
GRAPHQL	Nuclei, ZAP
GRPC	Nuclei
IP_ADDRESS	NMAP, Nuclei
IP_RANGE	NMAP
HOSTNAME	NMAP, Nuclei, Nikto
DATABASE	NMAP
MOBILE_APP	— (handled by the mobile-test agent)

A combination not in this table is skipped, not failed. The distinction matters for the execution row (see below).

The router is additive — adding a new scanner means explicitly listing the target types it supports. That's a deliberate choice so a new tool can't silently start running against every target type.

Reading execution results

The execution-history table shows one row per run. The counters tell three different stories:

Counter	Meaning
Passed	Item executed against every eligible target and met its pass condition. The controls it satisfies move toward MET.
Failed	Item executed but the pass condition failed for at least one target. The controls it satisfies move to GAP. If the item is marked isRequired, the rest of the pipeline is blocked.
Skipped	Item had no eligible target (the tool isn't applicable to any selected target type) OR the pipeline was already blocked by a prior required failure. Not a control gap — the audit story is "tool doesn't apply here," not "we tried and failed."

MET / GAP status only applies to controls touched by items that actually ran. A control that no run has evaluated yet shows as STALE on the framework summary, not as GAP.

Live status updates

While at least one row in the history table has status RUNNING, the Compliance dashboard re-fetches the executions list every 5 seconds and updates the row in place. Polling stops automatically once every run lands in a terminal state (PASSED / FAILED / PARTIAL). You don't need to click Refresh.

If a row appears stuck on RUNNING for more than a few minutes, check that the relevant agent container is healthy — the backend really dispatches the job, so a stuck RUNNING row means the agent isn't reporting back, not that the UI is wrong.

Final execution status

• PASSED — failed = 0. Every run item met its pass condition; skipped items are fine.
• FAILED — passed = 0. Nothing ran successfully (often a config issue — wrong target, no agent online).
• PARTIAL — both passed and failed are > 0. Some controls are MET, others are GAP. The summary shows which.

When the picker is empty

Symptom	Cause	Fix
Environment picker shows no options	Project has no environments linked.	Open project settings → Environments → link one (or more).
Targets list is empty for selected env	Environment has no targets configured.	Open the environment → add targets matching the target types you want covered.
Execute (0) button stays disabled	No targets checked.	Tick at least one. Use Select all if you want everything in the env.
Every item shows Skipped after the run	Tool–target type mismatch — none of your selected targets are eligible for the items in this profile (e.g. NMAP-heavy profile against only WEB_APP targets).	Either add a IP_ADDRESS/HOSTNAME target to the env, or swap to a profile whose items match the target types you have.

Backwards compatibility

The API endpoint POST /api/compliance/profiles/{id}/execute accepts both shapes:

• New (preferred): {"projectId": …, "environmentId": …, "targetIds": [1, 2, 3], "versionTag": "…"}
• Legacy (single-target): {"projectId": …, "environmentId": …, "target": "host:port", "versionTag": "…"}

If both are sent, targetIds wins. Existing automation that hits the legacy path keeps working unchanged.