One of the most expensive mistakes I’ve watched an organization make wasn’t a missed patch — it was buying a six-figure security tool that solved a problem the business didn’t actually have, while the real risk (an unvetted vendor with direct database access) sat untouched for another year. Security controls implemented without understanding business requirements first are, at best, wasted spend, and at worst, actively in the way of the business they’re supposed to protect. This article covers how I determine what an organization actually needs before recommending a single control.
Why Business Requirements Come Before Security Controls
Security exists to enable the business to operate safely, not to exist for its own sake. A control that isn’t grounded in an actual business requirement — regulatory obligation, customer trust commitment, operational continuity need — tends to either go unused, get bypassed by frustrated employees, or consume budget better spent elsewhere.
The Process of Determining Security Requirements
1. Identify Business Objectives and Critical Assets
I start with questions that have nothing to do with technology: What does this business sell? What would stop operations if it disappeared for a day? What data, if disclosed, would end customer trust or trigger regulatory penalty? This produces an asset inventory ranked by business criticality, not just technical value.
2. Identify Regulatory and Contractual Obligations
Depending on industry and geography, this might include GDPR, HIPAA, PCI DSS, SOX, CCPA, or sector-specific regulation. Contractual obligations matter just as much — enterprise customers frequently require SOC 2 reports or specific security clauses before signing.
| Driver Type | Example | Typical Requirement |
|---|---|---|
| Regulatory | HIPAA | Encryption of PHI at rest and in transit, access logging |
| Regulatory | PCI DSS | Network segmentation of cardholder data environment |
| Contractual | Enterprise customer MSA | SOC 2 Type II report, annual penetration test |
| Industry standard | Financial services | Multi-factor authentication for privileged access |
3. Stakeholder Interviews
I interview across departments, not just IT: legal (contractual/regulatory exposure), finance (fraud risk, financial system controls), HR (insider risk, background check requirements), operations (uptime and continuity needs), and sales/customer success (what customers are actually asking for in security questionnaires).
4. Define Risk Appetite and Tolerance
Business requirements must be filtered through how much risk the organization is actually willing to accept. A fast-moving startup may accept more operational risk than a healthcare provider bound by strict compliance mandates — requirements should reflect that, not a generic “best practice” checklist.
5. Translate Business Requirements into Security Requirements
This is the technical translation step: “We must protect customer payment data” becomes specific, testable requirements — network segmentation, tokenization, encryption standards, access logging, and quarterly vulnerability scanning per PCI DSS.
6. Prioritize and Sequence
Not everything can be implemented at once. I sequence requirements by combining business criticality, regulatory deadline pressure, and cost/effort — producing a roadmap rather than an overwhelming flat list.
Requirements-Gathering Workflow
flowchart TD
A[Identify Business Objectives & Critical Assets] --> B[Map Regulatory & Contractual Obligations]
B --> C[Stakeholder Interviews Across Departments]
C --> D[Define Risk Appetite]
D --> E[Translate Business Needs into Security Requirements]
E --> F[Prioritize by Criticality, Deadline, Cost]
F --> G[Document Requirements & Success Criteria]
G --> H[Design & Implement Controls]
H --> I[Validate Against Original Business Requirement]
Comparing Requirement-Gathering Approaches
| Approach | Strength | Weakness |
|---|---|---|
| Top-down (leadership-driven risk appetite) | Fast alignment with strategic priorities | Can miss operational-level realities |
| Bottom-up (department interviews) | Captures real operational pain points | Can lack strategic prioritization without synthesis |
| Compliance-driven (regulation as baseline) | Clear, auditable requirements | Risk of “checkbox security” without addressing actual threats |
| Threat-driven (based on relevant attacker TTPs) | Directly addresses realistic attack scenarios | Requires mature threat intelligence capability |
I generally blend all four — compliance sets the floor, threat intelligence sharpens priorities, and stakeholder interviews fill in what neither captures.
Real-World Example
A mid-sized SaaS company came to me convinced they needed a full SIEM deployment because a competitor had one. After stakeholder interviews, the actual driving business requirement turned out to be different: three enterprise prospects had stalled deals pending a SOC 2 Type II report. A SIEM was eventually part of the roadmap, but the immediate business requirement was formal access control documentation, vendor risk management processes, and an annual penetration test — the specific evidence a SOC 2 auditor would require. Solving the real requirement unblocked over $400,000 in stalled contract value; the SIEM, deployed later and properly scoped, cost a fraction of what the rushed version would have.
Common Mistakes
- Buying tools before defining what problem they need to solve.
- Treating a compliance framework as the entire security strategy rather than a baseline.
- Skipping stakeholder interviews outside of IT and security teams.
- Failing to revisit requirements as the business changes (new products, new markets, new regulations).
- Defining requirements in purely technical language that leadership can’t connect to business risk or budget justification.
Best Practices
- Document security requirements the same way you’d document product requirements — specific, testable, owned, and time-bound.
- Map every proposed control back to a specific business requirement; if you can’t, question whether it’s needed.
- Revisit requirements at least annually and whenever the business undergoes significant change (M&A, new product lines, new geographies).
- Use recognized frameworks (NIST CSF, ISO 27001) as structure, not as a substitute for organization-specific analysis.
- Keep a traceability matrix linking business requirement → security control → validation evidence.
FAQs
Who should be involved in determining security requirements? Not just IT and security — legal, finance, HR, operations, and customer-facing teams all surface requirements security teams alone would miss.
How do compliance requirements differ from business security requirements? Compliance sets a mandatory regulatory floor; business requirements also include customer trust, operational resilience, and strategic risk tolerance that may exceed compliance minimums.
How often should security requirements be reassessed? At least annually, and immediately after major business changes — new products, acquisitions, new regulatory jurisdictions, or significant incidents.
What happens if security requirements aren’t clearly defined before implementing controls? Controls tend to be misaligned with actual risk, either underprotecting critical assets or over-investing in low-priority areas, and often face user resistance because they weren’t designed around real workflows.
Summary and Recommendations
Effective security starts with understanding the business it protects, not with a product catalog. Combine regulatory obligations, stakeholder input, risk appetite, and threat relevance to define requirements before selecting controls — and revisit those requirements as the business evolves.
References:
- NIST Cybersecurity Framework: https://www.nist.gov/cyberframework
- ISO/IEC 27001: https://www.iso.org/standard/27001
- PCI Security Standards Council: https://www.pcisecuritystandards.org/
- SOC 2 Trust Services Criteria: https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
