Company-Wide Development Requirements

Overview
Company-wide development requirements are the enterprise-level, organization-mandated security requirements that apply to every software project an organization builds, buys, or integrates, regardless of the individual project's business purpose. In the ISC2 CSSLP body of knowledge they sit within Domain 2 (Secure Software Requirements), where the candidate must be able to identify, analyze, and document security requirements that originate from internal sources (policies, standards, risk appetite, architecture principles) as well as external sources (laws, regulations, contracts, industry standards). Company-wide requirements are the mechanism that turns high-level governance into concrete, repeatable, testable expectations for development teams.

Why Company-Wide Development Requirements Are Important
1. Consistency and a security baseline. Without enterprise requirements, each project team invents its own approach to authentication, logging, encryption, and error handling. The result is uneven security, duplicated effort, and weak links that attackers exploit. Company-wide requirements establish a minimum security baseline that every application must meet.
2. Compliance by design. Regulations such as GDPR, HIPAA, PCI DSS, SOX, and sector rules impose obligations on the entire organization, not on one project. Translating them once into company-wide requirements ensures every system inherits them and reduces the risk of fines, breach notification costs, and audit findings.
3. Cost efficiency. The CSSLP repeatedly stresses that defects found in the requirements phase cost a fraction of what they cost in production. Pre-defined enterprise requirements let teams reuse vetted controls, approved libraries, and reference architectures instead of discovering security needs late.
4. Risk management alignment. Company-wide requirements express the organization's risk appetite and tolerance. They make sure every project supports management's accepted risk posture rather than individual developer judgment.
5. Supplier and acquisition governance. Enterprise requirements flow down to outsourced developers, contractors, open-source components, and cloud providers through contracts and SLAs, which is a specific CSSLP task (ensuring requirements flow down to suppliers).
6. Measurability and accountability. When requirements are standardized, they can be traced, tested, audited, and reported through metrics, giving management evidence of due diligence and due care.

What Company-Wide Development Requirements Are
They are derived from the organization's governance hierarchy, which the exam expects you to know in order:
Policy (mandatory, high-level statement of management intent, e.g., All sensitive data must be protected in transit and at rest) → Standards (mandatory, specific technologies or parameters, e.g., TLS 1.2 or higher; AES-256; SHA-256) → Procedures (mandatory step-by-step instructions, e.g., how to request a certificate) → Guidelines (recommended but discretionary practices) → Baselines (minimum configurations). Company-wide development requirements are usually codified in standards and baselines that reference policy.

Typical categories include:
Confidentiality: data classification scheme, approved cryptographic algorithms and key lengths, key management, masking, and handling of PII, PHI, and cardholder data.
Integrity: input validation standards, output encoding, code signing, hashing, change control, and secure configuration management.
Availability: redundancy, backup and recovery, capacity, denial-of-service resilience, and business continuity alignment (RTO and RPO).
Authentication and Authorization: use of enterprise identity services (SSO, federation, MFA), password policy, least privilege, separation of duties, role-based or attribute-based access control.
Auditing and Logging: what events must be logged, log formats, protection of logs, retention periods, time synchronization, and integration with the SIEM.
Session Management and Error Handling: session timeout values, secure cookie attributes, generic error messages, no sensitive data in stack traces.
Secure Coding Standards: mandated adherence to CERT, OWASP ASVS, or language-specific guidelines; banned functions; approved languages, frameworks, and compilers.
Third-Party and Open-Source Components: approved component lists, software composition analysis, license compliance, vulnerability thresholds, software bill of materials (SBOM).
Privacy: data minimization, consent, retention and disposal, privacy by design, cross-border transfer rules.
Development Environment and Process: separation of development, test, and production; access control to source repositories; mandatory threat modeling, code review, SAST/DAST, and security sign-off gates before release.
Deployment and Operations: hardening baselines, secrets management, patching windows, vulnerability management SLAs, and incident response hooks.

