GRC is dead. Long live PRC.

If you are an Application Security (AppSec) or Product Security (ProdSec) Manager, you already know the feeling. You are caught in a perpetual tug-of-war. On one side, engineering teams are pushing code at lightning speed. On the other side, compliance officers are asking for spreadsheets, audit trails, and policy documentation.

To bridge this gap, organizations often try to squeeze product security into traditional GRC (Governance, Risk, and Compliance) frameworks. But let’s be honest: traditional GRC tools were built for corporate IT infrastructure, laptops, and HR policies. They simply don’t speak the language of microservices, CI/CD pipelines, and APIs.

At Codific, we realized the industry is missing a dedicated category. It’s time to draw a line in the sand. We are coining a new term for what security teams actually do at the software level: PRC: Product Risk and Compliance.

What is PRC?

Product Risk and Compliance (PRC) is a specialized framework and tooling category designed exclusively for the software product lifecycle. While GRC looks at the entire enterprise from a top-down corporate perspective, PRC looks at the software product from a bottom-up engineering perspective.

To understand PRC, it helps to break down what it means for a modern product security team:

• Product: The scope is strictly bounded by the application, its architecture, open-source dependencies, APIs, and the development ecosystem.

• Risk: Identifying, prioritizing, and mitigating risks that could lead to a product breach—ranging from design flaws (threat modeling) to code vulnerabilities and software supply chain threats.

• Compliance: Automating and continuous auditing against product-specific regulations and standards (such as the EU Cyber Resilience Act, NIST SSDF, OWASP Top 10, or ISO 21434).

GRC vs. PRC: What’s the Difference?

Why Do We Need PRC Tooling Now?

The software landscape has shifted drastically. Treating product security as a checkbox exercise inside a legacy GRC platform is no longer viable for three major reasons:

1. Increase Regulatory Pr

Governments and regulatory bodies have realized that enterprise security means nothing if the commercial software being shipped is inherently vulnerable. The European Union’s Cyber Resilience Act (CRA) demands that any hardware or software product with digital elements sold in the EU market must have built-in security from design to end-of-life. With strict rules regarding Software Bills of Materials (SBOMs) and mandatory 24-hour reporting timelines for actively exploited vulnerabilities, you cannot manage this level of engineering granularity in a static GRC registry.

2. The AppSec Tooling Explosion

A mature SDLC has a lot of tooling in place.  But the tools need to be configured correctly and follow the well documented best practices. PRC management makes sure that we have good visibility on the right processes being in place, and that the tools provide both the technical outcomes, as the documentation needed.

3. Developer Velocity Cannot Be Blocked

If security processes feel like an administrative burden, developers will bypass them. PRC tooling is built to simply the domain. It translates complex compliance mandates into actionable engineering tasks (like Jira tickets), ensuring that compliance becomes a natural byproduct of secure engineering, not a roadblock.

Operationalizing PRC: The Role of Maturity Models (OWASP SAMM & DSOMM)

Building a PRC program from scratch can feel overwhelming. How do you know what a “good” security posture looks like for your specific product line? This is where AppSec maturity models become the connective tissue of your PRC strategy. Instead of treating security as a static checklist, maturity models provide a structured, practical path to growing your security capabilities over time.

OWASP SAMM (Software Assurance Maturity Model)

OWASP SAMM is the industry-standard, risk-driven framework designed to help organizations assess, formulate, and execute a tailored software security strategy. It breaks down software security into 5 core business functions and 30 security practices. SAMM is highly prescriptive, giving AppSec managers a clear blueprint to evaluate their current standing and plan measurable security improvements aligned with their specific business risks.

OWASP DSOMM (DevSecOps Maturity Model)

While SAMM offers excellent program-level architecture, modern engineering thrives on automation and continuous delivery. OWASP DSOMM takes maturity tracking directly into the trenches of fast-paced DevSecOps pipelines. Organized into dimensions like Build and Deployment, Test and Verification, and Culture, DSOMM evaluates how deeply security activities are truly embedded into automated engineering workflows. For technical teams pushing daily releases, DSOMM provides highly actionable instructions, outlining the precise risks each technical activity mitigates and how to measure its efficacy.

