Regulations, Standards and Guidelines for Software

1. Why This Topic Matters

Software does not exist in a legal or organisational vacuum. Every application that stores a credit card number, processes a medical record, supports a financial statement, or runs inside a government network is subject to external rules that dictate how it must be built, tested, operated and retired. The CSSLP exam places this topic inside Domain 2 (Secure Software Lifecycle Management) because a security professional cannot manage a software lifecycle without knowing which external obligations shape it. Regulations define what you must do, standards define how the industry agrees it should be done, and guidelines offer recommended practice when there is room for judgement.

From an exam perspective this topic matters for three reasons:
• It is heavily tested in scenario questions that ask you to identify which regulation or standard applies to a given type of data, industry or jurisdiction.
• It underpins other domains: security requirements (Domain 3) are frequently derived from regulations; testing and acceptance (Domains 6 and 7) often verify compliance; supply chain security (Domain 8) is now driven by standards such as the NIST Secure Software Development Framework.
• It tests your understanding of governance: knowing the difference between mandatory, contractual and voluntary obligations, and understanding that compliance is a floor, not a ceiling, for security.

In practice, failing to recognise an applicable regulation leads to fines, loss of certification, breach of contract, reputational damage and even criminal liability for executives. Recognising it early, during requirements and design, is dramatically cheaper than retrofitting controls after an audit finding.

2. What It Is: Core Definitions

The exam expects precise use of terminology. Learn these distinctions:

Regulation (Law) - A rule created by a government or regulatory body that carries the force of law. Compliance is mandatory for organisations within its scope. Non-compliance results in legal penalties such as fines, sanctions, loss of licence or imprisonment. Examples: GDPR, HIPAA, SOX, GLBA, FISMA, CCPA/CPRA, the EU Cyber Resilience Act, NIS2, DORA.

Standard - A formal, documented specification developed by a recognised body (ISO, IEC, NIST, IEEE, PCI SSC) that establishes uniform requirements or criteria. Standards are typically voluntary unless they are adopted by law, incorporated into a contract, or required for certification. PCI DSS is the classic example of a contractually mandated industry standard: it is not a law, but card brands enforce it through merchant agreements.

Guideline - Recommended practice that provides direction but allows discretion in implementation. Guidelines are advisory. Examples: OWASP cheat sheets, NIST Special Publications when not mandated, SAFECode practices, vendor secure coding guides.

Framework - A structured collection of practices, processes and controls that organisations adapt to their own context, often used to organise compliance with multiple regulations and standards. Examples: NIST Cybersecurity Framework (CSF), NIST Risk Management Framework (RMF), COBIT, OWASP SAMM, BSIMM, Microsoft SDL.

Policy, Standard (internal), Procedure, Baseline - Inside an organisation, external regulations are translated into internal policy (high-level management intent), internal standards (specific mandatory technologies or configurations), procedures (step-by-step instructions) and baselines (minimum security configurations). The exam may describe this hierarchy and ask where a particular external requirement is implemented.

Key Relationship: Regulations frequently reference standards as the means of demonstrating compliance (for example, HIPAA Security Rule guidance pointing to NIST SP 800-66; FISMA requiring NIST SP 800-53 controls). Standards in turn are supported by guidelines that explain practical implementation. Think of a pyramid: laws at the top (fewest, most binding), standards in the middle, guidelines and best practices at the base (most numerous, most flexible).

3. Major Regulations You Must Know

Privacy and Data Protection
• GDPR (EU General Data Protection Regulation) - Protects personal data of EU residents regardless of where the processor is located. Key software implications: privacy by design and by default (Article 25), data minimisation, purpose limitation, right to erasure, data portability, breach notification within 72 hours, Data Protection Impact Assessments (DPIA), lawful basis for processing, fines up to 4 percent of global annual turnover or 20 million euros. Roles: data controller and data processor.
• CCPA / CPRA (California) - Consumer rights to know, delete and opt out of sale of personal information; applies based on revenue and data volume thresholds.
• PIPEDA (Canada), LGPD (Brazil), PDPA (Singapore), APPI (Japan) - National privacy laws with similar principles.
• COPPA (US) - Children under 13; requires verifiable parental consent before collecting personal information online.
• FERPA (US) - Student education records.

