Annex A 6.2: Terms And Conditions Of Employment

Annex a 6.2: terms and conditions of employment requirement means you must embed information security and acceptable-use obligations into employment (and contractor) terms, then prove those terms are issued, acknowledged, and enforced throughout the worker lifecycle. Operationalize it by standardizing security clauses, mapping them to your ISMS controls, and capturing repeatable HR/legal evidence for audits. ¹

Key takeaways:

• Put security duties in offer letters, employment agreements, contractor terms, and handbooks, not just in standalone policies. ²
• Treat this as an HR–Legal–Security control with auditable evidence, not a one-time template exercise. ³
• Build recurring evidence capture (samples, acknowledgements, exception logs) so you can pass certification and surveillance audits without scrambling. ²

Annex A control 6.2 sits in the “People controls” family and tests a simple idea: people cannot be held to security expectations that were never made a condition of their work. For an auditor, “we have policies” is weaker than “these obligations are part of employment and engagement terms, and we can show acknowledgements and enforcement.” That distinction matters because employment terms are durable, enforceable, and cover edge cases that policies often miss, such as confidentiality after termination, handling of customer data, use of personal devices, and return of assets.

For a CCO, GRC lead, or security compliance owner, the fastest path is to make 6.2 a documented control operation that HR and Legal can run without ad hoc interpretation. You want standardized clause language, defined issuance points (offer, onboarding, role change, offboarding), and a clean evidence trail. The most common failure mode is not the absence of a clause, it’s inconsistent coverage across employee types (contractors, temps, interns), geographies, and acquisition entities, plus missing proof that the terms were actually accepted.

This page gives you requirement-level implementation guidance you can implement quickly and defend in an ISO 27001 audit. ³

Regulatory text

Framework reference: ISO/IEC 27001:2022 Annex A 6.2 ³

Provided excerpt (summary-level): “ISO/IEC 27001:2022 Annex A control 6.2 implementation expectation (Terms And Conditions Of Employment).” ²

What the operator must do

• Ensure employment and engagement terms explicitly state information security responsibilities relevant to the role and the organization’s ISMS. ³
• Apply those terms consistently to employees and other workers who access information assets (for example, contractors and agency staff), with evidence that terms were issued and acknowledged. ²
• Keep the requirement operational: define when terms are presented, how acceptance is captured, how exceptions are approved, and how you verify ongoing coverage. ²

Plain-English interpretation

You must make security obligations a formal condition of work, not an optional “read this policy” request. Your workforce should have written, acknowledged commitments that cover confidentiality, acceptable use, protection of company and customer information, compliance with security policies, and consequences for violations. You also need to show auditors that the organization does this reliably for different worker populations and keeps records you can produce on demand. ³

Who it applies to (entity and operational context)

Applies to: Any organization operating an ISO 27001 ISMS, especially service organizations handling customer data or providing services where workers access systems, networks, or information. ³

Operational scope you should include

• Employees: full-time, part-time, interns, and temporary staff.
• Non-employees: contractors, consultants, agency workers, outsourced IT/admin personnel, and other third parties with logical or physical access.
• Access contexts: corporate endpoints, SaaS, production/admin consoles, customer environments, support tools, source code, logs, and paper records.

Practical scoping rule: If a person can access information, systems, or facilities in scope for the ISMS, they should be under terms that bind them to your security expectations, or you need an approved exception with compensating controls. ²

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

1) Define the minimum “security terms” set (control design)

Create a short, auditable list of security obligations that must appear in:

• Employment agreements / offer letter addenda (or employee handbook acknowledgement tied to employment)
• Contractor/consultant statements of work (SOW) and master services agreements (MSA) where individuals access your assets
• Acceptable use and confidentiality acknowledgements (if your jurisdiction prefers policy acknowledgements over contract clauses)

Minimum topics to cover (operator checklist)

