One reviewed record drives the pages, the kit and the watch. Nothing is typed into a page by hand, and nothing is generated at runtime by a model.
1. Read the official record
The ISO page is read live. The stage, stage date, edition, page count, committee and ICS are recorded. The prior edition and the requirement standard are read from the held copies. The DIS body is not public and is not used.
2. State the requirement in our words
Each of the 30 clause records and 93 control records starts from the held ISO/IEC 27001:2022 and 27002:2022 records. The requirement is paraphrased. The control title and defined terms stay as they are. A strict seven word overlap test runs against the held text before publication.
3. Add the guidance lens
The lens is our own statement of what the draft asks a team to do. It is labelled as a lens, not a quotation, and it is not a requirement. It is separate from the requirement, so a reader can always tell which is binding.
4. Derive the evidence
The evidence lines, common gaps and auditor probes come from the held record. They are specific to the clause or control, not a generic checklist. The page shows the category, the artefact and the question.
5. Check and publish
The overlap test, the API smoke, the browser smoke, the UX audit, the link check and the refresh diff all run before a deploy. A failure stops the build. The changelog records the date and the change.
6. Keep it current
The refresh script re-reads the official page and compares it with the record. A stage or date change fails the build loudly. That diff is also what the paid watch sends.