Healthcare
• HIPAA (US Health Insurance Portability and Accountability Act) - Protects Protected Health Information (PHI). The Privacy Rule governs use and disclosure; the Security Rule requires administrative, physical and technical safeguards for electronic PHI (access control, audit controls, integrity, transmission security, encryption as addressable). The HITECH Act strengthened enforcement, extended obligations to business associates and added breach notification.

Financial
• SOX (Sarbanes-Oxley Act) - Applies to US publicly traded companies. Section 302 (executive certification of financial reports) and Section 404 (internal controls over financial reporting). Software implications: change management, segregation of duties, audit trails, access controls over systems that feed financial statements. IT controls are typically mapped using COBIT or COSO.
• GLBA (Gramm-Leach-Bliley Act) - US financial institutions; Safeguards Rule requires a written information security program; Privacy Rule requires notice and opt-out for sharing non-public personal information.
• PCI DSS - Not a law but a contractual industry standard from the PCI Security Standards Council for any entity that stores, processes or transmits cardholder data. Requirement 6 is the most software-relevant: develop and maintain secure systems and software, address common coding vulnerabilities, protect public-facing web applications. The PCI Secure Software Standard and Secure Software Lifecycle (Secure SLC) Standard (together the PCI Software Security Framework) replaced PA-DSS for payment software vendors.
• DORA (EU Digital Operational Resilience Act) - ICT risk management and third-party risk for the EU financial sector.
• Basel III - Operational risk for banks, indirectly driving software risk controls.

