ISO 27001 Annex A 6.6: confidentiality and non-disclosure agreements

A prospect's security questionnaire asks you to show that every third party with access to client data is bound by a confidentiality agreement. Yours sit in three inboxes, a shared drive and one contractor's memory. This guide covers ISO 27001 Annex A 6.6 for UK firms of 25 to 250 people. It sets out what the control requires, where it ends, the clauses that hold up, the evidence auditors sample and the automation that turns coverage into a lookup.

It is written for information security managers, compliance leads and CTOs heading into a Stage 1 or Stage 2 audit against ISO 27001:2022. Legal time is scarce, and a deal is waiting on the answer.

What does ISO 27001 Annex A confidentiality or non-disclosure agreements (A.6.6) require?

ISO 27001 Annex A 6.6 asks you to work out where the business needs binding confidentiality promises and put them in enforceable agreements. Everyone whose access warrants one must sign, and in practice that means before they touch information. The control covers employees and third parties alike, and the terms must be kept current as risk changes.

The control is preventive. A signed agreement deters disclosure and removes the legal grey area a leaker would hide behind. It does not detect or repair a leak. It is also unusual among the people controls: it protects confidentiality alone and says nothing about integrity or availability.

What goes into each agreement should follow from what the signatory will touch. Three questions shape it:

• Kind of information: client data, source code, pricing or the product roadmap.
• Sensitivity: how much harm disclosure would cause.
• Permitted handling: what the signatory may do with the information, and what they must hand back.

Legal force is the commercial point. At this size, what is worth stealing is usually informational, and it leaves through people rather than firewalls. Without an executed agreement, your remedies after a leak range from weak to none: no injunction, no damages claim, only a strongly worded letter.

The exposure runs the other way too. Enterprise clients hand over their own confidential material and expect proof that everyone touching it is bound. Picture a diligence reviewer reading your ISO 27001 confidentiality or non-disclosure agreements. If they find expired vendor NDAs, or staff with none, they see a firm that cannot keep secrets. Where the material is personal data, a missing agreement turns a breach into a visible governance failure in front of the regulator.

How does ISO 27001 Annex A 6.6 differ from A.6.2, A.6.5 and A.5.20?

Annex A 6.6 is the confidentiality-agreement control. A.6.2 holds the employee contract clause, A.6.5 keeps the duty alive after someone leaves, and A.5.20 puts supplier-facing terms inside the wider supplier agreement. In practice A.5.20 can reuse A.6.6's templates and register, so the four controls share one paperwork layer rather than four processes.

The boundaries matter because one document can satisfy more than one control, and auditors ask which control it evidences. Use this map:

• A.6.2, terms and conditions of employment: the confidentiality clause in the employment contract. For staff, this clause usually satisfies A.6.6 without a separate document.
• A.6.5, responsibilities after termination or change of employment: keeps the duty alive once someone leaves, through the exit reminder and the return-or-destruction step.
• A.5.20, addressing information security within supplier agreements: carries confidentiality terms inside the wider supplier agreement, next to service and security requirements.
• A.6.6, this control: owns the standalone agreements for contractors, vendors and prospects, plus the templates and register behind them.

A.6.6 is a people control, not a supplier-management control. It tests whether the individual or organisation receiving your information is bound before they receive it. Supplier selection, monitoring and service review sit elsewhere in the standard.

Sequencing follows from the overlap. Plan a week or two of legal and process work, done alongside the employee paperwork under A.6.2. Finish it before supplier onboarding tightens under A.5.20, so the supplier team inherits a working register instead of building a second one.

Who owns A.6.6: HR, procurement or security?

HR runs the employee side through onboarding and exit. Procurement and the supplier relationship owner run the third-party side, and security sets the criteria and checks coverage. Without one shared agreement register, the three teams each hold part of the picture and nobody can prove the whole.

Each team's job is narrow enough to write down:

• HR: puts the confidentiality clause into employment contracts, serves the exit reminder and collects return-or-destruction confirmation at leaving.
• Procurement and supplier relationship owners: ask for the agreement before any third party gets access, and record it in the register.
• Security: sets the criteria for who signs what, checks coverage against the register and reports gaps.
• Legal counsel: produces and reviews the templates.

Write the signing rule as a short table of roles and the agreement each one signs. Then a new starter in procurement does not have to guess. Auditors ask how you decide, and a documented answer beats a shared understanding.

The register is what turns three partial views into one. Each team writes to it, security reads from it, and "are we covered?" has an answer in minutes. No in-house security lead? Setting the criteria, saying what the templates must cover and owning the review cycle is governance work a Fractional CISO can take on.

The failure on the other side is over-engineering. Demanding an NDA from every coffee-meeting contact trains the business to treat agreements as a formality, and people stop checking them.

Ritual paperwork is the paperwork that stops being tracked.

What clauses make an NDA enforceable for ISO 27001 Annex A 6.6?

An enforceable NDA defines the protected information, the permitted use and how long the duty runs. It sets the care owed against accidental disclosure, return-or-destruction on exit, and a governing law that works where the counterparty actually sits. Auditors treat this content as a checklist, so each template should answer every item in its own terms.

The full list the templates should cover:

1. Protected information: what counts as confidential.
2. Duration: how long the duty runs, including open-ended terms or "until public" where they fit.
3. Return or destruction: what the signatory hands back or destroys when the agreement ends.
4. Care standard: the care owed against accidental disclosure.
5. Ownership: who owns the information, trade secrets and intellectual property involved.
6. Permitted use and disclosure: what the signatory may do with the information, and when disclosure is allowed, such as when a court or regulator requires it.
7. Audit or monitoring: your right to check handling, in high-sensitivity cases.
8. Leak reporting: how a suspected leak must be reported to you.
9. Consequences: what follows if the terms are broken.
10. Governing law: a law that is enforceable where the counterparty sits. A clause that fails in the signatory's jurisdiction is decoration.

