Open most cybersecurity sections and you will find a list of true statements about the product. Data is encrypted in transit. The device authenticates the companion app. Firmware updates are signed.
Every one of those may be accurate. None of them is a requirement.
The distinction is not pedantry, and it is not a documentation preference. It decides whether your security work can be verified, and verification is what a submission is made of.
What separates the two
A requirement has three properties a principle lacks.
It is uniquely identified. It has a number. Something can point at it and something else can point back.
It is independently testable. Somebody who did not write it can read it, build a test, run the test, and get an unambiguous pass or fail without asking the author what was meant.
It is traceable in both directions. Upward to the threat or risk it exists to control. Downward to the test case that demonstrates it.
Run "the device uses TLS" against those three. It has no identifier. It cannot be tested, because there is no version, no cipher policy, no failure behavior, and no statement of what happens when the far end offers something weaker. And it traces to nothing in either direction.
Now the same control as a requirement:
SEC-042. All network communication between the device and the cloud service shall use TLS 1.3. The device shall present and accept only the cipher suites listed in Appendix C. The device shall terminate the connection and log an authentication failure event if the server certificate does not chain to the pinned issuing authority.
That fails a test if it is not true. Which means it can also pass one.
Appendix C is where the real answer lives, and it looks like
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. Not "strong ciphers." A named suite
that somebody can check a handshake against.
Being made to write that down is worth more than the precision itself. In development you pick a cipher because you have to pick something, the library had a default, and encryption reads as a binary property - it is either on or it is off. The nuances never come up, because nothing forces them to. Then somebody works through the attack vectors, or a vulnerability lands against part of the negotiation, and you find out that what you have is weaker than what you assumed you had. Security by design means having that argument while the requirement is being written, when it costs a conversation. The alternative is having it during a penetration test, when it costs a release.
The conversion, control by control
Most teams get stuck because the principle feels complete. Three questions break it open.
What exactly, with numbers? Not "strong encryption" but the algorithm, the key length, the mode. Not "the device authenticates" but what it authenticates, to what, using what credential material, derived how.
What happens when it fails? This is the question that produces the most requirements and it is the one people skip. A control that describes only the happy path is half a control. What does the device do when the certificate does not validate, when the signature check fails, when the credential is rejected five times? Attackers live entirely in that half.
Who verifies it, and how would they know? If the honest answer is "you would have to read the code," it is not testable yet and it will not survive contact with a reviewer or an auditor.
One principle usually becomes three to six requirements. That expansion is correct. It is the granularity at which security work can actually be checked, and it is why the exercise feels like it is generating paperwork when it is generating testability.
The trace matrix is the deliverable
The requirements are only half of it. The other half is the table nobody wants to build.
Threat → requirement → design element → test case → result.
Read left to right it says: we identified this threat, we wrote this requirement to control it, we implemented it here, we tested it this way, and here is the outcome.
Read right to left it answers the question a reviewer actually asks, which is not "did you do security work" but "how do you know it worked."
The design element column is where the security architecture views meet the requirements, which is why those views are expected to trace to requirements rather than stand on their own as illustrations.
Two failure modes show up in that table. A requirement with no test underneath it is an assertion. A test with no requirement above it is activity - somebody tested something, and there is no record of why. The first gets a deficiency. The second gets a question you will not enjoy answering.
Why this is not a medical device problem
Nothing above is device-specific. It is what it means to make a security claim you can defend.
A SOC 2 auditor asks the same question in different words. So does an enterprise security questionnaire, and so does a customer's diligence team, and so does opposing counsel if it ever comes to that. The difference is that a device manufacturer has an agency that will ask formally, in writing, on a schedule. Everyone else gets asked informally, later, and usually at a worse moment.
If you are outside regulated industries and want a standard to hold your own security requirements to, this is the one. It was not designed to make your documentation heavier. It was designed so that the sentence "we authenticate the client" cannot be true in a document and false in the binary.
Where to start
Take one control and convert it. Pick the one you are most confident about. Write it as a numbered requirement with a failure behavior. Then try to write the test. Most people discover on the first attempt that they did not know what the product actually does in the failure case.
Then work from the threat model down, not from the control list up. Controls that exist for no identified reason are how you end up with requirements that trace to nothing.
Build the matrix as you go. Reconstructing traceability at the end of a project is one of the more miserable weeks available in this work, and it produces a worse artifact than capturing it live.
This is engineering guidance, not legal or regulatory advice.
This is the work I do - FDA cybersecurity submissions, penetration test remediation, and security ownership for companies too small for a full-time CISO. bill@bato.com.