How Company-Wide Development Requirements Work
Step 1: Source identification. Requirements are gathered from internal sources (security policy, enterprise architecture, risk assessments, lessons learned from incidents, audit findings) and external sources (laws, regulations, contracts, industry standards such as ISO/IEC 27001, NIST SP 800-53, PCI DSS). Stakeholders include business owners, legal, compliance, privacy, security, operations, and the development organization.
Step 2: Translation into requirements. Policy statements are decomposed into specific, measurable, achievable, relevant, and testable requirements (the SMART criteria). A good requirement states what must be true, not how to implement it, unless a standard explicitly mandates a technology.
Step 3: Classification. Requirements are categorized as functional (what the software does, e.g., the system shall lock an account after five failed logins) or non-functional (quality attributes, e.g., performance, maintainability, security). Most security requirements are non-functional, which is why the exam emphasizes that they are often neglected unless explicitly captured.
Step 4: Publication and communication. Requirements are documented in an enterprise standard, placed in a central repository, built into project templates and checklists, and reinforced through training and awareness.
Step 5: Tailoring and inheritance. Each project inherits the enterprise baseline, then adds project-specific requirements derived from its own risk assessment, data classification, misuse and abuse cases, and threat model. Deviations require a documented, risk-accepted exception approved by the appropriate authority, with compensating controls and an expiration date.
Step 6: Traceability. Every requirement is recorded in the Security Requirements Traceability Matrix (SRTM), linking source (policy, regulation) → requirement → design element → code → test case → result. This proves coverage and supports audits.
Step 7: Verification and enforcement. Requirements are verified through design reviews, code reviews, static and dynamic analysis, penetration testing, and release gates. Non-compliance is tracked as a finding and remediated or formally accepted.
Step 8: Maintenance. Requirements are reviewed on a schedule and when triggers occur: new regulation, major incident, new technology adoption, mergers, or changes in business strategy.

Common Pitfalls
Writing requirements that are vague and untestable (the system shall be secure); copying regulatory text verbatim instead of translating it into engineering language; treating company-wide requirements as optional guidelines; failing to flow them down to vendors; neglecting non-functional requirements; and lacking an exception process, which drives teams to bypass controls silently.

How to Answer Exam Questions on Company-Wide Development Requirements
CSSLP questions are scenario-based and ask for the BEST, MOST, or FIRST action. Approach them in this order: identify the phase (requirements), identify the source of authority in the scenario (policy, regulation, contract), and then select the answer that is earliest, most governance-oriented, and most traceable.

Exam Tips: Answering Questions on Company-Wide Development Requirements
Tip 1: Policy is the top-level driver. When a question asks where enterprise security requirements originate or what should be consulted first, the answer is the organizational security policy (supported by management), not a tool, a developer preference, or a single project plan.
Tip 2: Know the governance hierarchy. Policy (mandatory, broad) → Standard (mandatory, specific) → Procedure (mandatory steps) → Guideline (optional). If a question describes a mandatory requirement for a specific algorithm or configuration, that is a standard; a recommendation is a guideline.
Tip 3: Internal vs. external requirements. Internal = policies, standards, business goals, risk appetite. External = laws, regulations, contracts, industry standards. Questions may test whether you recognize that a contractual or regulatory obligation must be converted into an internal requirement and traced.
Tip 4: Earliest is best. If options include defining or validating requirements before design versus testing or patching later, choose the requirements-phase action. Cost of defect remediation rises dramatically in later phases.
Tip 5: Good requirements are SMART and testable. Reject answer choices that are vague (should be secure, as much as possible). Prefer answers that are measurable and verifiable.
Tip 6: Non-functional does not mean non-essential. Security, privacy, auditability, and availability requirements are typically non-functional and must be explicitly captured; the exam likes to test that these are easily overlooked.
Tip 7: Traceability is the proof. If asked how to demonstrate that requirements were implemented and tested, or how to ensure none were missed, the answer is the Security Requirements Traceability Matrix (SRTM).
Tip 8: Data classification drives protection level. Questions on what company-wide control applies to a piece of data are answered by first classifying the data; protection requirements (encryption, retention, access) follow the classification.
Tip 9: Flow-down to suppliers. When outsourcing or buying software, company-wide requirements must be placed in contracts, SLAs, and acceptance criteria. The organization remains accountable even when work is outsourced.
Tip 10: Exceptions are formal. If a project cannot meet an enterprise requirement, the correct answer involves a documented risk acceptance by an authorized owner with compensating controls, never silent omission or developer-level waiver.
Tip 11: Think like a manager, not a coder. The CSSLP favors answers involving governance, stakeholder involvement, risk-based decisions, and process over purely technical fixes. If two answers are technically valid, choose the one that aligns with management-approved policy and organizational risk tolerance.
Tip 12: Eliminate distractors. Wrong options commonly rely on a single person's judgment, skip documentation, address symptoms late in the lifecycle, or focus on one project when the question asks about the enterprise. Remove those first, then choose among the remaining options the one that is most comprehensive and repeatable.

Quick Review Summary
Company-wide development requirements are enterprise-mandated security requirements derived from policy, standards, regulations, and contracts; they create a consistent baseline, enable compliance, reduce cost, and support risk management. They are translated into SMART, testable functional and non-functional requirements, inherited and tailored by each project, traced through the SRTM, enforced through SDLC gates, flowed down to suppliers, and maintained over time. On the exam, anchor your answers in policy, choose the earliest lifecycle action, insist on measurable and traceable requirements, and prefer governance-based solutions over ad hoc technical ones.