Execution Workflows
Scan Findings Become Corrective Actions Automatically
Every scan engine already produced dated, severity-rated findings (prowler_cspm, trivy_vuln, syft, presidio, etc.), but a high is still just a row until someone turns it into a plan. Gap J's auto-wire makes that translation automatic: every high or critical ScanFinding posted via POST /scans/{id}/results now creates an idempotent CompliancePlanItem in the tenant-wide 'Scan Findings' plan, linked to the finding, with requires_evidence true.
Transcript
High and critical scan findings no longer sit in a findings table. They become tracked corrective actions with evidence-required closure.
Every high or critical ScanFinding posted via the scan results callback now creates an idempotent item in the tenant-wide Scan Findings plan, linked to the finding.
Those items appear immediately in Assigned to me and overdue views, with a seven or fourteen day target date.
Close it with a verified Evidence Vault file or a passing rescan. Without that, the status to done transition is rejected.
A second report for the same finding does not create a second corrective action. Medium and lower findings stay as findings until you pull them into a plan deliberately.
Why this is required
Article 5(2) accountability and Article 9 risk management are not satisfied by knowing something is high, they are satisfied by showing the plan to fix it, who owns it, and when it will be done. A findings table with no plan is a gap analysis with no programme of work, which is exactly what a regulator's second question exposes.
Manual generation (Compliance Plans → Auto-Generate → include_scan_findings) already created that link, but it required a person to remember to click it. An automatic path means a finding that appears at 02:00 on a Saturday is tracked by 02:05, even before anyone has had coffee.
What EuroCompliant does
POST /scans/{id}/results handler (routers/scans.py:1515) now calls _auto_create_corrective_action_for_finding for every high/critical severity finding in the payload. The helper (scans.py:1520) creates or reuses the 'Scan Findings' CompliancePlan (status active, description auto-created…), then one CompliancePlanItem per finding (source scan, linked_finding_id, requires_evidence true, priority critical for critical else high, target_date 7/14 days). Idempotent per finding.id, re-soft-deleting and re-reporting the same title is deduped by title+connector above, but a second report for the same underlying finding.id does not create a duplicate corrective action.
Those items appear immediately in GET /compliance-plans/items (including ?mine=true and ?overdue=true), in the frontend Compliance Plans → Assigned to me and overdue views, and in GET /compliance-plans/items?status=todo filtered by source scan.
Loop-closure still requires verified evidence: a linked corrective action cannot move to done without either a resolution_evidence_id (Evidence Vault link) or a linked passing rescan (ScanJob completed with no open high/critical for that framework). The scheduler's overdue (scheduler.py:543) and upcoming (scheduler.py:588) notifiers run every 300 seconds and fire plan.item.due webhooks, so assignees are reminded without anyone running a cron manually.
Walking through it
Trigger a scan that finds something high or critical
Any connector/engine pair will do, e.g. a test git repo with a high trivy_vuln CVE or a Prowler critical.
Open /scans →See the corrective action appear
Open Compliance Plans → filter Assigned to me or overdue. The 'Scan Findings' plan now has a todo linked to that finding, with requires_evidence true and a target date 7/14 days out.
Open /plans →Close it with evidence
Attach a verified EvidenceFile or wait for a passing rescan. Without that, the status→done transition is rejected with 400 'Evidence required to close' (or a still-open finding message unless manual_override with evidence is passed).
Open /evidence →The law
Risk management system
A continuous iterative process, a finding that automatically becomes a dated, owned corrective action is evidence that iteration is actually operating.
Accountability (GDPR, borrowed)
Being able to show the plan, the owner and the deadline for every open high, not just the finding itself.
Frequently asked
Does a second scan report for the same issue create a second corrective action?
No for the same finding.id, idempotent per linked_finding_id and only for open/in-progress items. Re-reporting the same title on the same connector is also deduped by title+connector before a new ScanFinding is even created, so no second finding means no second corrective action either.
What about medium/low/info findings?
They are stored as ScanFindings but do not auto-create corrective actions, only high and critical do. Use Auto-Generate with include_scan_findings if you want to pull mediums into a plan deliberately.
Related guides
Compliance plans, milestones, and deadlines
Turn obligations into trackable tasks with deadlines, dependencies, milestones, and a Gantt timeline.
Compliance Roadmaps: Gantt Plans and Corrective Actions
Turn unfinished obligations and scan findings into a Gantt-tracked plan with owners, dates, and evidence-required closure.
Evidence vault & audit trail
Turning completed checklist items into artefacts a regulator can inspect, and the logging duties behind Articles 12 and 26.
Try it on your own systems
Everything in this guide runs in the live product. Start a free trial and follow along with your own data.
Start free trial