What A.5.31 asks for and why auditors sample it
If a certification auditor or a customer asks which laws apply to your information security, A.5.31 is the control they are testing. It requires you to identify the legal, statutory, regulatory and contractual requirements relevant to information security, to document them, to record how the organization meets each one, and to keep that view current. The control merges two controls from the 2013 edition: A.18.1.1, which covered identifying applicable legislation and contractual requirements, and A.18.1.5, which covered the regulation of cryptographic controls. The cryptography element means that rules on encryption, key handling and export or use of cryptographic tools belong in the same register as everything else.
The risk is simple: an obligation you never recorded is an obligation nobody is designing controls for. A missed data residency clause in a customer contract, a sector rule on incident notification or a restriction on encryption in one country can each produce a nonconformity and a real exposure, even when the technical controls are sound. Auditors usually sample this control by picking a few obligations from outside sources (a regulator's rule, a major customer's security schedule, a sector standard) and asking where each one appears in your register, who owns it and which control satisfies it. They also check the review date on the register against the last time the business changed its markets, products or contracts.
What makes this hard is that the obligations are spread across legal, contracts, procurement and product teams, and none of them owns the whole list. The register goes stale because contract clauses change at renewal and new markets bring new rules, but nobody is told. Ask the owner of the register to name who signs off each entry, which teams send changes to it, and how often it is reviewed. A useful first step is to reconcile the register against your top customer contracts and the sector rules that apply to you, then link each entry to the control or procedure that meets it, such as the A.8.24 cryptography rules or the A.5.34 privacy controls. Confirm the current scope of your own obligations with counsel, since this page cannot determine them for you.
Which laws, contracts and jurisdictions belong in the register
The register is only as complete as the sources behind it. Statutes, sector rules, customer and supplier contracts, and cryptography rules each enter the register through a different route, and the scope of the ISMS decides which of them apply to which part of the business.
Statutes and sector regulation
Laws that apply because of where the organization operates, what it does, or whom it serves, such as data protection, cybersecurity, financial or health rules. Start from the places of operation and the sectors served, then ask counsel or a regulatory specialist to confirm which obligations touch information security. Record the source, the competent authority and the people who track changes, because A.5.31 expects the register to stay current.
Customer contracts and their security terms
Security clauses, audit rights, breach notification windows, data location and subcontracting limits written into customer agreements are binding requirements even when no law names them. Extract each obligation into the register with the customer, the clause reference and the control that meets it. Review contract templates and negotiated exceptions together, since side letters often change the obligations that a sales team has promised.
Supplier agreements that flow down obligations
Contracts with suppliers can create requirements for the organization, for example when a supplier processes regulated data, or when a license restricts use. Record the flow-down obligations that the organization owes to its own customers and regulators, and check that supplier terms cover them. Gaps found here connect directly to the supplier controls in clause A.5.20.
Cryptography rules and export restrictions
Some jurisdictions restrict or require particular algorithms, key lengths, or the export of encryption technology, and some sectors mandate approved modules. These rules belong in the register alongside the cryptography decisions made under A.8.24, so that engineering choices can be traced to a legal basis. Ask export control and legal teams to confirm the status of each product and algorithm in the jurisdictions where data is stored or accessed.
Jurisdictions of operation and data subjects
Where the organization is established, where its staff and systems sit, and where its data subjects live can each trigger different obligations. A company with a head office in one country and customers in several may fall under rules in all of them. Map each jurisdiction to the entities, people and data it touches, and note which register entries apply only to a subset of sites or regions.
ISMS scope and customer sectors
The scope of the ISMS determines which business units, products, sites and systems the register must cover. A customer's sector can add expectations even when the organization is not regulated itself, for example when a bank or hospital requires contractual controls. Confirm with the certification body how scope boundaries interact with each legal source, and document the reasons for any source excluded from scope.
Handling contractual terms and cryptography rules
Customer contracts, data processing terms and supplier agreements often carry security obligations that go beyond the ISMS policy: notification windows, audit rights, hosting locations, minimum controls, subcontractor approval and retention or return rules. A.5.31 expects the organization to know which of these apply, to write them down and to keep the list current as contracts are signed, renewed or amended. Legal or contract management usually owns the contract itself, while the information security function owns the translation of each security term into a control, an owner and a check. A useful register records the contract, the clause reference, the obligation in plain language, the control that meets it, the evidence location and the next review date.
- Start from the contract, not the policy: Pull security-relevant clauses from every signed agreement and order form, including click-through terms for SaaS customers.
- Name an owner per obligation: Each entry needs a person accountable for meeting it, separate from the person who signed the contract.
- Link each term to a control: A notification window should point to the incident process in A.5.26, and a hosting restriction to the cloud controls in A.5.23.
- Track change events: Renewals, amendments and new subprocessors should trigger a register update before work starts.
- Record evidence and review dates: Store where proof of compliance lives, such as a test record or an access review, and when it was last checked.
Confirm with your legal team which clauses bind the organization and whether any terms conflict with each other before you build the register.
Rules on cryptography come from several sources: national or sector laws on approved algorithms, export and import controls on encryption technology, contractual requirements to use particular ciphers or key lengths, and internal standards. A.5.31 covers identifying these rules and documenting how the organization meets them, while A.8.24 covers the technical rules for using cryptography and managing keys. The legal and export questions usually belong to legal counsel or a compliance lead, and the technical implementation belongs to security engineering. The register should state the rule, its source, the systems it applies to and the configuration that satisfies it, so an assessor can trace a requirement to a live setting.
- Identify the applicable rules by jurisdiction: Record which countries host data, process it or receive it, because each may add requirements or restrictions.
- Document permitted algorithms and key lengths: Keep an approved list that matches the rules and your internal standard, and state which systems must follow it.
- Record export and import limits: Note any restrictions on shipping or using encryption products across borders, especially for cloud regions and third-party appliances.
- Link each rule to a configuration: Point to the TLS policy, key management setting or disk encryption configuration that enforces it.
- Plan for change: Assign a reviewer to watch for algorithm deprecations and rule changes, and log the decision when the approved list changes.
Ask legal counsel to confirm the current rules for each jurisdiction you operate in, because this list does not replace that advice.
A register only works if each entry has an owner, a method of checking and a record of the check. For contractual terms, the check is usually a periodic comparison between the register and the contracts actually in force, plus a review when a sales or procurement change occurs. For cryptography rules, the check combines documentation review with technical verification, such as scanning endpoints and services for disallowed protocols or weak key lengths. Internal audit or an independent reviewer can sample both sides, which is what an assessor will do when testing whether the register reflects reality.
- Assign a single register owner: One named role maintains the list and reports gaps to leadership, even though many teams contribute entries.
- Set a review cadence: Agree a schedule for reviewing contracts and cryptography rules, and record each review with its date and reviewer.
- Verify configurations automatically where possible: Scheduled scans or configuration checks can show that approved algorithms are in use.
- Sample contracts against the register: Reviewers should pick several agreements and confirm each security term appears and maps to a control.
- Escalate exceptions in writing: Where a system cannot meet a rule, record the exception, the risk accepted, the owner and the expiry date.
Confirm with your certification body how it expects the register and its review records to be presented, since sampling methods vary by assessor.
How an assessor tests A.5.31
This table sets out the steps an assessor takes to test A.5.31, the evidence each step asks for, and the findings that most often appear. Read it as a checklist for your own register before an audit, and treat each row as a question the assessor will ask you to answer with records.
| Test step | What the assessor checks | Common finding |
|---|---|---|
| Completeness against scope | Whether the register covers every legal, statutory, regulatory and contractual requirement that touches the ISMS scope, including sector rules and customer contracts | Requirements for a newly added product, region or customer contract are missing |
| Sampling and tracing | Picks several obligations and traces each to a documented control, policy, procedure or contract clause that meets it | An obligation is listed but no control or owner can be traced to it |
| Cryptography rules | Checks that export, import and national restrictions on cryptography are identified and that the organization's use of cryptography follows them | Cryptography restrictions for countries where systems are hosted or used are never assessed |
| Review dates and change records | Confirms the register has a set review cycle, a last-reviewed date and a history showing what changed and who approved it | The register has no review date, or the last change predates a known regulatory update |
| Interviews with owners | Asks legal, contract and compliance owners how they learn of new obligations and how those reach the register | Owners cannot describe how new obligations are detected or who tells the security team |
| Ownership of each obligation | Checks that every entry has a named owner with authority to act and time to meet the requirement | Obligations with no owner, or owned by someone who has left the organization |
| Link to the approach | Checks that the register describes how the organization meets each obligation, not only that it exists | The register lists laws but records no approach, evidence or responsible control |
Building the requirements register step by step
This sequence turns a vague duty to know your obligations into a maintained register that names each requirement, its owner, the control or procedure that meets it, and the date it was last reviewed.
Scope the sources of obligation
Start by listing every source that can bind the organization for information security: national and sector laws, regulations that apply to the markets and customers served, supervisory expectations, and contracts such as customer agreements, supplier terms and framework agreements. Legal or compliance staff confirm the list, and information security adds the technical sources, such as rules on cryptography and export or data localization constraints that may apply. The output is a source inventory with a named owner for each source and a note on where each one is held. The step is complete when the legal team has signed off that nothing obvious is missing from the list.
Identify and extract each obligation
Read each source and break it into individual obligations that can be tested, such as a duty to notify a regulator within a set period, a contractual right to audit, or a restriction on which cryptographic algorithms may be used. Record the wording or a precise reference for each one so that a later reader can find the original text. Keep obligations that are only partly relevant to information security, and mark them as in or out of scope with a reason. The output is a draft list of obligations, each with its source and clause reference. The step is done when a second reviewer has sampled the list against the source texts and found no obligation without a reference.
Classify obligations by type and impact
Group the obligations by type (statutory, regulatory, contractual, or cryptographic rules) and by the area of the business or system they affect. Assign an impact rating that reflects the consequence of non-compliance, using a scale the organization defines and documents, so that the most consequential items receive attention first. Flag obligations that overlap, such as a contract clause that repeats a regulation, so that one control can be shown to meet both. The output is a classified register with type, scope and impact for every line. The step is complete when the classification scheme is written down and applied consistently to all entries.
Assign an accountable owner
Name one accountable owner for each obligation or group of obligations. Owners are usually managers who understand the business process the requirement touches, such as the head of a product line for a customer contract, or the data protection lead for a privacy law. The information security function coordinates but does not own every requirement. Record each owner's role, not just a name, so the register survives staff changes. The output is an owner field completed for every entry, and owners have confirmed in writing that they accept the responsibility. The step is done when no line is unassigned.
Map each obligation to a control or procedure
For each obligation, identify the Annex A control, the clause of the management system, or the operating procedure that meets it, and describe in one or two sentences how it does so. Where a requirement has no matching control, record a gap and decide whether to add a control, change a process, or accept the risk through the risk treatment process. Cross-references to related controls, such as A.5.34 on privacy or A.8.24 on cryptography, belong here. The output is a mapping column that links every obligation to at least one control or documented procedure, plus a list of identified gaps with their treatment decisions. The step is complete when every obligation either maps to evidence or has a gap recorded.
Set the review cadence and triggers
Define how often the register is reviewed and what events force an earlier review, such as a new law, a change in the markets served, a new major customer contract, a significant incident or an acquisition. Assign the reviewer for each scheduled cycle and record the date of each review in the register. Include a check that the source inventory itself is still complete, because new obligations often arrive through sources that nobody was monitoring. The output is a documented review procedure and a review log showing the last review and the next scheduled review. The step is done when the cadence is written into the ISMS documentation and the first review date is set.
Approve the register and keep it under control
Submit the completed register to the people who have authority over the ISMS, typically top management or the body that approves information security policy, for approval. Store the approved version in a controlled repository where changes are recorded with author, date and reason, so the auditor can see how the register has evolved. Communicate the register to the owners and to the staff who rely on it, and keep a record of that communication. The output is an approved, version-controlled register with a change history and a distribution record. The step is complete when the approval is recorded and the register is the single reference that other controls point to.
Evidence that passes A.5.31 and how to keep it current
An assessor testing A.5.31 looks for a documented, owned and current picture of the obligations that apply to information security, plus proof that the organization acts on it. The cards below cover the artifacts that carry that proof and the routines that keep them accurate between audits.
Requirements register with owners
A register lists each legal, statutory, regulatory and contractual requirement relevant to information security, the source it comes from, the systems or processes it touches, and a named owner accountable for meeting it. Assessors usually start here and sample entries against the source text. Check that every entry names an owner and a review date, and that the register covers contract obligations as well as laws, such as customer security schedules and data processing terms.
Approved approach document
A short approved document describes how the organization identifies applicable requirements, decides how to meet each one, and handles conflicts between them. It is the 'approach' half of the control wording. Confirm that management or the delegated approver signed it, that it names who maintains the register, and that it links to the policy set maintained under A.5.1.
Contract clause extracts
Extracts from customer, supplier and partner agreements show the security, data protection, audit and notification obligations the organization has accepted. Keep a clause-level extract with the contract reference and date rather than the full contract for routine sampling. Check that each extract maps to a register entry and that the team responsible for delivery knows the obligation exists.
Legal review records
Records of legal or compliance review show when a requirement was assessed, by whom, what was decided and why. These may be memos, ticket approvals or meeting minutes. Assessors look for evidence that new laws, regulator guidance and contract terms were reviewed when they appeared, so check that each review has a date, a reviewer and a recorded outcome.
Versioned change logs
A change log records each update to the register, the approach document and the contract extracts, including what changed, when, and who approved it. Version control in a wiki or document platform gives this history automatically if edits go through approved workflows. Confirm the log can show the state of the register on any past audit date, not only the current version.
Scheduled reviews and triggers
Keep evidence current with a recurring review calendar and event-based triggers. The calendar sets a fixed cycle for the whole register, while triggers such as a new regulation, a new customer contract, a new country of operation or a regulator inquiry prompt an out-of-cycle update. Check that the calendar entries exist, that completed reviews are recorded, and that overdue reviews are escalated to the owner.
What meeting A.5.31 costs in money and effort
This table breaks down the cost components of keeping an A.5.31 register current, who is paid for each, whether the cost is one-time or recurring, and what drives it up or down. Use it to build a quote request and to separate internal effort from outside spend. No fee or duration figures are given because none were supplied for this topic.
| Cost component | Who is paid or who spends effort | One-time or recurring, and main drivers |
|---|---|---|
| Legal counsel time | External counsel or the in-house legal team reviewing which laws, regulations and sector rules apply | Mostly recurring. Drivers: number of jurisdictions, sector regulators, customer base in regulated markets, and how often the rules change |
| Contract review effort | Legal and security staff reading customer, supplier and partner agreements for security, audit, notification and data clauses | Initial pass is one-time per contract set, then recurring at each renewal or new agreement. Drivers: contract volume and how standardized the clauses are |
| Register tooling (commercial) | Licence fees to a GRC or compliance platform that holds the obligations register and links to controls | Recurring subscription. Drivers: user count, number of frameworks loaded, and modules purchased. Ask whether obligation libraries are included |
| Register tooling (self-hosted open source) | Infrastructure to host the tool and staff time to configure and maintain it, with no licence fee for the software itself | Mostly one-time setup, then recurring hosting and upkeep. Drivers: hosting model, backup needs, and upgrade effort. Confirm licence terms for the chosen tool |
| Version history and document control | Internal document owners maintaining the register and its change record | Recurring. Drivers: how many obligations are tracked and whether the wiki or GRC tool keeps version history for audit |
| Engineering time to map obligations to controls | Internal security engineers, or an implementation partner under a written scope, linking each obligation to a control, owner and evidence | One-time for the initial mapping, then recurring for changes. Drivers: number of obligations, existing control documentation, and cryptography rules that touch technical systems |
| Recurring review effort | Named owners and the compliance lead reviewing the register at planned intervals and after significant changes | Recurring. Drivers: rate of regulatory change, number of owners, and whether reviews are tied to the management review cycle |
| Auditor sampling and evidence | Certification body or independent auditor testing the register, and staff producing records on request | Recurring at each audit visit. Drivers: sample size chosen by the auditor, how quickly records can be retrieved, and the quality of the register |
Who owns the obligations, who prepares the evidence, and who assesses it
The organization owns its obligations. Legal counsel, the data protection officer, compliance leads and the people who negotiate customer and supplier contracts decide which laws, regulations and contractual terms apply, how the organization interprets them and what it commits to. A.5.31 expects the approach to meeting these requirements to be documented and kept current, so the owners must sign off on the register and on each change to it. Their work is judgment, and no outside party can take it over.
- Interpretation: Owners decide which statutes, sector rules and contract clauses bind the organization and how each one applies to its systems.
- Approval: Owners approve the register, the documented approach and any cryptography rules that follow from legal or export requirements.
- Contract review: Commercial and legal staff track security, notification and audit clauses in customer and supplier agreements.
- Change triggers: Owners announce new laws, amended contracts and regulator guidance so that the register is updated in time.
- Accountability: Named owners answer to management and to assessors for gaps and decisions.
Before relying on this tab, confirm that each owner has a named deputy and that sign-off dates are recorded in the register.
An implementation partner prepares the systems, the register and the evidence that the organization's owners and auditors will rely on. Typical work includes building the requirements register, setting up a document system with version history, connecting a GRC tool to the framework mapping, and collecting proof that reviews happened. The partner does not decide what the law requires and does not issue any assurance. Its deliverables are prepared inputs that the organization reviews and adopts.
- Register build: The partner helps structure the register by jurisdiction, contract and owner, with source references for each entry.
- Tooling: Open-source platforms such as CISO Assistant can hold the register and map entries to other frameworks, subject to the organization's own confirmation of each mapping.
- Documentation: Document systems such as XWiki or BookStack can keep the approach and review records under version control and role-based access.
- Evidence capture: The partner sets review schedules and records that show when each requirement was checked.
- Scope limits: Interpretation, legal opinions and sign-off remain with the organization and its counsel.
Before engaging a partner, ask for the written scope, the list of deliverables and a statement of which decisions stay with the organization.
Only an independent auditor or an accredited certification body can test the register and the approach against ISO/IEC 27001 and issue a certificate. The certification body is paid by the organization for the audit, and it must stay independent of the party that prepared the evidence. The auditor samples the register, checks that obligations were identified and that the approach was kept current, and reviews the records that show it. An auditor looks for evidence that the process runs, not for a document that merely exists.
- Sampling: Auditors pick obligations and trace each one to its owner, its assessment and its latest review record.
- Records: They check dated approvals, change history and the link between obligations and controls.
- Certificate: Only the certification body issues the certificate, and accreditation status can be checked in the IAF CertSearch database.
- Cycle: Under ISO/IEC 17021-1, a three-year certification cycle includes at least one audit each calendar year.
- Independence: Auditors should not design the register they later test.
Before booking, confirm that the certification body is accredited for ISO/IEC 27001 and that its scope covers the organization.
Where the register usually breaks down
A.5.31 registers rarely fail because nobody listed the laws. They fail at handoffs: when an obligation has no owner, when a contract term never reaches the security team, or when a new market or customer adds requirements nobody recorded. The cards below cover the gaps assessors most often find and how to close each one.
Obligations with no owner
Every entry in the register needs a named person who tracks changes to that requirement and confirms the organization still meets it. Many registers list laws against a department name, which looks complete but leaves nobody accountable when the text changes. For each row, check that a named role exists, that the role has time allocated, and that the row records the date of the last review. An illustrative example: a data residency rule added to a product line with no owner appears in no review cycle until a customer asks.
Contract terms that never reach security
Security clauses in customer and supplier agreements, such as audit rights, breach notification windows and data location limits, often sit with legal and never become controls. Ask the contract owner to route any agreement containing security or data obligations into the register, with the clause reference and the control that delivers it. Assessors often sample a signed contract and ask where its notification duty is implemented, so the register should answer that question without a search.
Cryptography rules tracked by no one
Restrictions on cryptography, such as export controls on encryption products, national algorithm mandates or limits on key lengths in certain sectors, are frequently recorded once and then forgotten. This is the part of A.5.31 that covers regulation of cryptographic controls, so it needs its own row. Confirm which team owns the rule, which systems rely on it, and whether any cryptographic library or hosting location change would affect compliance. Link the row to the use of cryptography control so the two stay consistent.
Registers not reviewed after market changes
A register that was accurate when a company served one country can be wrong after it signs its first customer in another jurisdiction or enters a regulated sector. Set review triggers tied to events: a new customer contract, a new market, a new product feature that processes personal data, or a supplier change. Record each trigger and the date the register was re-checked. Without triggers, the review depends on memory, and assessors will ask for the record that a review followed a specific change.
Versions and changes left untracked
A register that is overwritten each time it changes cannot show what the organization knew at a given date, which matters when an assessor tests whether requirements were kept up to date. Keep the register in a system that records who changed each entry and when, and keep prior versions available. Wiki platforms with page version history can serve this purpose if access is controlled, and the review owner should confirm that the historical record is preserved during platform upgrades.
Questions buyers ask about A.5.31
What drives the cost of identifying legal and contractual requirements for ISO 27001?
The cost depends mostly on how many jurisdictions, sectors and customer contracts apply to you, and on how much of the analysis your own staff can do. The main cost components are internal time from legal, compliance, security and contract managers, and any fees for outside counsel or a consultant who reviews the register. Costs recur because laws and contracts change, so the register needs periodic review. Ask any provider for a quote built from a written scope that names the jurisdictions, the contract types and the deliverables. The register itself has no separate ISO 27001 certification fee, since the certification body prices the audit of it.
How long does it take to build a legal and contractual requirements register?
There is no fixed duration, because it depends on the number of applicable laws, regulations and contract clauses and on how well existing records are organized. A single-jurisdiction organization with a few standard customer agreements can usually build a first version much faster than a multinational with regulated customers. Plan for the first pass to be iterative: draft the list, have legal review it, then have contract owners confirm the security obligations. Ask any consultant to state the expected duration and the steps it covers in the written scope before work starts.
What does A.5.31 need from legal and contract staff?
A.5.31 needs legal and contract staff to confirm which laws, regulations and contractual obligations actually apply and what they require of information security. In practice this means reviewing the regulatory landscape for your sector and locations, and reviewing customer, supplier and partner agreements for security, breach notification, audit and data handling clauses. Legal staff also decide how the organization's approach to meeting each requirement is documented. Security staff should not interpret the law alone, and the organization owns the final register and its legal sign-off.
Can a small team build the register without outside help?
A small team can usually build the register alone if it has someone who can read contracts and someone who knows the applicable regulations. The difficulty is coverage: small teams often miss contract clauses signed by sales, or requirements that apply only to a particular customer segment or country. A practical approach is to start with the regulations that clearly apply, then search the contract repository for security and data clauses. Confirm the final list with qualified legal counsel, since the organization remains responsible for its own legal position.
When should an organization bring in outside help for this control?
Bring in outside help when the register must cover several jurisdictions, when regulated customers demand specific contractual terms, or when internal staff lack time or expertise to review contracts. An implementation partner such as DeployOpen can prepare the register structure, link each requirement to the controls and evidence that satisfy it, and set up the system where the register is kept under version control. Legal interpretation and sign-off stay with qualified counsel, and only an independent auditor or certification body can assess conformity to the standard. Agree the scope, deliverables and timeline in writing before work starts.
How does a register of requirements get kept current over time?
A register stays current when it has named owners, a review schedule and triggers for ad hoc review. Triggers include new laws, new customer contracts with unusual security terms, new products or markets, and significant incidents. Keeping the register in a version-controlled wiki or GRC tool lets auditors see what changed, when and who approved it. Ask any provider how the register will be reviewed after handover and who will be responsible for each review.
Which tools can hold the register and show it to an auditor?
Self-hosted tools can hold the register and the evidence behind it. CISO Assistant, under the AGPL-3.0-only license, ships ISO 27001 among more than 200 frameworks and can run assessments against them, while XWiki and BookStack can host the register as controlled documents. XWiki keeps version history of every page change, and BookStack assigns permissions through roles. Confirm in your own environment that the chosen tool meets your retention, access and export needs before relying on it as the system of record.
How DeployOpen prepares A.5.31 evidence
DeployOpen helps organizations build the register of legal, statutory, regulatory and contractual requirements that A.5.31 expects, and the documented approach to meeting them, inside their own infrastructure. The organization owns the obligations and the decisions, while an independent auditor or certification body is the only party that issues a certificate.
How we scope
- Agree in writing which laws, regulations and contracts the register will cover, and which business units own each one.
- Define the sources to review, such as contracts with customers, sector rules and data protection obligations, before any build work starts.
- Record who maintains each requirement, how often it is reviewed and what triggers an update.
How we build
- Set up a self-hosted register of requirements, with an owner, source reference and applicable controls for each entry.
- Map the register to the wider ISMS, linking entries to related controls such as A.5.32, A.5.34 and A.8.24 where they apply.
- Configure the cryptography rules and other technical constraints the organization must follow so they are visible to engineering teams.
How we hand over
- Deliver the documented approach, the requirements register and the review records in the organization's own tools.
- Provide version history showing what changed, when and by whom, so an assessor can trace each update.
- Walk the internal owners through the register and confirm which items still need legal review before the assessment.
How we support
- Offer ongoing support and periodic register reviews as a retainer, if the organization wants help keeping pace with new obligations.
- Confirm with the organization's legal counsel which interpretations are final, since DeployOpen does not provide legal advice.
- Prepare evidence packs for the independent assessor on request, without issuing any audit report or certificate ourselves.
