I want to tell you about Renata Kohl, because her name comes up in my notes more often than I'd like for a contractor who was only on the payroll for fourteen weeks.
Renata was a UX contractor brought in through a staffing agency to help a mid-market payments company I'll call Vantage Ledger redesign its merchant dashboard ahead of a Series C raise. She was smart, fast, and — by every account I later gathered from the product team — genuinely likable. She sat in roadmap reviews. She saw the Q3 pricing model eighteen months out. She had a login to the Figma workspace holding wireframes for a feature that Vantage's VP of Product, a guy named Dave Kettering, believed would be the company's wedge into a competitor's core customer base.
Dave's team assumed HR had her covered. HR assumed the staffing agency's standard contract covered confidentiality, because that's what the agency's account manager had told them on a phone call eleven months earlier, an assurance nobody wrote down and nobody verified. Nobody at Vantage Ledger ever asked Renata to sign a document that named Vantage Ledger, defined what "confidential" meant in Vantage Ledger's context, or told her what would happen if she walked out the door with what she'd seen. The staffing agency's own boilerplate NDA existed, technically, but it ran between the agency and its temps — it protected the agency's client list, not Vantage's roadmap, and it expired the day her assignment ended.
Six weeks after her contract wound down, Vantage Ledger's sales team lost a seven-figure enterprise deal to a competitor called Ferrocode. The prospect's procurement lead mentioned, almost in passing, that Ferrocode's rep had "already walked us through a pricing structure that sounded a lot like what you're about to pitch." Dave did some quiet checking. Renata had joined Ferrocode's product team two weeks after leaving Vantage. There was no email trail, no smoking-gun Slack message, nothing that would hold up as deliberate theft in a courtroom. There was just a competitor who somehow knew things it shouldn't have, and a company with no signed agreement giving it standing to even send a strongly worded letter, let alone pursue an injunction.
I was brought in a month later, not to fix the deal — that was gone, and Vantage's finance team eventually booked the associated pipeline loss at just north of $3.8 million once you counted the follow-on referrals that also stalled — but to explain to the board why the company's information security program hadn't caught this. The honest answer was that it wasn't a technical control failure. Vantage had decent access management, decent endpoint controls, a reasonable password policy. What it didn't have was a functioning confidentiality and non-disclosure agreement program. Nobody had done the unglamorous work of Annex A control 6.6: identifying who needs to sign what, documenting the content of those agreements, reviewing them on a schedule, and actually collecting the signatures before day one instead of assuming someone else had.
That gap is where this article lives. Control 6.6 is one of the shortest entries in Annex A — a single sentence — but it sits underneath almost every other people control, every supplier relationship, and every visitor who walks through your lobby. Get it right and it's a quiet, low-drama piece of governance that rarely makes headlines. Get it wrong, and you find out the hard way, usually at the worst possible moment, that a verbal assurance from a staffing agency is not a legal instrument.
Who This Is For
This article is written for the people who actually own control 6.6 in practice: HR leads building onboarding checklists, information security managers assembling evidence for Stage 2 audits, legal counsel drafting the underlying agreement language, and procurement teams negotiating supplier contracts. If you've been asked to "handle the NDA piece" of your ISMS and you're not sure whether that means one document or a dozen, this is for you. You'll walk away with a working definition of what belongs in a confidentiality agreement, a clear map of who should be signing what and when, a defensible review cadence, and the evidence trail an auditor will expect to see. If any of the ISMS or legal terminology below is unfamiliar, our ISO 27001 terminology and glossary is a useful companion reference to keep open alongside this article. I'll also be candid about where NDAs are strong (deterrence, internal governance, a documented expectation) and where they're weak (they are not, by themselves, a security control that stops a determined leaker — they are a legal and cultural one).
What Control 6.6 Actually Requires
The full text of Annex A control 6.6, Confidentiality or non-disclosure agreements, reads: "Confidentiality or non-disclosure agreements reflecting the organization's needs for the protection of information shall be identified, documented, regularly reviewed and signed by personnel and other relevant interested parties." That's the whole control. No prescribed template, no mandated clause list, no specified duration. ISO leaves the content of the agreement to you and your legal counsel, but it is explicit about four verbs, and an auditor will test all four independently.
Identified means you've done the analysis of where confidentiality obligations are actually needed — not just "everyone signs the same generic form," but a deliberate look at which roles, contracts, and relationships expose confidential information and therefore need a documented obligation. Documented means the agreements themselves exist as records, in a form that specifies what's confidential, whose obligation it is, and for how long. Regularly reviewed means someone owns a schedule for revisiting the content of these agreements — not just re-signing the same static text forever, but checking whether it still reflects the organization's actual needs as the business, the regulatory environment, and the information being protected change. Signed means exactly what it says: a documented, attributable acceptance by the individual or the counterparty, collected before they gain access to the information the agreement is meant to protect, not backfilled after the fact.
Auditors testing 6.6 will typically pull a sample of personnel files, contractor engagements, and supplier contracts and ask three questions: is there a signed agreement, was it signed before access was granted, and does its content actually match what that person or company was exposed to. A generic one-page NDA that never mentions the specific categories of information at stake, signed six weeks after a contractor started work, fails on identification, documentation quality, and timing all at once — which is close to exactly what happened at Vantage Ledger.
Where 6.6 Fits: Related People and Organizational Controls
Control 6.6 doesn't operate in isolation. It's most useful to think of it as one link in a chain that starts before someone joins and continues after they leave. Screening and background checks under control 6.1 establishes who you're hiring; terms and conditions of employment under control 6.2 typically references or incorporates the confidentiality obligation into the employment contract itself; and responsibilities after termination or change of employment, covered under control 6.5, is where the NDA's post-employment survival clause actually gets exercised — the obligation you documented on day one is the thing you're enforcing on the way out. For a broader map of how all eight people controls interlock, the ISO 27001 people controls overview is worth reading alongside this piece.
The relationship with control 5.14, information transfer, and controls 5.19 through 5.23 on supplier relationships also matters — a confidentiality agreement with a vendor is frequently one clause inside a larger data processing or master services agreement rather than a standalone document, and I'll walk through that overlap in detail later in this article. None of these controls substitute for 6.6; the auditor is specifically looking for the signed, documented artifact, wherever it lives.
"The mistake I see most often isn't a missing NDA. It's an NDA that exists somewhere in a shared drive, was signed once in 2019, and hasn't been looked at since the company added three new product lines, a European entity, and a hundred contractors nobody remembers to onboard consistently. The document technically exists. It just doesn't reflect the business anymore." — Priya Chandrasekaran, Director of Information Security, Larkspur Health Analytics
Why NDAs Alone Aren't Enough — and Why They're Still Necessary
I'll say this plainly because it matters for how you scope your effort: a signed NDA does not stop a determined insider from copying a file to a personal drive, and it does not encrypt anything, log anything, or alert anyone. If you're relying on control 6.6 as your primary defense against data exfiltration, you've misunderstood what it's for. The technical backstop for that risk lives elsewhere in Annex A — data leakage prevention controls, access restriction, monitoring activities.
What an NDA does is establish, unambiguously and in writing, that the person on the other side of it understood the information was confidential, agreed to specific obligations, and can be held to a legal and disciplinary standard if they violate it. That matters for three separate reasons. First, deterrence: people who've signed something specific and been walked through it behave differently than people who assume information is fair game because nobody told them otherwise. Second, disciplinary and legal standing: without a signed agreement, your options when something goes wrong are dramatically narrower — Vantage Ledger's lawyers confirmed that without a document naming the company and defining the obligation, there was effectively no cause of action against Renata individually, only a much weaker and slower claim against the staffing agency for breach of its own separate contract. Third, and most relevant to your certification: it's the specific, auditable evidence ISO 27001 requires. You can have excellent technical controls and still fail this control if the paperwork doesn't exist.
It also helps to be clear about where an NDA sits relative to the other instruments that touch confidentiality, because organizations sometimes assume one of these substitutes for the others when each actually plays a distinct role.
Instrument | Primary Purpose | Does It Satisfy Control 6.6 Alone? |
|---|---|---|
Standalone NDA | Defines confidentiality obligations for a specific relationship | Yes, if documented, specific, and signed |
Confidentiality clause within employment contract (control 6.2) | Embeds the same obligation within the broader employment terms | Yes, provided the clause meets the same content standard as a standalone NDA |
Information classification policy | Defines sensitivity levels and handling rules organization-wide | No — it informs what an NDA should cover, but isn't itself a signed, party-specific agreement |
Acceptable use policy | Governs how employees may use organizational assets and systems | No — related but distinct; doesn't establish confidentiality obligations toward specific information |
Data processing agreement (GDPR-adjacent) | Governs lawful processing of personal data between controller and processor | No — addresses regulatory data-handling obligations, not general confidentiality; often needed alongside an NDA, not instead of one |
NDA Contents: A Clause-by-Clause Breakdown
I've reviewed a lot of confidentiality agreements over the years, ranging from a single laminated page a manufacturing client used for factory-floor visitors to a forty-page mutual NDA a defense contractor negotiated line by line with outside counsel on both sides. The length varies enormously by risk and relationship. The substance, though, tends to converge on the same core clauses. If any of the following is missing from an agreement you're relying on for control 6.6, treat that as a gap to close, not a stylistic choice.
Clause | What It Should Cover | Why It Matters for 6.6 |
|---|---|---|
Definition of confidential information | Specific categories (trade secrets, customer data, source code, financials, roadmaps) rather than a vague "any information" catch-all | Auditors and courts both want to see that the parties knew what was actually covered |
Exclusions | Information already public, independently developed, or lawfully received from a third party | Without exclusions, the agreement is overbroad and harder to enforce |
Obligations of the receiving party | Duty of care, no disclosure to unauthorized third parties, use limited to the stated purpose | This is the operative promise — everything else supports it |
Permitted disclosures | To advisors, auditors, or regulators under specific conditions | Prevents the agreement from blocking legitimate legal or audit activity |
Duration / term | How long confidentiality obligations last, including post-relationship survival | Directly tied to control 6.5 — this is the clause that outlives the relationship |
Return or destruction of information | What happens to documents, files, and access at the end of the relationship | Ties to control 5.11, return of assets, and closes the loop on offboarding |
Ownership and intellectual property | Confirms that sharing information doesn't transfer IP rights | Prevents disputes over who owns derivative work or ideas discussed |
Remedies / actions on breach | Injunctive relief, damages, indemnification, notice requirements | Defines what the organization can actually do if the agreement is violated |
Governing law and jurisdiction | Which laws and courts apply | Especially important for cross-border contractors and suppliers |
Signature and effective date | Names, roles, dated signatures of both parties | The evidentiary anchor an auditor will look for first |
Note what's deliberately not on that list: specific dollar penalties, non-compete restrictions, or broad restrictions on future employment. Those are separate legal instruments (liquidated damages clauses, non-competes, non-solicits) that some organizations bundle into the same document, but conflating an NDA with a non-compete is a common drafting mistake — non-competes are far more restricted by jurisdiction (several U.S. states, for example, have banned them outright for most employees) and mixing the two can render an otherwise sound confidentiality clause harder to enforce if a court strikes down the non-compete language sitting next to it. Keep confidentiality obligations and post-employment competition restrictions in clearly separable clauses, even within the same document, and have counsel review both independently.
Defining "Confidential Information" — Getting the Scope Right
The single clause that determines whether an NDA is useful or theater is the definition of confidential information. I've seen two failure modes with roughly equal frequency. The first is the definition that's so broad it's meaningless — "any and all information disclosed by either party" — which sounds protective but is actually hard to enforce, because a court asked to grant an injunction wants to see that the receiving party had fair notice of what specifically was off-limits. The second is a definition copied from a template that lists categories irrelevant to your business (patent applications, for a company with no patents; manufacturing processes, for a pure software shop) while omitting the categories that actually matter (customer usage data, pricing models, unreleased product roadmaps, security architecture).
The fix is to tie the definition of confidential information back to your information classification scheme under asset management. If your organization classifies information as Public, Internal, Confidential, and Restricted, your NDA template should explicitly state that information classified Confidential or Restricted under the ISMS is presumptively covered, with named examples relevant to the signer's role. A visitor NDA should reference physical premises and any documents shown during the visit. A contractor NDA for a product team member should explicitly name roadmaps, pricing, and pre-release features. A supplier NDA covering a payment processor should name transaction data, customer PII, and API credentials. Specificity is what makes the agreement both enforceable and auditable — a generic form gives you neither.
"I ask every client the same question during a Stage 1 readiness review: pull up your NDA and tell me, without looking anything up, what it actually protects. If the answer is a shrug, we have work to do before an auditor gets anywhere near the document." — Marcus Whitfield, Lead Auditor, Ironhale Certification Partners
Duration and Survival Clauses
How long should a confidentiality obligation last? ISO 27001 doesn't specify a duration — that's a business and legal decision — but I coach clients toward a tiered approach rather than a single blanket number, because a flat "confidentiality survives for two years" clause is either too short for trade secrets or needlessly long for information that's stale within months. The table below reflects illustrative durations I've seen work well across client engagements; treat the numbers as a starting framework to adapt with counsel, not a standard.
Information Category | Illustrative Survival Period After Relationship Ends | Rationale |
|---|---|---|
Trade secrets, proprietary algorithms, source code | Indefinite, or until information enters the public domain | Trade secret protection under most legal frameworks depends on continuous confidentiality efforts |
Customer and personal data | Duration of applicable data protection obligations, commonly 3–7 years post-relationship | Aligned to regulatory retention and breach-liability windows, not an arbitrary figure |
Financial and strategic plans (roadmaps, M&A discussions, pricing) | 2–5 years | Long enough to outlast the competitive relevance of the information |
Employee/HR-related confidential information | 2–3 years, or per applicable employment law | Balances legitimate protection against overreach into a former employee's career |
General business information, meeting content, vendor discussions | 1–2 years | Reflects genuinely time-limited sensitivity |
The one clause I insist clients never omit is a survival statement — explicit language confirming that confidentiality obligations continue after the underlying relationship (employment, contract, engagement) ends. Without it, some jurisdictions will interpret the NDA as expiring automatically alongside the relationship it was attached to, which defeats the entire purpose for anyone leaving with sensitive knowledge in their head rather than on a device.
Who Signs What: Employees, Contractors, Third Parties, Visitors
Control 6.6 explicitly extends beyond employees — "personnel and other relevant interested parties" is deliberately broad language, and it's the phrase auditors will hold you to. The most common finding I see in Stage 2 audits and internal reviews alike is a program that covers full-time employees thoroughly and then has nothing — or something informal and undocumented — for everyone else who touches confidential information. Renata Kohl's case at Vantage Ledger is a textbook version of exactly this gap: the employee NDA process was fine; the contractor process, routed through a third party, was assumed rather than verified.
Party | Typical Trigger for Signing | Recommended Agreement Type | Common Gap I See |
|---|---|---|---|
Full-time and part-time employees | Offer acceptance, before first day of system access | Confidentiality clause within employment contract, per control 6.2, or standalone NDA referenced by it | Usually solid; gaps appear with rehires or internal transfers into higher-sensitivity roles |
Contractors engaged directly | Contract signature, before access provisioning | Standalone NDA naming the specific engagement and information categories | Verbal assurance substituted for a signed document |
Contractors via staffing agency or MSP | Before the individual — not just the agency — begins work | Direct NDA between the individual and the organization, in addition to any agency-level agreement | Assuming the agency's own contract covers the client organization; it usually doesn't |
Interns and temporary staff | Same day as onboarding paperwork | Simplified NDA tailored to limited scope of access | Treated as "not real employees" and skipped entirely |
Board members and advisors | Appointment, before board materials are shared | Standalone NDA, often bundled with a director's confidentiality and conflict-of-interest agreement | Assumed to be covered by fiduciary duty alone, which varies significantly by jurisdiction and doesn't specify information categories |
Suppliers and vendors (organizational) | Contract execution, before data or system access is provisioned | Confidentiality clause within the master services agreement or data processing agreement | NDA signed at the sales/procurement stage, but not re-verified when the scope of access expands later |
Visitors to secure facilities | Sign-in, before entry to restricted areas | Short-form visitor confidentiality acknowledgment | No documented acknowledgment at all — a sign-in sheet is not a confidentiality agreement |
Auditors, assessors, and consultants (external) | Engagement letter, before access to systems or records | Standalone NDA, often mutual given two-way information exchange | Overlooked because the relationship is assumed to be "professional" and therefore implicitly bound |
The pattern across every gap in that table is the same: someone assumed a relationship implied confidentiality without anyone actually documenting and signing it. ISO auditors are trained to probe exactly this assumption, and "we trust our contractors" is not evidence.
Unilateral vs. Mutual NDAs
Not every confidentiality relationship is symmetric, and the agreement type should reflect that. A unilateral (one-way) NDA obligates only the receiving party — appropriate when your organization is disclosing information and the counterparty isn't sharing anything comparably sensitive back, such as a new employee, a contractor, or a visitor. A mutual (two-way) NDA obligates both parties — appropriate when information flows in both directions, such as a supplier evaluation where you're sharing architecture details and the vendor is sharing proprietary product roadmaps, or a partnership discussion where both companies are exposing strategic plans.
Factor | Unilateral NDA | Mutual NDA |
|---|---|---|
Typical use case | Employees, contractors, visitors, one-way vendor evaluations | Joint ventures, M&A due diligence, two-way supplier/partner information exchange |
Who bears the obligation | Receiving party only | Both parties, symmetrically |
Drafting complexity | Lower — one set of obligations to negotiate | Higher — both parties' counsel typically review and negotiate |
Common mistake | Using a unilateral NDA when the counterparty is also sharing sensitive information, leaving your own disclosures unprotected | Using a mutual NDA as a default even for simple one-way relationships, adding unnecessary negotiation overhead |
Best fit within 6.6 scope | Employees, contractors, interns, visitors | Suppliers, technology partners, M&A counterparties, joint research arrangements |
A quick gut-check I use with clients: if you'd be genuinely uncomfortable with the other party disclosing what you tell them, but you have nothing comparably sensitive to protect on their end, unilateral is correct and mutual adds friction for no benefit. If both sides are walking away from the conversation having learned something the other wouldn't want a competitor to see, insist on mutual — a unilateral NDA in that scenario leaves your own information exposed with no reciprocal legal protection.
The NDA Lifecycle: Identify, Draft, Sign, Review, Enforce
Control 6.6's four verbs — identified, documented, regularly reviewed, signed — map cleanly onto a lifecycle that should be running continuously across your organization rather than treated as a one-time onboarding task. I find it useful to walk clients through this as an explicit process diagram, because the two stages people skip most often — the initial "identify" step and the recurring "review" step — are exactly the two that don't get done unless someone owns them by name.
flowchart LR
A[Identify Need<br/>New role, contract,<br/>or relationship exposes<br/>confidential information] --> B[Draft or Select<br/>Agreement<br/>Match template to<br/>relationship type]
B --> C[Sign<br/>Before access is<br/>provisioned]
C --> D[Store as Record<br/>Signed copy retained,<br/>linked to onboarding file]
D --> E[Regularly Review<br/>Scheduled reassessment<br/>of content and coverage]
E -->|Content still fits| F[Enforce<br/>Reference on breach,<br/>termination, offboarding]
E -->|Content has drifted| B
F --> G[Post-Relationship<br/>Survival clause continues<br/>obligation]Two things about that diagram are worth calling out explicitly. First, the loop back from "Regularly Review" to "Draft or Select Agreement" is deliberate — a review that finds the existing agreement no longer reflects the organization's needs should trigger a redraft, not a rubber stamp. Second, "Enforce" isn't a final state; it feeds into the post-relationship survival period, which is where control 6.5 picks up the baton.
Assign a named owner to each stage rather than leaving the lifecycle as a shared, ambiguous responsibility — ambiguity is exactly what let the Vantage Ledger gap persist for over a year unnoticed.
Lifecycle Stage | Typical Owner | Key Output |
|---|---|---|
Identify need | Hiring manager, procurement lead, or facilities lead (role-dependent) | Flag raised before access is granted |
Draft or select agreement | Legal counsel, with security input on information categories | Correct template matched to relationship type |
Sign | HR (personnel), procurement (suppliers), reception/facilities (visitors) | Dated, attributable signature on file |
Store as record | HR systems administrator or document control owner | Retrievable record linked to the individual or contract |
Regularly review | Information security manager or GRC lead, with legal sign-off | Updated template or confirmed currency, logged |
Enforce | Legal counsel, HR (disciplinary), incident response team | Remedy pursued per the agreement's terms |
"We treat NDA review the same way we treat policy review — on the ISMS management review calendar, owned by name, with a due date. The year we didn't do that, we found out during an audit that our 2020-era NDA template still referenced a data center we'd decommissioned two years earlier and said nothing about the cloud infrastructure that had replaced it." — Sofia Reyes-Marsh, Head of GRC, Halcyon Freight Systems
Onboarding Sign-Off: Making Signature Non-Optional
The mechanics of getting an NDA signed sound trivial until you look at how many organizations manage it as a loose, decentralized process — an email attachment sent by whoever happens to be onboarding the person that week, tracked (or not) in a spreadsheet, with no hard gate preventing system access before the document comes back signed. That's the exact process gap that let Renata Kohl start work, sit in roadmap meetings, and gain Figma access without anyone confirming a signed confidentiality agreement existed with her name on it.
The fix is procedural, not technological, though technology helps. Confidentiality agreement signature should be a hard dependency in your onboarding workflow — provisioning of accounts, badges, and system access should be blocked until the signed agreement is on file, the same way many organizations already gate access on completed background screening under control 6.1. If you use an HRIS or identity governance platform, this is usually a simple workflow rule: no signed NDA record, no access ticket approval. If you're running onboarding manually, it means a named owner (usually HR, sometimes the hiring manager) who is accountable for confirming the signature before submitting the access request, and a checklist that makes the dependency explicit rather than assumed.
For contractors and third-party personnel specifically, build the same gate into your vendor and staffing agency onboarding process. Don't accept "our agency has its own confidentiality agreement" as sufficient — request a copy of that agreement to confirm it actually names your organization and covers the categories of information the individual will access, or require your own direct agreement with the individual as a condition of the engagement starting. This single change — verifying rather than assuming — is the one piece of process that would have prevented the Vantage Ledger incident entirely.
Signature method matters less than most people assume, but it's worth settling deliberately rather than defaulting to whatever's easiest in the moment.
Signature Method | Suitability | Notes |
|---|---|---|
E-signature platform (DocuSign, Adobe Sign, HelloSign, etc.) | Preferred for most relationship types | Timestamped, auditable, integrates with onboarding workflow tools |
Wet-ink signature, scanned and retained | Acceptable, more common for visitor or paper-based contexts | Ensure the scan is retained centrally, not left in a physical file only |
Click-through acceptance (checkbox plus name entry) | Acceptable for low-risk, high-volume scenarios like visitor kiosks | Weakest evidentiary form; avoid for higher-sensitivity relationships (employees, key contractors, suppliers) |
Verbal agreement, undocumented | Not acceptable for control 6.6 purposes | Provides no auditable evidence and minimal legal standing — this is precisely the failure mode behind the Vantage Ledger case study |
Periodic Review Cadence
"Regularly reviewed" is one of the four operative verbs in control 6.6's text, and it's also the one most commonly treated as satisfied by inertia — the agreement was reviewed once, at creation, and then never again. A defensible review cadence needs both a scheduled component and an event-triggered component.
Review Trigger | Recommended Cadence | What to Check |
|---|---|---|
Scheduled periodic review | Annually, aligned to ISMS management review | Does the definition of confidential information still match current information classification categories? Are duration clauses still appropriate? Has relevant law changed? |
New information category introduced (e.g., new product line, new PII category collected) | Within 90 days of the change going live | Does the existing NDA template cover the new category, or does it need an addendum? |
New jurisdiction of operation | Before onboarding personnel or suppliers in that jurisdiction | Does local law affect enforceability, required language, or permitted duration? |
Merger, acquisition, or major reorg | Within 6 months of close | Do legacy NDAs from the acquired entity meet the parent organization's standard? Do new reporting lines create new access that needs fresh agreements? |
Significant security incident involving a confidentiality breach | Immediately, as part of lessons-learned/corrective action | Did the NDA in place adequately name the information that was breached? Does the incident reveal a gap in coverage? |
Contract renewal (suppliers) | At each renewal cycle | Has the scope of the vendor's access changed since the agreement was last reviewed? |
Document the review itself, not just its outcome. An auditor is not satisfied by your assurance that "we review these annually" — they want a record: a review log, a version history on the template, minutes from the meeting where the legal and security teams signed off on the current version. If your management review agenda doesn't already include a standing item for confidentiality agreement currency, add one; it's a natural fit alongside broader ISMS documentation review.
Visitor and Short-Term Access NDAs
Visitors are the category most often left out entirely, partly because the exposure feels lower — someone touring a facility for an hour seems like a smaller risk than a six-month contractor. But "lower risk" is not "no risk," and control 6.6's language covers "other relevant interested parties" without carving out visitors. If your organization has secure areas under physical security perimeters and entry controls — a data center floor, a trading floor, a facility where unreleased hardware sits on a bench — visitors to those areas should sign a short-form confidentiality acknowledgment before entry, not just a general liability waiver at the front desk.
Keep the visitor form genuinely short: a paragraph defining confidential information as anything observed or disclosed during the visit, a statement of the obligation not to disclose it, and a signature line, dated. I've seen this work well as part of the same digital sign-in kiosk process many organizations already use for visitor badges — the confidentiality acknowledgment becomes a screen the visitor taps through before the badge prints, with the signed record retained electronically. That satisfies "documented and signed" without adding meaningful friction to the visitor experience, and it gives you an auditable record tied to a specific date and visit.
NDAs in Supplier Agreements
For most organizations past a certain size, the majority of confidentiality agreements aren't standalone documents at all — they're clauses embedded inside supplier and vendor contracts, and this is where control 6.6 overlaps most directly with supplier relationship security under controls 5.19 through 5.23. When you're addressing information security requirements within a supplier agreement (control 5.20), the confidentiality clause is typically one of the first sections negotiated, and it deserves the same rigor as a standalone NDA — a specific definition of what's confidential, a stated duration, return/destruction obligations, and remedies on breach.
The mistake I see most often with supplier NDAs is scope drift: the confidentiality clause was negotiated at the start of the relationship, when the vendor's access was limited to a narrow integration, and it was never revisited as the relationship expanded to cover broader system access, more sensitive data categories, or a fourth-party subcontractor the original vendor brought in. Control 5.22, monitoring and review of supplier services, exists partly to catch this kind of drift — pair your supplier confidentiality review with your broader supplier relationship review cadence rather than running them as separate, unsynchronized processes. If a supplier subcontracts any part of the work — increasingly common in cloud and managed-service arrangements — confirm contractually that the confidentiality obligations flow down to the subcontractor; a confidentiality clause that only binds your direct counterparty does nothing to protect information once it's shared with a fourth party several layers removed.
"Every renewal cycle, I ask the same blunt question in the vendor review: has what they can see changed since we signed this? Nine times out of ten the answer is yes, and the confidentiality language hasn't kept pace. That gap is where most of our supplier-related findings come from." — Tomasz Baran, Third-Party Risk Manager, Cresthaven Insurance Group
Mapping 6.6 to Interested Parties
Your organization's list of interested parties under Clause 4.2 is a natural input into scoping control 6.6 — it's the same exercise, applied from a different angle. If you've already documented the interested parties relevant to your ISMS (regulators, customers, suppliers, employees, shareholders, certification bodies), cross-reference that list against your confidentiality agreement coverage and ask, for each party category with access to confidential information, whether a signed agreement exists and whether its content reflects what that party can actually see. Gaps surface quickly this way — I've had clients discover, doing this exercise for the first time, that their outside legal counsel, their fractional CFO, and their board's audit committee members had never signed anything specific to the organization, relying instead on generic professional confidentiality norms that don't satisfy the documentation and signature requirements of 6.6.
Enforceability and Legal Limits — Illustrative Notes
I am not your lawyer, and nothing here is legal advice — a properly negotiated NDA needs review by counsel licensed in the relevant jurisdictions, every time, without exception. What I can offer, from sitting in a lot of rooms where NDAs got tested after the fact, are patterns worth understanding before you assume a signed document guarantees an outcome.
An NDA is a contract, and like any contract its enforceability depends on the basics: was there genuine mutual assent, was there consideration (something of value exchanged, which is usually easy to establish in an employment or engagement context but occasionally gets contested with unpaid interns or volunteers), and is the scope reasonable. Courts in most jurisdictions I've dealt with will scrutinize an NDA that's drafted so broadly it effectively prevents someone from ever working in their field again, and may narrow or void an unreasonable clause rather than enforce it as written — which is precisely why the specificity discussed earlier in this article isn't just good governance, it's what keeps the document enforceable if it's ever tested. An NDA also generally cannot be used to conceal information a court, regulator, or law enforcement agency has lawfully compelled disclosure of; a well-drafted permitted-disclosures clause should say so explicitly rather than leaving that ambiguity for a judge to resolve.
The other limit worth internalizing: an NDA is a civil instrument. It gives you standing to seek damages or injunctive relief; it does not, by itself, make unauthorized disclosure a crime, and it does not replace the protections (or requirements) that come from actual trade secret law, data protection law, or sector-specific regulation. Positioning an NDA as your organization's "legal compliance" mechanism is a category error — it supports your broader legal and regulatory posture, including obligations under frameworks like GDPR, but it does not substitute for them. Treat control 6.6 as one layer in a defense that also includes your classification scheme, access controls, and — where genuinely relevant to the relationship — separate trade secret and IP protection measures.
Jurisdictional Variance (Illustrative)
If your organization operates across multiple countries — employees in one jurisdiction, contractors in another, suppliers in a third — a single NDA template rarely travels cleanly across all of them without at least a review, and sometimes a rewrite. This is one of the most common blind spots I encounter with fast-growing companies that started with a single U.S. or U.K. template and expanded without revisiting it.
Jurisdictional Factor | Why It Affects Your NDA | Illustrative Example |
|---|---|---|
Employment law protections | Some jurisdictions limit how broadly post-employment confidentiality can restrict a former employee's ability to work | Several EU member states require specific compensation for restrictive post-employment covenants beyond basic confidentiality |
Non-compete restrictions | Confidentiality and non-compete provisions are often regulated separately, and bundling them can taint an otherwise valid confidentiality clause | A jurisdiction that bans or heavily restricts non-competes may still fully enforce a properly scoped confidentiality clause in the same document |
Data protection law | Confidentiality obligations covering personal data may need to align with local retention and processing rules, not just contract law | GDPR-adjacent obligations shape how long personal data references in an NDA-covered relationship can be retained |
Language and local-law requirements | Some jurisdictions require local-language contracts or specific formalities to be enforceable | A confidentiality clause in English only may be unenforceable in certain civil-law jurisdictions without a certified local-language version |
Trade secret statutes | Definitions of what qualifies as a protectable trade secret, and the steps required to maintain that status, vary | Continuous, demonstrable confidentiality efforts are often a legal prerequisite for trade secret status, not just good practice |
The practical takeaway isn't that you need a bespoke NDA for every country you touch — for most mid-market organizations that's overkill — but that you need a periodic legal review, mapped to your actual footprint, confirming your standard template still holds up where you operate. This is exactly the kind of check that belongs in the "regularly reviewed" cadence discussed earlier, triggered specifically when you open in a new jurisdiction.
Actions on Breach: What the NDA Should Specify
A confidentiality agreement that's silent on what happens after a breach leaves you improvising under pressure, which is the worst time to be figuring out your options. The breach and remedies clause should specify, at minimum, the categories of relief available and any procedural steps required before pursuing them.
Remedy Type | What It Provides | When It's Typically Invoked |
|---|---|---|
Injunctive relief | A court order stopping further disclosure or use, often available on an expedited basis | Ongoing or imminent disclosure, especially to a competitor |
Monetary damages | Compensation for demonstrated losses tied to the breach | After-the-fact breaches where harm can be quantified |
Indemnification | Reimbursement for costs incurred responding to the breach (legal fees, forensic investigation, notification costs) | Common in supplier and vendor agreements, less so in employment NDAs |
Disciplinary action (internal) | Termination, formal warning, or other HR action, governed by control 6.4 | Employee and contractor breaches, run in parallel with any legal remedy |
Notice and cure period | A defined window to remedy an inadvertent breach before formal action | Common in ongoing commercial relationships where the parties want to preserve the relationship if possible |
Coordinate this clause with your incident management process under incident management controls 5.24–5.28 — a suspected confidentiality breach should trigger the same assessment and response workflow as any other information security incident, not a separate ad hoc process run solely by legal. The two processes should reference each other explicitly in your documentation, because an auditor testing incident management will often ask how confidentiality breaches specifically are handled, and "we'd figure it out" is not an acceptable answer.
Return and Destruction of Information
The return-or-destruction clause is easy to underestimate because it reads like boilerplate, but it's the clause that actually closes the loop at offboarding. It should specify what happens to physical documents, electronic files, access credentials, and any derivative work product created using the confidential information, and it should set a timeframe — "promptly" is not a timeframe an auditor or a court finds persuasive; "within 10 business days of termination or upon written request" is.
This clause connects directly to control 5.11, return of assets, and to the offboarding checklist that should already exist under your termination process. In practice, I recommend building a single offboarding form that satisfies both controls at once: a section confirming all organizational assets (badges, laptops, access tokens) have been returned, and a section confirming the departing individual acknowledges their continuing confidentiality obligations and has returned or certified destruction of any confidential materials in their possession, including personal devices and personal cloud storage where company data may have synced. Get a signature on that acknowledgment at the exit interview — it's a small additional step that creates a much stronger evidentiary position if a dispute arises later, and it's exactly the kind of record that would have given Vantage Ledger's legal team something to work with had it existed for Renata's engagement.
IP Ownership Clauses
A confidentiality agreement is not the same instrument as an IP assignment agreement, but the two are frequently confused, and a gap here creates real business risk beyond the information security concern. The confidentiality clause protects information from disclosure; an IP ownership or assignment clause determines who owns work product, inventions, or improvements created using or informed by that information. Without a clear ownership clause, a contractor who develops a feature concept while exposed to your roadmap could, in some jurisdictions, retain a legitimate claim to ideas or code they contributed — a mess entirely separate from, but often confused with, a confidentiality breach.
Best practice is to include a brief, explicit ownership clause within the same document, or reference a separate IP assignment agreement signed concurrently, confirming that access to or discussion of confidential information does not transfer any ownership rights, and that any work product created in the course of the engagement belongs to the organization. This is standard practice in most contractor and employment agreements already, but it's worth explicitly confirming it's present rather than assuming — I've seen organizations with airtight confidentiality language and a complete gap on IP ownership, which becomes a very expensive discovery when a contractor's "personal side project" turns out to be built directly on company IP.
Evidence for Auditors
When an auditor tests control 6.6, they're not reading your NDA template in isolation — they're sampling real records and tracing them against real onboarding and offboarding dates. Walk into your Stage 2 audit or internal audit with the following ready, organized, and cross-referenced rather than scattered across HR, legal, and procurement systems.
Evidence Item | What the Auditor Is Checking | Where It Typically Lives |
|---|---|---|
Signed NDA/confidentiality agreement register | Completeness — every relevant party has a signed, dated record | HRIS, contract management system, or a maintained register/spreadsheet as an interim measure |
Sample of individual signed agreements, cross-referenced to start dates | Timing — signature occurred before, not after, access was granted | Personnel files, contractor files, vendor files |
Current confidentiality agreement template(s), version-controlled | Documentation — the content reflects the organization's actual needs | Document management system, legal repository |
Review log or version history for the template(s) | Regular review — evidence of scheduled reassessment, not a static document | ISMS document control records, management review minutes |
Onboarding process documentation showing the NDA-signature gate | Process control — signature is enforced, not optional | HR onboarding SOP, access provisioning workflow documentation |
Offboarding/exit checklist referencing continuing confidentiality obligations | Post-relationship coverage, tied to control 6.5 | HR offboarding records |
Supplier contracts with confidentiality clauses highlighted or extracted | Coverage of third parties, tied to controls 5.19–5.23 | Vendor/procurement contract repository |
Visitor confidentiality acknowledgment records | Coverage of short-term/visitor access | Facilities/reception sign-in system |
Statement of Applicability entry for control 6.6 | Justification for how the control is implemented (or, rarely, justified exclusion) | |
Register of interested parties, cross-referenced against NDA coverage | Identification — confirms the "identified" verb in the control text was actually performed | Clause 4.2 documentation |
If any of these live only in someone's memory or in an unmanaged email thread, that's your gap list before the auditor finds it for you. I generally recommend a single owned register — even a well-maintained spreadsheet is fine at smaller scale — that tracks every party required to sign, the agreement type, signature date, and next review date, because it lets you answer "show me everyone with a signed NDA" in minutes rather than a multi-day scramble across departments.
A minimal but audit-ready register typically needs no more than the following fields — resist the urge to over-engineer this into a heavyweight system before you've proven the process works manually.
Field | Purpose |
|---|---|
Party name and role/organization | Identifies who the obligation applies to |
Relationship type | Employee, contractor, agency contractor, supplier, visitor, board member, advisor |
Agreement type | Standalone NDA, employment clause, embedded supplier clause, visitor acknowledgment |
Signature date | Confirms timing relative to access grant |
Access grant date | Cross-check against signature date to confirm sequencing |
Duration / survival terms | Tracks when obligations expire, if not indefinite |
Last review date | Supports the "regularly reviewed" evidence requirement |
Next scheduled review date | Drives the recurring cadence rather than relying on memory |
Document location/link | Enables fast retrieval during an audit |
Common Mistakes
I've now seen most of the ways this control goes wrong, often more than once at different clients, so it's worth naming the patterns directly rather than making you rediscover each one the hard way.
Mistake | Why It Happens | Consequence |
|---|---|---|
Assuming a staffing agency's or vendor's own NDA covers your organization | Nobody reads the actual counterparty on the existing agreement | No standing to act when the individual, not the agency, breaches confidentiality |
Signing after access is granted, not before | Onboarding urgency outweighs process discipline | Fails the "identified before exposure" intent of the control; weak evidentiary position |
Using one generic template for every relationship type | Simplicity, but at the cost of relevance | Overbroad, hard to enforce, doesn't reflect actual information exposure |
No review cadence — the document is signed once and forgotten | No named owner, no calendar trigger | Content drifts out of alignment with the business; fails "regularly reviewed" |
Confusing confidentiality with non-compete | Templates bundle both without legal differentiation | Enforceability risk; non-compete restrictions can taint the whole document in some jurisdictions |
No survival clause | Overlooked as "obvious" | Obligation may be read as expiring with the relationship, defeating post-termination protection |
Visitors and short-term contractors excluded entirely | Perceived as low-risk or administratively inconvenient | Coverage gap explicitly within control 6.6's "other relevant interested parties" scope |
No central register — signed agreements scattered across departments | Ownership unclear between HR, legal, and procurement | Cannot produce evidence efficiently during audit; genuine gaps go undetected |
Supplier NDA not revisited as vendor access scope expands | Renewal treated as a formality | Confidentiality coverage lags actual data/system exposure |
Treating the NDA as a complete security control | Overreliance on a legal instrument | False sense of security; no technical backstop against actual exfiltration |
"Every one of those mistakes is fixable in under a quarter if someone owns it. The problem is never that it's hard. The problem is that it's nobody's explicit job until an audit finding — or a departing employee — makes it everyone's problem at once." — Dave Okonkwo, ISO 27001 Lead Implementer, Bellcrest Advisory
Case Study: The Contractor Gap at Vantage Ledger
I've already told you most of this story, but it's worth closing the loop on what changed. After the Ferrocode incident, Vantage Ledger rebuilt its confidentiality program around three changes: every contractor engaged through a staffing agency now signs a direct agreement with Vantage Ledger, not just the agency, before their first day of system access; the onboarding workflow in their HRIS was reconfigured so that access provisioning tickets are blocked without a recorded, dated signature; and offboarding now includes a signed exit acknowledgment specifically referencing continuing confidentiality obligations, tied to the return-of-assets checklist. Within eight months, during their first ISO 27001 Stage 2 audit, the auditor sampled twelve contractor files and found signed, correctly dated agreements in all twelve — a complete reversal from the gap that had cost the company $3.8 million the year before. Dave Kettering, now the company's champion for the control internally, still keeps a printed copy of Renata's file — empty of any signature — in a drawer as a reminder of what the gap actually looked like.
Case Study: The Stale Template at a Regional Health Network
A regional health network I worked with — I'll call it Meadowcrest Health Partners — had a confidentiality agreement program that looked complete on paper: every employee, contractor, and credentialed physician had a signed NDA on file, going back over a decade. The problem surfaced during an internal audit ahead of certification: the template hadn't been updated since 2016. It referenced "patient records," full stop, with no distinction between the paper charts the organization used at the time and the electronic health record system, telehealth platform, and three cloud-hosted analytics tools it now relied on. It said nothing about the categories of data those newer systems processed, and its duration clause predated the state's updated health data privacy statute by four years.
The internal audit didn't just flag a paperwork issue — it forced Meadowcrest to confront that a decade of "the NDA is signed" had created a false sense of coverage. The organization's legal and compliance teams spent six weeks rewriting the template to reflect current systems and current law, then ran a targeted re-signature campaign for the roughly 340 personnel and credentialed providers whose original agreement predated 2019, prioritized by access level. The certification body's Stage 2 auditor, briefed on the finding and the remediation, treated it as a well-managed minor nonconformity rather than a major one specifically because Meadowcrest could show the gap was self-identified through its own review process and closed with a documented corrective action — which is exactly the outcome you want a functioning "regularly reviewed" cycle to produce.
Case Study: The Supplier Scope Drift at a Logistics Platform
The third pattern worth walking through happened at a logistics and freight-matching platform working through supplier reviews as part of its ISMS maturation. A data enrichment vendor had signed a confidentiality agreement two years earlier when the relationship began, covering a narrow scope: aggregated, anonymized shipment volume data used for a single reporting dashboard. Over those two years, without anyone formally re-scoping the agreement, the integration had expanded organically — the vendor now had API access to customer contact details for a delivery-notification feature, added by an engineering team eager to ship a feature quickly and reasonably assuming legal had it covered.
The gap surfaced not through an incident but through the periodic supplier review cadence discussed earlier in this article, when a third-party risk analyst cross-referenced the vendor's actual API scopes against the confidentiality agreement's defined categories and found no overlap at all — the agreement, as written, said nothing about customer PII. The organization suspended the expanded data feed for eleven days while legal renegotiated the agreement to reflect actual current access, added explicit PII-handling and subprocessor flow-down language, and required the vendor to attest to deletion of any PII received outside the original scope. No breach occurred, no regulator inquiry followed, and the fix cost far less than a genuine incident would have — but it's a clean illustration of why control 5.22's ongoing monitoring of supplier services and control 6.6's review requirement need to run in sync rather than as two disconnected checklists.
Building the Business Case: Effort vs. Risk
Boards and budget owners sometimes push back on formalizing an NDA program as unnecessary legal overhead, especially at smaller organizations where "everyone knows everyone." The following framing has worked well in those conversations — it's not a universal cost model, just an illustrative way to size the effort against the exposure it addresses.
Organization Size | Illustrative Setup Effort | Illustrative Ongoing Effort | Primary Risk Addressed |
|---|---|---|---|
Under 50 people | 1–2 weeks: template drafting with counsel, onboarding workflow update | Annual review, roughly 1 day of combined HR/legal time | Founder and early-employee knowledge walking out the door with no legal recourse |
50–500 people | 4–8 weeks: tiered templates by relationship type, register build-out, contractor/agency remediation | Quarterly spot-checks, annual full review, roughly 3–5 days combined effort per year | Contractor and supplier gaps, exactly the pattern behind the Vantage Ledger and logistics platform case studies |
500+ people, multiple jurisdictions | 2–4 months: jurisdictional legal review, integration with HRIS/identity governance, supplier contract audit | Ongoing dedicated fraction of a GRC or legal FTE, continuous supplier review integration | Regulatory variance, M&A integration risk, scale of third-party relationships |
Against that effort, weigh the downside: a single incident like Vantage Ledger's cost more than a decade of ongoing program maintenance at any of these tiers combined. This isn't a hard sell once the numbers are framed side by side, and it's usually the fastest way to get budget released for what is, at its core, an unglamorous documentation exercise.
How 6.6 Relates to Other Frameworks You May Also Answer To
If your organization is pursuing or maintaining certifications beyond ISO 27001, control 6.6 isn't operating in a vacuum. SOC 2's confidentiality trust services criterion asks a closely related question — has the organization identified confidential information and applied controls, including agreements, to protect it — and a well-run 6.6 program gives you most of the evidence a SOC 2 auditor will want for that criterion, with only light adaptation for the different reporting format. Similarly, if personal data flows through relationships covered by your confidentiality agreements — contractors handling customer records, suppliers processing data on your behalf — those relationships increasingly need a GDPR-aligned data processing agreement alongside, not instead of, your confidentiality clause; the two documents serve different legal purposes even when they cover overlapping personnel and vendors. Building your NDA register with these adjacent obligations in mind from the start saves you from re-inventing the mapping exercise separately for each framework.
"The best sign that a confidentiality program is actually working is that nobody talks about it. It's just part of onboarding, part of offboarding, part of vendor setup — the same way locking your laptop is part of leaving your desk. The programs that fail are the ones where someone has to remember to think about it." — Elena Vasquez-Farro, VP of People Operations, Northgate Biotech
Confidentiality as a Trust Signal, Not Just a Compliance Line Item
It's worth zooming out before you close this document and go build (or rebuild) your NDA program. Control 6.6 gets treated, understandably, as one of the least exciting entries in Annex A — nobody gets excited about contract language the way they get excited about a new SIEM deployment or a slick access control rollout. But the organizations I've worked with that treat confidentiality agreements as a genuine trust signal, not just a box to check before an audit, get something out of it beyond certification: customers and partners in due diligence conversations notice when your confidentiality program is specific, current, and consistently enforced rather than a dusty template nobody's touched since incorporation. In competitive procurement processes — especially with enterprise customers who run their own vendor security assessments — a well-documented, well-evidenced control 6.6 answers a question that comes up in nearly every serious security questionnaire, and answering it cleanly, with real evidence rather than a vague assurance, shortens sales cycles more often than people expect.
That's the reframe I'd leave you with: this control isn't just about surviving an auditor's sample test, though it needs to survive that too. It's about being able to say, with a straight face and a signed document to back it up, exactly what you promised to protect, who promised to protect it, and what happens if that promise is broken — for every employee, every contractor, every supplier, and every visitor who's ever seen something they shouldn't repeat.
If you're building or repairing this program from scratch, don't try to solve every jurisdiction, every relationship type, and every legacy gap in one sprint. Start with the register — know who should have signed what — because that single artifact, more than any clause-drafting exercise, is what turns control 6.6 from an assumption into an evidenced, auditable program.
To move from framework to finished documents, PentesterWorld's Information Security Policy Template gives you a starting structure that references confidentiality obligations consistently across your broader policy set, and the ISO 27001 Mandatory Documents Checklist will confirm you haven't missed a related documentation requirement elsewhere in your ISMS. If you're earlier in the journey and still mapping how all 93 controls fit together, the Annex A — All 93 Controls at a Glance cheat sheet and The Complete ISO 27001 Implementation Guide eBook are the fastest way to see where control 6.6 sits in the bigger picture — and our ISO 27001 Glossary of Terms is a quick reference if any of the legal or audit terminology in this article needs unpacking for your team.