CRA reporting applies since 11 September 2026. Are your products ready?Book a CRA scoping call

Home / AITIGRITY

Testing: proof that every requirement holds

The Testing module writes the security test cases for your requirements and performs the tests, so verification is complete and traceable.

1. What this module is

A test strategy and test cases for the security requirements, generated, executed and linked back to each requirement.

2. Why it is useful

  • Auditors and notified bodies expect proof that each requirement was tested.
  • Test results are part of the technical documentation under the CRA and the evidence for ISO/SAE 21434 and IEC 62443-4-1.
  • Generated test cases keep pace with changing requirements across variants and releases.

3. How it works, briefly

  • Test cases are generated from the approved requirements.
  • Tests are executed and results recorded.
  • Each result is linked to its requirement, so gaps in coverage are visible at once.

4. Who uses it

Test and validation engineers, quality teams.

5. Which industries use it

Manufacturers in all six industries.

Connected to

Previous: Secure coding. Next: Assessment. All modules share one product model.

In depth: security testing

Why security testing matters, where it is required, which problems it prevents and what the effort looks like.

Why it matters

A requirement only counts once it is verified. Security testing shows that each requirement works in the real product, from authentication and secure updates to logging and hardening, and it produces the evidence that auditors, notified bodies and customers ask for.

Where it is required

ISO/SAE 21434 requires verification and validation of cybersecurity requirements, IEC 62443-4-1 requires security verification and validation testing, the technical documentation under the Cyber Resilience Act includes test reports, and FDA premarket submissions expect security testing evidence, including penetration tests.

Which problems it prevents

Untested requirements that only show up as findings in an audit. Test gaps that appear when a requirement changes and its tests do not. And missing evidence that delays a type approval, a conformity assessment or a market submission.

Typical effort without tooling

Writing test cases by hand and keeping them aligned with changing requirements takes considerable time for every release and every variant, and coverage gaps are hard to see in spreadsheets.

With AITIGRITY

Test cases are generated from the approved requirements, executed and linked back to them. Coverage gaps are visible immediately, and the test evidence stays current with every release instead of being rebuilt before each audit.

Where does your product stand?

Tell us about your product and the rule you are facing. You talk to an engineer from the first call.