A.6.2 Terms and conditions of employment: requirements and evidence

What A.6.2 asks employment contracts to say about security

A.6.2 asks that employment contractual agreements state the information security responsibilities of both the personnel and the organization. If your audit is coming and your offer letter or employment agreement template says nothing about security, that gap is the first thing to fix. The control exists because a person's duties to protect information are easy to assume and hard to enforce unless they are written into the agreement that creates the working relationship. The contract is also where the organization commits to its side, such as providing the policies, training and tools staff need to meet their duties. Read the clause as two-sided: it asks for personnel duties and organizational duties, and an assessor will look for both.

The control connects directly to policy acknowledgment. A contract clause that refers to the information security policy, and to the duty to follow it, gives the acknowledgment process a legal anchor. Staff can then be held to the policy in the same way they are held to other conditions of employment, and the disciplinary path in A.6.4 has a clear basis. In practice, ask HR and legal to confirm three things: which template versions were in use on each start date, whether the security clause appears in every template still in circulation (including contractor and temporary worker forms where the organization uses them), and whether the signed copy is retrievable for each person in scope.

This control is hard in practice for a predictable reason. Templates belong to HR and legal, which means security teams rarely own the wording, and signed copies sit in e-signature tools, HR information systems, shared drives and paper files. An auditor who samples employees will ask for the signed agreement, not a description of it, so the evidence has to be findable quickly. Confirm who owns the template, who approves changes to the security clause, and where signed originals are stored and how long they are kept. The 2013 predecessor, A.7.1.2 Terms and conditions of employment, is traced to A.6.2 in the correspondence table of ISO/IEC 27002:2022 Annex B. Under IAF MD 26:2023, the 2022 control set carries attributes and a purpose for each control, so ask your certification body which evidence it expects for A.6.2 before you prepare the sample.

Which employees, contracts and third-party staff A.6.2 covers

A.6.2 applies to every person whose work touches the ISMS, but the contract wording and the population an auditor samples depend on decisions made early. The cards below cover who is in scope, which agreements carry the responsibilities, and how the ISMS scope boundary shapes the evidence you must produce.

Permanent staff and their contracts

Permanent employees are the core population for A.6.2, and their written employment terms should state the information security responsibilities of the person and of the organization. Start with a roster from HR of every permanent role inside the ISMS scope, then check that each role's current contract template contains the security clause. The most common gap is an older template that predates the current policy set. Confirm that every active template carries the clause, not only the templates written after the last policy review.

Contractors and temporary workers

Contractors and temporary workers often hold the same access as employees but sign under a different agreement, such as a services contract or agency terms. Decide whether they fall under the same A.6.2 wording, a supplier clause, or both. Record the decision in the ISMS scope documentation so an auditor can see why a population was included or excluded. Check that the agency or vendor contract passes the responsibilities down to the individual worker.

Employees in each jurisdiction

Employment law differs by country, and some jurisdictions limit what can be written into a contract or how consent to monitoring must be obtained. A.6.2 does not override local law, so the organization needs a version of the security terms that works in each country where it employs people. Ask local counsel or HR to confirm the wording for each jurisdiction, and keep a register of which template applies to which country. An auditor sampling one employee from a branch office will expect the same control evidence as one from headquarters.

Offer letters and onboarding documents

Offer letters often reach candidates before the full contract, and some organizations ask new hires to sign policy acknowledgments only after their first day. Decide which document carries the security responsibilities and whether an offer letter that refers to the contract is enough. The safer approach is to make the security terms part of the signed contract and reference them in the offer, then track signature before system access is granted. Record the date each signature was completed.

Whether the ISMS scope decides the sample

The scope statement defines which locations, business units and services the ISMS covers, and an auditor typically draws the A.6.2 sample from people working inside that boundary. If a team handling customer data sits outside the stated scope, the organization must justify the exclusion and show that the team's controls are managed elsewhere. Review the scope statement and the personnel list together before the audit, so the sample you prepare matches the boundary the certification body will test.

How an assessor tests A.6.2 and what they sample

This table lists each step an assessor takes to test A.6.2, the evidence they request and the findings that commonly stop a clean result. Read it as a preparation checklist: each row shows what the assessor will ask to see and where organizations usually fall short.

