What is ISO 27001 Annex A 6.2?
ISO 27001 Annex A 6.2 requires that employment contracts and terms of employment state the organization’s and the individual’s information security responsibilities.
In simple terms, employees and relevant personnel should understand what security responsibilities apply to them as part of their employment or engagement.
These responsibilities may cover:
- Protecting confidential information.
- Following information security policies.
- Protecting credentials.
- Using company systems appropriately.
- Reporting security incidents.
- Following privacy requirements.
- Complying with applicable security procedures.
- Protecting company and customer information.
- Returning organizational assets.
- Maintaining confidentiality after employment where applicable.
Simple explanation
Security responsibilities should be part of the employment relationship, not something employees discover only after joining.
Why is Annex A 6.2 Important?
Employees can have access to:
- Customer information.
- Personal information.
- Source code.
- Company intellectual property.
- Financial information.
- Production systems.
- Security systems.
- Business plans.
- Confidential contracts.
If security expectations are not clearly established, employees may not understand their responsibilities.
For example:
An organization may have an Information Security Policy stating:
“Employees must protect confidential company information.”
But if employees are never made aware of their obligations and the employment relationship contains no appropriate security responsibilities, the organization may have difficulty demonstrating that these expectations were formally established.
Benefits of A.6.2
- Establishes security responsibilities.
- Sets expectations before or at the beginning of employment.
- Supports confidentiality.
- Supports acceptable use.
- Reinforces incident reporting.
- Helps protect organizational information.
- Supports legal and contractual requirements.
- Creates evidence that personnel were informed of their responsibilities.
Simple principle
People should know their security obligations before they are trusted with organizational information and systems.
What Does Annex A 6.2 Require?
The organization should ensure that appropriate information security responsibilities are communicated and agreed upon as part of the employment or engagement relationship.
These responsibilities should be:
- Appropriate to the role.
- Consistent with applicable laws.
- Consistent with organizational policies.
- Communicated to employees.
- Applicable to relevant contractors and other personnel where appropriate.
- Updated when responsibilities or requirements materially change.
The exact contractual wording will depend on the organization’s:
- Jurisdiction.
- Employment model.
- Industry.
- Role.
- Security requirements.
- Customer commitments.
- Regulatory obligations.
What Should Terms and Conditions Cover?
The exact content will vary, but security-related employment terms may address:
1. Compliance with Security Policies
Employees may be required to follow applicable organizational policies and procedures.
For example:
Employees must comply with applicable information security policies, procedures and standards.
2. Confidentiality
Employees should understand their responsibility to protect confidential information.
This may cover:
- Customer information.
- Company information.
- Trade secrets.
- Source code.
- Business plans.
- Security information.
3. Protection of Credentials
Employees should be responsible for protecting:
- Passwords.
- Authentication information.
- MFA devices.
- Access tokens.
- Security credentials.
They should not share credentials unless a formally authorized mechanism specifically permits it.
4. Acceptable Use
Employment terms may reference appropriate use of:
- Company devices.
- Email.
- Applications.
- Cloud services.
- Internet access.
- Company networks.
- Corporate accounts.
5. Incident Reporting
Employees should understand that they must report suspected security incidents promptly.
Examples:
- Lost device.
- Phishing email.
- Accidental disclosure.
- Suspicious login.
- Malware.
- Unauthorized access.
- Data leakage.
6. Privacy and Personal Data
Where applicable, employees should understand their responsibilities for protecting personal information.
This can include:
- Customer PII.
- Employee information.
- Applicant information.
- Business contact information.
7. Intellectual Property
Employment terms may address organizational ownership and protection of intellectual property according to applicable law and agreements.
Examples:
- Source code.
- Designs.
- Documentation.
- Algorithms.
- Business materials.
- Product information.
8. Return of Assets
Employees should understand their responsibility to return or surrender organizational assets when employment ends.
Examples:
- Laptops.
- Mobile devices.
- ID cards.
- Storage media.
- Physical documents.
- Security tokens.
9. Continuing Responsibilities
Some responsibilities may continue after employment ends, where legally applicable.
Examples:
- Confidentiality.
- Protection of trade secrets.
- Restrictions established by applicable agreements.
- Return or deletion of organizational information.
The exact post-employment obligations should be determined according to applicable law and contractual arrangements.
Activities Required to Implement A.6.2
Step 1 — Identify Security Responsibilities
Start by identifying the responsibilities employees need to understand.
For example:
| Responsibility | Applicable To |
|---|---|
| Information security policies | All employees |
| Confidentiality | All employees |
| Acceptable use | All employees |
| Incident reporting | All employees |
| PII protection | Personnel handling PII |
| Privileged access | Administrators |
| Secure development | Developers |
| Financial data protection | Finance |
| Customer data handling | Customer-facing teams |
Step 2 — Determine How Responsibilities Are Communicated
Security responsibilities may be communicated through a combination of:
- Employment contracts.
- Employment agreements.
- Offer letters.
- Employee handbooks.
- Confidentiality agreements.
- Acceptable-use acknowledgements.
- Information security policy acknowledgements.
- Contractor agreements.
The organization should determine which responsibilities belong directly in contractual terms and which can be incorporated by reference to controlled policies and procedures.
Step 3 — Include Security Requirements in Employment Documentation
A typical employment agreement might establish that the employee must:
- Comply with organizational policies.
- Protect confidential information.
- Protect credentials.
- Report security incidents.
- Use systems appropriately.
- Follow applicable privacy requirements.
- Return organizational assets.
- Comply with security procedures relevant to their role.
The wording should be reviewed by appropriate HR/legal personnel for the organization’s jurisdiction.
Step 4 — Make Policies Available
An employment contract should not be the only place employees encounter security requirements.
Employees should have access to relevant policies such as:
- Information Security Policy.
- Acceptable Use Policy.
- Access Control Policy.
- Password/MFA requirements.
- Data Classification Policy.
- Incident Management Procedure.
- Remote Working Policy.
- Privacy Policy.
This creates a connection between contractual responsibility and operational requirements.
Step 5 — Obtain Acknowledgement
The organization may maintain evidence that employees have:
- Received relevant policies.
- Read them.
- Acknowledged applicable requirements.
- Completed required security training.
The exact acknowledgement method depends on the organization’s processes.
Step 6 — Address Role-Specific Responsibilities
Not everyone has the same security responsibilities.
For example:
Developer
May need to follow:
- Secure coding requirements.
- Code review procedures.
- Source-code access controls.
- Production deployment requirements.
System Administrator
May need to follow:
- Privileged access procedures.
- MFA requirements.
- Logging requirements.
- Emergency access procedures.
HR Employee
May need to follow:
- Employee PII handling requirements.
- HR system access controls.
- Confidentiality requirements.
Role-specific responsibilities can supplement the organization’s general security obligations.
Step 7 — Update Responsibilities When Roles Change
Security responsibilities should be reviewed when:
- An employee changes roles.
- The employee receives privileged access.
- The organization introduces new systems.
- New regulations apply.
- Customer requirements change.
- Security responsibilities materially change.
For example:
A developer becomes a system administrator.
Their new responsibilities may include:
- Privileged access.
- Production administration.
- Emergency changes.
- Security monitoring.
The organization should ensure the employee understands the additional requirements.
Startup Example
Consider a 25-person SaaS startup.
The company provides software to enterprise customers and processes customer information.
The startup establishes the following employment-security requirements:
All Employees
- Follow information security policies.
- Protect company and customer information.
- Protect authentication credentials.
- Report suspected security incidents.
- Use company systems appropriately.
- Complete required security training.
- Return company assets when employment ends.
Developers
Additional requirements:
- Protect source code.
- Follow secure development procedures.
- Follow code review requirements.
- Do not copy customer data into unauthorized development environments.
Administrators
Additional requirements:
- Use privileged accounts appropriately.
- Use MFA.
- Follow emergency access procedures.
- Maintain security of administrative credentials.
Flow
Offer / Employment Agreement
↓
Security Responsibilities
↓
Policy Access
↓
Policy Acknowledgement
↓
Security Training
↓
Role-Specific Requirements
↓
Ongoing Compliance
This gives the organization a practical personnel-security framework.
Startup-Focused Quick Summary
A startup can implement A.6.2 without creating an enormous employment-contract framework.
Start with a basic security clause or appropriate contractual documentation covering:
- Confidentiality.
- Information security policy compliance.
- Acceptable use.
- Credential protection.
- Incident reporting.
- Privacy and personal-data responsibilities.
- Intellectual property protection.
- Asset return.
- Applicable post-employment responsibilities.
Then connect these obligations to the company’s security policies and training.
Example Security Responsibilities Matrix
| Responsibility | Employee | Contractor | Privileged User |
|---|---|---|---|
| Follow security policies | ✓ | ✓ | ✓ |
| Protect credentials | ✓ | ✓ | ✓ |
| Report incidents | ✓ | ✓ | ✓ |
| Protect confidential information | ✓ | ✓ | ✓ |
| Follow acceptable-use requirements | ✓ | ✓ | ✓ |
| Protect PII | Where applicable | Where applicable | Where applicable |
| Secure development requirements | Role-dependent | Role-dependent | Role-dependent |
| Privileged access requirements | — | Where applicable | ✓ |
| Return company assets | ✓ | ✓ | ✓ |
| Post-employment confidentiality | Where applicable | Where applicable | Where applicable |
Example Employee Security Acknowledgement
A company may maintain an acknowledgement confirming that an employee:
- Has received applicable information security policies.
- Understands their security responsibilities.
- Agrees to comply with applicable organizational security requirements.
- Understands their obligation to report security incidents.
- Understands confidentiality responsibilities.
- Understands appropriate use of company systems.
The exact wording should be aligned with the organization’s employment and legal requirements.
A.6.2 and Employee Onboarding
A.6.2 should be connected to onboarding.
A practical onboarding sequence is:
Before or at joining
Employment agreement
↓
Security responsibilities
↓
Confidentiality requirements
↓
Policy access
↓
Security acknowledgement
↓
Security awareness training
↓
Access provisioning
This creates a logical sequence:
Understand responsibilities → receive training → receive access.
A.6.2 and Offboarding
Security responsibilities also connect with employee termination.
When an employee leaves:
- Access should be revoked.
- Organizational assets should be returned.
- Confidential information should remain protected as applicable.
- Company data should not be retained improperly.
- Security credentials should be handled appropriately.
- Relevant continuing obligations should be communicated.
This connects A.6.2 with A.6.5 — Responsibilities After Termination or Change of Employment.
Audit Evidence for A.6.2
An auditor may review:
Employment Documentation
- Employment agreements.
- Offer letters.
- Employee handbook.
- Confidentiality agreements.
- Contractor agreements.
Security Policies
- Information Security Policy.
- Acceptable Use Policy.
- Privacy Policy.
- Access Control Policy.
- Remote Working Policy.
- Data Classification Policy.
Acknowledgement
- Policy acknowledgement records.
- Employee security declarations.
- Electronic acceptance records.
Training
- Security awareness training records.
- New employee onboarding records.
- Role-specific security training.
Role-Specific Responsibilities
- Job descriptions.
- Privileged access agreements.
- Administrator responsibilities.
- Secure development responsibilities.
Changes
- Role-change records.
- Updated responsibilities.
- Additional training.
- Access changes.
What an Auditor May Ask
About Employment Terms
“How are information security responsibilities communicated to employees?”
“Do employment agreements contain security requirements?”
“How do you address confidentiality?”
About Policies
“How do employees know which security policies they must follow?”
“Can you show evidence that employees received and acknowledged the policies?”
About Roles
“Do privileged users have additional security responsibilities?”
“How are role-specific security requirements communicated?”
About Contractors
“How are security responsibilities established for contractors?”
About Changes
“What happens when an employee changes roles?”
“How are new security responsibilities communicated?”
Common Mistakes in Implementing A.6.2
1. Security responsibilities are not documented
Employees are simply told:
“Follow company security policies.”
This may be too vague for important roles.
2. Employment contracts and policies are disconnected
The contract mentions security but employees do not have access to the referenced policies.
3. No acknowledgement
The organization cannot demonstrate that employees received or acknowledged important security requirements.
4. Contractors are ignored
Contractors may have access to the same sensitive information as employees.
Their security obligations should be addressed appropriately.
5. Everyone receives exactly the same requirements
A general employee and a privileged administrator may have different security responsibilities.
6. Security requirements are never updated
Employees move into new roles but their security responsibilities remain unchanged.
7. Overloading employment contracts
Not every operational instruction needs to be inserted directly into an employment contract.
A practical approach is often:
Contractual obligation
Controlled security policies
Procedures
Training
This is easier to maintain.
8. Using generic legal language without operational meaning
A clause such as:
“Employee shall comply with all applicable security requirements.”
is useful but should be supported by actual policies and procedures that define what those requirements are.
Practical Startup Implementation Model
A practical startup model is:
Define
Identify the security responsibilities that apply to personnel.
↓
Document
Include appropriate responsibilities in employment or engagement terms.
↓
Communicate
Provide access to relevant security policies.
↓
Acknowledge
Obtain appropriate acknowledgement.
↓
Train
Provide security awareness and role-specific training.
↓
Grant Access
Provision access according to role and authorization.
↓
Review
Update responsibilities when roles or requirements change.
↓
Offboard
Remove access and reinforce continuing obligations when employment ends.
Policy vs. Process vs. Evidence
| Category | Example |
|---|---|
| Policy | Human Resources Security Policy |
| Policy | Information Security Policy |
| Policy | Acceptable Use Policy |
| Process | Employee Onboarding Procedure |
| Process | Security Policy Acknowledgement Process |
| Process | Role Change Procedure |
| Process | Employee Offboarding Procedure |
| Evidence | Signed employment agreement |
| Evidence | Confidentiality agreement |
| Evidence | Policy acknowledgement |
| Evidence | Security training record |
| Evidence | Role-specific training record |
| Evidence | Employee onboarding checklist |
| Evidence | Role-change record |
Simple rule
Employment terms establish the obligation.
Policies and procedures explain the expected behavior.
Training builds awareness.
Evidence demonstrates that the requirements were communicated and acknowledged.
Relationship with Other ISO 27001 Controls
A.6.2 connects closely with the rest of the personnel-security lifecycle.
| Control | Relationship |
|---|---|
| A.5.34 | Privacy responsibilities |
| A.5.36 | Compliance with organizational security policies |
| A.6.1 | Screening before employment/engagement |
| A.6.2 | Security responsibilities in employment terms |
| A.6.3 | Security awareness, education and training |
| A.6.4 | Disciplinary process |
| A.6.5 | Responsibilities after termination or change |
| A.6.6 | Confidentiality or non-disclosure agreements |
| A.6.7 | Remote working |
| A.6.8 | Information security event reporting |
| A.5.15 | Access control |
| A.5.18 | Access rights |
A.6.1 vs. A.6.2
These controls address different stages of the personnel lifecycle.
A.6.1 — Screening
Before or during engagement
“Have we performed appropriate checks?”
A.6.2 — Terms and Conditions of Employment
At the beginning of the employment relationship
“Have we established the individual’s security responsibilities?”
A.6.3 — Awareness and Training
During employment
“Does the person understand how to perform those responsibilities?”
A.6.5 — After Termination or Change
When the relationship or role changes
“Are security responsibilities and access appropriately managed?”
This creates a personnel-security lifecycle:
Screen → Establish Responsibilities → Train → Operate → Change/Terminate
Useful Documents for A.6.2
Organizations may create:
- [Insert Draft Document Link] — Human Resources Security Policy
- [Insert Draft Document Link] — Employee Security Responsibilities
- [Insert Draft Document Link] — Employment Security Clause Template
- [Insert Draft Document Link] — Confidentiality Agreement Template
- [Insert Draft Document Link] — Employee Security Acknowledgement
- [Insert Draft Document Link] — Employee Onboarding Checklist
- [Insert Draft Document Link] — Contractor Security Agreement
- [Insert Draft Document Link] — Role-Based Security Responsibilities Matrix
- [Insert Draft Document Link] — Employee Role Change Checklist
- [Insert Draft Document Link] — Personnel Security Audit Checklist
A.6.2 Audit Readiness Checklist
Before an ISO 27001 audit, ask:
- Are information security responsibilities defined for employees?
- Are appropriate security responsibilities included in employment or engagement terms?
- Are confidentiality requirements established?
- Are acceptable-use responsibilities communicated?
- Are incident-reporting responsibilities communicated?
- Are privacy responsibilities communicated where applicable?
- Are relevant contractors covered?
- Are employees given access to applicable security policies?
- Are policy acknowledgements maintained?
- Is security awareness training completed?
- Are role-specific responsibilities defined?
- Are responsibilities updated when roles change?
- Are post-employment obligations addressed where applicable?
- Can the organization demonstrate all of the above with evidence?
Questions a Startup Should Ask
Before considering A.6.2 implemented, ask:
Do our employees know their information security responsibilities?
Are those responsibilities established as part of the employment relationship?
Do contractors have appropriate security obligations?
Are employees given access to the policies they are expected to follow?
Do we have evidence that employees received and acknowledged those requirements?
Do privileged roles have additional responsibilities?
What happens when someone changes roles?
What security responsibilities continue after employment ends?
If these questions have clear answers and supporting evidence, the startup has a much stronger foundation for A.6.2.
Startup-Focused Final Takeaway
ISO 27001 Annex A 6.2 is about making information security a formal part of the employment or engagement relationship.
A practical startup approach is:
Screen the individual
↓
Define security responsibilities
↓
Include appropriate terms in employment/engagement documentation
↓
Provide relevant policies
↓
Obtain acknowledgement
↓
Provide security training
↓
Grant appropriate access
↓
Update responsibilities when roles change
↓
Manage obligations during offboarding
The key question for A.6.2 is:
“Have we clearly established what information security responsibilities each employee or relevant worker has, and can we demonstrate that those responsibilities were communicated and acknowledged?”
A strong A.6.2 implementation does not require putting every security procedure into an employment contract. A better practical model is to combine appropriate contractual obligations + controlled security policies + procedures + training + evidence.