Security Strategy
When the shortlist comes before the requirements, the products tend to write them. We build security priorities and supplier requirements with your CISO and leadership team, before anyone draws up a shortlist.
Book a conversationHow a Security Strategy Works, and When You Need One
NIST's Cybersecurity Framework 2.0 describes security outcomes, not tools, and is meant for organizations of any size or sector. Governance sits at its center: risk appetite, priorities, and the legal and contractual requirements you have to meet. The method compares the outcomes you achieve today with a target you have chosen, and turns the gaps into a prioritized plan. Supplier security requirements belong in the same plan. The framework expects them set, and due diligence done, before a supplier relationship starts.
When it makes sense
- A large purchase is coming, such as a cloud migration, a network refresh or a new SaaS platform, and nobody has written down what the suppliers must meet.
- Supplier security reviews run differently for every purchase, or not at all for SaaS that looks low risk.
- Your board wants the security program in plain terms. Public companies must describe in their annual reports how they assess and manage material cybersecurity risk, and how the board oversees it.
- Security sits at the top of the cloud agenda, next to cost.
cost (85%) and security (82%) continue to be the leading challenges for organizations
Flexera 2026 State of the Cloud - Security purchases follow the last incident, and nobody owns the overall design. In our judgment, that is the clearest sign a strategy is overdue.
When it does not
In our judgment, a new strategy engagement is the wrong place to start when:
- You already have a current, board-approved strategy, an owner for it and a standard set of supplier requirements. The work then is applying them to each purchase, which is sourcing.
- You are in the middle of an incident or breach. That is work for your incident response team or provider first.
If your strategy already holds up, the work moves straight to sourcing.
Where Security Strategy Goes Wrong
Most of these mistakes happen before a contract exists, which is why the order of the work matters.
Tools bought before priorities
In our judgment, buying tools before the plan exists leaves you with a stack that reflects past sales calls more than your risks.
Overlapping tools
Analysts have reported widespread consolidation of security suppliers, driven by poor integration across mixed stacks and the effort it takes to run them. A strategy decides what the stack should look like before the next renewal adds to it.
Requirements written after the shortlist
The framework puts requirements and due diligence before the supplier relationship, and CISA's Secure by Demand guide builds security into each stage of procurement. In our judgment, requirements written after the shortlist end up shaped by what the shortlisted products already do.
A certificate that doesn't cover what you buy
An ISO/IEC 27001 certificate covers only the scope named on it. A supplier can hold a valid certificate that leaves out the product, region or data center you will use. Check the scope, and confirm the certificate with the body that issued it.
Evidence that has aged
CSA STAR attestation listings run for one year and STAR certificates for three, and ISO certificates stay valid only through surveillance audits. Ask for evidence that is current at signature.
A questionnaire as the whole review
A questionnaire is the supplier's own answer. CSA itself ranks self-assessment below a third-party audit. Size the review to the supplier's risk, rather than sending the same long questionnaire to everyone.
An SBOM taken at face value
A software bill of materials lists the components inside a product. On its own, it doesn't say whether a known vulnerability affects that product; CISA treats that as a separate statement, called VEX. CISA's 2026 minimum elements add detail but no test for missing components, so an SBOM is only as complete as its producer makes it.
Security Spend That Answers to Risk
For IT and security leaders: requirements before products
- Supplier requirements set before the shortlist, and sized to how critical each supplier is.
- Certificate scope written into the requirements, so you know whether the evidence covers the service you are buying.
- Security supplier pitches fielded by TREU, so your CISO's team reviews the evidence rather than the sales deck.
For finance: fewer tools bought twice
- Purchases tied to a prioritized plan, not to the last incident.
- Overlapping tools caught before the next renewal adds to the stack.
What to Watch For in Supplier Security Requirements
These are the areas a requirements set should cover, so your contract team has something to write against. The clauses themselves are negotiated with your legal team.
-
Requirements that stop at the RFP.
Carry each requirement from the RFP into the signed agreement.
-
Requirements sized to the supplier.
Rank suppliers by how critical they are, and set heavier requirements for those that hold sensitive data or run critical systems.
-
Who is responsible for what.
Split security responsibilities between you and the supplier in writing, so neither side assumes the other has a control covered.
-
Evidence, and how often.
Name the evidence the supplier will provide and how often: an audit report, a certificate and its scope, a penetration test summary, and an SBOM for software you will run.
-
A part in your incident plans.
Include critical suppliers in your incident planning and recovery. If you are a public company, your own disclosure deadline, generally four business days after you determine an incident is material, should shape the notice you require.
-
If you are regulated as a bank.
Banking regulators' third-party guidance lists security, breach notice, audit rights and subcontractor controls among the contract terms they expect.
-
The end of the relationship.
Decide before you sign how your data is returned or destroyed, and how the supplier's access is removed, when the agreement ends.
This list is a starting point for your review. TREU is not a law firm. Your counsel gives the legal advice.
How Your Security Strategy Shapes Each Purchase
See how we work-
Supplier identification
We set the requirements each new purchase has to meet, then find the suppliers that can meet them, before anyone builds a shortlist.
-
Buying cycle
We write the evidence requests into the RFP, your security team reviews what comes back, and we carry the requirements into the terms your legal team negotiates.
-
Implementation oversight and accountability
We hold the supplier to the commitments and dates in the signed agreement through go-live. Your security team, or a provider we source, runs the controls.
-
Client and supplier lifecycle management
As the business changes, we revisit your priorities and requirements with you, and bring them to each supplier business review and renewal while your agreements run.
Questions Buyers Ask About Security Strategy
What is the NIST Cybersecurity Framework?
NIST's guidance on cybersecurity outcomes, for organizations of any size, sector or maturity. It describes what to achieve, not how, and points to separate resources for practices and controls. Its Govern function sets the strategy, expectations and policy that shape the rest.
What is the difference between NIST CSF and the CIS Controls?
The framework describes outcomes and leaves the how to you. The CIS Controls are a specific, prioritized set of safeguards, and CIS publishes a mapping between the two. In our judgment, they work well together: the framework for the strategy, the CIS Controls for a control baseline.
We're compliant with HIPAA or PCI DSS. Isn't that a security strategy?
In our judgment, no. Each regime sets what must be done for one scope, such as health data or card data. A strategy sets priorities across the whole business and maps those obligations into it.
What security requirements should we set before we talk to suppliers?
Start with how critical the supplier will be. Then decide who is responsible for what, the evidence the supplier must provide, its part in your incident planning and what happens to your data when the agreement ends. For software, CISA's Secure by Demand guide gives buyers questions to ask before purchase.
Is a SOC 2 report enough?
For a service you will rely on, ask for a Type 2 report. It tests whether controls worked over a period, not only how they were designed. Read it for the system it describes, the period it covers, any exceptions and any providers it leaves out.
The supplier is ISO 27001 certified. Does that cover the service we're buying?
Not necessarily. A certificate covers only the scope named on it. Check that the scope includes the service, region and data center you will use, and confirm the certificate with the body that issued it.
Do we still need a security questionnaire?
Yes, but size it to the risk. Standard questionnaires come in shorter versions for lower-risk suppliers and deeper ones for suppliers with sensitive data. A questionnaire is the supplier's own answer, so for critical suppliers, ask for independent evidence as well.
Does TREU run our security operations or monitor our suppliers?
No. TREU is not a security operations provider. We set priorities and requirements with you and carry them into sourcing and the agreements that follow. Your team runs security operations, or a managed security or MDR provider we can source for you.