Secure by Design: How Businesses Should Evaluate Software Before Buying

A defense contractor in the middle of a CMMC readiness assessment recently discovered that a project management tool three departments had been using for two years stored file attachments in an unencrypted S3 bucket with a predictable naming convention. Nobody had asked the vendor about it during procurement. The tool solved a real problem, the sales rep was responsive, and the price fit the budget. Security architecture never came up because nobody on the buying side knew which questions to ask.

That gap between what software companies claim about their security and what their architecture actually supports is the entire reason “secure by design” exists as a concept. It is not a compliance checkbox. It is a description of how a product was built — whether security decisions were made at the architecture stage, before a single line of customer-facing code shipped, or bolted on afterward once a breach or an audit forced the issue.

Why “Secure by Design” Isn’t a Marketing Slogan Anymore

Every vendor now claims to take security seriously. Almost none of them can explain what that means at the architecture level, and fewer still can point to a development lifecycle that treats security as a design constraint rather than a feature request. The distinction matters because software built without security in mind from the start tends to carry structural weaknesses that patches never fully resolve — default credentials that persist across versions, authentication logic that was never designed for multi-tenant isolation, or data models that make least-privilege access nearly impossible to enforce cleanly.

CISA formalized this distinction through its Secure by Design initiative, which asks software manufacturers to commit publicly to specific, measurable security practices rather than vague assurances. The CISA Secure by Design and Secure by Default guidance lays out the difference between products that eliminate entire classes of vulnerability through design choices and products that rely on the customer to configure security correctly after purchase. For a buyer, that distinction is the difference between inheriting a manageable risk and inheriting someone else’s technical debt.

Businesses that treat vendor security evaluation as a real part of procurement, not an afterthought handled by whoever reads the contract, end up with fewer surprises eighteen months later. Our cybersecurity team gets pulled into these conversations most often after something has already gone wrong — a vendor breach, a failed audit finding tied to a third-party tool, or a client discovering mid-contract that a “cloud-native” application was never designed with tenant isolation in mind. Evaluating before the purchase order is signed is dramatically cheaper than remediating after.

The Procurement Blind Spot: Buying Software Without Asking the Right Questions

Most software purchase decisions at small and mid-sized businesses run through whoever owns the budget line, not whoever owns the risk. A finance director evaluating an expense management platform is thinking about integration with the general ledger and monthly cost, not session token handling or how the vendor manages secrets in their CI/CD pipeline. That’s a reasonable division of labor in most industries. It stops being reasonable the moment the software will touch Controlled Unclassified Information, connect to a network in CMMC scope, or sit inside the boundary of a system that has to pass a C3PAO assessment.

The pattern we see across finance, legal, and engineering clients alike is procurement happening in a vacuum — IT finds out about a new SaaS subscription after it’s already been expensed, sometimes after data has already started flowing into it. By then, the leverage a buyer has to demand security documentation, request an architecture review, or negotiate contract language around breach notification has largely evaporated. Vendors are far more willing to answer hard questions before the deal closes than after.

This is where a vCIO relationship earns its keep. Someone needs to own the standing question of whether a new tool fits inside the organization’s risk tolerance and compliance boundary before it gets purchased, not after it’s already processing sensitive data. That’s a strategic function, not a helpdesk ticket, and it’s exactly the gap a fractional or virtual CIO is built to close.

What CISA’s Secure by Design Pledge Actually Asks Vendors to Do

The CISA pledge asks participating software manufacturers to make measurable progress in specific areas: reducing the prevalence of default passwords, increasing multi-factor authentication adoption for customers, cutting entire vulnerability classes like SQL injection and path traversal through safer programming languages and frameworks, publishing a vulnerability disclosure policy, and shipping evidence of intrusions in default logging configurations rather than as a paid add-on. None of this is exotic. It reflects what security engineers have been recommending for two decades. What’s changed is that a federal agency is now asking vendors to commit to it publicly and measure their progress.

For a buyer, the pledge itself is a useful screening tool. A vendor that has signed on and can point to a published transparency report demonstrates a baseline level of security maturity that most competitors haven’t bothered to establish. A vendor that has never heard of the initiative isn’t automatically disqualified, but it does mean the burden of verification shifts entirely onto the buyer’s due diligence process.

That verification process should mirror how a mature compliance program treats any control: don’t take the vendor’s word for it, ask for evidence. SOC 2 Type II reports, penetration test summaries, and documented incident response plans are the minimum artifacts a serious vendor should produce without hesitation. If a vendor treats a request for a recent penetration test summary as an unusual or invasive ask, that reaction alone is informative.

Reading a Vendor’s Security Architecture Before You Sign Anything

Architecture reviews sound intimidating to non-technical buyers, but the core questions are straightforward once you know what to listen for. Ask how the vendor handles tenant isolation in a multi-tenant SaaS product — whether customer data lives in logically separated databases or shares infrastructure with weak boundary controls. Ask how encryption is implemented both at rest and in transit, and specifically whether the vendor manages its own encryption keys or gives customers the option to hold their own. Ask what the authentication model looks like: does the platform support SSO and enforce MFA, or is it still relying on username-and-password login as the default?

