Traceability Verify Security
Requirements 360
For requirements engineers, compliance leads and CTOs

Requirements workbooks for teams who have to defend them.

Every obligation in the regulation’s own words, split into rows your team can assign, verify and trace. Open it in Excel and walk into your next review knowing what evidence each row needs and where it goes.

Choose a workbook See a sample row
SourceBRD 3.2.1
RequirementINT-0142
DesignICD §4.6
VerificationTC-0311
EvidenceTR-0311-R2
Covers and maps to EU AI ActCyber Resilience ActNIST AI RMF ISO/IEC 25010INCOSE methodDOORS · Jama · Polarion · ReqIF
The gap

Regulations say what you must do. Nobody hands you the rows to prove you did it.

Teams today pick between a free checklist that won’t survive a review and an enterprise platform or consultant priced for someone else’s budget. These workbooks sit in the gap: the rigor an assessor expects, in an Excel file you own.

Free checklists

Quick to find. Weak in a review.

They paraphrase the law and bundle several duties into one line, and nothing stops a row being ticked “done” with no evidence behind it.

Platforms and consultants

Thorough. Priced for enterprises.

Subscriptions, onboarding and day rates, and your evidence ends up locked inside someone else’s tool.

Requirements 360

The rigor, without the lock-in.

The regulation quoted word for word, one testable question per row, and built-in checks that catch a weak “Verified” before an assessor does. One price, no subscription.

The workbooks

Pick one to see what it does.

Ready · EU AI Act, as amended July 2026

Articles 8 to 15 of the AI Act, turned into 108 rows an assessor can check.

For teams building high-risk AI systems for the EU market. High-risk obligations apply from 2 December 2027 (Annex III systems) and 2 August 2028 (Annex I products). This is the working file between the legal text and your technical documentation.

  • Quoted, never paraphrased. Every row carries the exact wording of the consolidated text, including Regulation (EU) 2026/1744.
  • One duty, one yes/no question. 67 provisions split into 108 rows. No bundled “ensure compliance” lines.
  • Undefined terms carried, not resolved. 72 rows name the words the Act leaves open, so you set the acceptance criteria.
  • Four checks flag a weak “Verified”. No reviewer, no evidence location, an undefined term with no acceptance criterion, or “Not applicable” with no reason.
  • Mapped to two frameworks. The Annex IV technical file, and the NIST AI RMF (72 subcategories) for US-facing programs.
108
checkable rows
67
provisions covered
72
undefined-term flags
4
live evidence checks

6 tabs: README · Requirements · Annex IV map · NIST map · Decomposition method · Vocabulary

$79.99Buy the AI Act workbook
Ready · Cyber Resilience Act

Annex I of the Cyber Resilience Act, split into rows your engineers can close.

For companies selling connected hardware or software into the EU. The Annex I requirements apply from 11 December 2027 (reporting under Article 14 already applies and is not covered here). Each essential requirement becomes a question, an evidence type, an evidence cadence and a slot in the Annex VII technical file.

  • Both parts of Annex I. Product security and vulnerability handling, quoted word for word.
  • Cadence on every row. Know which evidence is one-off and which must be refreshed for the support period.
  • Annex VII map. Shows which technical-file points are still open as rows close.
  • Undefined terms carried, not resolved. 29 rows flag the words the Act leaves open, and four checks catch a weak “Verified” or an unexplained “Not applicable”.
44
checkable rows
22
provisions covered
29
undefined-term flags
4
live evidence checks

5 tabs: README · Requirements · Annex VII map · Decomposition method · Vocabulary

$69.99Buy the CRA workbook
Ready · Any requirement set

A traceability matrix that shows you which rows aren’t ready for an audit.

For anyone starting, auditing or migrating a requirement set. Many RTM templates are empty grids. This one checks itself.

  • Custody seal. A row turns “Sealed” only when requirement text, source, measure, verification method, design, verification and evidence references and owner are all present, plus parent ID or compliance reference where the row needs them.
  • Missing links, named. Open rows say exactly what is absent, so the gap list writes itself.
  • Coverage with a run log. Catches the row that is sealed on paper but whose latest test failed.
  • Ready to import. ISO/IEC 25010 types, field mappings for DOORS, Jama, Polarion and ReqIF, and an export tab ready for import.
200
row matrix, expandable
10
links checked per row, at most
300
row test-run log
4
tools and formats mapped

6 tabs: README · Matrix · Coverage · Field guide · Tool mapping · Export

$59.99Buy the traceability matrix
BUNDLE All three workbooks AI Act, CRA and RTM-01 together, in one purchase. $169.99 Checkout opening soon
Sample data · AIA-01

One obligation, exactly as the Act words it.