Return and deletion matter most with suppliers. The NCSC supply chain security principles ask for contracts that spell out how a supplier returns and deletes your information and assets when the contract ends or transfers.

UK GDPR gives the same clauses a regulatory purpose. The ICO guide to data security under UK GDPR says security should mean only people you have authorised can disclose the data, and only within the authority you give them. A confidentiality agreement puts that authority in writing. That makes it one of the organisational measures you can point to under Article 32 and the security principle in Article 5(1)(f).

Two drafting habits undermine all of this. Free-template syndrome comes first. An unvetted internet NDA reads well and fails at enforcement, usually because it lacks survival terms, return-or-destroy duties or a workable governing-law clause. Have a lawyer produce two or three templates (one-way, mutual and a deep-access variant) and stop there.

The second habit is terms that die at termination because nobody drafted them to survive it. Survival wording costs a sentence to write and is very hard to add after the signatory has left.

Why must an NDA be signed before access is granted?

Sign before access means no data room, repository access or building pass until the agreement is executed. UK Intellectual Property Office guidance on non-disclosure agreements says to withhold information until the recipient has signed and returned the NDA. Auditors test this by comparing access dates against signature dates, and the timestamps never forget.

The guidance gives the reason plainly: without an NDA, you take the risk that others could use your ideas or information without your permission. Your clients' data raises the stakes further, because the damage is not only yours.

The same guidance adds a wrinkle: a one-way NDA may need to be executed as a deed to be enforceable. Whether your one-way template needs that is a question for your lawyer, best settled when the templates are drafted.

Treat "access" broadly. Gate each of these on execution:

• Data-room folders and shared workspaces.
• Source repositories and build systems.
• SaaS accounts holding client data.
• Building passes and visitor badges.

The usual failure is access first, paperwork later: the data room shared "while legal sorts the NDA".

A confidentiality agreement signed after the data room opened protects the paperwork, not the information.

What audit evidence shows ISO 27001 Annex A 6.6 is working?

Auditors expect the approved template set with its legal review trail, and executed agreements dated before first access. They also look for an agreement register showing versions and expiry, the written criteria for who signs what, and offboarding records with signed return-or-destruction confirmation. Each item answers a specific audit question.

Here is what each item proves:

• Approved template set with legal review trail: who vetted the wording, when and against what.
• Executed agreements dated before first access: sign-before-access held for the sampled staff, contractors and vendors.
• Agreement register: coverage, versions and expiry tracking, as opposed to a folder of scanned PDFs.
• Written signing criteria: the decision about who signs is deliberate.
• Offboarding records: the exit reminder was served and return or destruction was confirmed.
• Awareness training content and completion logs: staff know what confidentiality asks of them day to day.

The most common failure is storage rather than content. Signed agreements scattered across inboxes and drive folders are effectively unsigned when you must produce one, because an auditor's sample cannot wait for a search.

An NDA you cannot find is an NDA you do not have.

What do ISO 27001 auditors test in the room for confidentiality agreements?

Auditors sample a handful of third parties from the supplier list and trace each to an executed, in-date agreement. They cross-check access dates against signature dates, and review joiner and leaver files for the confidentiality clause and exit confirmation. How they grade a gap depends on whether it is a one-off or a pattern.

Expect five questions:

• "Who has to sign an NDA, and where is that decision written down?"
• "This vendor's engineers see client data. Show me their agreement and when their access started."
• "Walk me through what your NDA obliges someone to do if they suspect a leak."
• "When were these templates last in front of a lawyer?"
• "This person left in April. Show me the exit steps that dealt with confidentiality."

Prepare by running the sample yourself. Take the supplier list and pick the vendors whose engineers see client data. Trace each to an executed agreement, an expiry date and an access start date. Expired vendor NDAs are the classic find, so check those first.

Certification bodies grade by pattern and severity. Third parties handling sensitive information with no agreement, or access routinely preceding signature, is a breakdown of the control and grades major. A single lapsed renewal, a template overdue its legal review or a missing exit declaration grades minor. A pattern of minors can add up to a major. A register that already shows these answers turns the sample into a formality.

How do you automate sign-before-access, expiry tracking and offboarding for A.6.6?

Run confidentiality as a system you can query. Four pieces do the work: a register of every agreement, access granted only once the e-signature tool reports a signature, renewal and review tasks raised automatically, and leaver workflows that collect return-or-destruction declarations. Coverage then becomes a dashboard query instead of an archaeology project.

How each one works:

1. Register as data. Every executed agreement is a record with counterparty, template version, signed date and expiry. Gaps and approaching renewals become dashboard queries with owner alerts.
2. Signature-gated access. Data-room, repository and vendor-system access is granted only when the e-signature platform reports execution through a webhook. The workflow enforces the rule, and its timestamps evidence it.
3. Expiry and review triggers. Renewals are raised ahead of lapse, so a long-running vendor with live repository access is never quietly unbound. The annual cycle, or a new jurisdiction or regulatory change, fires a template-review task, and the trigger is kept as evidence.
4. Offboarding hooks. The leaver workflow serves the exit reminder and collects the return-or-destruction declaration as a step that cannot be skipped silently.

At 50 people the build can be modest. A database or GRC platform holds the register, a webhook comes from your e-signature tool, and a workflow rule handles renewals. GRCMANA builds this as part of its GRC engineering service.

The human layer is reserved for legal judgement: choosing the term, reviewing a counterparty's redlines, deciding whether a new jurisdiction needs different wording. At this scale, the same register and templates serve auditors, enterprise customers' due-diligence reviews and the later A.5.20 supplier work.

Frequently asked questions