A departing employee walks out the door with login credentials still active, a personal laptop full of client data, and zero contractual obligation to keep any of it confidential. Without documented security terms in the employment agreement, the organization has no legal mechanism to enforce accountability — and no standing to pursue disciplinary or legal action. This is the gap ISO 27001 Annex A Control 6.2 exists to close.
What 6.2 Requires
ISO 27001 Annex A 6.2 requires organizations to establish information security responsibilities within employment contracts and agreements before granting access to any organizational assets. As part of the ISO/IEC 27001:2022 standard, this people control applies to every organization pursuing ISO 27001 certification. Every employment contract — whether for a permanent employee, contractor, or temporary worker — must explicitly define both the individual’s and the organization’s obligations around information security.
This isn’t a suggestion to “mention security somewhere in the handbook.” The control demands legally binding commitments embedded directly in the signed agreement. Contracts must cover confidentiality and non-disclosure obligations, acceptable use of information and assets, data protection responsibilities, incident reporting duties, and post-employment obligations that survive termination.
The reason this matters legally: without contractual terms, you cannot enforce policy violations through disciplinary action. If an employee mishandles sensitive data but never signed an agreement acknowledging their security responsibilities, the organization’s recourse is severely limited. An employee handbook or intranet security policy, no matter how detailed, doesn’t carry the same legal weight as a signed contractual obligation.
Control 6.2 also requires that agreements address what happens after employment ends. Post-employment clauses covering confidentiality, return of assets, and non-disclosure of proprietary information must survive the termination of the employment relationship. This forward-looking requirement is what separates 6.2 from a simple onboarding checkbox — it establishes obligations that persist beyond the last day of work. In practice, 6.2 creates the legal foundation that makes every other people control enforceable.
Why 6.2 Matters
Consider this scenario: a systems administrator leaves your organization on good terms. No exit interview covers data handling. Their employment contract mentions “following company policies” in a single generic clause but never references information security specifically. Three months later, proprietary technical documentation surfaces on a competitor’s knowledge base. Your legal team investigates — and discovers there’s no NDA on file, no post-employment confidentiality clause, and no contractual basis to pursue action. The breach is real, the damage is quantifiable, but your ability to respond is legally hollow.
This isn’t hypothetical. Insider threats remain one of the most persistent and costly risk categories organizations face. The 2025 Verizon Data Breach Investigations Report found that 30% of data breaches involve internal actors — a figure that underscores how frequently the people closest to sensitive systems become the source of exposure. Without documented employment terms that establish clear security obligations, organizations lack the foundation to detect, address, or remediate these incidents through formal channels. The human factors in cybersecurity extend far beyond technical misconfiguration — they include the contractual gaps that make enforcement impossible.
The risk categories tied to weak employment terms extend well beyond data leakage. Regulatory exposure increases when you can’t demonstrate that staff were contractually bound to handle personal data in accordance with GDPR, HIPAA, or other applicable frameworks. Audit non-conformities arise when certification bodies request signed agreements and find gaps — particularly when the auditor samples a contractor or recent hire who was never asked to sign security terms. And the disciplinary process — covered separately under Control 6.4 — becomes unenforceable without the contractual basis that 6.2 provides. You cannot discipline someone for violating an obligation they never formally accepted.
What Attackers Exploit
Threat actors and insider risks thrive when employment agreements leave gaps. Specific failure modes tied to this control include:
- Unsigned or incomplete employment agreements — Employees granted system access before signing security clauses have no binding obligation to protect what they access.
- Missing post-employment confidentiality obligations — Former staff retain knowledge of systems, credentials, and processes with no legal restriction on disclosure, increasing the risk of data theft.
- Contractors operating without equivalent security terms — Third-party workers often access the same systems as employees but under weaker contractual protections.
- No documented acceptable use policy referenced in contracts — Without a signed reference to acceptable use, violations become disputes rather than enforceable breaches.
- Absence of disciplinary process linkage — If the contract doesn’t reference consequences for security violations, the organization cannot escalate through formal disciplinary channels.
How to Implement 6.2
Implementation splits into two distinct tracks: securing your own workforce and verifying that your vendors do the same. Both require documented evidence, not verbal assurances. The gap most organizations discover during implementation is not that they lack security policies — it’s that those policies exist in documents nobody signed.
For Your Organization (First-Party)
Start by auditing your existing employment contracts and agreements. Most organizations discover — often while working through an ISO 27001 implementation checklist — that security language sits in an employee handbook or intranet policy page rather than in the signed contract itself. That distinction matters: a handbook acknowledgment is not a legally binding contractual term. An employer can unilaterally update a handbook at any time, but a contract represents mutual agreement — and it’s that mutual agreement auditors and courts will look for.
Step-by-step implementation:
- Audit existing contracts. Review current employment agreements, contractor arrangements, and temporary worker contracts for security clause coverage. Flag any that lack explicit information security language.
- Draft standard security clauses covering six areas: confidentiality and NDA obligations, acceptable use of organizational assets, data protection responsibilities, incident reporting duties, post-employment obligations, and disciplinary consequences for violations.
- Integrate into HR onboarding. Build a workflow gate: no system access is provisioned until the signed agreement is on file. Link this to your identity provider (Okta, Microsoft Entra ID, or equivalent) so access provisioning depends on contract completion.
- Extend scope to all worker types. Contractors, temporary staff, agency workers, and consultants must sign equivalent security terms. The specific clauses may differ, but the coverage areas should mirror employee agreements.
- Establish a review cadence. Review employment terms annually or whenever the employee’s role changes significantly. A developer promoted to infrastructure lead may need updated terms reflecting broader access.
- Maintain a signed agreement register. Track signatory name, agreement version, date signed, and next review date. This register becomes primary audit evidence.
Evidence to produce: signed contracts with security clauses highlighted, NDA register with dates and versions, onboarding workflow documentation showing the verification gate, and the agreement register. Keep these artifacts organized and accessible — auditors will request them, and the time to locate a signed agreement from three years ago shouldn’t be measured in days.
Common mistakes:
- Keeping security terms in a separate handbook that isn’t legally signed — handbooks can be updated unilaterally, undermining enforceability
- Forgetting contractor and temporary worker coverage entirely
- Not updating terms when underlying security policies change
- Missing post-employment and post-contract clauses
- No link between contract terms and the disciplinary process defined in Control 6.4
For Your Vendors (Third-Party Assessment)
When assessing vendors against 6.2, generic attestations aren’t sufficient. Your supply chain is only as secure as the weakest employment agreement in a vendor’s HR process. You need to verify that your vendors’ own employees and contractors operate under equivalent security obligations — because their staff may handle your data with the same level of access as your own team.
Questions to include in security questionnaires:
- “Do your employment contracts include explicit information security obligations?”
- “Do you require NDAs for all staff with access to client data?”
- “Are contractors and temporary workers covered by equivalent security terms?”
Evidence to request: a redacted contract template showing security clauses (you can use ISO 27001 templates as a benchmark), the organization’s NDA policy, and onboarding process documentation demonstrating the contract verification gate. For a structured approach, consider using a vendor questionnaire template that covers 6.2-specific questions alongside broader third-party risk requirements.
Red flags to watch for:
- Vendor states “security is covered in the employee handbook” — this is not contractually binding
- No NDA policy exists or it’s applied inconsistently
- No post-employment confidentiality clause
- No evidence that contractors receive equivalent coverage
Beyond self-attestation: request a walkthrough of the vendor’s onboarding process and ask when the contract template was last reviewed. A template that hasn’t been updated since 2019 likely doesn’t reflect current data protection requirements or the 2022 revision of ISO 27001. Ask for the date of last review, who approved the update, and whether legal counsel was involved.
Audit Evidence for 6.2
Certification body auditors assess 6.2 by reviewing documented agreements and verifying that the process works consistently across worker types. They’re looking for systemic coverage, not perfection in any single contract. The following evidence types directly support audit readiness:
| Evidence Type | Example Artifact |
|---|---|
| Employment contract template | Template with information security clauses highlighted |
| Signed NDA/confidentiality agreements | Individual NDAs on file for each employee |
| Onboarding workflow documentation | Process showing contract verification gate before access provisioning |
| Contractor agreement template | Equivalent security terms for non-employee workers |
| Signed agreement register | Spreadsheet or system record: name, date, version, next review |
| Annual review records | Documentation of periodic employment term reviews |
| Post-employment acknowledgments | Signed confirmation of ongoing obligations at termination |
| Disciplinary policy reference | Contract clause linking to the organization’s disciplinary process |
Auditors typically sample across employee types — permanent staff, recent hires, contractors, and departing employees — to verify consistent application rather than checking every individual file. The most common finding isn’t a missing contract entirely; it’s a contract that exists but lacks specific security clauses, or a contractor who was onboarded through a different process that bypassed the standard agreement workflow. Prepare by running your own sample audit before the certification body arrives — our guide to ISO 27001 audit preparation covers the broader process.
Cross-Framework Mapping
Organizations managing multiple compliance frameworks can leverage 6.2 implementation to satisfy overlapping requirements across NIST 800-53, SOC 2, and other standards. This cross-framework alignment reduces duplicate effort and strengthens your overall compliance posture.
The following table maps ISO 27001 Annex A 6.2 to equivalent controls in major frameworks. “Full” coverage means the mapped control addresses the same objective; “Partial” means the mapped control covers a subset of 6.2’s requirements.
| Framework | Equivalent Control(s) | Coverage |
|---|---|---|
| NIST 800-53 | PL-04 (Rules of Behavior) | Full |
| NIST 800-53 | PS-06 (Access Agreements) | Full |
| NIST 800-53 | PM-01 (Information Security Program Plan) | Partial |
| NIST 800-53 | PM-03 (Information Security Resources) | Partial |
| NIST 800-53 | PM-04 (Plan of Action and Milestones) | Partial |
| NIST 800-53 | PM-06 (Measures of Performance) | Partial |
| NIST 800-53 | PM-09 (Risk Management Strategy) | Partial |
| NIST 800-53 | PM-14 (Testing, Training, and Monitoring) | Partial |
| NIST 800-53 | PM-28 (Risk Framing) | Partial |
| NIST 800-53 | PM-30 (Supply Chain Risk Management Strategy) | Partial |
| NIST 800-53 | PM-31 (Continuous Monitoring Strategy) | Partial |
| SOC 2 | CC1.4 (COSO Principle 4 — Commitment to Competence/Accountability) | Partial |
| NIST CSF 2.0 | GV.RR (Roles, Responsibilities, and Authorities) | Partial |
| CIS Controls v8.1 | Control 14.1 (Security Awareness Program) | Partial |
The strongest overlap sits with NIST SP 800-53 Rev. 5 controls PL-04 (Rules of Behavior) and PS-06 (Access Agreements), which directly address the same contractual mechanisms 6.2 requires — signed acknowledgments of security responsibilities before granting access. The partial mappings across the PM family reflect that many NIST program management controls touch on the organizational policies and workforce commitments that 6.2 formalizes, even though their primary scope is broader.
SOC 2 CC1.4 covers the accountability dimension through COSO Principle 4 but doesn’t prescribe the same contractual specificity as 6.2. Organizations pursuing both ISO 27001 and SOC 2 can use the same signed agreements as evidence for both frameworks, reducing audit preparation effort. The NIST CSF 2.0 mapping to GV.RR (Governance — Roles, Responsibilities, and Authorities) captures the governance intent but applies at a higher organizational level than individual employment terms.
Related ISO 27001 Controls
Control 6.2 doesn’t operate in isolation. It feeds into — and depends on — several related controls within the people controls domain and beyond. For a complete view of how these controls connect, see the ISO 27001 compliance hub.
| Control ID | Control Name | Relationship |
|---|---|---|
| 6.1 | Screening | Pre-employment screening informs what contract terms are needed based on role sensitivity |
| 6.3 | Information security awareness, education and training | Training reinforces the contractual obligations employees have signed |
| 6.4 | Disciplinary process | Contracts must reference the disciplinary process for security violations |
| 6.5 | Responsibilities after termination or change of employment | Post-employment terms from contracts feed directly into offboarding procedures |
| 6.6 | Confidentiality or non-disclosure agreements | NDAs are a specific evidence artifact supporting 6.2 compliance |
| 5.10 | Acceptable use of information and other associated assets | Acceptable use policies should be referenced within employment contracts |
| 5.1 | Policies for information security | Contracts require employees to acknowledge and follow the organization’s security policies |
| 8.1 | User endpoint devices | Device usage policies may be referenced in employment terms, especially for BYOD |
The strongest dependency runs between 6.2 and 6.4: without contractual terms establishing security obligations, the disciplinary process has no enforceable basis. Similarly, 6.5 (responsibilities after termination) depends entirely on what was documented in the original employment agreement — you cannot enforce post-employment obligations that were never contractually established.
Frequently Asked Questions
What is ISO 27001 6.2?
ISO 27001 Annex A 6.2 is a people control that requires organizations to define information security responsibilities in employment contracts and agreements — for employees and contractors alike — before granting access to organizational assets.
What happens if 6.2 is not implemented?
Without documented security terms in employment agreements, organizations cannot enforce policy violations through disciplinary action, lack legal recourse against data misuse by current or former staff, and face audit non-conformities during ISO 27001 certification assessments.
How do you audit 6.2?
Auditors review signed employment contracts for security clause coverage, verify that onboarding workflows gate access on contract completion, and sample across employee types — permanent staff, contractors, and recent departures — to confirm consistent application.
How UpGuard Helps
Tracking whether every employee and vendor meets their contractual security obligations becomes unmanageable at scale without purpose-built tooling. UpGuard User Risk continuously monitors whether your workforce and third parties uphold the security commitments documented in their agreements — surfacing gaps before auditors find them.