AIA-0093Article 14(4)(e) · Human oversight
“For the purpose of implementing paragraphs 1, 2 and 3, the high-risk AI system shall be provided to the deployer in such a way that natural persons to whom human oversight is assigned are enabled, as appropriate and proportionate: [...] (e) to intervene in the operation of the high-risk AI system or interrupt the system through a ‘stop’ button or a similar procedure that allows the system to come to a halt in a safe state.”
Question for your system
As appropriate and proportionate, can persons assigned oversight intervene in the operation of the high-risk AI system or interrupt it through a ‘stop’ button or similar procedure that brings it to a halt in a safe state?
Left undefined by the regulation
safe state · as appropriate and proportionate
Evidence
Test record
Method
Test
Annex IV
IV-2(e)
NIST AI RMF
MANAGE 2.4 · MEASURE 2.6
Check in action Status VerifiedReviewer (blank)Acceptance criterion for “safe state” (blank) 2 checks fail: row not counted as verified
CRA-0031Annex I, Part II, point (3) · part 1 of 2
“Manufacturers of products with digital elements shall: [...] (3) apply effective and regular tests and reviews of the security of the product with digital elements;”
Question for your product
Are effective and regular tests of the security of the product with digital elements applied?

Why it was split: tests and reviews can fail separately and need different evidence, so reviews get their own row (CRA-0032). “Effective” and “regular” are carried unchanged rather than given a definition the regulation does not give.

Left undefined by the regulation
effective · regular
Evidence
Test record
Cadence
Continuous
Method
Inspection
Annex VII
VII-2 · VII-6
Req IDRequirementMethodDesignTestEvidenceCustodyMissing links
INT-0142Transmit posted invoice records to the accounting interface within 15 minutes of posting, for 99.5% of transactions in 24 hours.TestICD §4.6TC-0311TR-0311-R2Sealed—
INT-0151Retry failed outbound transmissions on an exponential schedule, up to four attempts.(blank)ICD §4.9(blank)(blank)Openmeasure, method, verification ref, evidence
SEC-0031No single role shall grant both vendor-master maintenance and payment-release authorization.InspectionRole design v3GRC-0092GRC-0092-EXPORTSealed—
AVL-0005The invoice interface shall be available for 99.9% of scheduled operating hours in each calendar month.AnalysisOps design §6AN-0005AN-0005-SEPSealedCoverage: latest result Fail
What a page-by-page read misses: INT-0151 has a design but no measure and no test. AVL-0005 looks complete, but its latest run failed. The workbook flags both by itself. Rows are invented worked examples that ship with the template.
Compare

What you get that a free checklist doesn’t.

Free checklists paraphrase the obligations. These workbooks quote the regulation, split it into checkable rows, and catch weak evidence before a reviewer does.

FeatureTypical free checklistAI ActCRARTM-01
Regulation quoted word for wordParaphrased✓ 108 rows✓ 44 rowsn/a
One obligation, one yes/no question per rowBundled✓✓n/a
Undefined terms flagged, never defined for you—✓✓n/a
Built-in checks on weak “Verified” and unexplained “Not applicable” rows—✓ 4 checks✓ 4 checks✓ Custody
Technical file map, counts update live—✓ Annex IV✓ Annex VIIn/a
NIST AI RMF mapping per row—✓ 72 subcategoriesn/an/a
Reasoning for every split, row by row—✓✓n/a
Tool mapping and export (DOORS, Jama, Polarion, ReqIF)—n/an/a✓
What’s in the box

Every tab, before you buy.

AI Act Requirements Workbook

  • README
  • Requirements · 108 rows
  • Annex IV map
  • NIST map · 72 subcategories
  • Decomposition method
  • Vocabulary

CRA Requirements Workbook

  • README
  • Requirements · 44 rows
  • Annex VII map
  • Decomposition method
  • Vocabulary

Requirements Traceability Matrix

  • README
  • Matrix · 200 rows, 8 worked examples
  • Coverage · run log + summary
  • Field guide
  • Tool mapping
  • Export
How they’re built

Inform. Enforce. Enable.

Inform

What the rules say, row by row, in the regulation’s own words, mapped to the technical file.

Enforce

Checks that flag a row marked “Verified” with no reviewer, no evidence location or no acceptance criterion, and any “Not applicable” with no reason.

Enable

The columns your team fills in: owner, acceptance criteria, evidence, reviewer and status.

Rule 1
Quote, never paraphraseEvery row carries the regulation’s exact words.
Rule 2
One row, one yes/no answerNo row asks two things at once.
Rule 3
The evidence testParts proven with different evidence or methods become separate rows.
Rule 4
Examples are not obligations“Such as” lists stay together in one row.
Rule 5
The question stays inside the wordingNo duty is added or dropped.
Rule 6
Undefined terms carried, not resolvedYou set the meaning; we flag where it’s needed.
Before you license anything

