Compliance comes up in nearly every enterprise security deal. The customer mentions SOC 2 during discovery. The RFP has a section on NIST controls. The CISO asks how your product helps with ISO 27001 certification. The IT director needs to know about PCI DSS 4.0 changes.
If you fumble these conversations, you look like a product specialist who does not understand the business context. If you handle them confidently, you position yourself as someone who understands not just the technology but the regulatory landscape that drives purchasing decisions.
This post is a cheat sheet. Print it, bookmark it, keep it in your bag. It covers the four compliance frameworks you will encounter most often in cybersecurity pre-sales: NIST CSF, ISO 27001, SOC 2, and PCI DSS.
Framework Comparison: The Quick-Reference Table
| Attribute | NIST CSF | ISO 27001 | SOC 2 | PCI DSS 4.0 |
|---|---|---|---|---|
| Full Name | NIST Cybersecurity Framework | ISO/IEC 27001:2022 | Service Organization Control 2 | Payment Card Industry Data Security Standard |
| Published By | NIST (US Gov) | ISO/IEC (International) | AICPA (US) | PCI Security Standards Council |
| Scope | All critical infrastructure sectors | Any organization, any size | Service organizations handling customer data | Any entity that stores, processes, or transmits cardholder data |
| Mandatory? | Voluntary (mandatory for US federal agencies) | Voluntary (often contractually required) | Voluntary (often contractually required) | Mandatory for payment card handling |
| Certification/Audit | No formal certification; self-assessment | Third-party certification audit | Third-party audit by CPA firm | Self-Assessment Questionnaire (SAQ) or Qualified Security Assessor (QSA) audit |
| Audit Frequency | N/A (continuous improvement) | Annual surveillance audits; recertification every 3 years | Annual (Type II covers 6-12 month period) | Annual assessment; quarterly network scans |
| Time to Achieve | 3-6 months for initial assessment | 6-18 months for certification | 3-12 months depending on Type I vs Type II | 3-12 months depending on SAQ level or Report on Compliance |
| Cost Range | Low (internal effort) | $20K-$100K+ (certification + remediation) | $20K-$80K (audit) + remediation costs | Varies widely: $5K (SAQ) to $200K+ (QSA audit for Level 1 merchants) |
| Best For | Risk management baseline, federal alignment, internal maturity | International credibility, enterprise sales, comprehensive ISMS | SaaS companies, cloud services, B2B trust | Retailers, payment processors, e-commerce, hospitality |
Which Framework Does Your Customer Need? Decision Tree
Use this decision tree when a customer is unsure which framework to pursue, or when you need to quickly assess their compliance landscape during discovery.
Question 1: Does your customer process, store, or transmit credit card data?
- Yes -> They need PCI DSS. This is not optional. Start here. They may also need other frameworks, but PCI is mandatory.
- No -> Continue to Question 2.
Question 2: Does your customer sell to enterprise B2B customers who request security attestation?
- Yes -> They likely need SOC 2. Enterprise buyers, especially in technology and financial services, commonly require SOC 2 Type II reports from their vendors before signing contracts.
- No -> Continue to Question 3.
Question 3: Does your customer operate internationally or need a globally recognized certification?
- Yes -> ISO 27001 is the strongest choice. It is recognized globally and carries weight in European, Asian, and Middle Eastern markets where SOC 2 is less familiar.
- No -> Continue to Question 4.
Question 4: Does your customer need to align with US government requirements or establish a risk management baseline?
- Yes -> NIST CSF is the starting point. For federal contractors, NIST 800-53 controls may be required. For private sector, NIST CSF provides a solid voluntary framework.
- No specific driver -> Recommend NIST CSF as a starting point for any organization building a security program. It is the most flexible and serves as a foundation that maps well to other frameworks.
Important: Many customers need more than one framework. A SaaS company that processes payments might need SOC 2 + PCI DSS. A multinational healthcare company might need ISO 27001 + NIST CSF + HIPAA (which is not covered here but follows similar principles).
NIST Cybersecurity Framework: The 5 Functions
The NIST CSF organizes security activities into five core functions. This is the simplest framework to explain in a customer meeting because the five functions tell a logical story.
| Function | Purpose | Key Categories | SE Talking Point |
|---|---|---|---|
| Identify | Know what you have and what risks you face | Asset management, risk assessment, governance | “You can’t protect what you don’t know you have. Identify is about building the inventory and understanding the risk landscape.” |
| Protect | Implement safeguards for critical services | Access control, training, data security, maintenance | “Protect is your preventive controls — access management, encryption, security awareness. This is where most security budgets start.” |
| Detect | Identify cybersecurity events in a timely manner | Anomaly detection, continuous monitoring, detection processes | “Detection is where your SOC lives. The question is: how fast do you detect, and how accurate are your detections?” |
| Respond | Take action when a cybersecurity event is detected | Response planning, communications, analysis, mitigation | “Having a detection without a response plan is like having a fire alarm without a fire department. Respond is the playbook.” |
| Recover | Restore services after a cybersecurity event | Recovery planning, improvements, communications | “Recover is your resilience story. How fast can you return to normal operations after an incident? This is where DR and BCP connect to security.” |
Pro tip: The five functions form a natural narrative arc for a presentation: “First you identify your assets and risks, then you protect them, then you detect threats that get through your protections, then you respond to incidents, then you recover. Your security program should have capabilities across all five.”
ISO 27001: What SEs Need to Know
ISO 27001 is an Information Security Management System (ISMS) standard. The key word is “system” — it is not just about technology controls. It requires documented policies, risk assessments, management commitment, and continuous improvement.
Structure
- Clauses 4-10: Management system requirements (context, leadership, planning, support, operation, performance evaluation, improvement).
- Annex A: 93 controls organized into 4 themes (in the 2022 revision): Organizational, People, Physical, and Technological.
What Customers Get Wrong About ISO 27001
They think it’s a technology checklist. It is not. ISO 27001 requires risk-based control selection, not implementation of every Annex A control. You implement controls based on your risk assessment.
They underestimate the documentation. ISO 27001 requires documented policies, procedures, risk assessments, statements of applicability, and evidence of management review. This is where many organizations stall.
They think certification is one-time. Certification is valid for 3 years with annual surveillance audits. The ISMS must be continuously maintained.
SE Positioning
If your product generates audit evidence — logs, reports, compliance dashboards — position it as reducing the documentation burden and providing continuous evidence of control effectiveness. “Instead of manually gathering evidence for your annual surveillance audit, our platform provides real-time compliance dashboards that your auditor can review directly.”
SOC 2: The Framework Enterprise Buyers Care About Most
SOC 2 is based on the AICPA’s Trust Services Criteria (TSC). It evaluates how an organization handles customer data across five categories.
The 5 Trust Service Criteria
| Criteria | What It Covers | Required? |
|---|---|---|
| Security | Protection against unauthorized access (logical and physical) | Yes — always included |
| Availability | System uptime and operational accessibility | Optional |
| Processing Integrity | Accurate, complete, and timely data processing | Optional |
| Confidentiality | Protection of data designated as confidential | Optional |
| Privacy | Collection, use, retention, and disposal of personal information | Optional |
Security is always included. The other four are optional and selected based on the service organization’s commitments to its customers. Most SOC 2 reports include Security + Availability + Confidentiality.
Type I vs. Type II
- Type I: Controls are suitably designed as of a specific date (point-in-time snapshot).
- Type II: Controls are operating effectively over a period (typically 6-12 months).
Always ask: “Are your customers asking for Type I or Type II?” Type II is the gold standard. If a customer is early in their SOC 2 journey, Type I is a stepping stone — they get a report faster and can pursue Type II in the next cycle.
SE Positioning
Position your product as reducing the cost and pain of SOC 2 evidence collection. The most painful part of SOC 2 is gathering evidence for the auditor: access review logs, change management records, vulnerability scan results, incident response documentation. If your product automates any of this evidence collection, that is a direct ROI story.
PCI DSS 4.0: What Changed and What SEs Need to Know
PCI DSS 4.0 became the mandatory standard on March 31, 2025, replacing version 3.2.1. If your customer processes payment cards, they are now subject to 4.0 requirements.
Key Changes in 4.0
| Change | What It Means | SE Implication |
|---|---|---|
| Customized approach | Organizations can meet requirements with alternative controls if they demonstrate equivalent security | Positions flexibility-focused security products well — “Our platform supports both the defined and customized approach” |
| MFA for all CDE access | MFA is now required for all access to the cardholder data environment, not just remote access | If you sell identity/MFA solutions, this is a direct driver |
| Anti-phishing mechanisms | New requirement for technical controls to detect and protect against phishing | Email security and security awareness products have a direct compliance use case |
| Automated log review | Organizations must use automated mechanisms to review audit logs | SIEM and log management products can reference this specific requirement |
| Targeted risk analysis | Organizations must perform targeted risk analyses for each PCI requirement | GRC and risk assessment platforms have a new positioning angle |
| Enhanced password requirements | Minimum 12 characters (up from 7), complexity requirements updated | Identity and access management vendors can tie to this requirement |
PCI DSS Compliance Levels
| Level | Criteria | Assessment Type |
|---|---|---|
| Level 1 | >6 million transactions/year | On-site QSA audit + quarterly ASV scans |
| Level 2 | 1-6 million transactions/year | SAQ + quarterly ASV scans |
| Level 3 | 20,000-1 million e-commerce transactions/year | SAQ + quarterly ASV scans |
| Level 4 | <20,000 e-commerce or <1 million total transactions/year | SAQ + quarterly ASV scans (recommended) |
Real Pre-Sales Scenarios
Scenario 1: “We need SOC 2 — what does that mean for the proposal?”
A mid-market SaaS company is pursuing SOC 2 Type II for the first time. Their enterprise customers are requiring it as a condition of contract renewal.
What to do: Ask what Trust Service Criteria they plan to include (almost certainly Security + Availability + Confidentiality). Ask if they have selected an audit firm. Ask what their current control environment looks like. Then position your product’s capabilities against the specific controls the auditor will evaluate.
What to include in the proposal: Map your product’s features to specific SOC 2 controls. For example: “Our continuous monitoring capability supports the CC7.1 control (Detection and Monitoring Activities) by providing real-time alerting on unauthorized access attempts, with automated evidence collection for your annual audit.”
Scenario 2: “We’re a federal contractor — we need NIST”
A defense contractor needs to align with NIST 800-53 controls (note: this is the full control catalog, not just the CSF framework). They may also need CMMC (Cybersecurity Maturity Model Certification) if they handle Controlled Unclassified Information (CUI).
What to do: Clarify the specific NIST publication they need (CSF vs. 800-53 vs. 800-171). Ask about their CMMC level requirement. Federal compliance is prescriptive — specific controls must be implemented, not just “aligned to.”
What to include in the proposal: Reference specific NIST 800-53 control families your product addresses (AC for Access Control, AU for Audit and Accountability, SI for System and Information Integrity, etc.). Include the control ID numbers.
Scenario 3: “Our European customers are asking about ISO 27001”
A US-based technology company expanding into European markets is finding that prospects ask for ISO 27001 certification as a baseline for vendor trust.
What to do: Explain that ISO 27001 certification is a 6-18 month journey involving gap assessment, ISMS implementation, internal audit, and certification audit. Position your product as accelerating the technology controls portion while recommending a consulting firm for the management system components (policies, risk assessment, documentation).
What to include in the proposal: Map your product’s capabilities to specific Annex A controls. Highlight how your product provides evidence of control effectiveness that reduces audit preparation time.
The Cross-Framework Control Mapping
Many controls appear across multiple frameworks. This overlap is your friend — it means your product can be positioned as satisfying multiple compliance requirements simultaneously.
| Control Area | NIST CSF | ISO 27001 Annex A | SOC 2 TSC | PCI DSS 4.0 |
|---|---|---|---|---|
| Access Control | PR.AC | A.8.3, A.8.5 | CC6.1, CC6.2, CC6.3 | Req 7, 8 |
| Logging & Monitoring | DE.CM | A.8.15, A.8.16 | CC7.1, CC7.2 | Req 10 |
| Incident Response | RS.RP | A.5.24, A.5.25, A.5.26 | CC7.3, CC7.4 | Req 12.10 |
| Encryption | PR.DS | A.8.24 | CC6.1, CC6.7 | Req 3, 4 |
| Vulnerability Management | ID.RA, PR.IP | A.8.8 | CC7.1 | Req 6, 11 |
| Change Management | PR.IP | A.8.32 | CC8.1 | Req 6.5 |
How to use this table: When a customer says “We need SOC 2 and PCI DSS,” show them the overlap. “Many of the controls you implement for SOC 2 will also satisfy PCI requirements. Our platform covers access control, logging, and vulnerability management — that’s a shared foundation across both frameworks.”
Key Takeaways for SEs
Know the difference between mandatory and voluntary. PCI DSS is mandatory for payment card handling. Everything else is voluntary (though often contractually required).
Ask the right clarifying question. “Which framework?” is too vague. Ask: “Is this for an external audit, a customer requirement, or internal risk management?” The answer shapes how you position your product.
Map your product to specific controls. “We help with compliance” is meaningless. “We address SOC 2 CC7.1 continuous monitoring, NIST CSF DE.CM-1 network monitoring, and PCI DSS 10.4.1 automated log review” is specific and credible.
Compliance is a buying driver, not a feature. Customers do not buy security products because they love compliance. They buy because non-compliance creates business risk — lost contracts, failed audits, fines. Frame your product’s compliance value in terms of business impact.
Know when to bring in a specialist. If a customer needs help with the management system aspects of ISO 27001 or the scoping exercise for PCI DSS, recommend a GRC consultant. Your role as SE is to position the technology controls. Knowing your lane builds trust.
Related Posts in This Series
- How to Build a Business Case for NAC — Use compliance requirements as the financial justification for NAC projects
- How to Whiteboard a Zero Trust Architecture in 10 Minutes — Connect compliance controls to the Zero Trust architecture customers need
- Incident Response Plan Template — Build the IR plan that SOC 2 and ISO 27001 auditors look for
- Hybrid Cloud Security Architecture — Address cloud-specific compliance requirements across multi-cloud environments
- How to Run a Technical Discovery Call for Security Deals — Ask the right compliance-related questions during discovery
Practice with free flashcards, quizzes, and hands-on lab scenarios at cciesec.it-learn.io — built specifically for the CCIE Security v6.1 written (350-701 SCOR) and lab exam.
