Why Cybersecurity Rules Must Change with the System

A cybersecurity rule may be correct today and wrong next year. A supplier might replace a part. A maintenance tool might move online. A new connection might be added.

The written requirement has not changed, but the system around it has.

Clear rules are easier to check

“Provide secure diagnostics” is not clear enough. Diagnostics are tools used to find faults in a system. The sentence does not say who may use them or what should happen when access is refused.

A better requirement could say:

“The controller shall reject a request to change data unless the user has signed in and has permission.”

The team can now design a test for that behaviour.

Follow the reason behind each rule

Every cybersecurity requirement should link to the risk that created it. It should also link to the part of the system that handles it and the test that checks it.

For example, if a drone gets a new radio connection, engineers should be able to find:

• which threats might change;
• which requirements depend on the radio;
• which supplier is responsible;
• which tests must run again.

This connected information is called traceability. It helps teams understand the effect of a change instead of searching through many separate documents.

Test failure as well as success

A software update should work when the file is genuine. It should also reject a fake, damaged or old file. Testing only the happy path can hide serious problems.

The same idea applies to passwords, permissions and network messages. Engineers should test what happens when something goes wrong.

Engineer-approved AI can help find affected requirements and tests, but people still judge the risk and approve the result.