• Confidentiality and non-disclosure (including after separation)
• Handling of sensitive information (customer data, credentials, IP)
• Acceptable use (systems, email, internet, removable media where applicable)
• Account and credential rules (no sharing, MFA compliance, reporting compromise)
• Secure working expectations (remote work, public spaces, screen locking)
• Asset return and access removal on separation
• Reporting obligations (security incidents, lost devices)
• Disciplinary consequences for violations
• Reference to compliance with company security policies and training requirements

Keep this list mapped to your ISMS policies so you can show traceability from “employment terms” to “policy framework.” ³

2) Standardize clause language with Legal (control documentation)

Build approved templates and fallback positions:

• Employee security addendum template (or handbook clause block)
• Contractor security schedule attached to SOWs/MSAs
• Role-based addenda for privileged access (admins, engineers with production access, SOC, finance roles)

Add ownership: HR owns employee issuance, Procurement or Vendor Management owns third-party contracting, Legal owns clause approval, Security/GRC owns the control and testing.

Daydream tip (practical): Put the clause library, approvals, and evidence requests into one control record so HR and Legal are not asked the same questions each audit cycle.

3) Embed issuance points into HR and third-party workflows (control operation)

You need defined “moments that matter” where terms are issued or re-acknowledged:

• Hiring / engagement start (offer accepted or onboarding)
• Role change (promotion into privileged role, transfer to new data domain)
• Policy refresh or major changes (new acceptable use rules, new monitoring disclosures)
• Offboarding (exit certification, asset return, continuing confidentiality)

Operationalize with workflow gates:

• HRIS onboarding cannot complete until acknowledgement is captured.
• Ticketing/IAM access for privileged roles requires confirmation that the correct addendum is signed.
• Procurement cannot approve SOWs for individuals with access until the security schedule is executed or an exception is approved.

4) Define exception handling (auditors always ask)

Create an “Employment Terms Security Exception” process:

• Valid reasons (jurisdictional constraints, union agreements, acquired entity transition)
• Required compensating controls (enhanced monitoring, restricted access, additional training)
• Approver(s): Legal + Security + HR (and Procurement for contractors)
• Evidence retained: signed exception memo and expiration/renewal trigger

5) Test coverage and capture recurring evidence (assurance)

Set up a repeatable test that answers: “Are all in-scope workers covered by security terms and do we have proof?”

• Pull a population list from HRIS and contractor roster from Procurement/vendor management.
• Sample across geographies, worker types, and privileged roles.
• Verify: correct version of terms, signature/acknowledgement date, and storage location.
• Track findings, remediation, and closure evidence.

This is where most ISO 27001 programs fail: the terms exist, but the audit trail is incomplete. Build the evidence capture into your control cadence. ²

Required evidence and artifacts to retain

Maintain an audit-ready packet that does not require Legal to scramble:

Core artifacts

• Approved clause library (employee + contractor variants) with version control
• HR onboarding procedure showing where acknowledgement is collected
• Contractor engagement procedure showing how clauses attach to SOW/MSA
• Records of acknowledgements/signatures (system report exports or signed PDFs)
• Exceptions register with approvals and compensating controls
• Testing records: sampling methodology, sample results, remediation tickets, closure proof
• Offboarding checklist showing return of assets and continued obligations reminder

Evidence quality rules

• Evidence should show who accepted, what they accepted (version), and when.
• Store evidence in a controlled repository with retention aligned to your HR/legal requirements.

Common exam/audit questions and hangups

Auditors and certification bodies tend to probe these areas:

1. “Show me where security obligations are in employment terms.”
   Have the clause block highlighted and mapped to relevant ISMS policies. ³

2. “Do contractors have the same obligations?”
   Be ready with executed SOW/MSA security schedules and a contractor roster cross-check.

3. “How do you handle privileged users?”
   Expect scrutiny on production access roles. Show role-based addenda or explicit privileged-use terms.

4. “Prove acknowledgement, not just publication.”
   A policy URL is weak evidence. Provide HRIS acknowledgement reports or signed addenda.

5. “What happens when people leave?”
   Offboarding evidence should tie to access removal and asset return, with continuing confidentiality obligations stated.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails in audits	How to avoid it