Government and Critical Infrastructure
• FISMA (US Federal Information Security Modernization Act) - Requires federal agencies and contractors to implement NIST-based risk management: FIPS 199 (categorisation), FIPS 200 (minimum requirements), SP 800-53 (controls), SP 800-37 (RMF).
• FedRAMP - Standardised authorisation for cloud services used by US federal agencies.
• Executive Order 14028 (Improving the Nation's Cybersecurity, 2021) - Drove the NIST Secure Software Development Framework (SP 800-218), Software Bill of Materials (SBOM) requirements, and vendor self-attestation of secure development practices for software sold to the US government.
• NIS2 Directive (EU) - Cybersecurity obligations for essential and important entities, including supply chain security.
• EU Cyber Resilience Act - Mandatory cybersecurity requirements for products with digital elements sold in the EU, including secure-by-design obligations, vulnerability handling and security updates throughout the product lifecycle.
• ITAR / EAR (US export controls) - Restrict export of defence-related technology and, historically, strong cryptography; relevant when distributing software internationally.

Computer Crime and Intellectual Property
• Computer Fraud and Abuse Act (US) - Unauthorised access; relevant to penetration testing authorisation.
• DMCA - Anti-circumvention provisions; relevance to reverse engineering and software licensing.
• Software licensing (GPL, MIT, Apache, proprietary EULAs) - Legal obligations when using open source components; a compliance concern in supply chain management.

4. Major Standards and Frameworks You Must Know

ISO/IEC Standards
• ISO/IEC 27001 - Requirements for an Information Security Management System (ISMS); certifiable. ISO/IEC 27002 - Code of practice with control guidance (the 2022 edition includes controls for secure development lifecycle, application security requirements, secure coding and security testing).
• ISO/IEC 27034 - Application security; introduces the Organisation Normative Framework (ONF), Application Normative Framework (ANF) and Application Security Controls (ASC). This is the ISO standard most directly about secure software and is frequently tested.
• ISO/IEC 15408 (Common Criteria) - Framework for evaluating security properties of IT products using Protection Profiles, Security Targets and Evaluation Assurance Levels (EAL1 to EAL7). Mutual recognition through the CCRA.
• ISO/IEC 12207 - Software lifecycle processes. ISO/IEC 15288 - System lifecycle processes.
• ISO/IEC 21827 - Systems Security Engineering Capability Maturity Model (SSE-CMM).
• ISO/IEC 29147 (vulnerability disclosure) and ISO/IEC 30111 (vulnerability handling processes).
• ISO/IEC 27701 - Privacy Information Management System extension to 27001.
• ISO 31000 - Risk management principles. ISO/IEC 27005 - Information security risk management.
• ISO 9001 - Quality management; often the foundation into which security processes are integrated.
• IEC 62443 - Security for industrial automation and control systems, including 62443-4-1 (secure product development lifecycle requirements).

NIST Publications
• SP 800-218 Secure Software Development Framework (SSDF) - Four practice groups: Prepare the Organization (PO), Protect the Software (PS), Produce Well-Secured Software (PW), Respond to Vulnerabilities (RV). Now central to US federal procurement.
• SP 800-53 - Security and privacy controls catalogue, organised in families (AC, AU, CM, SA, SI, etc.). The SA (System and Services Acquisition) family covers developer security testing, secure development processes and supply chain.
• SP 800-37 - Risk Management Framework: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor.
• SP 800-30 - Risk assessment. SP 800-39 - Enterprise risk management.
• SP 800-160 - Systems security engineering (Volume 1) and cyber resiliency (Volume 2).
• SP 800-161 - Cybersecurity supply chain risk management.
• SP 800-64 - Security considerations in the SDLC (withdrawn but historically important; superseded in spirit by SSDF).
• SP 800-115 - Technical security testing. SP 800-61 - Incident handling.
• FIPS 140-3 - Cryptographic module validation (levels 1 to 4). FIPS 199 / 200 - Categorisation and minimum requirements. FIPS 197 - AES.
• NIST Cybersecurity Framework (CSF 2.0) - Govern, Identify, Protect, Detect, Respond, Recover.
• NIST Privacy Framework - Identify-P, Govern-P, Control-P, Communicate-P, Protect-P.

Industry and Community Standards and Guidelines
• OWASP Top 10 - Awareness document of the most critical web application risks (guideline, not a standard, though often cited contractually).
• OWASP ASVS (Application Security Verification Standard) - Verifiable security requirements at three levels; used for requirements and testing.
• OWASP SAMM (Software Assurance Maturity Model) - Prescriptive maturity model for secure development programmes.
• BSIMM (Building Security In Maturity Model) - Descriptive model that measures what real organisations actually do; useful for benchmarking.
• CWE (Common Weakness Enumeration) and CWE Top 25 - Catalogue of software weakness types. CVE - Specific vulnerability identifiers. CVSS - Severity scoring. CAPEC - Attack patterns.
• CERT Secure Coding Standards - Language-specific rules (C, C++, Java, Android).
• MISRA C / C++ - Coding standards for safety-critical embedded systems.
• Microsoft SDL - Vendor-originated lifecycle model widely adopted as a reference.
• SAFECode - Industry forum publishing fundamental practices for secure software development.
• CIS Controls and CIS Benchmarks - Prioritised safeguards and hardened configuration baselines.
• COBIT - IT governance framework commonly used to satisfy SOX.
• CMMI - Process maturity; CMMI for Development with security extensions.
• SOC 2 (AICPA Trust Services Criteria) - Attestation report on service organisations' controls for security, availability, processing integrity, confidentiality and privacy; frequently requested of SaaS providers.
• Cloud Security Alliance CCM - Cloud Controls Matrix mapping to many regulations.

5. How It Works: Applying Regulations, Standards and Guidelines Across the Lifecycle

Step 1 - Identify Applicability. Determine the organisation's industry, the jurisdictions where it operates and where its users reside, the data types processed (PII, PHI, cardholder data, financial records, classified data, children's data), and contractual commitments to customers. This is typically done with legal counsel, compliance officers and privacy officers. Applicability is driven by data, geography and sector, not by technology choice.

Step 2 - Perform a Gap Analysis. Compare current practices against required controls to identify deficiencies. The output drives the remediation roadmap and risk register.

Step 3 - Harmonise Through Control Mapping (Crosswalk). Most organisations face multiple overlapping obligations. Rather than building a separate programme for each, they adopt a unified control framework (often ISO 27001, NIST CSF or SP 800-53) and map each regulation's requirements to it. This reduces duplication and audit fatigue. Tools such as the Secure Controls Framework or CSA CCM provide pre-built mappings.

Step 4 - Translate into Security Requirements. Regulatory and standards requirements become explicit, testable functional and non-functional security requirements. For example, GDPR right to erasure becomes a requirement for data deletion capability across all data stores including backups; PCI DSS Requirement 3 becomes a requirement for cardholder data to be rendered unreadable (encryption, tokenisation, truncation); HIPAA audit controls become logging requirements for every access to ePHI. Requirements traceability matrices link each requirement back to its regulatory source so auditors can follow the chain.

