Confidentiality or non-disclosure agreements

Confidentiality and non-disclosure agreements (NDAs) are easy to treat as a generic HR legal form. Under ISO/IEC 27018:2019 Annex A.11.1, they are an access control prerequisite for public cloud PII processors. The requirement is narrow but operationally strict: if a person can access PII in your cloud service, that person must be subject to a confidentiality obligation. That means you need a defined population, a binding instrument, and a way to prove coverage continuously as roles and systems change.

For a CCO, compliance officer, or GRC lead, the fastest route to operationalizing this requirement is to treat it like an access-gating control with evidence: no confidentiality obligation on file, no PII access. Done well, this becomes a stable control that supports audits, reduces insider-risk exposure, and prevents “shadow access” by contractors or support staff who were never properly onboarded.

This page gives requirement-level guidance: who is in scope, what the obligation must cover, how to implement it in HR/IT workflows, and what evidence you should retain to survive audits without scrambling.

Regulatory text

Requirement (excerpt): “Individuals under the control of the public cloud PII processor with access to PII shall be subject to a confidentiality obligation.” ¹

Operator meaning: if you operate a public cloud service as a PII processor, you must bind every person you control who can access PII to confidentiality terms. “Subject to” is the key phrase: the obligation must apply to them as a condition of their work, and it must remain enforceable through their access period and after they leave, where appropriate.

Plain-English interpretation (what the control is really asking)

This requirement expects three things:

1. A complete inventory of people with PII access under your control. This includes employees and contractors, but also less-obvious groups like temporary staff, interns, onsite engineers, support agents, and certain outsourced roles if you direct their work and grant access.
2. A written confidentiality obligation that covers PII. A generic NDA can work if it explicitly covers personal data/PII and improper use or disclosure, not just “company confidential information.”
3. A repeatable mechanism to enforce “signed before access” and prove it later. Auditors won’t accept “HR has them somewhere.” They will ask you to show coverage for a sample of PII-access users and demonstrate no gaps.

Who it applies to (entity + operational context)

In-scope entities

• Cloud Service Providers acting as public cloud PII processors ¹

In-scope individuals (“under your control”)

Treat these as in scope if they can access PII in systems you operate:

• Employees (full-time and part-time)
• Contractors and consultants working under your direction
• Temporary staff, interns, apprentices
• Privileged admins (SRE, DBAs, security engineers)
• Customer support and incident response staff with production access
• Certain third-party personnel if you provision accounts, assign tasks, and manage their access as if they were internal

Practical rule: if you can disable their access, you control the access. If you control the access and the access includes PII, you need a confidentiality obligation on file.

What you actually need to do (step-by-step)

1) Define the scope and the “PII access” threshold

• Document what counts as PII in your environment (align to your data classification).
• Define what counts as “access”: production database access, support tooling that displays user records, log access with identifiers, export permissions, admin console views, backup restore permissions.
• Map systems where PII lives or can be derived (including support tools and observability platforms).

Output: a short “PII access definition” and a list of in-scope systems.

2) Build the in-scope population list

• Pull a list of identities with access to in-scope systems (IAM groups/roles, ticketing-approved access lists, PAM vault users).
• Enrich the list with HR/contractor metadata: worker type, manager, start date, end date, location, employing entity.
• Identify edge cases: shared accounts, break-glass accounts, vendor-managed support accounts.

Output: “PII Access Roster” (name/ID, role, access type, system, start date, manager, confidentiality obligation status).

3) Standardize the confidentiality obligation language (and make it PII-specific)

Work with legal/HR to ensure your template covers:

• Confidentiality duty covering PII and customer data, not only trade secrets
• Permitted use boundaries (access only for authorized business purposes)
• Prohibition on unauthorized disclosure, copying, or personal use
• Data handling expectations (secure storage, no unapproved transfers)
• Incident reporting duty (report suspected exposure promptly through defined channels)
• Survival/continuing obligations after termination, as appropriate
• Acknowledgement of monitoring and acceptable use, if your environment relies on those controls

Tip: Keep one “master” template for employees and one for contractors, but make the PII clause consistent.

4) Implement “signed before access” gating in onboarding

• Add a mandatory onboarding step: confidentiality agreement executed before provisioning PII access.
• Tie access requests to an HR/compliance check (automated if possible): request cannot be approved unless the agreement status is “complete.”
• For emergency access, require a time-bound exception approval and a rapid retroactive signature workflow, then track it as a control deviation.

Evidence goal: for any sampled user, you can show signature date precedes first PII access date.

5) Extend the control to role changes and privilege escalation

• Add a trigger for internal transfers and privilege elevation (e.g., engineer becomes on-call with production access).
• Confirm the existing agreement covers the new level of access and PII exposure.
• If your agreement is role-neutral, this is a check-box; if role-specific, issue an addendum.

6) Operationalize offboarding and post-termination obligations

• Ensure offboarding includes immediate access removal and asset return.
• Preserve executed agreements after termination in a retrievable repository, because audits may sample former staff who had access.

7) Run periodic completeness checks (coverage assurance)

• Reconcile access rosters against executed agreement records.
• Investigate mismatches: orphaned accounts, contractor conversions, expired contracts, missing signatures.
• Document remediation actions and prevent recurrence (process fix, not just one-off cleanup).

