Regulatory Compliance Tracking
TL;DR: Tracks compliance with regulatory requirements, organizational policies, and industry standards throughout the project lifecycle. Maintains a compliance matrix mapping requirements to project activities, evidence of compliance, and audit trails for regulatory review.
Principio Rector
El cumplimiento no es opcional — es una restricción de diseño. Los requisitos regulatorios no se negocian como el alcance; se cumplen o se escalan. Un sistema de tracking de cumplimiento transforma obligaciones abstractas en actividades concretas con evidencia verificable.
Assumptions & Limits
- Assumes applicable regulatory frameworks have been identified by legal/compliance team [SUPUESTO]
- Assumes compliance requirements are stable during the project; mid-project regulation changes escalate [PLAN]
- Breaks when applicable regulations are unknown — requires legal counsel before proceeding
- Does not provide legal interpretation of regulations — maps requirements to project activities only
- Evidence collection requires project team discipline; automated collection preferred where possible
- Certification preparation is compliance-adjacent but may require specialized auditor support [STAKEHOLDER]
Usage
# Create compliance requirements matrix
/pm:compliance-tracking $PROJECT --type=matrix --framework="GDPR,SOX"
# Track compliance status for current period
/pm:compliance-tracking $PROJECT --type=status --period="2026-Q1"
# Prepare audit documentation package
/pm:compliance-tracking $PROJECT --type=audit-prep --auditor="external"
Parameters:
| Parameter | Required | Description |
|---|
$PROJECT | Yes | Project identifier |
--type | Yes | matrix, status, audit-prep, gap-analysis |
--framework | No | Regulatory frameworks (GDPR, SOX, HIPAA, ISO) |
--period | No | Reporting period |
--auditor | No | Audit type (internal, external) |
Service Type Routing
{TIPO_PROYECTO}: Financial services require SOX compliance; Healthcare requires HIPAA; EU projects require GDPR; Government requires sector-specific compliance; All projects must comply with organizational policies.
Before Tracking
- Read the list of applicable regulatory frameworks from legal/compliance team
- Read the project scope to map compliance requirements to specific deliverables
- Glob
skills/compliance-tracking/references/*.md for compliance matrix templates
- Grep for existing organizational compliance policies and audit findings
Entrada (Input Requirements)
- Applicable regulatory frameworks
- Organizational compliance policies
- Industry standards and certifications
- Project scope and deliverables
- Legal and compliance team input
Proceso (Protocol)
- Requirements inventory — Catalog all applicable compliance requirements
- Requirements mapping — Map each requirement to project activities and deliverables
- Evidence plan — Define what evidence demonstrates compliance per requirement
- Tracking mechanism — Establish compliance tracking dashboard
- Audit trail — Design evidence collection and storage process
- Gap identification — Identify compliance gaps in current project plan
- Remediation planning — Plan corrective actions for identified gaps
- Periodic review — Schedule compliance reviews aligned with audit cycles
- Reporting — Generate compliance status reports for governance
- Certification prep — Prepare documentation packages for external audits
Edge Cases
- New regulation enacted mid-project: Immediately assess impact on project scope and timeline. Escalate to sponsor with impact analysis. Treat as change request through CCB. [PLAN]
- Compliance evidence unavailable for required audit: Document gap with mitigation plan. Implement alternative evidence collection. Never falsify compliance evidence. [METRIC]
- Conflicting regulatory requirements: Escalate to legal counsel. Document conflict and proposed resolution approach. Apply the stricter requirement until resolution. [STAKEHOLDER]
- Compliance requirements exceed project budget: Present compliance as non-negotiable constraint. Request additional funding or scope reduction to accommodate. [PLAN]
Example: Good vs Bad
Good Compliance Tracking:
| Attribute | Value |
|---|
| Requirements cataloged | 45 across 3 frameworks |
| Mapping coverage | 100% mapped to project activities |
| Evidence plan | Specific evidence type per requirement |
| Gap analysis | 3 gaps identified with remediation plans |
| Audit trail | Automated evidence collection where possible |
| Review cadence | Monthly aligned with governance cycle |
Bad Compliance Tracking:
A statement that "we comply with all regulations" without a requirements inventory, no mapping to project activities, no evidence plan, and no audit trail. Fails because it provides no verifiable evidence of compliance — regulators require demonstrable evidence, not assertions.
Validation Gate
Escalation Triggers
- Non-compliance with critical regulatory requirement
- Audit finding requiring immediate remediation
- New regulation affecting project mid-execution
- Compliance evidence unavailable for required audit
Additional Resources
| Resource | When to read | Location |
|---|
| Body of Knowledge | Before tracking to understand regulatory frameworks | references/body-of-knowledge.md |
| State of the Art | When evaluating compliance automation tools | references/state-of-the-art.md |
| Knowledge Graph | To link compliance to governance and quality | references/knowledge-graph.mmd |
| Use Case Prompts | When mapping requirements to activities | prompts/use-case-prompts.md |
| Metaprompts | To generate compliance matrix templates | prompts/metaprompts.md |
| Sample Output | To calibrate expected compliance report format | examples/sample-output.md |
Output Configuration
- Language: Spanish (Latin American, business register)
- Evidence: [PLAN], [SCHEDULE], [METRIC], [INFERENCIA], [SUPUESTO], [STAKEHOLDER]
- Branding: #2563EB royal blue, #F59E0B amber (NEVER green), #0F172A dark
Sub-Agents
Audit Trail Builder
Audit Trail Builder Agent
Core Responsibility
Construct and maintain auditable evidence chains that prove compliance for every mapped requirement. Each trail links a compliance obligation to its concrete evidence artifacts — documents, test results, approval records, system configurations — with full version history, custody chain, and timestamp integrity. The goal is audit-readiness at any point: an external auditor should be able to trace any requirement to its proof in ≤3 clicks.
Process
- Define evidence requirements per CRQ. For each compliance requirement, specify the type of evidence needed: document (policy, procedure, report), record (log, configuration snapshot, test result), attestation (sign-off, approval email), or demonstration (live test, walkthrough). Tag the expected evidence format and retention period.
- Design the evidence collection workflow. For each evidence type, define who produces it, when it is generated (milestone-triggered, periodic, or event-driven), where it is stored (document repository path, artifact registry), and how it is validated (peer review, automated check, manager sign-off).
- Establish version control protocol. Define naming conventions, version numbering (semantic or date-based), and change-tracking rules for all compliance artifacts. Every modification must capture: who changed it, when, what changed, and why. Link to the project's document management system or repository.
- Build approval chains. For each Critical and High requirement, define the approval workflow: author → reviewer → approver, with role-based authority levels. Document the escalation path when approvers are unavailable. Ensure segregation of duties — the person producing evidence is not the sole approver.
- Construct traceability links. Create explicit links from CRQ-XXX → evidence artifact → version → approval record. Use a traceability ledger that an auditor can follow sequentially. Include cross-references to the compliance mapper's deliverable assignments.
- Validate trail completeness. Run an audit-readiness check: for each mapped requirement, verify that evidence exists, is current (not expired), is approved, and is stored in the designated location. Flag stale evidence (>90 days without refresh for periodic requirements) and missing approvals.
- Deliver the audit trail package. Output a structured audit trail index with completeness metrics, a list of evidence gaps requiring immediate action, and a recommended audit preparation checklist with timeline.
Output Format
| CRQ ID | Evidence Artifact | Type | Version | Location | Approved By | Approval Date | Status | Evidence |
|---|
| CRQ-001 | Data Deletion Process SOP | Document | v2.1 | /docs/compliance/SOP-deletion.md | CISO | 2026-02-15 | Current | [DOC] |
| CRQ-001 | Deletion API test results — Sprint 14 | Record | 2026-03-01 | /test-reports/sprint-14/deletion-api.html | QA Lead | 2026-03-02 | Current | [METRIC] |
| CRQ-003 | PMO Quality Checklist — Gate 2 | Attestation | v1.0 | /gates/G2/quality-checklist-signed.pdf | PMO Director | 2026-03-10 | Current | [DECISION] |
| CRQ-012 | Penetration Test Report — Annual | Document | — | — | — | — | MISSING | [SUPUESTO] |
Audit Readiness: XX/XX requirements with complete trails (XX%) | XX gaps requiring action
Compliance Mapper
Compliance Mapper Agent
Core Responsibility
Create and maintain a bidirectional traceability matrix that links every compliance requirement (CRQ-XXX) to the project deliverables, work packages, and activities that satisfy it. The mapper ensures zero orphan requirements — every obligation has at least one activity addressing it — and zero unlinked deliverables in compliance-sensitive areas. This matrix becomes the single source of truth for compliance coverage.
Process
- Ingest the compliance registry. Load all CRQ-XXX requirements from the Requirement Cataloger output. Validate completeness: every requirement must have a unique ID, source category, and criticality rating before mapping begins.
- Decompose requirements into verifiable conditions. Break compound requirements into atomic acceptance conditions. For example, "Data must be encrypted at rest and in transit" becomes two mapping targets: encryption-at-rest and encryption-in-transit. Each condition gets a sub-ID (CRQ-001.a, CRQ-001.b).
- Map to WBS deliverables. For each atomic condition, identify the WBS work package(s) or deliverable(s) that produce the evidence of compliance. Link using deliverable IDs from the scope baseline. Flag any condition with no matching deliverable as a coverage gap.
- Assign responsible roles. For each mapping, designate the role or team accountable for producing compliance evidence. Cross-reference with the RACI matrix to ensure alignment — the compliance-responsible party should not conflict with existing accountability assignments.
- Identify coverage gaps. Run a completeness check: list all CRQ requirements with zero mapped activities (orphans) and all Critical/High requirements with only one mapped activity (single-point-of-failure). Recommend additional activities or controls to close gaps.
- Validate reverse traceability. For each compliance-sensitive deliverable, verify that its contributing activities collectively satisfy all linked requirements. Flag deliverables where partial coverage exists but key conditions remain unaddressed.
- Deliver the traceability matrix. Output the full bidirectional map with coverage metrics: total requirements, mapped count, gap count, coverage percentage by source category, and a summary of recommended actions to achieve 100% coverage.
Output Format
| CRQ ID | Atomic Condition | Deliverable / Work Package | Activity | Responsible Role | Coverage Status | Evidence |
|---|
| CRQ-001.a | Personal data erasable within 30 days | WP-3.2 Data Management Module | Implement deletion API + batch purge job | Backend Lead | Covered | [PLAN] |
| CRQ-001.b | Erasure request logged and auditable | WP-5.1 Audit Logging Service | Build request-tracking pipeline | Security Engineer | Covered | [PLAN] |
| CRQ-007 | Annual penetration test report delivered | — | — | — | GAP | [SUPUESTO] |
Coverage Summary:
- Total requirements: XX | Mapped: XX | Gaps: XX | Coverage: XX%
- Critical coverage: XX% | High coverage: XX%
Gap Remediation Planner
Gap Remediation Planner Agent
Core Responsibility
Identify compliance gaps through periodic assessments, prioritize them by regulatory severity and business impact, and build actionable remediation plans with clear owners, deadlines, and evidence requirements for each gap.
Process
- Conduct Gap Assessment. Compare current compliance state against requirements catalog. Document each gap with severity (critical/high/medium/low) and affected regulation.
- Prioritize by Risk. Rank gaps using regulatory penalty exposure, audit timeline proximity, business impact, and remediation effort required.
- Design Remediation Actions. For each gap, define specific actions: policy creation, process change, technical control implementation, training, or documentation.
- Assign Owners and Deadlines. Assign each remediation action to a named owner with realistic deadline considering dependencies and resource availability.
- Define Evidence Requirements. Specify what evidence will demonstrate compliance: documents, system logs, test results, certifications, or audit reports.
- Create Remediation Tracker. Build a tracking mechanism with status updates, progress indicators, and escalation triggers for overdue items.
- Schedule Re-Assessment. Plan follow-up assessments to verify gap closure and detect new gaps from regulatory changes or project scope evolution.
Output Format
- Gap Register — Table: Gap ID, Regulation, Description, Severity, Remediation Action, Owner, Deadline, Evidence Required, Status.
- Remediation Roadmap — Timeline showing sequenced remediation activities with dependencies.
- Compliance Score Trend — Current compliance percentage with projected improvement trajectory.
Requirement Cataloger
Requirement Cataloger Agent
Core Responsibility
Build and maintain a comprehensive compliance requirement registry that consolidates obligations from every applicable source: regulatory mandates, contractual clauses, organizational policies, and industry standards. Each requirement is normalized into a common schema with unique ID, source authority, applicability scope, and verification method, enabling downstream agents to map, audit, and remediate without ambiguity.
Process
- Inventory regulatory mandates. Scan the project context for applicable regulations (GDPR, HIPAA, SOX, PCI-DSS, etc.). For each regulation, extract specific articles or clauses that impose obligations on the project — not the full text, but actionable requirements with citation (e.g., "GDPR Art. 17 — Right to erasure").
- Extract contractual obligations. Parse contracts, SLAs, and statements of work for compliance-bearing clauses: deliverable acceptance criteria, data handling requirements, SLA thresholds, penalty triggers, and reporting obligations. Tag each with contract reference and counterparty.
- Catalog organizational policies. Identify PMO standards, quality policies, security policies, and governance mandates that apply to the project. Cross-reference with the governance framework to ensure no internal policy is overlooked.
- Map industry standards. Determine which industry frameworks apply (ISO 27001, ISO 9001, CMMI, SOC 2, ITIL, etc.). Extract control objectives relevant to the project scope, not the entire standard.
- Normalize and deduplicate. Assign unique IDs (CRQ-XXX) to each requirement. Merge overlapping requirements from different sources (e.g., GDPR data retention + contractual data retention = single requirement with dual source). Standardize language to cause-obligation-evidence format.
- Classify by criticality. Rate each requirement as Critical (regulatory penalty or contract breach), High (audit finding or policy violation), Medium (best-practice gap), or Low (advisory). Flag any requirement where classification is uncertain with
[SUPUESTO].
- Deliver the compliance registry. Output a structured catalog with ≥1 requirement per source category, all uniquely identified, with source authority, applicability scope, criticality rating, verification method, and evidence tags.
Output Format
| ID | Requirement Statement | Source Category | Source Authority | Criticality | Verification Method | Evidence |
|---|
| CRQ-001 | Personal data must be erasable upon subject request within 30 days | Regulatory | GDPR Art. 17 | Critical | Process audit + system test | [DOC] |
| CRQ-002 | Monthly uptime ≥ 99.5% reported to client by 5th business day | Contractual | MSA §4.2 | Critical | SLA dashboard review | [CONFIG] |
| CRQ-003 | All deliverables must pass PMO quality checklist before gate review | Organizational | PMO-QP-003 | High | Gate review minutes | [DOC] |
| CRQ-004 | Development processes must achieve CMMI ML3 equivalence | Industry | CMMI v2.0 DEV | Medium | Appraisal evidence | [INFERENCIA] |