The answers reveal whether security was a design input or an afterthought. A vendor that built multi-tenant isolation into the data model from day one can explain it in specific, confident terms. A vendor that added isolation later, usually after a customer asked or an auditor flagged it, tends to describe it in vaguer language involving row-level filters bolted onto a shared schema.

This is also where cloud transformation work intersects with vendor evaluation directly. Migrating workloads to a new platform means inheriting that platform’s security posture as your own, whether or not the contract says so explicitly. If the vendor’s cloud architecture has weak isolation or poor key management, that weakness becomes part of your attack surface the moment data starts flowing.

The CMMC and NIST 800-171 Angle: Why This Matters More for Defense Contractors

For a business outside the defense industrial base, a vendor security gap is a business risk. For a defense contractor handling CUI, it’s a scoping problem with a contractual and regulatory dimension. Every piece of software that touches, processes, or transmits CUI falls inside the assessment boundary for CMMC, which means the vendor’s security posture becomes part of what a C3PAO is evaluating, whether the vendor knows it or not.

NIST SP 800-171 lays out the 110 controls contractors must implement to protect CUI, and a meaningful share of them depend on how third-party software behaves — access control enforcement, audit log generation, encryption of data at rest, and incident response coordination all assume the tools in the environment actually support those functions. A procurement tool that can’t generate exportable audit logs, or a file-sharing platform that doesn’t support customer-managed encryption keys, doesn’t just create a gap — it can make an entire control family unimplementable no matter how well the rest of the environment is configured.

DFARS 252.204-7012 adds a reporting obligation on top of the technical requirement: contractors must report cyber incidents involving covered defense information within 72 hours of discovery. That clock doesn’t pause because the incident originated at a vendor rather than internally. If a SaaS platform in your CUI boundary gets breached, you inherit the reporting timeline whether or not the vendor’s contract obligates them to notify you promptly. Vendor contracts should specify breach notification timelines that leave enough runway to meet that 72-hour window, and that language needs to be negotiated before signature, not requested after an incident.

Our compliance team walks contractors in Boston, Tampa, and Sarasota through exactly this exercise as part of CMMC readiness work — mapping every third-party tool against the control families it touches and flagging the ones that create scoping problems before an assessor does.

Questions to Ask Every Software Vendor Before Purchase

A structured intake process turns vendor evaluation from a gut-feel judgment into something repeatable. The following questions belong in every RFP or vendor questionnaire, particularly for any tool that will touch sensitive data or sit inside a compliance boundary:

• Does the vendor maintain a current SOC 2 Type II report, and will they share it under NDA before contract signature?
• What does the encryption model look like at rest and in transit, and who holds the keys?
• Is multi-factor authentication supported natively, and is it enforced by default or opt-in?
• How does the platform log security-relevant events, and can those logs be exported to an external SIEM?
• What is the vendor’s documented process and timeline for notifying customers of a security incident?
• Has the vendor undergone a third-party penetration test in the last twelve months, and can they share a summary?
• If the product is multi-tenant, how is customer data logically or physically separated from other tenants?
• What is the vendor’s patch and vulnerability disclosure timeline, and do they publish a CVE history?

None of these questions require a security background to ask. They require someone to actually ask them before the purchase order is signed, and to treat a vague or defensive answer as data rather than noise.

Red Flags That Should Kill a Deal

Certain vendor responses should end a deal regardless of how good the product demo looked. A vendor that cannot produce a SOC 2 report, a recent penetration test summary, or any third-party security attestation after repeated requests is telling you, indirectly, that no one has independently verified their claims. A vendor that treats MFA as an enterprise-tier upsell rather than a default feature is prioritizing revenue over baseline security hygiene. A vendor whose support team can’t explain, even at a high level, how customer data is segregated in a multi-tenant environment likely doesn’t have a clean answer because the architecture doesn’t have one.

Contract language matters just as much as technical answers. A vendor that refuses to specify a breach notification timeline, or that buries data ownership and portability terms in language favoring indefinite vendor retention after contract termination, is signaling how they’ll behave during an actual incident. These aren’t hypothetical concerns for organizations tracking against NIST SP 800-171 — they’re the exact gaps that turn a routine vendor relationship into a scoping and reporting headache during an assessment.

Supply Chain Risk: The Software You Didn’t Build Still Belongs to You

Software supply chain risk gets discussed in the context of open-source dependencies and build pipelines, but the same logic applies directly to every SaaS vendor a business signs a contract with. CISA’s resilience guidance on supply chain and third-party risk makes the point plainly: an organization’s security posture is only as strong as the weakest vendor with access to its systems or data. That principle doesn’t stop at code dependencies — it extends to the CRM platform, the HR system, the document management tool, and every other piece of software with a login screen and access to organizational data.