Test step	What the assessor does	Evidence requested	Common findings
Review the contract template	Reads the standard employment agreement and checks whether it states personnel information security responsibilities in plain terms	Current template, version history, approval record from HR and legal	Template omits security duties entirely or refers to a policy that no longer exists
Check the organization's own obligations	Looks for wording where the organization commits to protecting personnel data, providing training and maintaining the policy	Template clauses on employer duties, linked policy references	Only staff duties appear; the organization's side of the commitment is missing
Sample signed agreements	Selects contracts across roles, seniority, hire dates and contract types, including recent joiners and contractors where they are in scope	Signed agreements or e-signature records with dates, sample list and selection rationale	Unsigned contracts, missing signatures for some roles, or agreements signed after start date with no explanation
Check alignment with policy acknowledgment	Compares the date and wording of contract signature with the date staff acknowledged the information security policy	Acknowledgment logs, policy versions in force on each hire date, mapping to signed contracts	Acknowledgments exist but do not match the policy version in force, or contracts cite an outdated policy
Confirm template currency	Checks that the template was updated after major policy or legal changes and that older versions were retired	Change log, dates of template revisions, list of contracts still on earlier versions	Outdated templates still in use for new hires, with no review record
Interview HR and hiring managers	Asks how contracts are issued, who signs off exceptions, and what happens when a contract is not returned	Interview notes, process description, exception register if one exists	Staff describe a different process from the documented one, or exceptions are handled informally
Check contractors and third-party staff	Confirms that non-employee personnel with access sign terms covering the same security responsibilities	Contractor agreements, supplier contract clauses, access records linked to each person	Contractors work with system access under a generic agency agreement that does not mention security duties
Test exception handling	Asks how staff who refuse or delay signing are prevented from accessing systems	Access restriction records, escalation records, sign-off for any approved exception	No documented rule for unsigned staff, so access continues without a contract on file

How to implement A.6.2 in a contract and onboarding flow

This sequence turns A.6.2 from a policy statement into signed employment terms that state personnel and organizational security responsibilities, linked to policy acknowledgment and kept current through hiring and renewals.

Inventory current employment and contractor templates
HR and legal collect every template used to engage people: employment contracts, fixed-term and part-time variants, contractor and consultant agreements, and any agency or temporary staff terms. Compare them against the list of roles that have system or data access. The output is an inventory with one row per template, noting who uses it, which jurisdiction it governs and whether it mentions information security at all. Done when every active template is accounted for and gaps are marked.
Define the responsibilities to state
The information security lead and HR agree two lists. The first covers what personnel must do, such as protecting company information, following the acceptable use and information security policies, reporting suspected events and returning assets. The second covers what the organization commits to, such as providing the policies, training and tools needed to meet those duties. Map each item to the policy section that defines it. The output is a responsibility matrix with a named owner for each line, reviewed by the security lead and HR.
Draft clause language with legal review
Write standard clauses that reflect the matrix, using the organization's own policy wording rather than generic text. Keep the clauses short enough to read, and add variants where local employment law limits monitoring or restricts certain obligations. Counsel reviews each variant against the applicable law and against confidentiality terms already in the contract. The output is a reviewed clause library and a version number on each template. Ask counsel to confirm which obligations survive termination, because that link belongs to A.6.5.
Align clauses with policy acknowledgment
The contract should point to the information security policy as a document the person must read and accept, and the onboarding system should record that acceptance separately from the contract signature. Confirm the policy version referenced in the clause matches the version in the acknowledgment tool. The output is a cross-reference sheet that lists each clause, the policy section it relies on, and the acknowledgment record that proves it. Auditors often sample this link, so it should be explicit.
Roll out to new hires and renewals
Insert the updated clauses into the offer and onboarding workflow for new starters, and into the renewal or amendment process for existing staff and long-term contractors whose templates predate the change. Decide with legal whether existing staff sign an amendment or accept a policy update, and document that decision. The output is a rollout record showing which templates changed, the effective date and which populations were moved to the new terms.
Collect and store signed agreements
Obtain signatures through the HR system or e-signature platform that keeps the signer identity, date and template version. Chase exceptions before system access is granted, and escalate unsigned cases to the manager and HR. Store the signed copies where the auditor can retrieve them by person and by role. The output is a signature log that matches the population from the system access list, with any missing signatures recorded and their remediation tracked.
Check the flow and keep evidence current
Sample a set of recent hires, contractors and renewals and trace each one from template to signature to policy acknowledgment to system access. Fix any broken link and record the result. Repeat the check when policies or templates change, and at the internal review the management system already runs. The output is a short test record with the sample, the findings and the owner of each fix. Whether the design meets the requirement is for the independent auditor to decide.

How the contract ties to policy acknowledgment and onboarding

