ISO 27001 Employment Contracts: The Essential 2026 Guide

ISO 27001 employment contracts are the first thing an auditor reaches for when testing Annex A 6.2, and they are usually the one thing the organization cannot produce. Out comes the signed policy acknowledgement instead, or the non-disclosure agreement, and neither of them is what the control asks for. A.6.2 is one of the eight people controls in the 2022 edition, and its wording is narrow: the contractual agreement itself has to state what the individual and the organization are each responsible for in terms of information security.

That distinction is worth getting right before your stage 2 audit, because fixing it afterwards means going back to people who have already signed something. This guide covers what belongs in ISO 27001 employment contracts, where A.6.2 stops and the neighboring people controls take over, how to deal with staff who signed years before you had an ISMS, and the handful of mistakes that reliably turn this control into a finding.

What ISO 27001 Employment Contracts Must State

ISO/IEC 27002:2022 frames control 6.2 as a requirement that the employment contractual agreements state the personnel’s and the organization’s responsibilities for information security. Two details in that sentence do most of the work.

The first is contractual. A policy you publish on the intranet, a handbook, an induction slide deck and an acceptable-use acknowledgement are all useful, and several other controls expect them, but none of them is a contractual agreement. If your security terms live only in a policy that you can revise unilaterally, you have met a different control.

The second is and the organization’s. The obligation in ISO 27001 employment contracts runs in both directions. Most contract templates list what the employee must do and say nothing about what the employer provides — the equipment, the training, the reporting channel, the support for handling information securely. Auditors rarely raise this as a nonconformity on its own, but it is the clearest sign that a clause was copied rather than written.

The control’s attributes place it as preventive, touching all three information security properties, mapped to the Protect cybersecurity concept, with human resource security as its operational capability and governance and ecosystem as its security domain. It is a modified version of control 7.1.2 in the 2013 edition, which is why this control is quietly skipped during a transition project: the old template usually still passes, so nobody opens it.

Where A.6.2 Stops and the Other People Controls Start

Five controls in the people theme get conflated, and the conflation is what produces most of the confused evidence packs. Each one governs a different moment and a different artifact.

Control	What it governs	When it applies	Primary artifact
A.6.1 Screening	Verification of background before access is granted	Before the offer is confirmed	Screening and verification records
A.6.2 Terms and conditions of employment	Security responsibilities written into the agreement	At the point of hire	Signed contract containing security clauses
A.6.4 Disciplinary process	What happens when someone disregards the rules	After a breach or incident	Documented process, anonymized case log
A.6.5 Responsibilities after termination	Duties that survive the end of employment	At exit and for a defined period after	Exit checklist, surviving clauses
A.6.6 Confidentiality or NDAs	Confidentiality as a standalone commitment	Before access to information or assets	Signed confidentiality agreement

One correction worth making explicitly, because a great many commercial pages covering ISO 27001 employment contracts get it backwards: the language about obligations continuing for a defined period after employment ends belongs to A.6.5, not to A.6.2. A.6.2 is a point-in-time obligation discharged at hire. If your clause set handles the post-employment period well but was never actually incorporated into anyone’s agreement, you have evidence for A.6.5 and a gap at A.6.2.

The same applies in the other direction with ISO 27001 confidentiality agreements. A.6.6 is its own control, so a confidentiality clause inside the employment contract can serve both, but only if the clause is genuinely adequate as an NDA. Pointing at a single sentence promising discretion will satisfy neither control.

The Five Clause Groups to Put in ISO 27001 Employment Contracts

The guidance in 27002 for this control resolves into five groups that ISO 27001 employment contracts should address. Treat them as the checklist you run your current template against, rather than as wording to paste.

• Confidentiality or non-disclosure terms, agreed before access to information or assets is granted — including, where the role touches personal data, terms adequate for that purpose.
• Legal responsibilities and rights, which in practice means copyright and intellectual property in work produced, and obligations arising from data protection legislation.
• Responsibility for classification and asset management — the classification of information the person creates or handles, and their duties toward the assets, processing facilities and services they are given.
• Responsibility for information received from interested parties, meaning customer, partner and third-party information that arrives with its own handling conditions attached.
• Consequences of disregarding security requirements, which is the hook that connects this clause to your ISO 27001 disciplinary process. A clause that creates an obligation with no stated consequence is hard to enforce and easy for an auditor to question.

Two further items are worth including even though they sit slightly outside the control: any restrictions on use of technology and social media, and an explicit statement that the person agrees to the organization’s information security terms. The second costs one line and makes the signature unambiguous.

If you are mapping this across frameworks, the equivalent requirement in NIST CSF 2.0 is subcategory GV.RR-04, “Cybersecurity is included in human resources practices” — formerly PR.IP-11 in CSF 1.1. The NIST Cybersecurity Framework treats it as a governance outcome rather than a document, which is a useful reframing when you are arguing internally for the clause.

The Retrofit Problem Nobody Warns You About

Here is the practical difficulty that catches first-time implementers. You cannot unilaterally add a clause to a contract somebody already signed. So the moment you improve your ISO 27001 employment contracts, you have created two populations: people hired after the change, who signed it, and everybody else, who did not.