Nation-state actors and ransomware groups have both demonstrated a preference for compromising widely used software vendors rather than attacking well-defended targets directly, because a single vendor compromise can provide a foothold into hundreds of downstream customers at once. That reality changes the calculus for vendor evaluation. A niche software vendor with a small customer base and immature security practices isn’t a low-risk purchase just because it’s a small company — it may be an easier target precisely because it’s under-resourced on security, and a compromise there still lands inside your environment.

This is one of the reasons a layered managed IT services approach matters even for organizations with strong internal IT teams — someone needs to be watching the aggregate risk surface created by every vendor connection, not just the perimeter around internally managed systems. Manufacturing clients in particular, where operational technology and IT increasingly share network segments, feel this acutely; a single insecure vendor-supplied monitoring tool can create a path from a compromised laptop straight into production equipment. Our manufacturing clients see this scenario more often than most.

Building an Internal Software Evaluation Process

Formalizing vendor evaluation doesn’t require a large security team. It requires a defined process that any employee proposing a new tool has to follow before a contract gets signed. A workable version of that process includes:

• A standing intake form that routes any new software request through IT and compliance before purchase, not after
• A short vendor security questionnaire, built from the questions above, that gets sent to every vendor regardless of deal size
• A defined threshold for when a full architecture review is required — typically any tool touching regulated data or connecting to core network infrastructure
• Contract language templates covering breach notification timelines, data ownership, and portability rights, reviewed by whoever owns compliance
• A periodic re-evaluation cycle for existing vendors, since a platform’s security posture at renewal time may look nothing like it did at initial purchase

Organizations without a dedicated security function often find this process easier to sustain through a co-managed IT arrangement, where an internal IT team retains day-to-day control but leans on an outside partner for the specialized review work — vendor risk assessments, architecture reviews, and compliance mapping — that doesn’t happen often enough to justify a full-time hire. It’s the same logic that applies to AI integration tools now flooding the market: the pace of new vendor onboarding has outstripped most internal teams’ capacity to vet each one properly, which makes a repeatable process more valuable than ever.

Two published resources are worth building into that evaluation workflow directly. Our breakdown of what counts as an External Service Provider under CMMC explains how vendor relationships get scoped into an assessment boundary, which is essential reading before signing anything that will touch CUI. And for any organization still deciding between Microsoft 365 commercial, GCC, and GCC High, our guide on which tenant you actually need for CMMC walks through a decision that gets made incorrectly, and expensively, more often than any other software purchase in this space.

What Good Vendor Security Documentation Actually Looks Like

A vendor that has genuinely built security into its product can usually produce documentation without friction: a current SOC 2 report, a public vulnerability disclosure policy, a status page with historical uptime and incident data, and a security whitepaper that describes the architecture in specific technical terms rather than marketing language. The CyberAB Marketplace is a useful starting point when evaluating vendors and consultants specifically operating in the CMMC ecosystem, since listed organizations have already been vetted against a baseline set of credentials.

Software that has been properly designed for security also tends to age better operationally. Vulnerability patching becomes routine rather than a fire drill, because the architecture was built to accommodate updates without breaking customer integrations. Our clients who’ve gone through SaaS security posture management reviews consistently find that the tools causing the most ongoing friction are the ones that were never designed with enterprise security controls in mind — configuration drift accumulates because the platform wasn’t built to make secure defaults easy to maintain. The same pattern shows up in our guidance on vulnerability management under CMMC: a vendor’s own patch cadence directly determines how much residual exposure your organization carries between releases.

Where Backup and Recovery Fit Into Vendor Risk

Vendor evaluation rarely accounts for what happens when the vendor itself fails — through an outage, a ransomware event, or a business closure. Contracts should specify what happens to customer data on termination, whether the vendor supports scheduled data exports in a usable format, and whether the organization has an independent backup and data recovery strategy for anything stored exclusively in a third-party platform. Relying entirely on a vendor’s own resilience, without an independent copy of critical data, converts a vendor’s bad week into your organization’s bad month.

This consideration applies just as directly to regulated industries outside the defense sector. Healthcare organizations evaluating a new EHR module and non-profit organizations vetting a donor management platform face the same fundamental question: does this vendor’s architecture protect data the way its marketing claims it does, and what’s the fallback plan if it doesn’t.

Conclusion

Evaluating software before you buy it isn’t a compliance exercise reserved for organizations pursuing CMMC certification, though it carries the highest stakes there. It’s a basic extension of the same due diligence any business already applies to hiring a contractor or signing a lease — understanding what you’re actually getting before you’re contractually committed to it. The vendors worth doing business with can answer architecture questions specifically and produce documentation without hesitation. The ones that can’t are asking you to take their security posture on faith, and faith isn’t a control that shows up on an assessment.

Stealth Technology Group works with defense contractors across Boston, Tampa, and Sarasota to build vendor evaluation processes that hold up under assessment scrutiny, long before a purchase order gets signed. You can read more of our team’s field notes on CMMC and cybersecurity on our Insights page, or learn more about how we work with contractors navigating this exact problem.

If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.