What is ISO 27001 Annex A 6.6 – Confidentiality or Non-Disclosure Agreements?
ISO 27001 Annex A 6.6 requires organizations to identify, document, regularly review, and require appropriate confidentiality or non-disclosure agreements (NDAs) that reflect the organization’s information security needs.
In simple terms, an organization should make sure that people and organizations who receive access to confidential or sensitive information understand that they must protect that information.
This can apply to:
- Employees
- Contractors
- Consultants
- Temporary workers
- Suppliers
- Service providers
- Partners
- External auditors
- Developers
- Freelancers
- Other third parties who may access confidential information
Simple Explanation
If you give someone access to confidential information, make sure there is a clear and appropriate obligation to protect it.
An NDA is not simply a document to satisfy an auditor. It should establish clear expectations about what information must remain confidential, how it may be used, who may receive it, and what happens when the relationship ends.
Why is Annex A 6.6 Important?
Organizations routinely share information with employees, vendors, customers, consultants, and business partners.
That information may include:
- Customer data
- Personally identifiable information (PII)
- Source code
- Product designs
- Security architecture
- Credentials or authentication information
- Business plans
- Financial information
- Pricing information
- Contracts
- Audit reports
- Vulnerability information
- Security incidents
- Intellectual property
- Trade secrets
- Internal policies and procedures
Without appropriate confidentiality obligations, there may be uncertainty about what information a person is allowed to disclose or use.
Risks without appropriate confidentiality agreements
An organization may face:
- Unauthorized disclosure of customer information
- Leakage of source code
- Exposure of business plans
- Disclosure of security information
- Misuse of intellectual property
- Uncontrolled sharing with third parties
- Confidential information being retained after a relationship ends
- Disputes about confidentiality obligations
- Contractual or regulatory problems
Simple Principle
Confidential information should have clear protection requirements before it is shared.
What Does ISO 27001 Annex A 6.6 Require?
The control expects organizations to have appropriate confidentiality or non-disclosure agreements based on their information security requirements.
The agreement should be appropriate to:
- The type of information being accessed
- The relationship with the individual or organization
- The level of information security risk
- Applicable legal and regulatory requirements
- Contractual requirements
- Customer requirements
- The organization’s information classification scheme
The organization should also periodically review confidentiality requirements to ensure they remain relevant.
An organization does not necessarily need one identical NDA for every person.
A startup may have different agreements for:
| Relationship | Possible Agreement |
|---|---|
| Employee | Employment confidentiality clause / NDA |
| Contractor | Contractor NDA |
| Freelancer | Confidentiality clause / NDA |
| Vendor | Supplier NDA |
| Strategic partner | Mutual NDA |
| Customer | Customer agreement / confidentiality clause |
| Consultant | Consultant NDA |
| Auditor | Confidentiality agreement |
| Investor | NDA where appropriate |
| Temporary worker | Temporary worker NDA |
The exact legal form should be determined according to the relationship and applicable law.
What Should a Confidentiality Agreement Cover?
An effective confidentiality agreement should clearly define the organization’s expectations.
Depending on the relationship, it may address:
1. Definition of Confidential Information
Define what information is considered confidential.
Examples:
- Customer information
- Source code
- Product information
- Security information
- Business plans
- Financial information
- Personal data
- Internal documentation
- Intellectual property
- Credentials or security-related information
The definition should be practical and appropriate to the relationship.
2. Purpose of Information Use
The agreement can specify that confidential information may only be used for authorized business purposes.
For example:
A contractor receives access to source code to perform software development work.
The contractor should not use that source code for another client or personal project.
3. Disclosure Restrictions
The agreement should establish when information may or may not be disclosed.
For example:
- No unauthorized disclosure
- No sharing with unauthorized third parties
- Disclosure only to authorized personnel
- Legal disclosure requirements handled appropriately
4. Information Protection Responsibilities
The agreement may require appropriate safeguards such as:
- Secure storage
- Access restrictions
- Password protection
- Encryption where appropriate
- Secure transmission
- Prevention of unauthorized copying
- Protection against unauthorized access
5. Third-Party Disclosure
Where applicable, the agreement should address whether confidential information may be shared with subcontractors or other third parties.
For example:
A software development vendor should not automatically provide MAE’s confidential information to another subcontractor without authorization.
6. Return or Destruction of Information
The agreement should address what happens when the relationship ends.
Depending on the circumstances, the person or organization may need to:
- Return confidential documents
- Delete electronic copies
- Return company devices
- Remove local copies
- Delete credentials or access tokens
- Confirm destruction where appropriate
This should align with legal, contractual, retention, and backup requirements.
7. Continuing Confidentiality Obligations
Some confidentiality responsibilities may continue after:
- Employment ends
- A contract expires
- A project finishes
- A supplier relationship ends
- A consultant leaves
The organization should clearly define applicable continuing obligations.
8. Exceptions
Confidentiality agreements commonly need to address information that is:
- Already publicly available
- Independently developed
- Already lawfully known
- Required to be disclosed by law or regulation
The exact wording should be reviewed by appropriate legal professionals.
Confidentiality vs. NDA
The terms confidentiality agreement and NDA (Non-Disclosure Agreement) are often used interchangeably, but the important ISO 27001 consideration is not the document’s title.
The important question is:
Does the agreement establish appropriate information security and confidentiality obligations for the relationship?
For example, confidentiality requirements may be incorporated directly into an employment contract instead of having a separate NDA.
Therefore:
NDA ≠ necessarily separate document
An organization can satisfy the control through appropriate contractual clauses, agreements, policies, or combinations of these where they establish the required obligations.
Activities Required to Implement Annex A 6.6
Step 1: Identify Relationships That Require Confidentiality Obligations
Create a list of relationships that may access confidential information.
For example:
- Employees
- Contractors
- Vendors
- Consultants
- Partners
- Auditors
- Temporary workers
Step 2: Identify the Information They Can Access
Map relationships to information.
For example:
| Role | Information Access | Confidentiality Requirement |
|---|---|---|
| Developer | Source code | High |
| HR employee | Employee PII | High |
| Finance employee | Financial information | High |
| Marketing employee | Public campaign material | Lower |
| Cloud administrator | Production systems | High |
| External consultant | Project information | Medium/High |
| Cleaning contractor | Limited physical access | Appropriate contractual requirements |
This helps avoid using an unnecessarily broad or inappropriate approach.
Step 3: Define Confidentiality Requirements
Determine:
- What information must be protected?
- Who can access it?
- How can it be used?
- Who can it be shared with?
- What security requirements apply?
- What happens when the relationship ends?
- How long do obligations continue where applicable?
Step 4: Create Appropriate Agreement Templates
Maintain appropriate templates for different relationships.
For example:
- Employee NDA
- Contractor NDA
- Supplier NDA
- Mutual NDA
- Consultant NDA
- Partner Confidentiality Agreement
Avoid using one generic agreement for every situation if the risks and relationships are materially different.
Step 5: Include Confidentiality Requirements in Onboarding
Confidentiality should be addressed before or as part of granting access to sensitive information.
A typical workflow is:
Offer / Contract → NDA / Confidentiality Clause → Policy Acknowledgement → Training → Access Provisioning
Step 6: Include Requirements in Supplier Management
Where third parties have access to confidential information, confidentiality requirements should be considered during supplier onboarding and contracting.
This connects A.6.6 with:
- A.5.19 Information Security in Supplier Relationships
- A.5.20 Information Security Within Supplier Agreements
- A.5.21 ICT Supply Chain Security
Step 7: Review Agreements Periodically
Confidentiality requirements may need to change when:
- Job responsibilities change
- New sensitive information is introduced
- A supplier’s scope changes
- New regulations apply
- Customer requirements change
- The organization changes its information classification
- A new type of third party receives access
Step 8: Manage Confidentiality During Offboarding
When an employee or contractor leaves:
- Remind them of continuing obligations where applicable
- Recover company assets
- Revoke access
- Handle confidential information
- Address return/deletion requirements
- Document completion where appropriate
This connects A.6.6 with Annex A 6.5.
Startup Example
Consider a 35-person SaaS startup.
The company has:
- Customer databases
- Source code
- AWS infrastructure
- Product roadmap
- Security documentation
- Customer contracts
- Employee information
The company hires a freelance developer.
The developer requires access to:
- Git repository
- Development environment
- Project documentation
- Limited customer-related technical information
Before granting access:
Contract → NDA / Confidentiality Clause → Security Responsibilities → Security Training → Access Provisioning
The NDA establishes requirements around:
- Source code confidentiality
- Customer information
- Security information
- Authorized use
- Disclosure restrictions
- Return/deletion where applicable
- Continuing confidentiality obligations
The startup retains evidence that the agreement was completed.
What an auditor may verify
The auditor could select a sample of employees and contractors and ask:
“Show me evidence that confidentiality obligations were established before this person received access to confidential information.”
The startup should be able to provide appropriate evidence without exposing unnecessary confidential or personal information.
Startup-Focused Quick Summary
A startup does not need a complicated legal system to implement A.6.6 effectively.
A practical approach is:
1. Identify
Who receives confidential information?
2. Classify
What type of confidential information can they access?
3. Define
What confidentiality obligations are required?
4. Document
Use an appropriate NDA, employment clause, supplier agreement, or other contractual mechanism.
5. Communicate
Make the individual or organization aware of the obligations.
6. Control
Ensure access is consistent with the relationship and authorization.
7. Review
Update requirements when roles, risks, or relationships change.
8. Offboard
Address continuing obligations, return, deletion, and access termination when the relationship ends.
Confidentiality Agreement Matrix
A startup can maintain a simple matrix such as:
| Relationship | NDA / Confidentiality Required | Agreement Type | Review Trigger |
|---|---|---|---|
| Employee | Yes, where applicable | Employment clause / NDA | Role change |
| Developer | Yes | Employment/Contractor NDA | Role/access change |
| System Administrator | Yes | Employment clause / NDA | Privilege change |
| Freelancer | Yes | Contractor NDA | Project change |
| Supplier | Based on access | Supplier agreement/NDA | Scope change |
| Consultant | Yes, where applicable | Consultant NDA | Engagement change |
| Auditor | Appropriate confidentiality terms | Engagement agreement/NDA | Engagement change |
| Strategic Partner | Based on information shared | Mutual NDA | Relationship change |
The matrix should be tailored to the organization’s actual legal and business requirements.
Confidentiality Lifecycle
A practical lifecycle is:
Identify Relationship
↓
Identify Information
↓
Assess Confidentiality Requirements
↓
Select Appropriate Agreement
↓
Execute Agreement
↓
Communicate Responsibilities
↓
Grant Appropriate Access
↓
Monitor / Review
↓
Role Change or Contract Change
↓
Update Requirements
↓
Offboarding / Contract Closure
↓
Return / Delete Information Where Required
↓
Continue Applicable Confidentiality Obligations
Audit Evidence for Annex A 6.6
An auditor may request evidence such as:
Policies and Procedures
- Information Security Policy
- Confidentiality Policy
- Employee Security Policy
- HR Security Procedure
- Supplier Security Procedure
- NDA Management Procedure
- Contract Management Procedure
- Offboarding Procedure
Agreements
- Employee confidentiality clauses
- Employee NDAs
- Contractor NDAs
- Supplier agreements
- Consultant agreements
- Partner agreements
- Confidentiality clauses in customer/vendor contracts
Operational Evidence
- NDA execution records
- Contract approval records
- Confidentiality acknowledgement
- Onboarding checklist
- Supplier onboarding checklist
- Contractor onboarding records
- Role change records
- Offboarding records
- Return/deletion confirmations where applicable
- NDA review records
Supporting Evidence
- Information classification policy
- Confidential information classification
- Supplier risk assessment
- Access control records
- Security awareness training
- Employment terms
- Legal/regulatory requirements
Audit Checklist for Annex A 6.6
| Audit Question | Evidence |
|---|---|
| Are confidentiality requirements defined? | Policy / procedure |
| Are relevant personnel covered? | Employee/contractor records |
| Are contractors covered where appropriate? | Contractor agreements |
| Are suppliers covered where required? | Supplier contracts |
| Are confidential information requirements identified? | Classification / risk assessment |
| Are NDAs or confidentiality clauses appropriate to the relationship? | Agreement samples |
| Are confidentiality obligations communicated? | Signed agreement / acknowledgement |
| Are security responsibilities included where appropriate? | NDA / contract |
| Are disclosure restrictions defined? | NDA |
| Are information return/deletion requirements addressed? | Contract / offboarding procedure |
| Are continuing obligations addressed where applicable? | NDA / employment terms |
| Are agreements reviewed when circumstances change? | Review records |
| Are agreements properly maintained? | Contract register |
| Are confidentiality requirements connected to supplier management? | Supplier records |
| Are confidentiality obligations addressed during offboarding? | Exit checklist |
Common Mistakes
1. Treating NDA as a One-Time Document
Signing an NDA is not the entire control.
The organization should also consider whether confidentiality requirements remain appropriate when circumstances change.
2. Using the Same NDA for Everyone
An employee, cloud provider, auditor, and software developer may have very different information access and contractual relationships.
The agreement should be appropriate to the relationship.
3. Ignoring Contractors
Startups frequently use:
- Freelancers
- Consultants
- Developers
- Marketing agencies
- IT support companies
They may have significant access to sensitive information.
4. Giving Access Before the Agreement Is Completed
A common weakness is:
Access → NDA
instead of:
Appropriate Agreement → Security Requirements → Access
Where appropriate and legally feasible, confidentiality obligations should be established before sensitive information is shared.
5. Not Covering Continuing Obligations
A person may leave the company but still have confidentiality obligations relating to information obtained during the relationship.
The organization should clearly address applicable continuing obligations.
6. Ignoring Suppliers
A SaaS startup may share sensitive information with:
- Cloud providers
- MSPs
- IT vendors
- Security consultants
- Auditors
- Payroll providers
- Marketing agencies
Confidentiality requirements should be considered as part of supplier security management.
7. Keeping NDA Records Poorly
The organization may have signed NDAs but be unable to demonstrate:
- Who signed
- When they signed
- Which version applied
- Whether the agreement is still applicable
- Whether a new agreement was required after a change
8. Confusing NDA With Access Control
An NDA does not replace technical security controls.
For example:
An NDA does not justify giving a contractor unrestricted production access.
The NDA establishes confidentiality obligations.
Access controls determine what the person can actually access.
Practical Startup Implementation Model
A startup can implement A.6.6 using the following model:
Identify
Identify people and organizations receiving confidential information.
Classify
Identify the sensitivity of the information.
Assess
Determine the confidentiality requirements.
Document
Use the appropriate NDA, contract clause, or agreement.
Communicate
Ensure obligations are understood.
Control
Apply appropriate access controls.
Review
Review obligations when relationships or access change.
Offboard
Handle information return, deletion, access removal, and continuing obligations.
Evidence
Maintain sufficient records to demonstrate implementation.
Improve
Update templates and processes based on incidents, new risks, contractual requirements, or organizational changes.
Policy vs. Process vs. Evidence
It is useful to distinguish these three layers.
| Layer | Example |
|---|---|
| Policy | Organization requires confidential information to be protected |
| Procedure | HR/Security determines when an NDA or confidentiality clause is required |
| Agreement | Employee/contractor/supplier agrees to confidentiality obligations |
| Evidence | Signed agreement and execution record |
| Technical Control | Access restrictions prevent unauthorized access |
| Offboarding | Confidential information and access are handled when relationship ends |
A common audit weakness is having the policy and NDA template but no evidence that the process actually operated.
Relationship With Other ISO 27001 Controls
A.6.6 works closely with several other Annex A controls.
A.6.1 – Screening
Screening occurs before or during engagement.
A.6.6 establishes confidentiality obligations.
A.6.2 – Terms and Conditions of Employment
A.6.2 establishes security responsibilities within the employment relationship.
A.6.6 focuses specifically on confidentiality and non-disclosure requirements.
A.6.5 – Responsibilities After Termination or Change of Employment
A.6.5 ensures relevant security responsibilities continue to be managed after termination or role changes.
This can include continuing confidentiality obligations.
A.5.12 – Classification of Information
Classification helps determine what information requires stronger confidentiality protection.
A.5.15 – Access Control
The NDA does not replace access control.
Access should still be limited according to business need and authorization.
A.5.19 – Information Security in Supplier Relationships
Third-party confidentiality requirements should be considered when managing suppliers.
A.5.20 – Information Security Within Supplier Agreements
Supplier contracts can contain confidentiality and information security requirements.
A.5.32 – Intellectual Property Rights
Confidentiality can help protect intellectual property, while A.5.32 addresses broader IP rights and obligations.
A.5.34 – Privacy and Protection of PII
Where confidential information includes personal data, privacy requirements must also be addressed.
A.6.6 vs. A.6.2 vs. A.6.5
These controls are closely connected but have different purposes.
| Control | Main Question |
|---|---|
| A.6.2 | Have security responsibilities been established as part of the employment relationship? |
| A.6.6 | Are appropriate confidentiality/non-disclosure obligations established? |
| A.6.5 | Are security responsibilities properly managed after termination or employment changes? |
For example:
Employee joins
→ A.6.1 Screening
→ A.6.2 Employment Security Responsibilities
→ A.6.6 Confidentiality Obligations
→ A.6.3 Security Training
→ Access Provisioning
Employee leaves
→ A.6.5 Continuing Responsibilities
→ Access Revocation
→ Asset Return
→ Confidentiality Obligations Continue Where Applicable
Useful Documents and Resources
A startup implementing A.6.6 may maintain:
- Confidentiality and Non-Disclosure Policy
[Insert Draft Document Link] - Employee NDA Template
[Insert Draft Document Link] - Contractor NDA Template
[Insert Draft Document Link] - Supplier Confidentiality Agreement
[Insert Draft Document Link] - Mutual NDA Template
[Insert Draft Document Link] - Confidentiality Requirements Matrix
[Insert Draft Document Link] - NDA and Confidentiality Agreement Register
[Insert Draft Document Link] - Employee Confidentiality Acknowledgement
[Insert Draft Document Link] - Contractor Onboarding Security Checklist
[Insert Draft Document Link] - Confidentiality Review Checklist
[Insert Draft Document Link] - Offboarding Confidentiality Checklist
[Insert Draft Document Link] - Supplier Contract Security Checklist
[Insert Draft Document Link] - Personnel Security Audit Checklist
[Insert Draft Document Link]
Important: NDA and contractual language should be reviewed for the organization’s applicable jurisdiction, industry, regulatory requirements, and specific relationship. ISO 27001 does not prescribe one universal NDA template.
Questions an Auditor May Ask
An auditor may ask:
“Who is required to sign an NDA?”
The organization should be able to explain its criteria based on role, relationship, information access, risk, and contractual requirements.
“Show me an example for an employee.”
Provide an appropriate employment agreement or NDA.
“What about contractors?”
Demonstrate that contractors are covered where appropriate.
“What about suppliers?”
Show how confidentiality requirements are addressed in supplier agreements.
“How do you determine what confidentiality requirements are needed?”
Show the relationship between information classification, risk, role, contractual requirements, and agreement requirements.
“What happens when an employee leaves?”
Demonstrate the offboarding process and how continuing confidentiality obligations are communicated where applicable.
“How do you know the NDA is current?”
Show agreement/version management and review processes.
“Does the NDA replace access controls?”
The answer should be no.
Confidentiality agreements are contractual/organizational controls. Access controls are technical and organizational controls that restrict actual access.
Startup-Focused Final Takeaway
Annex A 6.6 is fundamentally about making confidentiality expectations clear before sensitive information is shared.
A practical startup approach is:
Identify who receives confidential information
↓
Understand what information they can access
↓
Determine appropriate confidentiality requirements
↓
Use the appropriate NDA or contractual clause
↓
Communicate the obligations
↓
Grant access according to authorization
↓
Review when roles or relationships change
↓
Address continuing obligations during offboarding
The key audit question is:
Can we demonstrate that people and organizations who receive our confidential information have appropriate, documented confidentiality obligations?
For a startup, the goal should not be to create a large collection of legal documents simply for ISO 27001.
The goal is to establish a simple, risk-based and consistently operated confidentiality process that protects customer information, intellectual property, source code, business information, security information, and other sensitive information throughout the relationship lifecycle.