Step 5 - Design and Build to the Standard. Architects apply secure design principles and select approved components (for example, FIPS 140-3 validated cryptographic modules where federal requirements apply). Developers follow adopted coding standards (CERT, MISRA, internal standards derived from OWASP). Privacy by design requires that privacy-protective defaults are engineered in rather than configured later.

Step 6 - Verify and Validate. Testing demonstrates conformance. Static and dynamic analysis maps findings to CWE identifiers; ASVS provides the verification checklist; penetration testing satisfies PCI DSS Requirement 11; Common Criteria evaluation or FIPS validation provides third-party assurance. Evidence is retained for auditors.

Step 7 - Operate, Monitor and Maintain Compliance. Compliance is continuous, not a point-in-time event. Vulnerability management, patch timelines (for example, PCI DSS requires critical patches within one month), breach notification procedures (GDPR 72 hours, HIPAA 60 days), audit logging retention and periodic reassessment all continue through operations. Regulatory changes must be tracked and fed back into requirements.

Step 8 - Govern and Attest. Management establishes policy, assigns ownership (data protection officer, compliance officer, product security lead), performs internal audits, and produces attestations such as SOC 2 reports, PCI Reports on Compliance, ISO certificates or SSDF self-attestation forms. Third-party and supply chain components are brought into scope through contracts, SBOMs and vendor assessments.

Important Conceptual Points
• Compliance is not security. Meeting a regulation is a minimum baseline. A compliant application can still be insecure, and a highly secure application may fail an audit on documentation. The exam often tests this: the best answer usually treats compliance as a risk-driven floor and advocates going beyond it where risk warrants.
• Risk-based approach. Most modern frameworks (ISO 27001, NIST RMF, GDPR) are risk-based: they require you to assess risk and apply proportionate controls rather than follow a rigid checklist.
• Due care versus due diligence. Due care is doing what a reasonable person would do (implementing controls); due diligence is the ongoing effort to verify they work (monitoring, auditing). Regulations frequently judge organisations against these standards after a breach.
• Jurisdiction and extraterritoriality. Laws like GDPR apply based on the data subject's location, not the company's. Cloud deployments must consider data residency and cross-border transfer mechanisms.
• Mandatory versus voluntary versus contractual. Law is mandatory; standards are voluntary unless incorporated into law or contract; PCI DSS is contractual; guidelines are advisory. When a question hinges on enforcement, this distinction is the key.
• Safe harbour and addressable controls. Some regulations provide relief if specified measures are in place (for example, encrypted data exempt from breach notification under many state laws). HIPAA distinguishes required from addressable implementation specifications; addressable does not mean optional, it means assess and document a reasonable alternative if not implemented.

6. How to Answer Exam Questions on This Topic

CSSLP questions on regulations and standards fall into predictable patterns. Learn to recognise each pattern and apply a consistent approach.

Pattern A - Identify the Applicable Regulation or Standard. The scenario describes an industry, data type or location and asks which rule applies. Approach: isolate the trigger words. Cardholder data, merchant, acquirer, card brand -> PCI DSS. Patient, medical, health plan, ePHI, business associate -> HIPAA/HITECH. Publicly traded, financial reporting, internal controls, executives certify -> SOX. EU residents, personal data, data subject, controller/processor, 72 hours -> GDPR. Federal agency, authorisation to operate, categorisation -> FISMA/RMF/SP 800-53. Children under 13 -> COPPA. Banks sharing customer information, Safeguards Rule -> GLBA. Cryptographic module validation -> FIPS 140-3. Product evaluation, EAL, Protection Profile -> Common Criteria (ISO/IEC 15408). Application security controls, ONF/ANF -> ISO/IEC 27034.

Pattern B - Classify the Type of Instrument. You are asked whether something is a law, standard, guideline or framework, or which is legally enforceable. Approach: remember that only regulations carry legal force; PCI DSS is contractual; ISO and NIST are standards (mandatory only when adopted by law or contract, as NIST is for US federal agencies); OWASP Top 10 is a guideline/awareness document; SAMM and BSIMM are maturity models (SAMM prescriptive, BSIMM descriptive).