The standard does not tell you how to close that gap, and there is no single correct route. Three work in practice:

• A contract addendum issued to existing staff and signed back — cleanest, slowest, and the one that needs HR and legal involvement.
• Folding the clause in at the next contractual variation — a promotion, a role change, a pay review — which is low friction but leaves the gap open for an unpredictable length of time.
• A separately signed acknowledgement that references the clause set by version. Weaker contractually than an addendum, but it is signed, dated and auditable, and it closes the population.

What matters for the audit is that the population is complete. A sample of ten recent hires that all pass is not a result if two hundred longer-serving people are covered by nothing signed. Decide the route, record the decision and its rationale, and track completion as a number you can show. An in-progress rollout with a date and a percentage is a far better answer than a clean sample over an incomplete population.

Contractors, Agency Workers and Temporary Staff

ISO 27001 employment contracts have to reach anyone with access to your information assets, which includes contractors, freelancers and temporary staff. Your employment contract does not reach an agency worker, because you have no employment relationship with them — their agreement is with the agency.

That leaves two routes, and most organizations need both. Either you enter a direct agreement with the individual covering the same ground, which is normal for independent contractors, or you place an obligation in the supplier contract requiring the agency to impose equivalent terms on the people it supplies, plus a right to see evidence that it has. The second route is really A.5.20, information security in supplier agreements, doing the work — and relying on it without ever exercising the evidence right is a common weak point.

Whichever route you take, the sequencing rule does not change: the agreement is signed before access is granted, not during the first week.

What an Auditor Asks to See

Evidence	What a good answer looks like
Contract template	Current version, under document control, reviewed with HR and legal input, security clauses identifiable as such
Signed contracts (sample)	Covers employees and non-employees; signature date precedes the access grant date
Confidentiality agreements	On file for roles handling personal or sensitive information
Communication records	Induction or onboarding records showing the responsibilities were explained, not merely signed
Statement of Applicability	6.2 marked applicable with the contract named as the implementation, per clause 6.1.3
Review evidence	A template review inside the last 12 months, with the version history to prove it

Note the second row. Comparing the signature date against the account creation date is a cheap test and an effective one, and it is the single check most likely to turn a tidy-looking file of ISO 27001 employment contracts into a nonconformity.

Why ISO 27001 Employment Contracts Fail an Audit

The failure patterns are consistent enough to list. In rough order of how often they appear:

• Access granted before the agreement was signed. The clause exists, the signature is three weeks late, and the joiner had a mailbox on day one.
• The contract contains no security terms at all — common in small organizations and startups using an off-the-shelf template from before the ISMS existed.
• Non-employees excluded. Contractors and agency staff have system access and no equivalent agreement.
• The policy acknowledgement is offered instead of the contract. Good evidence, wrong control.
• Version drift. The template was improved, nobody re-signed, and no review is recorded in the past twelve months.
• Legacy staff uncovered, with no addendum route and no completion tracking.

None of these are difficult to fix. All of them are much easier to fix before the contracts are signed, which is the argument for treating A.6.2 as an early task in the project rather than a documentation tidy-up near the end. If you are still sequencing the work, our guide on how to get ISO 27001 certified sets out where this lands in the wider timeline, and ISO 27001 background screening covers the control immediately upstream of it.

Frequently Asked Questions

Does the contract have to mention ISO 27001 by name?

No. Nothing in A.6.2 requires ISO 27001 employment contracts to name the standard, and naming it can be counterproductive if your scope later changes. What the control wants is the substance of the responsibilities, expressed clearly enough that the person understands what they are agreeing to.

Do we still need a separate NDA?

Not necessarily. A.6.6 is a separate control, but it asks for confidentiality commitments, not for a separate piece of paper. A confidentiality clause inside the employment contract can serve both controls if it is substantive enough to stand alone. Many organizations keep a separate NDA anyway, because it is easier to issue to non-employees and easier to point at during an audit.

Can one clause set cover every role?

Usually yes, as the baseline. The control asks for responsibilities appropriate to the role, so highly privileged roles — administrators, developers with production access, anyone handling large volumes of personal data — generally warrant additional terms layered on top rather than a different contract entirely.

We have no employees, only founders and contractors. Is A.6.2 applicable?

Yes, and this is a common mistake on the Statement of Applicability. The control applies to personnel with access, not to employees specifically. Marking 6.2 as not applicable because you have no payroll will be challenged. Cover the founders and the contractors through whatever agreements do exist.

How often should the template be reviewed?

ISO 27001 sets no interval for this, so any frequency you see quoted is convention rather than requirement. Annual review alongside the rest of your documented information is the common choice, and it is what most auditors expect to see; the defensible position is a stated review cycle that you actually follow.

Getting the Clause Written

If you would rather start from drafted wording than a blank page, the ISO 27001 Toolkit includes the clauses for ISO 27001 employment contracts alongside the rest of the people-control documentation — 165 templates in Microsoft Office format for $99, with the example text highlighted so you can see what needs replacing. It will not substitute for your employment lawyer reading the final clause, and it should not: this is the one control where the artifact is a legal document first and an ISMS record second.