A.6.6 and A.6.7 — NDAs and Remote Working Security

A.6.6 and A.6.7 — NDAs and Remote Working Security

A.6.6 and A.6.7 — NDAs and Remote Working Security: The Foundation Most Organizations Get Wrong

Every organization I audit tells me they "take confidentiality seriously" and have "robust remote working policies." Then I ask to see their NDA register, and they look at me like I've asked for their childhood diary. I request evidence of remote working security controls, and someone emails me a two-page work-from-home policy that was written in 2019 and updated once — to change the company logo.

Controls A.6.6 (Confidentiality or non-disclosure agreements) and A.6.7 (Remote working) aren't glamorous. They don't involve fancy technical controls or expensive tooling. But they're the contractual and operational backbone of how organizations protect information when it leaves the controlled office environment — whether that's through the minds of employees and contractors, or through the laptops they're using at coffee shops and kitchen tables.

Let me break down what these controls actually require, where organizations consistently get them wrong, and how to implement them in ways that actually protect your information rather than just checking boxes.

A.6.6 — Confidentiality or Non-Disclosure Agreements: More Than Legal Boilerplate

The control requires that confidentiality or non-disclosure agreements "reflecting the organization's needs for the protection of information should be identified, documented, regularly reviewed and signed by personnel and other relevant interested parties." Notice the language: reflecting the organization's needs. This isn't about downloading a template NDA from the internet and having everyone sign it.

What Your NDAs Should Actually Address

Most NDAs I review during audits are laughably generic. They protect "confidential information" without defining what that means in the organization's context. Here's what robust NDAs should address, aligned with the ten elements specified in ISO 27002:

  • Clear definition of protected information — Reference your information classification scheme from Control A.5.12 (Classification of information). If someone signs an NDA but doesn't know what "Restricted" versus "Confidential" means in your organization, the agreement is toothless.
  • Duration of obligations — Some information loses sensitivity over time. Other information (trade secrets, personal data under GDPR) requires protection indefinitely. Your NDAs should distinguish between these scenarios.
  • Required actions at termination — What happens to confidential information when employment ends? Return physical documents? Destroy electronic copies? Provide certification of destruction?
  • Notification requirements for breaches — Not just "tell us if there's a breach" but specific timelines and cooperation requirements that align with your incident response procedures under Control A.5.26.
  • Ownership and intellectual property rights — Particularly critical for organizations developing proprietary solutions or handling customer data.
  • Permitted use and access rights — What can they actually do with the information? This should align with your access control policies.

The NDA Register: Where Organizations Consistently Fail

I audited a software development company with 200 employees and 50 active contractors. When I asked for their NDA register, they produced an Excel spreadsheet with 47 entries — all employees from the initial company formation. Nobody had tracked NDAs for the past four years of growth.

They had contractors with access to source code who had never signed an NDA. They had employees in sensitive roles whose NDAs predated the company's pivot to handling healthcare data and were therefore inadequate under ISO 27018 (protection of personally identifiable information). The NDAs referenced an information classification policy that no longer existed.

Your NDA register should track:

  • Who signed which version of the agreement, and when
  • What information classifications they have or had access to
  • Renewal or review dates for time-limited agreements
  • Status of ongoing obligations after relationship termination
  • Linkage to your access control matrix from Control A.5.15 (Access control)

This isn't bureaucracy for its own sake. Without this register, you can't answer basic audit questions: Who needs updated NDAs when your classification scheme changes? Which former contractors still have confidentiality obligations? Who needs notification when sensitive project information is compromised?

A.6.7 — Remote Working: Beyond the Kitchen Table Policy

The remote working control requires that "security measures should be implemented when personnel are working remotely to protect information accessed, processed or stored outside the organization's premises." The guidance in ISO 27002 covers eleven specific areas that organizations must consider.

Physical Security of Remote Sites

Most remote working policies I review say something like "ensure you work in a secure location." But what does that mean? The standard requires assessment of "the physical security of the location and the local environment, including the different jurisdictions where personnel are located."

I audited a financial services firm where employees regularly worked from vacation rentals in different countries. Their policy didn't address the fact that vacation rental WiFi networks are often unsecured, that some countries have mandatory data retention laws, or that hotel business centers represent significant confidentiality risks.

Your policy should address:

  • Acceptable locations — Home offices? Coffee shops? Client sites? Vacation rentals? Each carries different risks.
  • Physical security requirements — Lockable storage for documents and devices, privacy screens for laptops, restrictions on printing sensitive information.
  • Environmental considerations — Protection from shoulder surfing, secure disposal of printed materials, rules about discussing confidential matters over calls.
  • Cross-border considerations — For organizations operating internationally, this links to ISO 27036 (supplier relationship security) when considering cloud services accessed from different jurisdictions.

