Purpose of the Template
When a third-party contractor's compromised session leads to a data breach, your incident response starts with questions you should've answered months earlier: What access did they have? Who approved it? When was it last reviewed? AdaptHealth recently disclosed a social engineering attack involving a third-party contractor, highlighting the risks of undocumented access.
This policy template establishes the governance framework for granting, monitoring, and terminating third-party access to your systems and data. It's designed for healthcare organizations subject to HIPAA Security Rule requirements, but the controls apply to any environment where external parties handle sensitive data. You'll use this to define access approval workflows, set review cadences, and create an audit trail that satisfies both internal oversight and external examinations.
Prerequisites
Before implementing this policy, ensure you have:
- An inventory of all third-party relationships that involve system access or data sharing, including contractors, vendors, service providers, and business associates under HIPAA.
- A data classification scheme distinguishing between public, internal, confidential, and restricted data. Your access controls should scale with classification levels.
- Role-Based Access Control infrastructure that assigns permissions by function, not individual. Third parties receive role assignments, not unrestricted access.
- A designated access governance owner (typically your CISO, Chief Compliance Officer, or Risk Manager) who approves exceptions and reviews quarterly reports.
If you're missing any of these, address them first. A policy without supporting infrastructure creates compliance theater, not security.
The Template
THIRD-PARTY VENDOR ACCESS POLICY
1. SCOPE AND APPLICABILITY
This policy applies to all external parties requiring access to [ORGANIZATION NAME] information systems, applications, or data repositories. This includes:
- Contractors and consultants
- Managed service providers
- Software vendors requiring administrative access
- Business associates as defined under HIPAA
- Auditors and compliance assessors
2. ACCESS REQUEST AND APPROVAL
2.1 Initial Access Request
All third-party access requests must include:
- Business justification tied to a specific project or service
- Scope of access required (systems, applications, data types)
- Duration of access need (with specific end date)
- Sponsoring business owner within [ORGANIZATION NAME]
- Confirmation of executed Business Associate Agreement (if applicable)
2.2 Approval Authority
- Standard access (read-only, non-production): Department head approval
- Elevated access (write, production systems): CISO or designee approval
- Access to restricted data (PHI, PII, financial): Chief Compliance Officer approval
2.3 Social Engineering Awareness Requirement
Before access is provisioned, the third party's point of contact must complete our social engineering awareness training module and acknowledge receipt of our security incident reporting procedures.
3. ACCOUNT PROVISIONING
3.1 Account Standards
- Third-party accounts must be clearly identifiable (naming convention: VENDOR_[CompanyName]_[Function])
- No shared credentials between vendors or between vendor and employee accounts
- [Multi-Factor Authentication](https://www.cisa.gov/mfa) required for all remote access
- [Just-in-Time Access](https://www.microsoft.com/en-us/security/blog/2020/05/11/just-in-time-access-in-azure-active-directory/) for administrative functions (maximum 8-hour sessions)
3.2 Principle of Least Privilege
Access grants are limited to:
- Specific systems required for the defined business purpose
- Minimum permission level necessary to complete assigned tasks
- Restricted to approved IP ranges or VPN endpoints where technically feasible
4. MONITORING AND REVIEW
4.1 Continuous Monitoring
Third-party sessions are subject to:
- Real-time logging of authentication events and privilege escalations
- Automated alerts for access outside approved hours or from unapproved locations
- Session recording for privileged access to production environments
4.2 Quarterly Access Reviews
Access governance owner conducts quarterly reviews of:
- All active third-party accounts and their permission levels
- Business justification for continued access
- Alignment with current contracts and project status
Business owners must revalidate need within 10 business days or access is automatically suspended.
5. ACCESS TERMINATION
5.1 Scheduled Termination
When the approved access period expires or project concludes:
- Access is automatically disabled on the specified end date
- Business owner receives 7-day advance notice to request extension
- Extensions require new approval following Section 2.2 process
5.2 Emergency Revocation
Access is immediately revoked when:
- Contract or Business Associate Agreement terminates
- Security incident involves the third-party account
- Third-party organization reports a breach or compromise
- Business owner requests termination
6. INCIDENT REPORTING
Third parties must report suspected [security incidents](https://www.cisa.gov/security-incident) involving [ORGANIZATION NAME] data or systems within 2 hours of discovery via [INCIDENT REPORTING CHANNEL].
7. COMPLIANCE AND AUDIT
This policy supports compliance with:
- HIPAA Security Rule §164.308(a)(4) (Information Access Management)
- HIPAA Security Rule §164.312(a)(2)(i) (Unique User Identification)
- [ISO/IEC 27001:2022](https://www.iso.org/standard/82875.html) Control 5.18 (Access Rights)
- ISO/IEC 27001:2022 Control 5.19 (Information Security in Supplier Relationships)
Policy violations may result in immediate access termination and contract review.
EFFECTIVE DATE: [DATE]
REVIEW CYCLE: Annual
POLICY OWNER: [TITLE]
Customization Tips
Adjust approval thresholds based on your organization's size and structure. A 50-person company doesn't need three-tier approval; a large healthcare system might need more. The key is documented accountability at each level.
Define your access duration defaults. Some organizations set 90-day maximum initial grants with renewal requirements. Others tie duration to contract length. Choose what fits your risk tolerance, but avoid "indefinite" access.
Tailor the social engineering awareness requirement to your threat profile. If you're seeing credential phishing attempts targeting vendors, consider requiring annual refresher training and phishing simulation participation.
Specify your monitoring tools. Replace generic "real-time logging" with your actual SIEM platform and detection rules. If you're using Privileged Access Management tools for session recording, name them. Specificity helps during audits.
Add industry-specific requirements. If you're subject to NYDFS Cybersecurity Regulation, reference the annual vendor risk assessment requirement. If you handle payment card data, add PCI DSS Service Provider validation requirements.
Validation Steps
Map existing third-party accounts to the new policy. Export your current vendor access list and check each account against the provisioning standards. You'll find accounts that violate the policy immediately (shared credentials, no expiration dates, excessive permissions). Document these as remediation items with deadlines.
Test your approval workflow. Submit a mock access request and track it through your approval chain. Time how long it takes. If standard requests take more than 3 business days, your process will get bypassed during urgent projects.
Run a quarterly review simulation. Pull the list of third-party accounts your policy owner should review. Can they easily determine business justification, current project status, and whether access is still needed? If not, your account provisioning process isn't capturing the right metadata.
Verify your monitoring capabilities. Pick three active third-party accounts and check your SIEM for their authentication logs, privilege escalations, and data access events. If you can't see these activities, your monitoring controls don't match your policy commitments.
Schedule your first compliance audit. Within 60 days of policy adoption, have your internal audit team or external assessor review a sample of third-party access grants against the policy requirements. Expect findings. Use them to refine the policy and close gaps before your next SOC 2 Type II or HIPAA assessment.
This policy won't prevent every social engineering attack, but it creates the control structure that limits damage when a third-party account is compromised. The difference between a contained incident and an SEC disclosure often comes down to whether you can answer "who had access to what" with documentation instead of guesswork.
