DevSecOps + Compliance = DevSecCompOps? Building a Unified Security & Regulatory Pipeline

General
1

I’ve been working with fintech startups across Africa on their security and compliance implementations, and I keep seeing the same inefficiency: security teams and compliance teams work in silos. Separate tools, separate processes, separate audits.

This doesn’t make sense. Security and compliance are asking overlapping questions, just from different angles. In 2026, with continuous monitoring requirements becoming the norm (SOC 2, ISO 27001, GDPR), we need unified pipelines.

The Convergence of Security and Compliance

Here’s what I’m seeing with my fintech clients:

SOC 2 requires continuous control monitoring.
ISO 27001 requires regular security assessments.
GDPR (Q4 2025 amendments) emphasizes ongoing compliance verification.
EU AI Act (August 2026 enforcement) requires continuous risk management for AI systems.

All of these frameworks want the same thing: proof that your controls work, continuously, not just at audit time.

What a Unified Pipeline Looks Like

Instead of separate “security checks” and “compliance checks,” I’m helping clients build integrated pipelines:

Policy Engine Layer: One set of policies that encode both security requirements and regulatory requirements. Using tools like Open Policy Agent or Cloud Custodian.

Examples:

  • Security: “Database must require TLS 1.2+”
  • Compliance: “SOC 2 CC6.7 requires encrypted data in transit”
  • Implementation: Same policy checks both requirements

Automated Evidence Collection: Continuous monitoring that generates evidence for both security posture and compliance status.

  • Container image scans → Security vulnerability reports + SOC 2 change management evidence
  • Infrastructure-as-code checks → Security misconfigurations + ISO 27001 configuration management evidence
  • Access logs → Security incident detection + GDPR data access auditing

Continuous Control Monitoring: Real-time dashboards showing both security posture and compliance posture. Not separate dashboards - unified view.

The Technical Stack

Here’s what actually works in production:

Policy-as-Code: OPA, Kyverno, or Cloud Custodian for policy enforcement
Evidence Collection: Custom automation + tools like Drata, Vanta, or Secureframe
Security Scanning: Snyk, Trivy, or Aqua integrated into CI/CD
Audit Logging: Centralized logging with immutable storage (security + compliance requirement)
Control Monitoring: Custom dashboards or GRC platforms

The key: all of these feed into a single compliance data warehouse. One source of truth.

The Wins

Clients who’ve done this are seeing:

Faster Audits: Evidence is already collected. Last SOC 2 audit took 1 week instead of 4 weeks.

Security and Regulatory Alignment: Security engineers and compliance teams speak the same language - controls, policies, evidence.

Reduced Tool Sprawl: Instead of separate tools for SOC 2, ISO 27001, and security monitoring, unified tooling.

Better Security: Continuous monitoring catches issues faster than quarterly compliance checks.

The Challenges

It’s not all smooth:

Alert Fatigue: Continuous monitoring generates a LOT of signals. You need good filtering and prioritization.

Competing Frameworks: SOC 2, ISO 27001, GDPR, and PCI-DSS all have overlapping but not identical requirements. Mapping them is complex.

Cultural Integration: Security teams and compliance/legal teams don’t always collaborate naturally. This requires organizational change.

Key Insight: Compliance IS Security, Just Different Questions

Think about it:

  • Security asks: “Can an attacker access this data?”
  • Compliance asks: “Can we prove only authorized people access this data?”

Both need:

  • Access controls
  • Audit logs
  • Change management
  • Incident response

Same technical controls, different reporting requirements.

Questions for the Community

Who else is integrating compliance into DevSecOps?

  • What tools are you using for unified security + compliance monitoring?
  • How do you handle framework overlaps (SOC 2 vs ISO 27001 vs GDPR)?
  • How did you get security and legal/compliance teams to collaborate?
  • What’s your approach to reducing alert fatigue from continuous monitoring?

The market is calling this “continuous compliance” or “compliance automation.” I think it’s really just the logical evolution of DevSecOps - shift compliance left, just like we shifted security left.

Thoughts?

2