Pattern C - Determine the Best Governance Action. The scenario describes a conflict, uncertainty or new requirement and asks what the security professional should do first or best. Approach: the ISC2 mindset favours consulting legal counsel and compliance for interpretation of law, performing a risk assessment or gap analysis before acting, obtaining management approval for policy, documenting decisions, and integrating requirements early in the lifecycle. Avoid answers that ignore the law, accept risk unilaterally, or bolt controls on at the end.

Pattern D - Compliance versus Security Trade-offs. Approach: choose the answer recognising compliance as a baseline and risk management as the driver. If a control is required by law, it is not optional regardless of cost; if a control exceeds the law but reduces significant risk, it is still justified.

Pattern E - Lifecycle Placement. Where in the SDLC should regulatory requirements be addressed? Approach: as early as possible - during planning and requirements gathering - with verification during testing and continuous monitoring during operations. Any answer suggesting compliance is handled only at release or audit time is almost always wrong.

Pattern F - Numeric and Factual Recall. Breach notification windows (GDPR 72 hours to supervisory authority; HIPAA no later than 60 days), GDPR fine tiers (2 or 4 percent), Common Criteria EAL range (1 to 7), FIPS 140-3 levels (1 to 4), SSDF practice groups (PO, PS, PW, RV), RMF steps (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor), ASVS levels (1 to 3), SOX sections (302, 404), COPPA age threshold (under 13). Memorise these.

7. Exam Tips: Answering Questions on Regulations, Standards and Guidelines for Software

Tip 1 - Read for the trigger, not the noise. Scenario questions are padded with irrelevant detail. Find the data type, the industry and the geography; they determine applicability. Everything else is distraction.

Tip 2 - Mandatory, contractual or voluntary? If the question asks about enforcement, penalties or legal exposure, immediately sort the options into regulation (law), contractual standard (PCI DSS, SOC 2 commitments to customers) and voluntary standard or guideline (ISO, NIST for non-federal, OWASP). Only the first two carry external enforcement.

Tip 3 - Know what each standard is FOR. Many wrong answers are real standards applied to the wrong purpose. ISO/IEC 27001 is about the management system, not product evaluation; Common Criteria evaluates products, not organisations; FIPS 140-3 validates cryptographic modules, not whole applications; ISO/IEC 27034 is about application security processes and controls; ISO/IEC 12207 is lifecycle processes generally; SP 800-53 is a control catalogue; SP 800-218 is secure development practices; SAMM measures programme maturity.

Tip 4 - Prescriptive versus descriptive. SAMM tells you what you should do (prescriptive). BSIMM tells you what others actually do (descriptive, observational). This distinction appears regularly.

Tip 5 - Compliance is the floor. When an option says compliance guarantees security or that passing an audit means the software is secure, reject it. The best answer treats regulatory requirements as minimum baseline inputs to a risk-based programme.

Tip 6 - Early is always better. For questions about when to address regulatory requirements, the answer is during requirements and design, with traceability through testing and operations. Shift left.

Tip 7 - Involve the right people. Security professionals do not interpret law alone. Answers involving legal counsel, privacy officers, compliance officers and executive sponsorship for interpreting regulations and setting policy reflect the expected professional behaviour.

Tip 8 - Think like a manager, not a technician. The CSSLP is a professional certification. When choices range from a technical fix to a governance action, questions about regulations usually favour governance: assess, document, map, obtain approval, then implement.

Tip 9 - Watch for scope traps. GDPR applies to EU residents' data processed anywhere; HIPAA applies to covered entities and business associates, not every company that touches health information; SOX applies to publicly traded companies; PCI DSS applies to any entity handling cardholder data regardless of size, with validation requirements scaled by merchant level; FISMA applies to federal systems and contractors operating them.

Tip 10 - Addressable does not mean optional. Under HIPAA, an addressable specification must be assessed; if not implemented, a documented rationale and equivalent alternative are required.

Tip 11 - Supply chain is now regulatory. Expect questions linking EO 14028, SSDF (SP 800-218), SBOMs, vendor attestation and the EU Cyber Resilience Act to third-party component management. The modern answer to how do we assure third-party software is a combination of SBOM, attestation to a recognised framework and contractual security requirements.

