Security software: considerations before you build

General information, not legal or financial advice. Written October 10, 2026 and scoped to five public pages: two from the National Institute of Standards and Technology, one from the Cybersecurity and Infrastructure Security Agency, one from the European Commission and one from the American Institute of CPAs. Where a page is guidance and not a rule, the article says so. Bring the facts of your product to a lawyer licensed where your customers operate.

A security product asks its customers for something unusual: trust in the thing that is supposed to protect them. A bug in an ordinary product costs a customer some convenience. A bug in a security product can turn the product into the way in. For that reason buyers ask more of a security vendor than of most, and they often ask in the vocabulary of public frameworks. This article lists the considerations a founder can settle before building, each tied to a public page. It says nothing about whether any product is secure, and it makes no claim about WE or any client.

Start with what the product can and cannot promise

The first sentence to write is “my product does this specific thing, for this kind of customer, and these things stay outside it”. Security markets reward large promises and punish them later. A sentence such as “stops attacks” or “keeps data safe” is a claim about the world that the company has to be able to defend, and counsel will want to read every such sentence before it is published. Describing what the software does, what it logs, what it blocks by rule and what it leaves to the customer is a different kind of sentence, and a safer one to build a business on.

Then write down what the product itself holds. A security product often has privileged access to customers’ systems, credentials or logs, which makes the vendor’s own security part of the product. The build versus buy for auth, billing and email article covers when a small team should not build a sensitive component itself.

The frameworks buyers use to talk to you

Two NIST pages give a founder the vocabulary customers use. The Cybersecurity Framework page describes the framework as helping organizations to better understand and improve their management of cybersecurity risk, and presents it as a resource for industry, government, and organizations to reduce cybersecurity risks. The page showed no date for itself when read; the most recent dated item on it was from February 2026.

The Secure Software Development Framework is the one aimed at people who write software. NIST’s page says it is a set of fundamental, sound, and secure software development practices, defined in “NIST Special Publication (SP) 800-218”, which offers “Recommendations for Mitigating the Risk of Software Vulnerabilities”. It adds that software producers and acquirers can use it to foster their communications. The page showed “Updated October 06, 2026” when read.

Neither page describes a certification a company can hold. The pages do not say that any customer requires them, and this article does not either. What they offer a small team is a common way to describe what the company does, which makes the answers in a customer’s questionnaire easier to write down once and reuse. Answering a security and privacy questionnaire describes that process, and the security baseline checklist lists a general baseline for a small team.

Building security in from the start

The Cybersecurity and Infrastructure Security Agency’s Secure by Design page is an argument rather than a rule. It says it’s time to build cybersecurity into the design and manufacture of technology products, and that every technology provider must take ownership at the executive level to ensure their products are secure by design.

The page is addressed to technology makers, and it says what it expects of them, not what the law requires. For a founder, the practical reading is that a product’s early decisions about identity, logging and defaults are the ones customers will judge it on, and they are cheaper to make before the first customer than after the tenth. The year-one security baseline note covers a general version of that list. The page shows no date, so confirm its current wording before quoting it to anyone.

What an assurance report is, and is not

Buyers often ask for an independent report. The AICPA’s SOC page describes SOC as a suite of offerings that CPAs may provide in connection with system-level controls of a service organization. Its SOC 2 guide is titled “SOC 2 Reporting on an Examination of Controls at a Service Organization” and covers controls relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy.

The page describes the offering, and it does not say that any customer requires a report, how long one takes, or what it costs. A company that does not hold a report should not say or imply that it does. A founder should ask what a customer will accept in its place while the company is young, and should plan the controls that an examiner would test well before asking for one. This article does not claim that WE or any company it describes holds any report.

A European rule for products with digital elements

For customers in the European Union, the Commission’s page on the Cyber Resilience Act says the CRA aims to safeguard consumers and businesses buying software or hardware products with digital elements, and that the CRA introduces mandatory cybersecurity requirements for manufacturers. It also says the Act requires manufacturers to handle vulnerabilities during the lifecycle of their products. The dates it gives are these: the Act entered into force on 10 December 2024, reporting obligations apply as of 11 September 2026, and the main obligations introduced by the Act will apply from 11 December 2027. The page showed 7 September 2026 as its last update when read.

The text read does not settle whether a given hosted service is a product with digital elements, what a manufacturer must produce or how the reporting obligations work in practice. Those are questions for counsel, and the answers may differ for a downloadable agent and a hosted dashboard. A founder with European customers should ask early what the Act would ask of the product and who at the company would own the vulnerability process. The reporting date has already passed as this is written.

Questions to put to counsel before you build

None of these is advice. They follow from the pages above.

• Which statements about the product’s protective effect belong in marketing, and which need evidence first?
• What access to customer systems or data would the product hold, and what do the contract and the architecture say about it?
• Which frameworks will likely customers use to evaluate the company, and which can the company describe truthfully today?
• If a customer asks for an independent report, what will the company say now, and when could it say more?
• Is any product, or any part of it, a product with digital elements for a customer in the European Union?
• Who handles a vulnerability report, how quickly, and where is the process written down?
• Which answer changes if the product gets deeper access, a new customer type or a new region?

Keep the answers in writing. Vertical SaaS: depth over breadth covers the choice of whom to serve first, which matters here because each customer type brings its own questions. The glossary defines terms used in these pages.

What this article cannot tell you

This article does not tell you whether your product is secure, whether a rule applies to it, or what any customer will require. It covers five pages read on October 10, 2026: two from NIST, one from CISA, one from the European Commission and one from the AICPA. It does not cover the control catalogs and standards behind these pages, the other SOC reports, ISO standards, sector rules such as those for payments or health data, export controls on security tools, vulnerability disclosure law, breach-notification law, penalties, insurance, or any country outside the United States and the European Union. It does not say that a company following a framework is secure. These pages change, so confirm anything you rely on against the current official text with a lawyer licensed where your customers operate.

In the data

These figures describe U.S. businesses in general, not WE’s results. Each one names its source.

Show the data as a table

Share of establishments that closed in 2023, by firm age: Information

Firm age	Establishment exit rate, 2023, Information
Age 1	29.8%
Age 2	21.4%
Age 3	18.7%
Age 4	17.2%
Age 5	15.5%
Age 6 to 10	13.3%
Age 11 to 15	11.9%
Age 16 to 20	10.1%
Age 21 to 25	10.4%
Age 26 and older	9.8%

For comparison, across all sectors the rate was 25.7% at age 1 and 7.1% at 26 and older. Smaller sectors have fewer firms per class, so their rates move more from class to class.

Source: U.S. Census Bureau, Business Dynamics Statistics, sector by firm age , 2023

Retrieved 2026-10-16. Rates are the published establishment exit rates (exits in 2023 over the average count of establishments in 2022 and 2023), rounded to one decimal.

Sources

1. Secure Software Development Framework (SSDF), National Institute of Standards and Technology, Computer Security Resource Center . Accessed October 10, 2026.
2. Cybersecurity Framework, National Institute of Standards and Technology . Accessed October 10, 2026.
3. Secure by Design, Cybersecurity and Infrastructure Security Agency . Accessed October 10, 2026.
4. Cyber Resilience Act, European Commission, Shaping Europe's digital future . Accessed October 10, 2026.
5. SOC Suite of Services, American Institute of CPAs (AICPA and CIMA) . Accessed October 10, 2026.

Spotted an error? Read how we handle corrections in our editorial policy.