Compliance

VibeFlow provides built-in compliance tracking for regulated industries. Tag work items with compliance frameworks, track findings from security reviews, and generate audit-ready reports.

Supported Frameworks

Compliance Tagging

Tag any work item (todo, issue, or finding) with one or more compliance frameworks:

Adding Tags

1. Open a work item
2. Click + Compliance Tag
3. Select the framework (e.g., HIPAA)
4. Add the section reference (e.g., "§164.312")
5. Add a description (e.g., "Access control implementation")

Tag Deduplication

Tags are deduplicated by (framework, section_reference) per entity — you can't tag the same section twice on the same item.

Compliance Findings

Findings are created during security review when vulnerabilities are identified:

Finding Properties

Finding Lifecycle

1. Created (open) — Security lead identifies a vulnerability
2. In Progress (in_progress) — Remediation work underway
3. Resolved (resolved) — Fix implemented, commit recorded
4. Accepted Risk (accepted_risk) — Risk acknowledged, not fixed

Auto-Resolution

When a remediation issue linked via create_security_review_link is completed:

• The source item's security_reviewed flag is automatically set to true
• The finding status can be updated to resolved with the resolution commit

Compliance Dashboard

The Compliance tab provides:

• Summary view — Findings grouped by framework with resolved/open counts
• Findings list — All findings with filtering by framework, severity, and status
• Source Item and Addressed By columns — Trace findings back to origin and remediation
• Section Reference column — Quick reference to specific compliance sections

Worked Example — SOC 2 CC6.1 on a Session-Ownership Hardening

This is the actual flow we recommend, illustrated with a recent change:

1. Originating issue ships: A code-modifying issue (e.g., the post-compaction session_init self-rehydration fix) is committed and moved to done.
2. Security Lead reviews: The Security Lead persona, polling for done items where security_reviewed=false, identifies that the original fix used a bare session_id equality check — a stolen / leaked session ID could be replayed from a different host to take over an active session.
3. Finding created: The Security Lead opens a compliance finding tagged SOC 2 §CC6.1 ("Logical access controls — restrict access to authorized users") with severity high, points the Source Item at the originating issue, and rejects security review with remediation guidance.
4. Remediation issue: A follow-up issue is filed (e.g., "harden self-rehydration to a 4-facet match: session_id + user_id + working_directory + persona") and linked via create_security_review_link. The remediation issue inherits the same SOC 2 §CC6.1 tag.
5. Auto-close: When the remediation issue is committed and marked done, the linkage flips the original item's security_reviewed flag to true and the finding can be closed resolved with the fix commit recorded.

The compliance dashboard then shows: one CC6.1 finding, status resolved, with both the source item and the remediation item linked — giving an auditor a single-page narrative of the issue, the analysis, and the fix without needing to grep commit history.

📷 Screenshot needed: Compliance Findings tab filtered to SOC 2 showing one resolved CC6.1 finding with the Source Item and Addressed By columns populated. Caption: "A finding traces from the original code change to the remediation issue — auditor-ready in one row."

Best Practices

1. Tag early — Apply compliance tags when creating work items, not after the fact
2. Link findings to remediation — Always create a linked fix item for each finding
3. Document accepted risks — When accepting risk, add detailed remediation notes
4. Regular audits — Review the compliance dashboard weekly for unresolved findings