Sam, this is exactly what we’re trying to implement with Open Policy Agent in our CI/CD pipeline. Your unified approach makes so much sense, but I’m struggling with the practical details.

Granularity Question: How Often Should Policies Run?

This might sound basic, but: at what granularity do you check policies?

Options we’re considering:

  • Every commit: Catches issues earliest, but might slow down development
  • Every PR: Less frequent, but developers might have already written non-compliant code
  • Every deploy: Ensures production is compliant, but issues surface late

We started with “every commit” and developers complained about the feedback loop. Too many policy failures for work-in-progress code.

We moved to “every PR” but now we’re catching issues after developers think they’re done.

The False Positive Problem

Your alert fatigue point is exactly what we’re dealing with. Our OPA policies are generating noise:

Example: Policy says “no hard-coded secrets.” But it flags test fixtures, environment variable examples in documentation, even the word “password” in comments.

False positives kill trust. Developers start ignoring policy failures if 80% are false alarms.

Questions for you, Sam:

  1. How do you tune policies to reduce noise without missing real issues?
  2. Do you have different policy strictness for different environments (dev vs prod)?
  3. How do you handle the “this is a legitimate exception” cases?

Feedback Loops Between Security and Engineering

You mentioned security and compliance teams need to collaborate. From a developer perspective, what makes that collaboration work?

We had security team write policies, then hand them to engineering. Result: policies that block legitimate use cases because security didn’t understand our architecture.

We’re trying embedded security engineers (like Keisha mentioned in the other thread), but it’s slow going. Cultural change is hard.

3

Sam, this framework overlap problem you mentioned - we’re living it right now. Our Fortune 500 financial services company has to maintain compliance with SOC 2, PCI-DSS, ISO 27001, and internal security policies.

The Tool Sprawl Problem

Right now we have:

  • Separate SOC 2 compliance platform (Drata)
  • PCI-DSS scanning tools (different vendor)
  • Internal security monitoring (Splunk + custom dashboards)
  • Vulnerability management (Tenable)

Three different “compliance dashboards” that don’t talk to each other. When executives ask “Are we compliant?”, we have to manually aggregate data from multiple sources.

Framework Mapping is Complex

Your point about overlapping but not identical requirements is the hard part. Example:

SOC 2 CC6.1: Requires logical access controls
ISO 27001 A.9.2: Requires user access management
PCI-DSS 8.2: Requires unique ID for each user

All three care about access controls, but with different specific requirements. Do we implement three different controls? Or one control that satisfies all three, and document the mappings?

We’re trying the unified approach, but the mapping exercise is consuming weeks of time from both security and legal teams.

Budget Pressure to Consolidate

Our CFO is pushing hard to consolidate tools. The reasoning: “Why are we paying for three compliance platforms that do the same thing?”

But they don’t actually do the same thing - each framework has unique requirements. Yet there’s enough overlap that unified tooling should be possible.

Question for you, Sam: Have your clients successfully consolidated to a single GRC platform that handles multiple frameworks? Or do you need specialized tools for each?

The Dream State

What we really want:

  • Unified control framework with framework-specific mappings
  • Single evidence collection system that generates evidence for all frameworks
  • Consolidated audit preparation that doesn’t require manually gathering data from 10 different sources

Is this realistic or are we chasing unicorns?

Also curious: how do you handle the organizational politics of consolidating tools? Each compliance team has their preferred vendor and doesn’t want to change.

4

Sam, I love this concept. At our SaaS company, we’re calling it “Governance as Code” but it’s the same idea - unified security and compliance in pipelines.

The Cultural Challenge is Bigger Than the Technical One

Your mention of security and compliance/legal teams not collaborating naturally - this is the hardest part for us.

Here’s what we’re seeing:

Security engineers think in terms of threats, vulnerabilities, attack vectors. They want to prevent breaches.

Compliance teams think in terms of controls, evidence, audit requirements. They want to pass audits.

Legal teams think in terms of regulations, liability, contracts. They want to avoid fines.

These groups often work in different reporting structures, use different vocabulary, and have different success metrics.