Tip 12 - Privacy principles are testable. Know data minimisation, purpose limitation, consent, transparency, individual rights (access, rectification, erasure, portability), privacy by design and by default, and the roles of controller and processor. Questions may describe a design decision and ask which principle it violates.

Tip 13 - Eliminate before you select. Discard options that are factually wrong about what a standard covers, that place compliance late in the lifecycle, that equate compliance with security, or that have the security professional act outside their authority. What remains is usually the answer.

Tip 14 - When two answers seem right, pick the broader governance one. For example, between implement encryption and perform a gap analysis against the applicable standard, the gap analysis typically comes first because it determines what controls are actually needed.

8. Worked Example Questions

Example 1. A software company based in the United States sells an analytics product to retailers in Germany and France. The product collects shopper browsing behaviour linked to loyalty accounts. Which regulation most directly governs the handling of this data?
Analysis: Trigger words - EU residents, personal data linked to identifiable accounts. The company's US location is a distraction; GDPR is extraterritorial. Answer: GDPR. Related implications: privacy by design, DPIA, lawful basis, data subject rights.

Example 2. A development team wants a third-party evaluation that demonstrates the security functionality of its network appliance to multiple international government customers. Which standard is most appropriate?
Analysis: Product evaluation, security functionality, international recognition. Answer: Common Criteria (ISO/IEC 15408), with mutual recognition through the CCRA. ISO 27001 would be wrong because it certifies the management system, not the product.

Example 3. Which of the following is a contractually enforced standard rather than a law?
Analysis: Sort options into law versus contractual versus voluntary. Answer: PCI DSS. HIPAA, SOX and GDPR are laws.

Example 4. An organisation is subject to HIPAA, PCI DSS and SOX. What is the most efficient approach to managing software security compliance?
Analysis: Multiple overlapping obligations. Answer: Adopt a unified control framework and map each regulation's requirements to it (control crosswalk), implementing each control once and reusing the evidence for all three.

Example 5. A project manager proposes addressing regulatory requirements during user acceptance testing to avoid slowing development. What should the security professional recommend?
Analysis: Lifecycle placement trap. Answer: Integrate regulatory requirements during requirements definition and design, with traceability to test cases; retrofitting at acceptance is far more costly and risks non-compliance.

Example 6. An organisation claims that because it passed its annual PCI DSS assessment, its payment application is secure. Which statement best evaluates this claim?
Analysis: Compliance versus security. Answer: Compliance demonstrates that minimum required controls were in place at the time of assessment; it does not guarantee the absence of vulnerabilities, and a continuous risk-based secure development programme is still needed.

Example 7. Which NIST publication defines practice groups named Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities?
Answer: NIST SP 800-218, the Secure Software Development Framework (SSDF).

Example 8. A team wants to benchmark its secure development programme against what peer organisations actually do in practice rather than against a prescribed ideal. Which model fits?
Analysis: Descriptive versus prescriptive. Answer: BSIMM. SAMM would be the choice for a prescriptive roadmap.

9. Quick Reference Summary

• Regulation = law, mandatory, legal penalties (GDPR, HIPAA, SOX, GLBA, FISMA, CCPA, COPPA, NIS2, CRA, DORA).
• Standard = formal specification, voluntary unless adopted by law or contract (ISO/IEC 27001/27002/27034/15408/12207, NIST SP 800-53/800-218/800-37, FIPS 140-3, PCI DSS as contractual).
• Guideline = advisory recommended practice (OWASP Top 10, cheat sheets, SAFECode, vendor guides).
• Framework = adaptable structure to organise controls (NIST CSF, RMF, COBIT, SAMM, BSIMM, Microsoft SDL).
• Flow: identify applicability -> gap analysis -> control mapping -> security requirements -> secure design and coding -> verification -> continuous monitoring -> governance and attestation.
• Core exam mindset: compliance is the floor, risk drives the ceiling, shift requirements left, consult legal for interpretation, map once and comply many, and know precisely what each standard is for.

Master these distinctions and patterns and you will be able to handle virtually any question the CSSLP exam presents on regulations, standards and guidelines for software.