The employment contract is the anchor for A.6.2, but the contract alone rarely proves much. An auditor expects the clause that states the person's information security responsibilities to be linked to a dated record showing that the person accepted the policy version in force at the time. Keep the signed contract and the acknowledgment record as a pair, so that for any sampled employee you can show what they agreed to, which policy they accepted, and when. In practice this means the onboarding workflow should generate both in one step: the contract clause references the acceptance policy by title and version, and the HR system or identity platform stores the acknowledgment with a timestamp. Confirm with your HR and legal teams which signature method they use and whether it meets local requirements for electronic signature.

Policies change while people are employed, and the evidence has to follow the change. Decide in advance which changes require re-acknowledgment (for example, changes to acceptable use, remote working or data handling rules) and which only require notice. When a policy version changes, record the new version number, the effective date, and the date each in-scope person re-acknowledged it. Track people who have not responded and set a clear escalation path, because an unanswered re-acknowledgment is an open gap an assessor will ask about. Where a contract is amended rather than re-signed, keep the amendment on file with the same identifiers.

The contract clauses only have force when the organization can act on them. Screening under A.6.1 confirms the checks that were done before the person joined, and the disciplinary process under A.6.4 defines what happens when a breach of the stated responsibilities occurs. Duties that continue after the person leaves, such as confidentiality, belong to A.6.5. Map each responsibility in your contract template to the procedure that enforces it and to the record that proves it, so that a breach or a departure can be traced from the clause to the action taken. Ask your legal counsel to confirm that the clauses are enforceable in each jurisdiction where you employ staff.

Evidence that passes an A.6.2 audit

An auditor testing A.6.2 usually starts with the contract template, then pulls signed agreements for a sample of people and checks that the wording matches what the organization says it does. The cards below cover the artifacts that connect the template to each signed person, and the records that show the template stayed current between audits.

Approved contract template with version history

This is the master employment agreement, with the security clauses that state personnel responsibilities. An auditor checks that the template is approved by HR, legal and information security, and that the version in force on each sampled hire date is the one signed. Keep every prior version with its approval date so the sampled signatures can be matched to the right wording. Confirm that the version history can be produced quickly, not reconstructed from email.

Signed agreements for sampled staff

Auditors select individuals from the HR roster and ask for the countersigned agreement. The signature must be dated, must reference the template version, and must sit in a record that HR can retrieve by employee identifier. Gaps are common where contracts were signed on paper before a template change or where a rehire never received the current version. Check the sample against the HR system before the audit so missing items surface early.

Contractor and temporary worker terms

Contractors, agency staff and temporary workers often sign different documents from employees, usually a services agreement or an engagement letter. Auditors check whether these instruments carry equivalent security responsibilities and whether they cover the organization's own duties. Confirm that each third-party worker has a signed record linked to the sponsoring manager, and that the terms are reviewed when the engagement is extended or the scope of access changes.

Responsibility statement for the organization

A.6.2 asks that the agreement state the organization's security responsibilities as well as the individual's. This statement typically commits the organization to providing security training, defined tools and a channel for reporting concerns. Keep it as a named section within the template, approved at the same level as the personnel clauses. Check that the commitments match what the organization actually delivers, because an auditor who finds a promised training program with no records will question the whole agreement.

Policy acknowledgment records linked to each person

Where security policies are incorporated by reference, auditors expect a per-person acknowledgment that ties the signed contract to the policy versions in force. Store each acknowledgment with the policy identifier, version and timestamp, and link it to the employee record. An automated onboarding workflow can generate this record at the point of hire, which reduces the chance that a new joiner starts work without one. Confirm the platform can export the link for any sampled person.

Review log for template updates

The template must stay aligned with current policy, law and the organization's risk picture. A review log records each scheduled review, who attended, what changed, and why, including changes prompted by legal updates or incidents. Auditors use it to judge whether the organization actually maintains the control or only produced the document once. Set a review cadence in the policy and keep the log as a dated register, so evidence of periodic review is available without extra preparation.

What meeting A.6.2 costs in money and effort

This table lists the cost components of putting A.6.2 in place, who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Read it as a checklist for building a quote, since no price list applies and no figures are supplied for these items. The main takeaway is that legal review and HR process time usually matter more than software, and that self-hosted tooling mainly removes e-signature and HR platform license spend.

