Vanta policy template instructions
This Vanta policy template represents a complete, compliance-ready policy with placeholders for company specific text. Each policy section represents a policy-specific topic that you should consider and/or modify to match your company’s practices.
For each policy section
Consider if this section and its corresponding risks applies to you. If it does not, remove it and/or replace it with your organization’s corresponding practices.
Replace any highlighted text in angled brackets < >1 with your own language
Rewrite the policy language such that it reflects the practices of your organization
Policy completion checklist
Use Find to make sure that all text in angled brackets is replaced
Proofread your policy for spelling and grammar mistakes
Confirm that the policy’s content reflects your organizations practices
Add any company-specific letterhead, branding, and formatting
Remove this instructions page
Export this document as PDF — File > Save As > Change “File Format” to PDF
Upload the PDF to Vanta at https://app.vanta.com/policies
More questions?
A good rule-of-thumb is to keep your language high enough level such that it stays representative for at least a year. If you have more questions about how to use this template, please reach out to support@vanta.com or your auditor for additional guidance.
Access Control Policy
Policy Owner: <Policy owner>
Effective Date: <Effective date>
...
To limit access to information and information processing systems, networks, and facilities to authorized parties in accordance with business objectives.
...
All <Company Name> information systems that process, store, or transmit confidential data as defined in the <Company Name> Data Management Policy2. This policy applies to all employees of <Company Name> and to all external parties with access to <Company Name> networks and system resources.
...
Access to information computing resources is limited to personnel with a business requirement for such access. Access rights shall be granted or revoked in accordance with this Access Control Policy.
...
Access Control Policy
<Company Name> shall determine the type and level of access granted to individual users based on the “principle of least privilege.” This principle states that users are only granted the level of access absolutely required to perform their job functions, and is dictated by <Company Name>’s business and security requirements. Permissions and access rights not expressly granted shall be, by default, prohibited.
<Company Name>’s primary method of assigning and maintaining consistent access controls and access rights shall be through the implementation of Role-Based Access Control (RBAC). Wherever feasible, rights and restrictions shall be allocated to groups. Individual user accounts may be granted additional permissions as needed with approval from the system owner or authorized party.
All privileged access to production infrastructure shall use Multi-Factor Authentication (MFA)3.
Access to Networks and Network Services
The following security standards shall govern access to <Company Name> networks and network services:
Technical access to <Company Name> networks must be formally documented including the standard role or approver, grantor, and date
Only authorized <Company Name> employees and third-parties working off a signed contract or statement of work, with a business need, shall be granted access to the <Company Name> production networks and resources
<Company Name> guests may be granted access to guest networks after registering with office staff without a documented request
Remote connections to production systems and networks must be encrypted
...
When configuring cross-account access using AWS IAM roles, you must use a value you generate for the external ID, instead of one provided by the customer, to ensure the integrity of the cross account role configuration. A partner-generated external ID ensures that malicious parties cannot impersonate a customer's configuration and enforces uniqueness and format consistency across all customers.
The external IDs used must be unique across all customers. Re-using external IDs for different customers does not solve the confused deputy problem and runs the risk of customer A being able to view data of customer B by using the role ARN of customer B along with the external ID of customer B.
Customers must not be able to set or influence external IDs. When the external ID is editable, it is possible for one customer to impersonate the configuration of another.
...
<Company Name> requires that all personnel have a unique user identifier for system access, and that user credentials and passwords are not shared between multiple personnel. Users with multiple levels of access (e.g. administrators) should be given separate accounts for normal system use and for administrative functions wherever feasible. Root, service, and administrator accounts may use a password management system to share passwords for business continuity purposes only. Administrators shall only use shared administrative accounts as needed. If a password is compromised or suspected of compromise the incident should be escalated to <IR Team> immediately and the password must be changed.
User Registration and Deregistration
Only authorized administrators shall be permitted to create new user IDs, and may only do so upon receipt of a documented request from authorized parties. User provisioning requests must include approval from data owners or <Company Name> management authorized to grant system access. Prior to account creation, administrators should verify that the account does not violate any <Company Name> security or system access control policies such as segregation of duties, fraud prevention measures, or access rights restrictions.
User IDs shall be promptly disabled or removed when users leave the organization or contract work ends in accordance with SLAs. User IDs shall not be re-used.
User Access Provisioning
New employees and/or contractors are not to be granted access to any <Company Name> production systems until after they have completed all HR on-boarding tasks, which may include but is not limited to signed employment agreement, intellectual property agreement, and acknowledgement of <Company Name>’s information security policy
Access should be restricted to only what is necessary to perform job duties
No access may be granted earlier than official employee start date
Access requests and rights modifications shall be documented in an access request ticket or email. No permissions shall be granted without approval from the system or data owner or management
Records of all permission and privilege changes shall be maintained for no less than one year
Management of Privileged Access
Granting of administrative rights shall be strictly controlled, and requires approval from the asset owner.
User Access Reviews
Administrators shall perform access rights reviews of user, administrator, and service accounts on a <quarterly> basis to verify that user access is limited to systems that are required for their job function. Access reviews shall be documented.
Access reviews may include group membership as well as evaluations of any specific or exception-based permission. Access rights shall also be reviewed as part of any job role change, including promotion, demotion, or transfer within the company.
Removal & Adjustment of Access Rights
The access rights of all users shall be promptly removed upon termination of their employment or contract, or when rights are no longer needed due to a change in job function or role. The maximum allowable time period for access termination is <time, e.g., 24> business hours.
Access Provisioning, Deprovisioning, and Change Procedure
The Access Management Procedure for <Company Name> systems can be found in Appendix A to this policy.
...
Conflicting duties and areas of responsibility shall be segregated to reduce opportunities for unauthorized or unintentional modification or misuse of <Company Name> assets. When provisioning access, care should be taken that no single person can access, modify or use assets without authorization or detection. The initiation of an event should be separated from its authorization. The possibility of collusion should be considered when determining access levels for individuals and groups.
...
Control and management of individual user passwords is the responsibility of all <Company Name> personnel and third-party users. Users shall protect secret authentication information in accordance with the Information Security Policy.
...
Where feasible, passwords for confidential systems shall be configured for at least <minimum password requirements>:
<e.g., eight (8) or more characters, one upper case, one number>
<Systems shall be configured to remember and prohibit reuse of passwords for last <16> passwords used>
<Passwords shall be set to lock out after <6> failed attempts>
<Passwords shall expire after <90 days>>
<Initial passwords must be set to a unique value and changed after first log in>
<For manual password resets, a user’s identity must be verified prior to changing passwords>
<Do not limit the permitted characters that can be used>
<Do not limit the length of the password to anything below 64 characters>
<Do not use secret questions (place of birth, etc) as a sole password reset requirement>
<Require email verification of a password change request>
<Require the current password in addition to the new password during password change>
<Verify newly created passwords against common passwords lists or leaked passwords databases>
<Check existing user passwords for compromise regularly>
<Store passwords in a hashed and salted format using a memory-hard or CPU-hard one-way hash function>
<Enforce appropriate account lockout and brute-force protection on account access>
...
Information Access Restriction
Applications must restrict access to program functions and information to authorized users and support personnel in accordance with the defined access control policy. The level and type of restrictions applied by each application should be based on the individual application requirements, as identified by the data owner. The application-specific access control policy must also conform to <Company Name> policies regarding access controls and data management.
Prior to implementation, evaluation criteria are to be applied to application software to determine the necessary access controls and data policies. Assessment criteria include, but are not limited to:
Sensitivity and classification of data.
Risk to the organization of unauthorized access or disclosure of data
The ability to, and granularity of, control(s) on user access rights to the application and data stored within the application
Restrictions on data outputs, including filtering sensitive information, controlling output, and restricting information access to authorized personnel
Controls over access rights between the evaluated application and other applications and systems
Programmatic restrictions on user access to application functions and privileged instructions
Logging and auditing functionality for system functions and information access
Data retention and aging features
All unnecessary default accounts must be removed or disabled before making a system available on the network. Specifically, vendor default passwords and credentials must be changed on all <Company Name> systems, devices, and infrastructure prior to deployment. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, and Simple Network Management Protocol (SNMP) community strings where feasible.
Secure Log-on Procedures
Secure log-on controls shall be designed and selected in accordance with the sensitivity of data and the risk of unauthorized access based on the totality of the security and access control architecture.
Password Management System
Systems for managing passwords should be interactive and assist <Company Name> personnel in maintaining password standards by enforcing password strength criteria including minimum length, and password complexity where feasible.
All storage and transmission of passwords is to be protected using appropriate cryptographic protections, either through hashing or encryption.
Use of Privileged Utility Programs
Use of utility programs, system files, or other software that might be capable of overriding system and application controls or altering system configurations must be restricted to the minimum personnel required. Systems are to maintain logs of all use of system utilities or alteration of system configurations. Extraneous system utilities or other privileged programs are to be removed or disabled as part of the system build and configuration process.
Management approval is required prior to the installation or use of any ad hoc or third-party system utilities.
Access to Program Source Code
Access to program source code and associated items, including designs, specifications, verification plans, and validation plans shall be strictly controlled in order to prevent the introduction of unauthorized functionality into software, avoid unintentional changes, and protect <Company Name> intellectual property.
All access to source code shall be based on business need and must be logged for review and audit.
...
Requests for an exception to this Policy must be submitted to the IT Manager for approval.
...
Version
...
Date
...
Description
...
Author
...
Approved by
...
<1.0>
...
<29-Apr-2020>
...
<First Version>
...
<OWNER>
...
<APPROVER>
APPENDIX A – Access Management Procedure7
At the completion of the onboarding process, HR will send an email that will generate a series of service tickets for access.
IT will provision access for all company-wide systems as well as engineering systems for the Members of Technical Staff (MTS) group.
Additional access, beyond standard pre-approved access, must be requested and approved by a manager or system owner.
...
Role
...
...
Google Wrkspc
...
Expense Tool
...
CRM
...
App
...
Infrastructure
...
Version Control
...
Build System
...
Vuln Scanner
...
Employee
...
x
...
x
...
x
...
x
...
Engineer 1
...
x
...
x
...
x
...
x
...
x
...
x
...
x
...
Engineer Sprvs
...
x
...
x
...
x
...
x
...
x
...
x
...
x
...
x
...
Sales
...
x
...
x
...
x
...
x
...
x
...
Sales Mgr
...
x
...
x
...
x
...
x
1 Remove or change this if not accurate
2 Reference to another Vanta template policy.
3 Remove or change this if not accurate
4 Customer access management added v2.0. Supports AWS FTR requirements. Delete if not relevant or not using AWS.
5 New Segregation of duties language v2.0
6 Some v2.0 addition. Tailor for your environment. Consider some security standards have prescriptive requirements.
7 If your company has a defined access management procedure, describe it here. If your company does not have such a procedure, you can delete this appendix in its entirety. The procedure described is provided as an example.
8 Example Access matrix v2.0. Predefined access based on role would not require tickets and approvalsPolicy Owner: Managing Director
Effective Date: 2023-05-01
Purpose
To limit access to information and information processing systems, networks, and facilities to authorized parties in accordance with business objectives.
Scope
All CloudCard information systems that process, store, or transmit confidential data as defined in the CloudCard Data Management Policy. This policy applies to all employees of CloudCard and to all external parties with access to CloudCard networks and system resources.
Policy
Access to information computing resources is limited to personnel with a business requirement for such access. Access rights shall be granted or revoked in accordance with this Access Control Policy.
Business Requirements of Access Control
Access Control Policy
CloudCard shall determine the type and level of access granted to individual users based on the “principle of least privilege.” This principle states that users are only granted the level of access absolutely required to perform their job functions, and is dictated by CloudCard’s business and security requirements. Permissions and access rights not expressly granted shall be, by default, prohibited.
CloudCard’s primary method of assigning and maintaining consistent access controls and access rights shall be through the implementation of Role-Based Access Control (RBAC). Wherever feasible, rights and restrictions shall be allocated to groups. Individual user accounts may be granted additional permissions as needed with approval from the system owner or authorized party.
All privileged access to production infrastructure shall use Multi-Factor Authentication (MFA).
Access to Networks and Network Services
Only authorized CloudCard employees and third-parties working off a signed contract or statement of work, with a business need, shall be granted access to the CloudCard production networks and resources. All such access shall be provisioned using the Access Provisioning, Deprovisioning and Change Procedure.
Remote connections to production systems and networks must be encrypted.
Applications running on CloudCard networks must not trust other systems on the network. All systems and users in the CloudCard network will be required to authenticate into other systems as if they were not part of the network.
CloudCard Applications must not trust CloudCard office networks. These networks are considered remote-work sites for the purposes of network security. All connections from a system on a CloudCard office network to a CloudCard production network must be encrypted and authenticated as if it were a connection from a remote site.
User Access Management
CloudCard requires that all personnel have a unique user identifier for system access, and that user credentials and passwords are not shared between multiple personnel. Users with multiple levels of access (e.g. administrators) should be given separate accounts for normal system use and for administrative functions wherever feasible. Root, service, and administrator accounts may use a password management system to share passwords for business continuity purposes only. Administrators shall only use shared administrative accounts when needed for a business purpose that cannot be satisfied with user-specific administrative accounts.
If a password is compromised or suspected of compromise the incident should be escalated to Principal Engineer immediately and the password must be changed.
User Registration and Deregistration
Only authorized administrators shall be permitted to create new user IDs, and may only do so upon receipt of a documented request from authorized parties. User provisioning requests must include approval from data owners or CloudCard management authorized to grant system access. Prior to account creation, administrators should verify that the account does not violate any CloudCard security or system access control policies such as segregation of duties, fraud prevention measures, or access rights restrictions.
User IDs shall be promptly disabled or removed when users leave the organization or contract work ends in accordance with SLAs. User IDs shall not be re-used.
User Access Provisioning
New employees and/or contractors are not to be granted access to any CloudCard production systems until after they have completed all HR on-boarding tasks, which may include but is not limited to background check, non-disclosure agreement, and acknowledgement of CloudCard’s Information Security Policy.
Access should be restricted to only what is necessary to perform job duties
No access may be granted earlier than official employee start date, except for non-privileged access specific systems necessary for the employee onboarding process, listed in Appendix B.
Access requests and rights modifications shall be documented in an access request ticket or email. No permissions shall be granted without approval from the system or data owner or management
Records of all permission and privilege changes shall be maintained for no less than one year
User Access Reviews
Administrators shall perform access rights reviews of user, administrator, and service accounts on a quarterly basis to verify that user access is limited to systems that are required for their job function. Access reviews shall be documented.
Access reviews may include group membership as well as evaluations of any specific or exception-based permission. Access rights shall also be reviewed as part of any job role change, including promotion, demotion, or transfer within the company.
Removal & Adjustment of Access Rights
The access rights of all users shall be promptly removed upon termination of their employment or contract, or when rights are no longer needed due to a change in job function or role. The maximum allowable time period for access termination is 24 business hours for critical / high risk systems, and 2 weeks for low / medium risk systems.
Access Provisioning, Deprovisioning, and Change Procedure
Access for all employees, either new employees joining CloudCard, or existing employees needing additional access, must be provisioned, changed, or deprovisioned via the regular Access Request process (documented in Appendix A).
The access request process must ensure that access is approved by the owner of the corresponding system (in most cases, the Managing Director) before being granted.
Separation of Duties
CloudCard is a small organization with a very small number of employees, so traditional separation of duties by person is counteractive to the effectiveness of our group. To mitigate the risk of unauthorized or unintentional modification or misuse of CloudCard assets by privileged users, we instead separate duties by requiring system-enforced peer or manager review where feasible, and monitoring, logging, or audit tracking of changes or privileged actions where it is not feasible or possible to require approval.
User Responsibility for the Management of Secret Authentication Information
Control and management of individual user passwords is the responsibility of all CloudCard personnel and third-party users. Users shall protect secret authentication information in accordance with the Information Security Policy.
Password Policy
Where feasible, passwords for confidential systems shall be configured for at least:
16 or more characters, including one uppercase letter, one lowercase letter, a special character, and a number
Systems shall be configured to remember and prohibit reuse of passwords for last 16 passwords used.
Passwords shall be set to lock out after 6 failed attempts
Passwords shall expire after 90 days
Initial passwords must be set to a unique value and changed after first log in
For manual password resets, a user’s identity must be verified prior to changing passwords
Do not limit the permitted characters that can be used
Do not limit the length of the password to anything below 64 characters
Do not use secret questions (place of birth, etc) as a sole password reset requirement
Require email verification of a password change request
Require the current password in addition to the new password during password change
Verify newly created passwords against common passwords lists or leaked passwords databases
Check existing user passwords for compromise regularly
Store passwords in a hashed and salted format using a memory-hard or CPU-hard one-way hash function
Enforce appropriate account lockout and brute-force protection on account access
System and Application Access
Information Access Controls
Applications must restrict access to program functions and information to authorized users and support personnel. The level and type of access controls should correspond to the risk level of the information and functionality contained in the system. Factors that determine the risk level of the sytem include, but are not limited to:
Sensitivity and classification of data
Risk to the organization of unauthorized access or disclosure of data
The ability to, and granularity of, control(s) on user access rights to the application and data stored within the application
Restrictions on data outputs, including filtering sensitive information, controlling output, and restricting information access to authorized personnel
Controls over access rights between the evaluated application and other applications and systems
Programmatic restrictions on user access to application functions and privileged instructions
Logging and auditing functionality for system functions and information access
Data retention and aging features
Default Accounts
All unnecessary default accounts must be removed or disabled before making a system available on the network. Specifically, vendor default passwords and credentials must be changed on all CloudCard systems, devices, and infrastructure prior to deployment. This applies to ALL default passwords, including but not limited to those used by operating systems, software that provides security services, application and system accounts, and Simple Network Management Protocol (SNMP) community strings where feasible.
Password Management System
All Employees should use 1Password to manage any password associated with their CloudCard employment. Any passwords that have a legitimate business need to be shared between people should be shared through 1Password.
All storage and transmission of passwords is to be protected using appropriate cryptographic protections, either through hashing or encryption.
The Principal Engineer will update this section of the policy if a different password management tool is to be used, and will ensure that the password management tool implements and continues to implement strong cryptographic protections, effective security controls to prevent other parties (including the vendor of the password management tool) from decrypting the passwords, and two factor authentication.
Monitoring Systems
Use of utility programs, system files, or other software that might be capable of overriding system and application controls or altering system configurations must be restricted to the minimum personnel required. Systems are to maintain logs of all use of system utilities or alteration of system configurations. Extraneous system utilities or other privileged programs are to be removed or disabled as part of the system build and configuration process.
Management approval is required prior to the installation or use of any ad hoc or third-party system utilities.
Access to Program Source Code
Access to program source code and associated items, including designs, specifications, verification plans, and validation plans shall be strictly controlled in order to prevent the introduction of unauthorized functionality into software, avoid unintentional changes, and protect CloudCard intellectual property.
All access to source code must be protected by two factor authentication. Access to source code shall be based on business need and must be logged for review and audit.
Exceptions
Requests for an exception to this Policy must be submitted to the Managing Director for approval.
Violations & Enforcement
Any known violations of this policy should be reported to the Managing Director. Violations of this policy can result in immediate withdrawal or suspension of system and network privileges and/or disciplinary action in accordance with company procedures up to and including termination of employment.
Version | Date | Description | Author | Approved by |
1.0 | 2023-03-21 | First Version | Ryan Heathcote | Luke Rettstatt |
2.0 | 2024-07-05 | Annual Review | Ryan Heathcote | Luke Rettstatt |
Appendix A – Access Request Process
When an employee needs access to a system or set of systems, an Access Request card will be created in Trello from the Access Request Template. The access request template will be completed to identify:
the person who needs the access
the system(s) to which this person needs access
when an employee is terminated, indicate ALL SYSTEMS on the card; the personnel implementing the request will then need to check all systems for existence of access for the user to ensure that all access is revoked.
the specific privileges in the system the person needs
An member of management with authority over the corresponding system will approve the request via a comment on the Trello card. Access must not be granted until the approval has been provided.
Once the access is approved, someone with sufficient rights to grant the access will do so, and will document the granting of the access with a screenshot of the access granted, and attach the screenshot to the Trello card.
Finally, the Trello card will be moved to the Access Request History list on the Security board.
Appendix B - Essential New Hire Systems
An employee needs non-privileged access granted in several systems before their official start date to ensure that onboarding is smooth. These systems are:
Gusto
Google Workspace
1Password
Toggl
Appendix C - AWS Cross-Account Access Best Practice
When CloudCard grants customers access to CloudCard services via AWS IAM roles, CloudCard must generate and provide the externalID value to the customer. CloudCard must not use a customer-generated value for externalID.
When configuring cross-account access using AWS IAM roles, a CloudCard generated value must be used for the external ID rather than a customer-provided value to ensure the integrity of the cross account role configuration. A partner-generated external ID ensures that malicious parties cannot impersonate a customer's configuration and enforces uniqueness and format consistency across all customers.
The external IDs used must be unique across all customers. Re-using external IDs for different customers does not solve the confused deputy problem and runs the risk of customer A being able to view data of customer B by using the role ARN of customer B along with the external ID of customer B.
Customers must not be able to set or influence external IDs. When the external ID is editable, it is possible for one customer to impersonate the configuration of another.