How We Got Them to Collaborate

What’s working for us:

1. Shared Ownership Model: Instead of “security owns this, compliance owns that,” we created cross-functional “governance guilds” that include:

  • Security engineers
  • Compliance specialists
  • Legal counsel
  • Product engineering representatives

These guilds own specific control domains (data protection, access management, change control).

2. Policy-as-Code Reviewed Like Any Other Code: Our compliance policies go through the same pull request and code review process as application code. This:

  • Makes policies visible to everyone
  • Allows engineering to suggest improvements
  • Creates shared understanding of requirements
  • Provides version control and audit trails

3. Unified Language: We stopped using framework-specific language (“CC6.7” vs “A.9.2”) and started describing controls in business terms: “We encrypt data in transit because: (a) it protects customer data, (b) it’s required by SOC 2, (c) it’s required by ISO 27001.”

Getting Buy-In from Legal/Compliance Who Don’t Think in Code

This is Luis’s political challenge. Here’s what worked:

Show, Don’t Tell: We built a prototype of policy-as-code for one control area and demonstrated the benefits:

  • Real-time compliance posture (not quarterly snapshots)
  • Automatic evidence for audits
  • Faster identification of violations

Legal got excited when they saw “We can prove we were compliant on any given day” vs “We can show we were compliant during audit period.”

Risk Framing: We framed it as risk reduction, not technology. “This reduces the risk of compliance drift between audits.”

Make Them Part of the Design: We involved legal in policy design from day one. They helped translate regulatory requirements into technical controls.

Question for Sam

How do you handle the situation where security wants one thing and compliance wants something different?

Example: Security wants aggressive password rotation (change every 30 days). NIST guidelines say frequent rotation reduces security. Compliance frameworks often require rotation. Who wins?

5

Sam, bringing an ML perspective to this - do standard compliance tools handle ML workflows adequately?

ML Pipelines Have Different Compliance Needs

Your unified DevSecOps + Compliance pipeline makes sense for traditional applications. But ML introduces unique requirements:

Training Data Provenance: Need to track:

  • Source of training data
  • Consent status for personal data
  • Data quality metrics
  • When data was collected vs when model was trained

Model Governance: ISO 42001 (AI Management Systems) is the new standard for AI governance. It requires:

  • Model cards documenting performance and bias
  • Risk assessments for AI systems
  • Testing for fairness and robustness
  • Human oversight mechanisms

Bias Testing: For EU AI Act compliance, high-risk AI systems need:

  • Testing across demographic groups
  • Fairness metrics documentation
  • Adversarial robustness testing
  • Explainability depending on use case

Model Lineage: Need to answer “Which training data went into which model version, and what consent did users have at that time?”

Do Standard Tools Cover This?

Tools like Drata, Vanta, Secureframe are great for traditional SOC 2 controls. But do they handle:

  • Training data lineage?
  • Model versioning and rollback?
  • Bias testing evidence?
  • ML-specific risk assessments?

Or do we need separate ML governance tools (like Fiddler, Arthur, ValidMind)?

The Risk: More Tool Sprawl

Luis mentioned having three different compliance dashboards. I worry we’re about to add “ML compliance dashboard” as a fourth, creating the very silos Sam is trying to eliminate.

ML-Specific Control Checks

Here’s what I think needs to be in a unified pipeline for ML:

Pre-Training Checks:

  • Validate consent for all personal data in training set
  • Check data quality metrics meet thresholds
  • Verify training data doesn’t contain PII that shouldn’t be there

Post-Training Checks:

  • Run fairness metrics (demographic parity, equalized odds, etc.)
  • Test model for adversarial robustness
  • Generate model card documentation
  • Validate explainability requirements met

Deployment Checks:

  • Ensure model versioning and rollback capability
  • Verify monitoring and drift detection in place
  • Confirm human oversight mechanisms for high-risk systems

These are compliance controls, just for ML instead of infrastructure.

Question for Sam: Are your fintech clients doing ML? How are they integrating ML governance into their compliance pipelines?