Cost component	Who is paid or who spends time	One-time or recurring	What drives it up or down
Legal review of contract templates	External counsel or internal legal counsel	One-time, then recurring on change	Number of contract types, jurisdictions and local employment law differences
HR process time to add security clauses and collect signatures	Internal HR staff, hiring managers	Recurring with every hire and role change	Headcount, hiring volume and how many templates are in use
E-signature or HR system licenses	Software vendor (licensed); none if a self-hosted tool is used	Recurring subscription, where licensed	Number of users or signers and whether the HR platform already includes signing
Engineering effort to link onboarding records to a self-hosted system	Internal IT or an implementation partner under a written scope	One-time build, then recurring maintenance	Number of source systems, integration depth and whether records already live in one place
Evidence sampling support during audit	Internal compliance lead, HR, and the independent certification body's auditor fee	Recurring each audit cycle	Sample size the auditor selects, population size and how quickly records can be retrieved
Periodic re-review of contract terms	Legal, security and HR owners	Recurring, typically tied to policy review	Frequency of policy changes, new regulation and contract template count
Preparation and gap check before audit	Internal team or implementation partner	One-time per certification cycle	How complete existing signed agreements are and how many exceptions must be chased

Who drafts, signs off and audits the employment terms

Your HR and legal team owns the employment terms. They decide what the contract says about information security, who signs it, and when it is re-issued. The organization is responsible for the control, so the wording of the responsibilities clause must reflect the policies the organization actually runs, not a generic template. Legal review also decides how the clause sits alongside local employment law, works councils and collective agreements, which vary by jurisdiction and are for counsel to confirm.

Clause ownership: HR or legal approves the security responsibilities wording for employees and for the organization itself.
Signature process: Decide whether signatures are wet ink, e-signature, or an acknowledgment inside an HR system, and record who holds the signed copy.
Template versioning: Keep dated versions of the contract template so an auditor can match each signed agreement to the wording in force at the time.
Contractors and temporary staff: Confirm how agency and contractor agreements carry the same responsibilities through supplier terms.
Local law review: Ask counsel to confirm what must be disclosed to staff and how consent is recorded in each country.

Check that HR can produce, for any sampled person, the signed agreement, its template version and the date of signature.

Where A.6.2 evidence usually breaks down

Auditors sample signed agreements and check that each one matches the current policy and the person it belongs to. The gaps below are the ones that most often turn a control that exists on paper into a finding, and each card ends with the check that closes it.

Confidentiality clauses without security duties

Many employment contracts include a confidentiality paragraph but say nothing about the information security responsibilities of the person or of the organization. A.6.2 asks for both sides to be stated. Check whether each template names concrete duties such as following the acceptable use and information security policies, protecting company equipment and data, and reporting incidents. Then confirm legal has reviewed the wording against local employment law.

Template versions with no history

HR often keeps one current contract template with no record of what changed, when, or which staff received which version. When the security policy is revised, an auditor asks which agreement a given employee signed and whether it referenced the policy in force at the time. Keep dated, versioned templates with an approval record and a note of what changed in each release.

Contractors on different paperwork

Contractors, agency staff and temporary workers often sign a services agreement or a vendor NDA instead of an employment contract. Those documents may omit the security responsibilities that employees accept, so the same person can be bound differently depending on who pays them. List every contractor role with access to systems, then confirm each one has an agreement that states security duties and names the organization's policies.

Unsigned legacy staff

Employees hired before the current template or policy was introduced may never have signed it. Records often show a contract on file but no acknowledgment of the security terms. Run a reconciliation of the active staff list against signed agreements, obtain signatures or a documented exception for each gap, and set a rule that role changes trigger re-signature when the terms have changed.

Acknowledgments not linked to a person

Some organizations collect policy acknowledgments through a shared form, a scanned batch or an email thread that cannot be matched to an employee record. An auditor who samples one person cannot confirm that the signature belongs to that individual, which version they accepted, or when. Store each acknowledgment against a unique identifier from the HR or identity system, with the document version and date, so any sampled name can be traced in minutes.

Agreements that the HR system cannot find

Signed agreements are sometimes stored in personal folders, paper files or a mailbox that departs with the employee. Retrieval then depends on who remembers where a file went. Set a single system of record for signed agreements, restrict access to HR and audit staff, and test retrieval by pulling a random sample of agreements on a set schedule so gaps appear before the auditor finds them.

Questions buyers ask about A.6.2 before an audit

How much effort does A.6.2 take to implement?

