The audit trail requirement that keeps getting written backwards
A single misplaced modal verb can turn a control into a permission. It survives review because it reads like a requirement, and it is only found when someone reads the specification as an adversary rather than an author.
In a requirements specification, the verb carries the entire regulatory weight of the sentence. Everything else is description. Change shall not to shall, or must to may, and a control becomes a permitted behaviour — while the sentence still reads perfectly well.
We see this on almost every URS review we run, and once in a document that had already been approved by three reviewers and used as the basis for an executed OQ.
How it happens
Requirements specifications are rarely written from scratch. They are assembled — from a vendor's functional description, from a previous project's template, from a supplier's response to a questionnaire. Each of those sources is written from a different point of view, and the point of view determines the verb.
A vendor writes capability statements: the system allows an administrator to purge historical records. That is an accurate description of the software. Pasted into a URS and lightly edited, it becomes the system shall allow an administrator to purge historical records. The sentence now says something entirely different: you have specified, and will test, and will approve, the ability to delete audit data.
Nobody made a decision. The verb changed voice when the sentence changed document, and the meaning followed it.
The pattern in one line
Vendor capability language describes what the system can do. Requirement language specifies what it must and must not do. The two are not interchangeable, and the paste that converts one into the other is invisible in review.
Why review does not catch it
Because the sentence is grammatical, technically accurate about the software, and sits among two hundred others that are fine. Reviewers read specifications for completeness and for technical correctness. They rarely read them for whether each sentence, taken alone and read hostilely, permits something it should forbid.
There is also a structural problem. The reviewers who understand audit trail regulation are frequently not the ones who understand the system, and vice versa. The requirement passes both reviews because each reviewer assumes the other checked the half they did not.
How to find it in yours
This does not require a tool or a consultant. It requires an hour and a deliberately adversarial reading.
- Extract every requirement containing a modal verb — shall, must, should, may, can, will — into a flat list, stripped of section headings and context.
- Sort by verb, not by section. This is the step that does the work: all your
maystatements sitting together look very different from the same statements scattered through forty pages. - Read the
mayandcangroup first. Anything permissive touching records, audit trails, user access or time settings is a candidate. In a GxP specification, permissive language about controls is almost always a paste artefact. - Then read every requirement in the quality, security and administration modules as an inspector would — asking not "is this true" but "what does this sentence let someone do".
- Check the traceability matrix last. If a reversed requirement has already been tested, you have an executed protocol proving the system does the wrong thing, which is a harder conversation than the specification alone.
The most expensive version of this finding is not the requirement. It is the executed test script that verified it, signed and dated, sitting in the validation file as evidence.
The preventive fix
Two changes remove most of the exposure.
Separate the source documents
Keep vendor functional descriptions in a clearly marked input document that is never edited into the URS directly. Requirements get written, not converted. The extra hour at the start costs less than the review that finds it later — and far less than the review that does not.
Make the verb an explicit review step
Add a line to the requirements review checklist that is only about modal verbs, performed on the sorted list rather than in document order. It is mechanical, it takes under an hour on a large specification, and it catches a category of error that ordinary technical review structurally cannot.
None of this is sophisticated. It is a clerical failure with regulatory consequences, which is precisely why it survives so well: everyone reviewing the document is looking for something harder.
Written from URS review work across ERP, MES and laboratory systems. If you want a second reading of a specification before it goes to approval, that is a defined piece of work we do regularly — usually two to three days.