1. Purpose
The Contractor Security Agreement defines the information-security, confidentiality, access-control, privacy, technology, and operational-security obligations applicable to contractors providing services to the organization.
The agreement is intended to ensure that contractor activities do not introduce unacceptable risks to:
- Organizational information
- Customer information
- Personal data
- Source code
- Systems and applications
- Cloud environments
- Production environments
- Security infrastructure
- Business operations
Core Principle
Define Responsibilities → Restrict Access → Protect Information → Monitor → Report → Revoke → Return/Delete
2. Parties
This Agreement is between:
Organization: ______________________________
Contractor: ______________________________
Contractor Company, if applicable: ______________________________
Contract / Statement of Work: ______________________________
Effective Date: ______________________________
Contract End Date: ______________________________
3. Scope
This Agreement applies to contractors who:
- Access organizational systems
- Access customer systems or information
- Process personal data
- Access source code
- Access cloud environments
- Access production systems
- Perform security testing
- Perform development or technical services
- Provide IT or managed services
- Access confidential or restricted information
- Support critical business processes
The requirements should be proportionate to the contractor’s role, access, information exposure, and risk.
4. Security Responsibilities
The Contractor agrees to:
☐ Protect organizational information
☐ Protect customer information
☐ Protect personal data
☐ Follow applicable information-security policies
☐ Follow applicable procedures
☐ Use systems only for authorized purposes
☐ Protect credentials
☐ Follow access-control requirements
☐ Follow security instructions
☐ Report security incidents promptly
☐ Report suspected security weaknesses
☐ Cooperate with authorized investigations
☐ Protect organizational assets
☐ Return or securely delete information when required
5. Contractor Personnel
Where the Contractor uses personnel to perform the services:
☐ Personnel must be authorized
☐ Personnel must have appropriate security responsibilities
☐ Confidentiality obligations must apply
☐ Required screening must be completed where applicable
☐ Personnel must receive relevant security requirements
☐ Access must be limited to the personnel who require it
☐ The Contractor remains responsible for its personnel’s compliance with applicable contractual requirements
The Contractor must not provide organizational access to unauthorized personnel.
6. Confidentiality
The Contractor shall protect all confidential information obtained through the engagement.
Confidential information may include:
- Customer information
- Personal data
- Source code
- Credentials
- Security architecture
- Vulnerability information
- Business information
- Product information
- Financial information
- Internal documentation
- System configurations
- Security reports
- Proprietary information
Confidential information must not be disclosed to unauthorized persons.
Where a separate NDA or confidentiality agreement exists, the applicable agreement shall also apply.
7. Information Classification
The Contractor shall follow the organization’s information-classification requirements.
Where information is classified as:
- Public
- Internal
- Confidential
- Restricted
the Contractor shall apply the required protection measures.
The Contractor shall not downgrade, redistribute, or disclose information without authorization.
8. Authorized Use
The Contractor may use organizational information and systems only:
- For the contracted service
- For authorized business purposes
- Within the approved scope
- Using approved systems and methods
The Contractor shall not:
☐ Use information for unrelated purposes
☐ Copy information unnecessarily
☐ Sell or disclose organizational information
☐ Use organizational information for personal purposes
☐ Attempt unauthorized access
☐ Circumvent security controls
☐ Perform unauthorized security testing
☐ Share credentials
9. Access Control
Access shall be:
- Authorized
- Role-based
- Limited to business need
- Least-privilege
- Time-bound where practical
- Individually attributable
The Contractor shall not use another person’s account.
Shared accounts should not be used unless specifically approved and appropriately controlled.
10. Contractor Access Approval
Before access is granted:
☐ Business requirement identified
☐ Contractor identity verified
☐ Role identified
☐ Required systems identified
☐ Information access identified
☐ Access level defined
☐ Manager/system owner approval obtained
☐ Security approval obtained where required
☐ Contractual requirements completed
☐ MFA configured where applicable
11. Authentication and MFA
The Contractor shall:
☐ Use individual accounts
☐ Protect authentication credentials
☐ Use MFA where required
☐ Not share passwords
☐ Not share MFA codes
☐ Protect authentication devices
☐ Report compromised credentials immediately
☐ Follow organizational password requirements
12. Privileged Access
Where privileged access is required:
☐ Business justification shall be documented
☐ Access shall be separately approved
☐ Individual privileged accounts shall be used
☐ MFA shall be enabled where applicable
☐ Access shall be limited to required systems
☐ Administrative activity may be logged
☐ Temporary access shall be used where practical
☐ Access shall be revoked when no longer required
13. Production Access
Production access requires additional authorization.
The Contractor shall:
☐ Obtain specific approval
☐ Use approved accounts
☐ Use MFA
☐ Follow change-management requirements
☐ Follow production-access procedures
☐ Avoid unnecessary production data access
☐ Avoid copying production data
☐ Follow logging and monitoring requirements
☐ Follow emergency-access procedures
14. Cloud Security
Where the Contractor accesses cloud environments:
☐ Approved cloud accounts shall be used
☐ Individual identities shall be used
☐ MFA shall be enabled
☐ Least privilege shall be applied
☐ Cloud credentials shall be protected
☐ Administrative access shall be restricted
☐ Production access shall be separately controlled
☐ Cloud security policies shall be followed
☐ Unauthorized cloud resources shall not be created
15. AWS Security
Where AWS access is provided:
☐ Individual IAM/SSO identity shall be used
☐ MFA shall be enabled
☐ Access shall be role-based
☐ Least privilege shall be applied
☐ AWS root-account access shall not be provided for routine contractor activities
☐ Production access shall be separately authorized
☐ Administrative permissions shall be restricted
☐ AWS activity may be logged and monitored
☐ Access shall be revoked when no longer required
16. Source-Code Security
Where source-code access is required:
☐ Repository access must be approved
☐ Individual accounts must be used
☐ MFA must be enabled where required
☐ Source code must be protected
☐ Code must not be copied unnecessarily
☐ Source code must not be uploaded to unauthorized platforms
☐ Secrets must not be committed to source code
☐ Code-review requirements must be followed
☐ Production deployment permissions must be separately controlled
17. Secrets and Credentials
The Contractor shall protect:
- Passwords
- API keys
- Access tokens
- SSH keys
- Certificates
- Cloud credentials
- Database credentials
- Encryption keys
- Service-account credentials
The Contractor shall:
☐ Store secrets securely
☐ Avoid storing secrets in source code
☐ Avoid sharing credentials
☐ Rotate credentials when required
☐ Report suspected compromise immediately
☐ Return or destroy credentials when required
18. Information Transfer
The Contractor shall use approved methods for transferring organizational information.
☐ Approved file-sharing systems
☐ Encrypted communication where required
☐ Approved email channels
☐ Secure API connections
☐ Access-controlled repositories
☐ Secure transfer mechanisms
The Contractor shall not use personal email, unauthorized cloud storage, or unauthorized file-sharing services for restricted information.
19. Personal Data
Where the Contractor processes personal data:
☐ Processing shall be limited to authorized purposes
☐ Access shall be restricted
☐ Data minimization shall be followed
☐ Personal data shall be protected
☐ Unauthorized disclosure shall be prohibited
☐ Retention requirements shall be followed
☐ Deletion/return requirements shall be followed
☐ Security incidents shall be reported
☐ Applicable privacy requirements shall be followed
A separate Data Processing Agreement should be established where required.
20. Customer Information
Where customer information is accessible:
☐ Customer requirements shall be followed
☐ Access shall be limited
☐ Customer information shall not be used for unrelated purposes
☐ Information shall not be disclosed without authorization
☐ Customer-specific security requirements shall be followed
☐ Security incidents affecting customer information shall be reported
21. AI and Generative AI
The Contractor shall not submit organizational, customer, personal, confidential, restricted, or source-code information to an AI or Generative AI service unless expressly authorized.
Where AI tools are approved:
☐ Approved tool shall be used
☐ Data-use terms shall be understood
☐ Confidentiality requirements shall be maintained
☐ Customer information restrictions shall be followed
☐ Personal-data requirements shall be followed
☐ Source-code restrictions shall be followed
☐ AI-generated output shall be reviewed where required
22. Contractor Devices
Where the Contractor uses its own device:
☐ Device must meet agreed security requirements
☐ Supported operating system must be used
☐ Security updates must be maintained
☐ Malware protection must be maintained where applicable
☐ Device encryption should be enabled where required
☐ Screen locking must be enabled
☐ Organizational information must be protected
☐ Unauthorized persons must not access organizational information
The organization may require use of managed devices for higher-risk activities.
23. Remote Working
Contractors working remotely shall:
☐ Protect organizational information
☐ Secure their workspace
☐ Protect company devices
☐ Use approved connectivity
☐ Avoid exposing confidential information in public environments
☐ Use MFA
☐ Follow remote-working requirements
☐ Report lost devices or suspected compromise
24. Security Testing
Where the Contractor performs security testing:
☐ Testing scope shall be documented
☐ Written authorization shall be obtained
☐ Testing window shall be defined
☐ Systems in scope shall be identified
☐ Testing limitations shall be documented
☐ Production testing shall require explicit authorization
☐ Test credentials shall be controlled
☐ Findings shall be protected
☐ Testing evidence shall be securely handled
☐ Access shall be revoked after testing
Unauthorized security testing is prohibited.
25. Vulnerability Information
Vulnerability information must be treated as sensitive information where applicable.
The Contractor shall:
☐ Protect vulnerability information
☐ Limit access
☐ Avoid unauthorized disclosure
☐ Use approved reporting channels
☐ Protect penetration-test reports
☐ Protect security-testing evidence
☐ Notify the organization of critical security issues promptly
26. Security Incident Reporting
The Contractor shall promptly report suspected security incidents.
Examples include:
- Unauthorized access
- Credential compromise
- Malware
- Phishing
- Lost device
- Data leakage
- Accidental disclosure
- Suspicious cloud activity
- Source-code exposure
- Security weakness
- Unauthorized access to customer information
Security Contact
Security Contact: __________________________
Email: __________________________
Emergency Contact: __________________________
Incident Portal: __________________________
27. Security Incident Cooperation
Following a security incident, the Contractor shall, as appropriate:
☐ Cooperate with investigation
☐ Preserve relevant evidence
☐ Provide requested information
☐ Support containment
☐ Support remediation
☐ Assist with impact assessment
☐ Support required customer/regulatory actions
☐ Implement agreed corrective actions
The Contractor shall not destroy relevant evidence without authorization where preservation is required.
28. Logging and Monitoring
Where applicable, organizational systems may log and monitor contractor activity for purposes including:
- Security
- Access control
- Incident investigation
- Compliance
- Operational protection
- Fraud prevention
Contractor activity may be subject to monitoring in accordance with applicable law, contractual requirements, and organizational policies.
29. Change Management
Contractors shall not make unauthorized changes to organizational systems.
Where applicable:
☐ Change request required
☐ Impact assessed
☐ Security impact assessed
☐ Approval obtained
☐ Testing completed
☐ Implementation window defined
☐ Rollback plan defined
☐ Change documented
☐ Post-change validation completed
30. Software and Tools
Contractors shall use only approved software and tools for organizational work where required.
The Contractor shall not introduce unauthorized:
- Software
- Libraries
- Cloud services
- SaaS applications
- Scripts
- Extensions
- Remote-access tools
- Security tools
Software and tools introduced into organizational environments may be subject to security review.
31. Open-Source Software
Where development services are provided:
☐ Open-source components shall be used appropriately
☐ Applicable licenses shall be respected
☐ Security requirements shall be followed
☐ Components shall be identified where required
☐ Known vulnerabilities shall be addressed
☐ Unauthorized components shall not be introduced into production
32. Physical Security
Where contractors access organizational facilities:
☐ Access badge requirements shall be followed
☐ Visitor requirements shall be followed
☐ Secure-area restrictions shall be followed
☐ Company assets shall be protected
☐ Confidential information shall not be exposed to unauthorized persons
☐ Badges must not be shared
33. Security Awareness
The Contractor shall complete required security awareness activities where applicable.
Topics may include:
- Information protection
- Phishing
- Password security
- MFA
- Incident reporting
- Data protection
- Remote working
- Acceptable use
- AI security
- Customer information protection
34. Background Verification
Where the nature of the role requires screening:
☐ Identity verification
☐ Employment/engagement verification
☐ Qualification verification
☐ Reference checks
☐ Criminal checks where lawful and relevant
☐ Regulatory/sanctions screening where applicable
☐ Additional checks for security-sensitive roles
The organization should determine screening requirements based on role risk and applicable law.
35. Subcontractors
The Contractor shall not subcontract services involving organizational information or systems without authorization where contractual requirements require approval.
Where subcontractors are approved:
☐ Subcontractor identified
☐ Role documented
☐ Access identified
☐ Information identified
☐ Security requirements communicated
☐ Confidentiality obligations established
☐ Screening requirements considered
☐ Access restricted
☐ Organization approval obtained where required
36. Information Retention
The Contractor shall retain organizational information only for:
- The approved business purpose
- The agreed contractual period
- The required legal/regulatory period
Unnecessary copies should not be retained.
37. Information Return and Deletion
At the end of the engagement, or when otherwise required:
☐ Organizational information returned
☐ Customer information returned
☐ Personal data returned/deleted where required
☐ Source code returned or access removed
☐ Local copies deleted
☐ Cloud copies deleted where required
☐ Backup copies addressed where applicable
☐ Credentials returned/revoked
☐ Evidence of deletion provided where required
38. Contractor Offboarding
At termination or completion:
☐ Contractor access identified
☐ User accounts disabled
☐ Privileged access revoked
☐ AWS/cloud access revoked
☐ SaaS access revoked
☐ Source-code access revoked
☐ VPN access revoked
☐ API tokens revoked
☐ SSH keys addressed
☐ Certificates addressed
☐ Credentials rotated where necessary
☐ Assets returned
☐ Information returned/deleted
☐ Subcontractor access revoked
☐ Offboarding evidence retained
39. Continuing Confidentiality
Confidentiality obligations shall continue after termination to the extent required by the applicable agreement, law, or contractual obligations.
Termination of access does not automatically terminate confidentiality obligations.
40. Security Exceptions
The Contractor shall not intentionally deviate from security requirements without authorization.
Any exception shall:
☐ Be documented
☐ Include business justification
☐ Be risk assessed
☐ Identify compensating controls
☐ Have appropriate approval
☐ Have a defined duration
☐ Be monitored
☐ Be closed or renewed through an approved process
41. Security Audit and Assurance
Where contractually agreed and proportionate to risk, the organization may request reasonable evidence of security compliance.
Evidence may include:
- Security certifications
- Security questionnaires
- Penetration-test summaries
- Security policies
- Training records
- Access records
- Incident information
- Business continuity evidence
- Relevant assurance reports
The Contractor shall not be required to disclose unrelated confidential information unless specifically agreed.
42. Security Requirements for High-Risk Contractors
Additional requirements may apply where the Contractor has:
- Production access
- Privileged access
- Customer-data access
- Personal-data access
- Source-code access
- Cloud administration access
- Security-system access
- Critical operational responsibilities
Additional controls may include:
☐ Enhanced screening
☐ Stronger authentication
☐ Managed device requirement
☐ Temporary access
☐ Session monitoring
☐ Additional security training
☐ Additional contractual controls
☐ Periodic access review
☐ Independent security assessment
43. Contractor Security Review
The organization may periodically review contractor security requirements based on risk.
The review may consider:
☐ Access changes
☐ Information changes
☐ Security incidents
☐ Vulnerabilities
☐ Service changes
☐ Subcontractors
☐ Contract changes
☐ Business criticality
☐ Security assurance
☐ Previous findings
44. Security Findings and Corrective Action
Where security weaknesses are identified:
☐ Finding documented
☐ Risk assessed
☐ Contractor notified
☐ Corrective action defined
☐ Owner assigned
☐ Target date established
☐ Remediation evidence obtained
☐ Effectiveness verified
☐ Residual risk assessed
☐ Finding closed or formally accepted
45. Contractor Obligations During Business Disruption
Where applicable, the Contractor shall:
☐ Follow business-continuity instructions
☐ Follow disaster-recovery requirements
☐ Protect information during disruption
☐ Maintain agreed services
☐ Support recovery activities
☐ Communicate service-impacting issues
☐ Follow emergency-access requirements
46. Customer and Regulatory Requirements
Where applicable, the Contractor shall comply with security requirements arising from:
- Customer contracts
- Regulatory requirements
- Privacy obligations
- Industry requirements
- Service agreements
- Security standards
- Organizational policies
The Contractor shall be informed of requirements applicable to the services being provided.
47. Contractor Security Contact
Primary Security Contact: __________________________
Email: __________________________
Phone: __________________________
Escalation Contact: __________________________
48. Contractor Declaration
The Contractor confirms that:
☐ Security responsibilities have been communicated.
☐ Applicable security requirements have been reviewed.
☐ Confidential information will be protected.
☐ Organizational systems will be used only for authorized purposes.
☐ Access will not be shared.
☐ Credentials will be protected.
☐ Security incidents will be reported promptly.
☐ Unauthorized security testing will not be performed.
☐ Organizational and customer information will not be disclosed without authorization.
☐ Applicable privacy requirements will be followed.
☐ Security requirements will be followed during remote work.
☐ Organizational information will be returned or securely deleted when required.
☐ Contractor access will be surrendered at the end of the engagement.
49. Organization Responsibilities
The organization should:
☐ Define contractor requirements
☐ Identify required access
☐ Approve access
☐ Communicate applicable policies
☐ Provide required security guidance
☐ Monitor access where appropriate
☐ Review contractor security where required
☐ Revoke access at termination
☐ Protect contractor personal information
☐ Provide appropriate security contacts
50. Contract Information
Contract / SOW Reference: __________________________
Service: __________________________
Business Owner: __________________________
Supplier/Contractor Owner: __________________________
Security Owner: __________________________
Contract Start: __________________________
Contract End: __________________________
51. Approval
Organization
Name: __________________________
Role: __________________________
Signature: __________________________
Date: __________________________
Contractor
Name: __________________________
Role: __________________________
Signature: __________________________
Date: __________________________
52. Contractor Security Evidence
The organization should retain appropriate evidence such as:
- Signed Contractor Security Agreement
- NDA/confidentiality agreement
- Contract/SOW
- Contractor screening evidence/status
- Security questionnaire
- Security assessment
- Access approvals
- MFA evidence
- Privileged-access approval
- Production-access approval
- Security training
- Policy acknowledgement
- Security review records
- Findings
- Corrective actions
- Incident records
- Offboarding evidence
Sensitive credentials and secret values should never be retained as routine security-agreement evidence.
53. AWS SaaS Startup Example
An AWS SaaS startup engages an external DevOps contractor for a three-month infrastructure project.
The contractor requires:
- AWS access
- GitHub access
- CI/CD access
- Temporary production access
Before Access
The startup:
- Confirms the business requirement.
- Verifies the contractor.
- Completes required screening.
- Signs the Contractor Security Agreement.
- Defines required access.
- Approves privileged/production access separately.
- Enables MFA.
- Provides only required permissions.
During Engagement
The contractor must:
- Use individual accounts.
- Protect credentials.
- Follow change management.
- Protect source code.
- Avoid unnecessary production-data access.
- Report security incidents.
- Follow approved AI and cloud requirements.
End of Engagement
The startup:
- Revokes AWS access.
- Revokes GitHub access.
- Revokes CI/CD access.
- Revokes VPN/SaaS access where applicable.
- Rotates credentials where necessary.
- Recovers company assets.
- Confirms return/deletion of information.
- Records completion evidence.
Audit Trail
Contract → Contractor → Screening → Security Agreement → Access Approval → MFA → Controlled Access → Monitoring → Review → Revocation → Return/Delete → Closure
54. Startup-Friendly Contractor Security Model
For a small startup, the process can remain simple.
Before Engagement
Contract → NDA → Role/Risk → Screening → Security Requirements → Access Approval
During Engagement
MFA → Least Privilege → Secure Devices → Incident Reporting → Monitoring → Review
End of Engagement
Revoke → Return/Delete → Rotate Secrets → Verify → Record
For high-risk contractors, add:
- Enhanced screening
- Managed devices
- Temporary privileged access
- Production-access approval
- Additional security review
- Periodic access recertification
55. Common Mistakes
Avoid:
- Giving contractors access before the agreement is completed.
- Giving access based only on the contractor’s job title.
- Allowing shared accounts.
- Giving permanent access for temporary work.
- Giving production access without separate approval.
- Allowing contractor personnel to use unauthorized subcontractors.
- Ignoring contractor-owned devices.
- Failing to protect source code.
- Failing to control cloud credentials.
- Allowing confidential information to be uploaded to unauthorized AI tools.
- Failing to revoke access when the contract ends.
- Forgetting API keys, SSH keys, certificates, tokens, and SaaS accounts during offboarding.
- Treating the signed agreement as proof that security controls are operating effectively.
56. Relationship With Other ISMS Documents
| Document | Relationship |
|---|---|
| Supplier Security Requirements | Defines security requirements for external parties |
| Contractor Screening Procedure | Defines contractor screening |
| Contractor Screening Checklist | Verifies screening |
| Supplier Onboarding Checklist | Supports supplier onboarding |
| Contractor Access Procedure | Controls contractor access |
| Access Management Procedure | Controls account and access lifecycle |
| Confidentiality Agreement | Establishes confidentiality obligations |
| Data Processing Agreement | Addresses applicable personal-data processing |
| Security Awareness Procedure | Provides security training |
| Incident Response Procedure | Handles contractor-related incidents |
| Supplier Security Review | Periodically evaluates supplier security |
| Supplier Offboarding Checklist | Supports relationship termination |
| Contractor Offboarding Procedure | Controls contractor exit |
57. ISO/IEC 27001 Connection
A Contractor Security Agreement supports the organization’s management of supplier and external-party security requirements, access control, information protection, confidentiality, incident reporting, and termination of access.
However, a Contractor Security Agreement is not itself a universally prescribed ISO/IEC 27001 document or form.
The organization should determine the applicable requirements based on:
- ISMS scope
- Contractor risk
- Information accessed
- System access
- Privileged access
- Production access
- Customer requirements
- Legal and regulatory requirements
- Contractual obligations
- Applicable controls
The agreement should be consistent with the organization’s supplier-security and access-management framework.
58. Audit Evidence Checklist
☐ Approved contract
☐ Contractor Security Agreement
☐ NDA/confidentiality agreement
☐ Contractor identity verification
☐ Screening evidence/status
☐ Role-risk assessment
☐ Security requirements
☐ Access request
☐ Access approval
☐ MFA
☐ Privileged-access approval
☐ Production-access approval
☐ Security training
☐ Policy acknowledgement
☐ Security review
☐ Findings
☐ Corrective actions
☐ Incident records where applicable
☐ Access revocation
☐ Asset return
☐ Information return/deletion
☐ Credential/token revocation
☐ Offboarding evidence
59. Final Contractor Security Audit Trail
For every significant contractor relationship, the organization should be able to demonstrate:
Why was the contractor engaged?
Who is the contractor?
What service are they providing?
What information will they access?
What systems will they access?
What level of access is required?
What security requirements apply?
Were screening requirements completed?
Was the security agreement completed?
Who approved the access?
Was MFA enabled?
Was privileged or production access separately approved?
How was contractor activity controlled?
How were security incidents handled?
Were subcontractors controlled?
When was access revoked?
Were information and assets returned or deleted?
Was the contractor relationship formally closed?
Final Principle
A contractor should receive access because it is required for an approved business purpose—not simply because the contractor is working for the organization.
The strongest contractor-security model connects contractual obligations, screening, confidentiality, least privilege, MFA, information protection, monitoring, incident reporting, and secure offboarding into one traceable lifecycle.