The effort depends mostly on how many contract types you use and how many people sign them. A single employment template that already names security duties may need only a targeted revision, while a company with several employment models, regional contracts and a long history of unsigned or inconsistent paperwork will need an inventory first. The main drivers are the number of contract templates, the number of jurisdictions, whether existing agreements already reference the information security policy, and how many current staff must re-sign. Ask any partner or consultant for a written breakdown of which templates they will review, which records they will check, and who performs the re-signing exercise, because those items determine the work far more than the control wording itself.

Can HR handle A.6.2 alone, or do we need outside help?

HR can usually own the process, since it holds the contracts and the signature records. Security should define the information security responsibilities that go into the wording, because A.6.2 asks that contracts state the security responsibilities of both the personnel and the organization. Where HR lacks a security owner or the contract library is scattered across tools, an implementation partner can help map what each template says, draft clauses for review and set up a signing record that an auditor can sample. Responsibility for the controls stays with your organization, and an independent auditor, not a consultant, judges whether the evidence is sufficient.

Does A.6.2 require a legal review of employment contracts?

The standard does not prescribe who drafts the wording, but employment terms are governed by local law, so legal review is the normal and prudent step. Counsel should confirm that the security clauses are enforceable in each jurisdiction, that they fit with existing confidentiality and disciplinary terms, and that they do not conflict with local employment rules on monitoring or data handling. Ask your legal team to document its review, because an assessor will want to see that the wording was approved, not simply that it exists in a template.

What should we require from contractors and other third parties?

Contractors, temporary staff and some service providers often work with the same information as employees, so their agreements should state their security responsibilities too. The usual approach is to use a contractor agreement or statement of work that references the same information security policy, sets obligations for the organization and the contractor, and is signed before access is granted. Confirm with your procurement and legal teams which party is the employer of record for each worker type, because that decides which document carries the obligation. Keep a list of who holds an agreement so that access reviews can be checked against it.

How often should contract templates and policy references be reviewed?

Review templates on a schedule set by your own ISMS, and also whenever the information security policy, the Statement of Applicability, the employment model or applicable law changes. The review should confirm that the cited policy version is current, that the responsibilities still match actual roles, and that the change history is recorded. Your ISMS documents should name the owner and the trigger events so that the review is repeatable. The schedule itself is an organizational decision, and an auditor will test whether you followed the schedule you wrote, so set one you can keep.

What does an auditor sample to test A.6.2?

An auditor usually starts with the contract template, then selects a sample of personnel records and checks that each person signed an agreement containing the security terms before or at the time they gained access. They also look at the policy acknowledgment linked to those contracts, the dates of signature, and any exceptions with approval. Expect questions about staff who joined before a template change, and have a documented plan for re-signing or for explaining the gap. Prepare the records so that a sample can be pulled quickly, because gaps found during sampling are common reasons for nonconformities.

Can a partner prepare the A.6.2 records without signing them on our behalf?

Yes, a partner can prepare the templates, clauses, signing workflow and evidence index, provided your organization is the party that issues and collects the signed agreements. Signatures must come from the individuals and from an authorized representative of your organization, so a partner should never sign for staff or for you. Confirm in the written scope which deliverables the partner owns, such as draft clauses and a record structure, and which steps stay with your HR and legal teams, such as approval, execution and storage of signed copies. Only an independent auditor or certification body can issue a report or certificate.

How DeployOpen prepares A.6.2 records for your audit

DeployOpen plans, implements and documents the self-hosted platforms that hold your employment agreement records, policy acknowledgments and HR workflows, inside your own infrastructure. We prepare the systems and evidence an auditor samples for A.6.2, while your organization owns the contract wording, the policy and the control itself.

How we scope

Agree in writing which employment agreement templates, contractor forms and HR systems fall within the A.6.2 scope.
Confirm with your HR and legal teams which information security responsibilities the contracts must state for each role group.
Engagements are fixed-scope, so deliverables and timelines for A.6.2 are set out before any work begins.

How we build

Configure a self-hosted document or HR workflow platform so signed agreements are stored with version history and timestamps.
Link each agreement template to the current information security policy version and the acknowledgment record for each person.
Document the configuration, access rules and retention settings so an assessor can trace how signed records are produced.

How we hand over

Deliver a written evidence map showing which records answer A.6.2 and where each one is stored.
Provide a sample pack of signed agreements and acknowledgments, exported from the running system, for your internal review.
Hand over runbooks for adding new hires, contractors and changed roles, with the owner named for each step.

How we support

Ongoing support, upgrades and continuous testing of the platform are available as retainers after handover.
Your organization decides when to bring in an independent auditor or certification body, which alone issues any report or certificate.
Confirm with your certification body which sample of agreements it expects to see and how far back it will look.