Technical Controls and Network Security

The standard explicitly requires consideration of "communications security requirements" and "the use of home networks and public networks." This isn't optional guidance — these are implementation requirements.

A common mistake I see is organizations that require VPN use but don't specify what happens before the VPN connects. If someone opens Outlook while connected to hotel WiFi before the VPN establishes, their email synchronizes over an unsecured connection.

Technical requirements should include:

  • Always-on VPN or virtual desktop solutions that prevent any data transmission outside secure channels
  • Endpoint protection requirements including firewall configuration and malware protection, aligned with Control A.8.7 (Protection against malware)
  • Multi-factor authentication for all remote access, addressing the standard's note about "vulnerability of single-factor authentication mechanisms"
  • Device management capabilities including remote wipe, location tracking, and automated screen locks

The Equipment and Asset Management Challenge

One of the most overlooked aspects of remote working security is asset management. The standard requires consideration of "provision of suitable equipment and storage furniture" and "revocation of authority and access rights and the return of equipment when remote working activities are terminated."

I've seen organizations where 40% of remote workers use personal devices that IT has never inventoried. When someone leaves, there's no process to ensure company data is removed from personal equipment or that access to company systems is properly revoked.

This links directly to Control A.5.9 (Inventory of information and other associated assets) and requires:

  • Asset registers that include all remote working equipment, whether company-owned or BYOD
  • Classification of information permitted on personal devices
  • Technical controls to separate company and personal data
  • Clear procedures for asset return and data removal at termination

What the Auditor Looks For

During an audit, I'm looking for specific evidence that these controls are implemented effectively, not just documented:

For A.6.6 (NDAs):

  • Current NDA register showing all personnel and relevant external parties
  • NDA templates that reference your actual information classification scheme
  • Evidence of regular review — meeting minutes, updated versions, change logs
  • Terminated relationship tracking — how you ensure ongoing obligations are understood and monitored
  • Integration with HR processes — new hire checklists, termination procedures

For A.6.7 (Remote Working):

  • Comprehensive remote working policy addressing all eleven areas from the standard
  • Technical implementation evidence — VPN logs, endpoint protection reports, device inventory
  • Training records for remote workers and support staff
  • Regular security assessments of remote working arrangements
  • Incident reports related to remote working security failures and lessons learned

Integration with Other Controls

These controls don't operate in isolation. Effective implementation requires integration with:

  • A.5.1 (Information security policies) — Your remote working policy should be part of your overall information security policy framework
  • A.5.16 (Identity management) — Remote access requires robust identity and access management
  • A.6.4 (Privacy and protection of personally identifiable information) — Remote processing of personal data has additional requirements under privacy regulations
  • A.8.33 (Application programming interfaces) — If remote workers access cloud services, API security becomes critical

For organizations using cloud services for remote working, ISO 27017 (cloud services security) provides additional guidance on shared responsibility models and cloud-specific security controls.

Common Implementation Mistakes

Based on hundreds of audits, here are the mistakes I see repeatedly:

The "Set and Forget" NDA: Organizations create NDAs once and never update them. When they pivot to handling new types of sensitive data, expand internationally, or change their information classification scheme, the NDAs become inadequate.

The "WiFi is Fine" Remote Policy: Policies that don't distinguish between secured home networks and public WiFi, treating all remote locations as equivalent risks.

The "Trust but Don't Verify" Approach: Organizations that require certain remote working behaviors but never audit compliance or provide tools to make compliance easy.

Pro tip: The most effective remote working policies I've seen include specific tools and resources to make secure remote working easier than insecure alternatives. If your VPN is slower and more difficult to use than working without it, compliance will be poor regardless of policy requirements.

Remember, these controls form the foundation of how your organization protects information outside your direct physical control. Get them right, and you have a solid basis for secure operations. Get them wrong, and even the most sophisticated technical controls won't protect you from fundamental human and process failures.

For more detailed guidance on implementing these controls in your specific environment, consider consulting with experienced practitioners who can help you navigate the complexities of your particular risk landscape. You can also find additional resources and discussion on practical ISO 27001 implementation at the IX ISO 27001 Info Hub.

Need personalized guidance? Reach our team at ix@isegrim-x.com.


Related Articles

Read more

ISO 27001 and Zero Trust Architecture — Modern Security Meets Compliance

ISO 27001 and Zero Trust Architecture — Modern Security Meets Compliance

Executive Summary: * Architecture-Documentation Alignment: Zero Trust implementations fail audit when security architecture shifts to identity-centric models but ISMS documentation still describes perimeter-based controls * Multi-Framework Convergence: Zero Trust principles naturally align with ISO 27001's risk-based approach and map directly to NIST CSF, CMMC, and TISAX requirements—creating implementation synergies