Security obligations exist only in an InfoSec policy	Policies can be optional or not acknowledged	Put key obligations into employment/engagement terms or require signed acknowledgements tied to onboarding
Contractors are excluded “because Procurement owns it”	Control applies to people with access, regardless of payroll	Add a mandatory security schedule to SOW/MSA templates and enforce as a procurement gate
No version control on clauses	You can’t prove what was agreed to at a point in time	Maintain a clause library with versioning and archive prior versions
Acknowledgements are scattered across email/PDFs	Evidence retrieval becomes fragile	Centralize storage and standardize naming, or use HRIS/CLM exports
No exception process	Exceptions exist informally and become audit findings	Create a formal exception register with approvals and expirations

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this control, so this page does not cite enforcement actions.

Risk still compounds operationally:

• Weak employment terms can limit your ability to discipline misuse, recover assets, or enforce confidentiality after termination.
• In service organizations, gaps in contractor coverage commonly become customer trust issues during security reviews and can slow enterprise deals.
• For ISO 27001 certification, poor evidence and inconsistent coverage can drive nonconformities, corrective actions, and repeat findings in surveillance audits. ³

Practical 30/60/90-day execution plan

First 30 days (stabilize design and ownership)

• Assign a control owner in GRC and named counterparts in HR, Legal, Procurement.
• Inventory current worker types and where terms live (HRIS, CLM, shared drive).
• Draft the minimum security terms set and map each item to existing ISMS policies/controls.
• Produce v1 templates (employee addendum/handbook language + contractor security schedule) and route for Legal approval.

Days 31–60 (embed into workflows and start evidence capture)

• Implement onboarding gates in HRIS or ticketing: no completion without acknowledgement.
• Update Procurement/SOW templates and require the contractor security schedule for access-granting engagements.
• Stand up a central evidence repository and naming convention.
• Launch the exception process and register.

Days 61–90 (prove operation and close gaps)

• Run the first coverage test across employees and contractors; document the results and remediation.
• Fix systemic gaps (missing signatures, outdated templates, acquired entity carve-outs).
• Produce an “audit packet” with templates, procedures, sample acknowledgements, and testing results.
• Add recurring control operation in Daydream so evidence requests, sampling, and exception reviews run on a predictable cadence instead of calendar panic. ²

Frequently Asked Questions

Do we need signed employment agreements, or is a handbook acknowledgement enough?

Annex A 6.2 focuses on ensuring security responsibilities are part of the terms and conditions of employment and are evidenced. Many organizations meet this through a handbook acknowledgement tied to employment, as long as it is enforceable in your jurisdictions and you can produce acceptance records.

Does this apply to contractors hired through an agency?

Yes if those individuals access your systems, information, or facilities in scope for the ISMS. Cover them through agency agreements plus an individual-facing acknowledgement or a contractor security schedule attached to the SOW.

What should we do for open-source contributors or unpaid advisors who might see sensitive information?

Treat them as third parties with access and require appropriate terms before granting access (for example, a contributor agreement or NDA plus acceptable-use terms). If you cannot impose terms, restrict access to non-sensitive environments and document an exception with compensating controls.

How do we handle different countries with different employment law constraints?

Maintain a global baseline clause set plus approved local variants. Track coverage by country and keep Legal-approved deviations in a controlled library so you can explain differences to auditors.

What evidence is strongest in an ISO 27001 audit?

A system-generated acknowledgement report from HRIS/CLM tied to a specific document version is typically easier to defend than email threads. Pair it with the approved clause library and a recent sampling test with remediation closure.

We have the clauses, but can’t find acknowledgements for older employees. What now?

Run a remediation campaign to collect acknowledgements, document the gap, and track completion. For audit readiness, keep the campaign plan, completion evidence, and a root-cause fix (for example, an HRIS gate) to prevent recurrence.

Footnotes

1. ISO/IEC 27001 overview; ISMS.online Annex A control index

2. ISMS.online Annex A control index

3. ISO/IEC 27001 overview