Security by Design: Why Threat Modeling is the Foundation of PRC

You cannot comply with modern product regulations by running automated code scanners alone. Scanners are fantastic at catching implementation errors (like a SQL injection bug in a line of code), but they are completely blind to structural, architectural design flaws.

This is why threat modeling is a non-negotiable pillar of PRC. Threat modeling forces teams to systematically analyze their product architecture, trace data flows across trust boundaries, and catch design vulnerabilities before code is ever written.

From a compliance perspective, threat modeling has shifted from an industry “best practice” to a legal mandate:

• The CRA Requirement: Under the Cyber Resilience Act (Annex I), manufacturers must design and develop products to strictly limit attack surfaces. Threat modeling is recognized as the primary mechanism to operationalize this “security by design” principle.

• The Technical Documentation: The CRA requires manufacturers to compile and maintain an extensive technical documentation (Annex VII). Your threat models, data flow diagrams, and corresponding architectural mitigations serve as foundational audit evidence that must be persisted and updated throughout the product’s active lifecycle.

Streamlining PRC and CRA Compliance with SAMMY

Knowing that you need to implement threat modeling, satisfy the CRA, and track OWASP SAMM/DSOMM maturity is one thing—managing it across dozens of product teams without causing widespread operational friction is another.

To bridge this exact gap, we developed SAMMY, a dedicated AppSec and PRC management platform built to turn best practices into clear, measurable engineering actions.

PRC with SAMMY

SAMMY helps application security managers conquer the complex demands of PRC through three core capabilities:

1. Eliminating Framework Fatigue via Cross-Mappings

One of the biggest drains on a security team’s time is answering the same security question for three different audits. SAMMY natively supports an extensive array of maturity models (SAMM, DSOMM) and regulatory frameworks (CRA, NIS2, DORA). By utilizing ultra-high-quality direct mappings, SAMMY allows you to run an assessment in one framework, like OWASP SAMm, and automatically carry over the results to populate a CRA assessment. You audit once, and comply across many.

2. Structuring CRA Assessments & Risk Postures

SAMMY provides a dedicated, structured workplace specifically tailored for the Cyber Resilience Act framework. The threat modeling tool within SAMMY will store the threats and the required data flow diagrams. The supplier management feature help to keep tabs on supply chain risk. And having all these features link together in one place make producing the required technical documentation easy.

3. Creating an Audit-Ready Source of Truth

Instead of maintaining fragmented text files or outdated spreadsheets, SAMMY centralizes your threat modeling outcomes, design choices, and maturity metrics. When regulators or customers request proof of your secure software development lifecycle (Secure SDLC) or product documentation, SAMMY allows you to export comprehensive, structured reports instantly.

The Core Pillars of a True PRC Platform

If you are looking to scale your Product Risk and Compliance program, your technical tooling ecosystem must support four core pillars:

1. Continuous Visibility: A real-time inventory of all software products, internal components, data flows, and development processes.

2. Structured Maturity Tracking: The ability to benchmark engineering processes against models like OWASP SAMM and DSOMM to drive continuous improvement.

3. Proactive Architectural Assurance: Making threat modeling a living, documented part of the development lifecycle to meet “security by design” regulatory mandates.

4. Automated Cross-Compliance Mappings: Intelligently linking engineering telemetry to regulatory requirements (like the CRA) so compliance becomes a natural, friction-free byproduct of secure engineering.

Join the PRC Movement

For too long, AppSec and ProdSec managers have been forced to play translator between engineering reality and corporate compliance expectations. By establishing PRC as a distinct category, we want to give product security teams the dedicated terminology, frameworks, and tools they need to take ownership of product risk and compliance.

Your software product is not just another asset on an IT checklist—it is the lifeblood of your business. It’s time to stop managing its security like it’s a corporate laptop.

Ready to transform how your organization handles product risk? Explore how SAMMY can structure your AppSec maturity and accelerate your Cyber Resilience Act readiness. Let’s connect and change the way the industry thinks about product security.