How to Write Cybersecurity Rules Engineers Can Test

Imagine telling a team to “make the car secure”. That sounds sensible, but it does not explain what the system must actually do.

A useful cybersecurity requirement needs to be clear enough to build and test. This matters for cars, trains, factories, drones and many other complex systems.

Start with the risk

First, ask what could go wrong. Could someone install fake software? Could an unknown user control a maintenance tool? Could a message be changed while it travels across a network?

Standards such as IEC 62443 and ISO/SAE 21434 help teams study these risks. A standard is a set of agreed engineering rules. IEC 62443 focuses on industrial systems, while ISO/SAE 21434 focuses on road vehicles.

Be specific

“The system shall support secure updates” is too vague. A clearer requirement could say:

“The update manager shall reject software when its digital signature is not valid.”

A digital signature is a mathematical check that helps prove software came from a trusted source and was not changed.

A good requirement should answer four questions:

• What starts the action?
• What should the system do?
• When should it do it?
• How will the team test it?

Keep the links

Requirements should connect back to the original risk and forward to the test result. These links are called traceability.

If a supplier, interface or piece of software changes, traceability helps the team find what needs checking again. It does not prove the system is secure, but it helps engineers ask the right questions.

Engineer-approved AI can suggest clearer wording and missing links, while engineers make the final decisions.