Where Daydream fits naturally: Daydream can act as the system of record for third-party due diligence and workforce compliance evidence by centralizing executed agreements, mapping them to access rosters, and producing audit-ready exports without chasing HR, IT, and procurement separately.

Required evidence and artifacts to retain

Maintain artifacts that let you prove coverage, timing, and enforceability:

Core artifacts

• Executed confidentiality/NDA agreements (signed copies) for all in-scope individuals
• Standard templates and version history (so you can show what terms applied at the time)
• PII access roster and system access lists (from IAM/PAM/ticketing)
• Onboarding and access provisioning procedures showing “signed before access”
• Exception records (emergency access approvals, deviations, remediation)
• Offboarding checklist records and access revocation evidence (especially for privileged users)

Operational evidence

• Access request tickets tied to agreement status checks
• Periodic reconciliation reports (access vs. agreements) and remediation logs

Common exam/audit questions and hangups

Auditors and assessors usually probe for these issues:

1. “Show me everyone with production PII access and their NDA status.” Hangup: you can’t produce a single list, or the list excludes contractors.
2. “Was the agreement signed before access was granted?” Hangup: signature dates are missing or stored in a system that doesn’t preserve timestamps.
3. “Does the agreement explicitly cover PII and customer data?” Hangup: NDA only references “confidential business information,” with no data protection duty.
4. “What about outsourced support or third-party operators?” Hangup: the organization assumes the third party “handles their own HR,” but you actually provision the access, so you need to confirm obligations exist and are enforceable in your operating model.
5. “How do you handle break-glass access?” Hangup: no documented exception path, no after-action review, no proof the user was already bound.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Treating confidentiality agreements as HR-only paperwork.
  Fix: make NDA status an access control dependency for PII systems.

• Mistake: Excluding contractors because “procurement owns them.”
  Fix: define the in-scope population by access, then assign ownership for each worker type.

• Mistake: Using a generic NDA that never mentions PII.
  Fix: add a PII clause, permitted-use boundaries, and post-termination expectations.

• Mistake: Inability to prove timing.
  Fix: store agreements in a system that preserves signature dates and link them to identity records used in IAM.

• Mistake: Shared/admin accounts bypass the control.
  Fix: prohibit shared accounts for PII systems where possible; otherwise bind every authorized user and document compensating controls.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement. Treat this control as a baseline expectation because it addresses insider-risk and accountability: without a binding confidentiality obligation, you have weaker contractual leverage to deter misuse, investigate incidents, or discipline improper access to PII under your processing responsibilities. The operational risk shows up during incidents and audits: you may be unable to demonstrate that people handling PII were formally obligated to protect it, which can complicate customer assurances and contractual commitments.

Practical execution plan (30/60/90)

First 30 days (stabilize and stop new gaps)

• Inventory PII systems and define “PII access.”
• Identify all identities with PII access (employees + contractors).
• Confirm you have a PII-capable NDA template for each worker type.
• Add a manual gate: no new PII access without confirmed executed agreement.
• Start an exceptions log for emergency access.

By 60 days (close existing gaps and harden workflows)

• Remediate missing agreements for in-scope users.
• Implement an automated check in the access request workflow (ticketing/IAM) tied to agreement status.
• Document procedures for onboarding, role changes, privilege elevation, and offboarding.
• Establish a reconciliation cadence and owner.

By 90 days (make it audit-proof)

• Produce a repeatable report: “PII access roster + NDA status + signature date.”
• Test the control: pick a sample of users and prove “signed before access” with evidence.
• Formalize metrics you track internally (coverage completeness, exceptions, remediation cycle) without relying on unsourced benchmarks.
• Centralize evidence for fast retrieval (Daydream or an equivalent controlled repository with access controls and retention).

Frequently Asked Questions

Does an employee handbook confidentiality clause satisfy the requirement?

It can, if it creates a binding confidentiality obligation that clearly covers PII and applies to the individuals with PII access. In practice, auditors prefer an executed agreement or explicit acknowledgement you can retrieve per person.

Do contractors need to sign our NDA if their employer already has confidentiality terms?

If the contractor is under your control and you grant them access to PII, you need assurance they are subject to a confidentiality obligation that covers that access. Many organizations require your NDA or a contract addendum plus evidence the individual is bound.

What counts as “access to PII” for engineers who only see logs?

If logs contain identifiers or user-linked records, treat that as PII access. Define this explicitly in your PII access threshold, then include relevant logging and observability tools in scope.

How do we handle break-glass or emergency production access?

Require that only pre-bound individuals can use break-glass accounts, and document the approval and after-action review. Track exceptions and remediate process gaps that caused the emergency request.

Do NDAs need to be renewed periodically?

ISO/IEC 27018 Annex A.11.1 requires a confidentiality obligation, not a renewal cycle. If your templates change materially, use version control and consider re-execution or an addendum for in-scope populations.

What evidence is most likely to be requested in an audit?

Expect requests for executed agreements, a list of PII-access users, and proof the agreement was in place before access. Also expect questions on contractors and privileged users because those populations often have coverage gaps.

Footnotes

1. ISO/IEC 27018:2019 Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors