SOX 404 Compliance

Sarbanes-Oxley Act, Section 404: Management Assessment of Internal Controls

Overview

The Sarbanes-Oxley Act (SOX) Section 404 requires publicly traded companies to establish and maintain adequate IT General Controls (ITGC) for systems that support financial reporting. Bindy, as a critical DNS infrastructure component in a regulated banking environment, must comply with SOX 404 controls.

Key Requirement: Companies must document, test, and certify the effectiveness of IT controls that affect financial data integrity, availability, and security.

Why Bindy Must Comply with SOX 404

Even though Bindy is DNS infrastructure (not a financial application), it falls under SOX 404 because:

1. Supports Financial Systems: Bindy provides DNS resolution for financial applications (trading platforms, payment systems, customer portals)
2. Service Availability: DNS outages prevent access to financial reporting systems (material impact)
3. Change Management: Unauthorized DNS changes could redirect traffic to fraudulent systems (data integrity risk)
4. Audit Trail: DNS logs provide evidence for financial transaction tracking and fraud detection

In Scope for SOX 404:

• ✅ Change management (code changes, configuration changes)
• ✅ Access controls (who can modify DNS zones, RBAC)
• ✅ Audit logging (7-year retention, immutability)
• ✅ Segregation of duties (2+ reviewers for changes)
• ✅ Incident response (service restoration, root cause analysis)

SOX 404 Control Objectives

SOX 404 defines 5 categories of IT General Controls:

Bindy’s SOX 404 Compliance Controls

1. Change Management (CRITICAL)

SOX 404 Requirement: All code and configuration changes must be authorized, tested, and traceable.

Bindy Implementation:

Evidence for Auditors:

# Show all commits with signatures (last 90 days)
git log --show-signature --since="90 days ago" --oneline

# Show PR approval history
gh pr list --state merged --limit 100 --json number,title,reviews

# Show CI/CD test results
gh run list --workflow ci.yaml --limit 50

Audit Questions:

• ✅ Q: Are all changes authorized? Yes, 2+ approvals required via GitHub branch protection
• ✅ Q: Are changes traceable? Yes, signed commits with author name, timestamp, and description
• ✅ Q: Are changes tested? Yes, CI/CD runs cargo test, cargo clippy, cargo audit on every PR
• ✅ Q: Can you prove no unauthorized changes? Yes, branch protection prevents direct pushes, all changes via PR

2. Access Controls (CRITICAL)

SOX 404 Requirement: Restrict access to production systems and enforce least privilege.

Bindy Implementation:

RBAC Verification:

# Verify controller has minimal required permissions
./deploy/rbac/verify-rbac.sh

# Expected output:
# ✅ Controller has get/list/watch on secrets
# ✅ Controller can create/delete secrets (RNDC key lifecycle)
# ✅ Controller CANNOT update/patch secrets (immutable pattern)
# ✅ Controller can delete managed resources (Bind9Instance, Bind9Cluster, finalizer cleanup)
# ✅ Controller CANNOT delete user resources (DNSZone, Records, ClusterBind9Provider)

Evidence for Auditors:

1. RBAC Policy: deploy/rbac/clusterrole.yaml - Shows minimal required permissions with detailed rationale
2. RBAC Verification: CI/CD artifact rbac-verification.txt - Proves least-privilege access (delete only for lifecycle management)
3. Secret Access Logs: Elasticsearch query Q1 - Shows only bindy-controller accessed secrets
4. Quarterly Access Reviews: docs/compliance/access-reviews/YYYY-QN.md - Shows regular access audits

Audit Questions:

• ✅ Q: Are access rights restricted? Yes, controller has minimal RBAC (create/delete secrets for RNDC lifecycle only, delete managed resources for finalizer cleanup only)
• ✅ Q: Are privileged accounts monitored? Yes, all secret access logged and alerted
• ✅ Q: Are access reviews conducted? Yes, quarterly reviews with security team approval

3. Audit Logging (CRITICAL)

SOX 404 Requirement: Maintain audit logs for 7 years with tamper-proof storage.

Bindy Implementation:

Log Types (7-Year Retention):

Evidence for Auditors:

# Show 7-year retention policy
aws s3api get-bucket-lifecycle-configuration --bucket bindy-audit-logs

# Show WORM (Object Lock) enabled
aws s3api get-object-lock-configuration --bucket bindy-audit-logs

# Show log integrity (checksum verification)
kubectl logs -n dns-system -l app=audit-log-verifier --since 24h

# Query audit logs for specific time period
# (Example: All DNS zone changes in Q4 2025)
curl -X POST "https://elasticsearch:9200/bindy-audit-*/_search" \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {
      "bool": {
        "must": [
          { "term": { "objectRef.resource": "dnszones" } },
          { "range": { "requestReceivedTimestamp": {
              "gte": "2025-10-01T00:00:00Z",
              "lte": "2025-12-31T23:59:59Z"
            }
          }}
        ]
      }
    }
  }'

Audit Questions:

• ✅ Q: Are logs retained for 7 years? Yes, S3 lifecycle policy enforces 7-year retention
• ✅ Q: Can logs be tampered with? No, S3 Object Lock (WORM) prevents deletion/modification
• ✅ Q: How do you verify log integrity? Daily SHA-256 checksum verification via CronJob
• ✅ Q: Can you provide logs from 5 years ago? Yes, S3 Glacier retrieval (1-5 minutes)