A tool will index your requirements. It won't decide what a requirement has to carry.

Not whether DOORS or Jama or Polarion is any good — they are, at what they are for. What has to be true before any of them helps you. And underneath it, a timing problem: the license takes a procurement cycle, and the review is in three weeks.

01

Decide what a requirement record carries

Every tool asks this at configuration — item types, required fields, relationship rules, workflow states — on day one, from a team that has not agreed yet. Answering it in a spreadsheet costs a weekend. Answering it wrong inside a licensed tool costs a migration.

02

Clean the set before you import it

Tools import exactly what you hand them. Orphans, compound statements, missing verification methods and unsourced thresholds all import perfectly. What you get is a licensed, indexed, beautifully rendered version of the same mess — now visible to everyone on the project at once.

03

Evaluate vendors against your own schema

Every demo looks good on the vendor's data. The only comparison that means anything is handing each of them your actual field set and trace rules and watching them model it. Without that you are comparing interfaces, and you will pick the prettiest one.

04

Then migrate, as a mapping exercise

A structured, machine-readable matrix is the thing you import. Start structured and the migration is a column-mapping job. Start unstructured and it is archaeology, done by whoever is least able to argue about scope.

When the tool is the right answer

Past a few hundred requirements, with people editing concurrently, formal baselining, or change-impact analysis across thousands of links, a spreadsheet stops being honest and a real tool earns its license. These files are not an alternative to that. They are the weeks before it — and the clean, decided, structured set you hand the tool on the day procurement finally clears.

AI requirements engineering

An agent can read every row. It still can’t tell you your threshold is right.

Agentic AI is genuinely good at one half of requirement quality and no help at all with the other. Knowing which half you are in is most of the skill.

Holds

What an agent is actually good at

  • Reading all of it. A reviewer skims four hundred requirements and concentrates hardest on the first fifty. An agent reads the last fifty at the same depth as the first.
  • Mechanical defects. Two obligations hiding behind one and. An unverifiable adjective. A shall that never names who acts. A measure with no unit. These are pattern failures, and pattern work is what the technology is for.
  • Contradiction across a set. The same term used two ways in different sections. Two thresholds that cannot both be met. Nobody catches these by reading top to bottom.
  • A first draft. Turning a stakeholder sentence into a testable statement is largely pattern work, and correcting a draft is faster than facing an empty cell.
  • Arguing for a verification method. Useful mostly because it gives you something specific to disagree with.
Breaks

What it cannot do for you

  • Tell you it is the right requirement. That is stakeholder judgment about your project, and no model has access to it.
  • Supply a threshold. Ask for one and you will get fifteen minutes, or 99.5%. Plausible, well formatted, sourced from nothing. A confident wrong number is worse than an empty cell, because it stops anyone asking.
  • Validate. Verification asks whether the thing was built right. Validation asks whether it was the right thing, and that still needs the system, the users, and real conditions.
  • Carry accountability. An agent's pass is an opinion. A named person still signs, and the signature is what gets audited.

Both columns point the same direction. An agent can only check a requirement that was written to be checkable — the same structure a reviewer needs, held to more consistently. Which is the argument for the artifacts here whether or not you ever point a model at them, and why they ship as structured, machine-readable files instead of locked PDFs.

That is why the AI Act Requirements Workbook is a workbook, not a manifesto. It informs you what the high-risk requirements say, row by row in the regulation's own words; enforces the basics with checks that catch an unsigned or unevidenced row; and enables your team with the columns to record owners, acceptance criteria and evidence.

Written to survive a real review.

We are requirements engineers with experience across commercial off-the-shelf platforms, financial management systems, mission planning and aerospace programs. Every file is written from scratch; worked examples are invented.

INCOSE methodologyCompTIA Security+DOORS · Jama · HP ALM30-day refund if it doesn’t fit your review
Support and terms

The small print, in plain words.

Refunds

If a workbook doesn’t fit your review, ask for a refund within 30 days of purchase and you get your money back. Reply to your order confirmation email and we’ll refund you.

Updates

Each workbook states the exact source text and version it covers on its README tab. When that text is amended, we publish a new version and tell buyers at the email used for the order.

Contact

Questions before you buy, or about an order: email hello@getrequirements360.com. For an existing order, you can also reply to your order confirmation email.

No affiliation

Requirements 360 is independent. It is not affiliated with, endorsed by, or produced for the European Commission, NIST, any government agency, standards body or software vendor.

Terms

Payment and delivery are handled by Lemon Squeezy, our reseller. Each purchase is for use by the buyer’s own team and may not be resold or redistributed. Quoted regulation text remains the official text of its publisher.