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.
...
| Anchor | ||||
|---|---|---|---|---|
|
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.
| Anchor | ||||
|---|---|---|---|---|
|
...
<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>
| Anchor | ||||
|---|---|---|---|---|
|
...