4. Segregation of Duties

SOX 404 Requirement: No single person can authorize, execute, and approve changes.

Bindy Implementation:

Evidence for Auditors:

# Show branch protection requires 2 approvals
gh api repos/firestoned/bindy/branches/main/protection | jq '.required_pull_request_reviews'

# Expected output:
# {
#   "required_approving_review_count": 2,
#   "dismiss_stale_reviews": true,
#   "require_code_owner_reviews": false
# }

Audit Questions:

• ✅ Q: Can one person make and approve changes? No, 2+ approvers required, PR author excluded
• ✅ Q: Can admins bypass controls? No, branch protection applies to admins
• ✅ Q: How do you verify segregation? GitHub audit logs show separate approver identities

5. Evidence Collection for SOX 404 Audits

What Auditors Need:

Provide the following evidence package for SOX 404 auditors:

1. Change Management Evidence:

   • Git commit log (last 12 months) with signatures: git log --show-signature --since="1 year ago" > commits.txt
   • PR approval history: gh pr list --state merged --since "1 year ago" --json number,title,reviews > pr-approvals.json
   • CI/CD test results: GitHub Actions workflow artifacts
   • CHANGELOG.md showing all changes with author attribution

2. Access Control Evidence:

   • RBAC policy: deploy/rbac/clusterrole.yaml
   • RBAC verification output: CI/CD artifact rbac-verification.txt
   • Quarterly access review reports: docs/compliance/access-reviews/
   • Secret access audit trail: Elasticsearch query Q1 results (last 12 months)

3. Audit Logging Evidence:

   • S3 bucket configuration (lifecycle, WORM, encryption): aws s3api describe-bucket.json
   • Log integrity verification results: CronJob output (last 12 months)
   • Sample audit logs (redacted): Elasticsearch export for specific date range
   • Audit log access logs (meta-logging): S3 server access logs

4. Incident Response Evidence:

   • Incident response playbooks: docs/security/INCIDENT_RESPONSE.md
   • Incident logs (if any occurred): S3 bindy-audit-logs/incidents/
   • Tabletop exercise results: Semi-annual drill reports

SOX 404 Audit Readiness Checklist

Use this checklist quarterly to ensure SOX 404 audit readiness:

• Change Management:

  • All commits in last 90 days are signed (run: git log --show-signature --since="90 days ago")
  • All PRs have 2+ approvals (run: gh pr list --state merged --since "90 days ago" --json reviews)
  • CI/CD tests passed on all merged PRs (check GitHub Actions)
  • CHANGELOG.md is up to date with author attribution

• Access Controls:

  • RBAC verification script passes (run: ./deploy/rbac/verify-rbac.sh)
  • Quarterly access review completed (due: Week 1 of Q1/Q2/Q3/Q4)
  • Secret access audit query Q2 returns 0 results (no unauthorized access)
  • 2FA enabled for all contributors (verify in GitHub org settings)

• Audit Logging:

  • S3 WORM (Object Lock) enabled on audit log bucket
  • Log integrity verification CronJob running daily
  • Last 90 days of audit logs in Elasticsearch (query: GET /bindy-audit-*/_count)
  • S3 lifecycle policy enforces 7-year retention

• Documentation:

  • Security documentation up to date (docs/security/*.md)
  • Compliance roadmap reflects current status (.github/COMPLIANCE_ROADMAP.md)
  • Incident response playbooks tested in last 6 months (tabletop exercise)

Quarterly SOX 404 Attestation

Sample Attestation Letter (for CFO/CIO signature):

[Company Letterhead]

SOX 404 IT General Controls Attestation
Q4 2025 - Bindy DNS Infrastructure

I, [CFO Name], certify that for the quarter ended December 31, 2025, the Bindy DNS
infrastructure has maintained effective IT General Controls in compliance with
Sarbanes-Oxley Act Section 404:

1. Change Management Controls:
   - ✅ 127 code changes reviewed and approved via 2+ person process
   - ✅ 100% of commits cryptographically signed
   - ✅ 0 unauthorized changes detected

2. Access Control Controls:
   - ✅ RBAC least privilege verified (automated script passes)
   - ✅ Quarterly access review completed (2025-12-15)
   - ✅ 0 unauthorized secret access events detected

3. Audit Logging Controls:
   - ✅ 7-year audit log retention enforced (WORM storage)
   - ✅ Daily log integrity verification passed (100% checksums valid)
   - ✅ Audit logs available for entire quarter

4. Segregation of Duties:
   - ✅ 2+ approvers required for all code changes
   - ✅ No self-approvals detected
   - ✅ Branch protection enforced (no direct pushes to main)

Based on my review and testing, I conclude that internal controls over Bindy DNS
infrastructure were operating effectively as of December 31, 2025.

Signature: ___________________________
[CFO Name], Chief Financial Officer
Date: 2025-12-31

Common SOX 404 Audit Findings (And How Bindy Addresses Them)

See Also

• Audit Log Retention Policy - 7-year retention, WORM storage
• Secret Access Audit Trail - Quarterly review process
• Security Architecture - RBAC architecture
• Build Reproducibility - Supply chain security
• Compliance Roadmap - Tracking compliance progress
• SECURITY.md - Main security policy