...

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 < >¹ with your own language

• Rewrite the policy language such that it reflects the practices of your organization

Policy completion checklist

1. Use Find to make sure that all text in angled brackets is replaced

2. Proofread your policy for spelling and grammar mistakes

3. Confirm that the policy’s content reflects your organizations practices

4. Add any company-specific letterhead, branding, and formatting

5. Remove this instructions page

6. Export this document as PDF — File > Save As > Change “File Format” to PDF

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

Operations Security Policy

Policy Owner: <Policy owner>

...

Policy Owner: Principal Engineer

Effective Date: 2023-05-01

Anchor
purpose purpose

Purpose

To ensure the correct and secure operation of information processing systems and facilities.

Anchor

...

scope

...

scope

Scope

All <Company Name> CloudCard information systems that are business critical and/or process, store, or transmit company data. This Policy applies to all employees of <Company Name> CloudCard and other third-party entities with access to <Company Name> CloudCard networks and system resources.

Anchor
_tnbl0fwsnfq3 _tnbl0fwsnfq3

Operations Security

Documented Operating Procedures

...

The use of processing resources and system storage shall be monitored and adjusted to ensure that system availability and performance meets <Company Name> CloudCard requirements.

Human resource skills, availability, and capacity shall be reviewed and considered as a component of capacity planning and as part of the annual risk assessment process.

Scaling resources for additional processing or storage capacity, without changes to the system, can be done outside of the standard change management and code deployment process.

Separation of

...

Test and Production Environments

...

Development and staging Test environments shall be strictly segregated from production SaaS environments to reduce the risks of unauthorized access or changes to the operational environment. Confidential production customer data must not be used in local development or test environments without the express approval of the <approver of the use of customer data, e.g., VP of Customer Support>Managing Director.

Refer to the Data Management Policy³ for a description of Confidential data. If production customer data is approved for use in the course of development or testing, it shall be scrubbed of any such sensitive information whenever feasible.

...

Anchor

...

config-hardening-review config-hardening-review

Systems and Network Configuration, Hardening, and Review

Systems and networks shall be provisioned and maintained in accordance with the configuration and hardening standards described in Appendix A ⁴ to this policy.

Firewalls and/or appropriate network access controls and configurations shall be used to control network traffic to and from the production environment in accordance with this policy.

Production network access configuration rules shall be reviewed at least annually. Tickets shall be created to obtain approvals for any needed changes.

Anchor

...

malware

...

malware

Protection from Malware

In order to protect the company’s infrastructure against the introduction of malicious software, detection, prevention, and recovery controls to protect against malware shall be implemented, combined with appropriate user awareness.

Anti-malware protections shall be utilized on all company-issued endpoints except for those running operating systems not normally prone to malicious software. Additionally, threat detection and response software shall be utilized for company email. The anti-malware protections utilized shall be capable of detecting all common forms of malicious threats and performing the appropriate mitigation activity (such as removing, blocking or quarantining).

<Company Name> CloudCard should scan all files upon their introduction to systems, and continually scan files upon access, modification, or download. Anti-malware definition and engine updates should be configured to be downloaded and installed automatically whenever new updates are available. Known or suspected malware incidents must be reported as a security incident.

It is a violation of company policy to disable or alter the configuration of anti-malware protections without authorization.

Anchor

...

backup

...

backup

Information Backup

The need for backups of systems, databases, information and data shall be considered and appropriate backup processes shall be designed, planned and implemented. Backup procedures must include procedures for maintaining and recovering customer data in accordance with documented SLAs⁵. Security measures to protect backups shall be designed and applied in accordance with the confidentiality or sensitivity of the data. Backup copies of information, software and system images shall be taken regularly to protect against loss of data. Backups and restore capabilities shall be periodically tested, not less than annually.

Backups must be stored separately (<describe specific requirements for separate region or availability zone>) from the production data location⁶. <Company Name> in more than one availability zone.

CloudCard does not regularly backup user devices like laptops. Users are expected to store critical files and information in company-sanctioned file storage repositories.

Backups are configured to run <frequency of backups, e.g., daily> continuously and incrementally, as well as daily on in-scope systems. The backup schedules are maintained within the backup application softwareAWS.

A backup restore test should be performed at least annually to validate the backup data and backup process⁷Backup restoration should be tested as part of the annual testing of the Business Continuity and Disaster Recovery Plan.

...

Anchor

...

logging-monitoring logging-monitoring

Logging & Monitoring

Production infrastructure shall be configured to produce detailed logs appropriate to the function served by the system or device. Event logs recording user activities, exceptions, faults and information security events shall be produced, kept and reviewed through manual or automated processes as needed. Appropriate alerts shall be configured for events that represent a significant threat to the confidentiality, availability or integrity of production systems or Confidential data.

...

• Log user log-in and log-out

• Log CRUD (create, read, update, delete) operations on application and system users and objects

• Log security settings changes (including disabling or modifying of logging)

• Log application owner or administrator access to customer data (i.e. Access Transparency)

• Logs must include user ID, IP address, valid timestamp, type of action performed, and object of this action.

• Logs must be stored for at least 30 days, and should not contain sensitive data or payloads

Protection of Log Information

...

File Integrity Monitoring and Intrusion Detection¹⁰

<Company Name> CloudCard production systems shall be configured to monitor, log, and self-repair and/or alert on suspicious changes to critical system files where feasible.

...

Unauthorized intrusions and access attempts or changes to <Company Name> CloudCard systems shall be investigated and remediated in accordance with the Incident Response Plan.

Anchor
_jz1wgyf3kcb0 _jz1wgyf3kcb0

Control of Operational Software

The installation of software on production systems shall follow the change management requirements defined in this policy.

Anchor
_fsg0oome3fl _fsg0oome3fl

Technical Vulnerability Management¹¹

Information about technical vulnerabilities of information systems being used shall be obtained in a timely fashion, the organization's exposure to such vulnerabilities shall be evaluated, and appropriate measures taken to address the associated risk. A variety of methods shall be used to obtain information about technical vulnerabilities, including <vulnerability scanning, penetration tests, review of external vendor alerts, and the bug bounty program>.

...

The <IT and Engineering> departments shall evaluate the severity of vulnerabilities identified from any source, and if it is determined to be a risk-relevant critical or high-risk vulnerability, a service ticket will be created. The <Company Name> CloudCard assessed severity level may differ from the level automatically generated by scanning software or determined by external researchers based on <Company Name>’s CloudCard’s internal knowledge and understanding of technical architecture and real-world impact/exploitability. Tickets are assigned to the system, application, or platform owners for further investigation and/or remediation.

Vulnerabilities assessed by <Company Name> CloudCard shall be patched or remediated in the following timeframes¹²:

Service tickets for any vulnerability which cannot be remediated within the standard timeline must show a risk treatment plan and planned remediation timeline.

Anchor
_6torid6m5k3 _6torid6m5k3

Restrictions on Software Installation

Rules governing the installation of software by users shall be established and implemented in accordance with the <Company Name> CloudCard Information Security Policy¹³.

Anchor
_vfcoyevmp6sn _vfcoyevmp6sn

Information Systems Audit Considerations

Audit requirements and activities involving verification of operational systems shall be carefully planned and agreed to minimize disruptions to business processes.

...

Risks shall be considered prior to the acquisition of, or significant changes to, systems, technologies, or facilities. Where requirements are formally identified, any relevant security requirements shall be included. The acquisition of new suppliers and services shall be made in accordance with the Third-Party Management Policy¹⁴.

The company shall perform an annual network security assessment that includes a review of major changes to the environment such as new system components and network topology.

Anchor
_loeg243lf6nb _loeg243lf6nb

Exceptions

Requests for an exception to this policy must be submitted to the <approver of exceptions to this policy, e.g., IT Manager> for approval.

Anchor
_mzluiy1ehiyp _mzluiy1ehiyp

Violations & Enforcement

Any known violations of this policy should be reported to the <person who should receive reports of violations of this policy, e.g., IT Manager>. 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. Anchor_gjdgxs_gjdgxs

...

Version

...

Date

...

Description

...

Author

...

Approved by

...

<1.0>

...

<29-Apr-2020>

...

<First Version>

...

<OWNER>

...

<APPROVER>

APPENDIX A - Configuration and Hardening Standards

Configuration and hardening standards shall be maintained on the internal documentation portaland including termination of employment.

...

...

...

Servers and Virtual Machines¹⁶

This is the standard for system-level server and virtual server (VM) configuration hardening. Some customization to these settings may be required to configure the system for its specific target environment, such as setting the proper names, groups, authentication settings, and other personalization options.

<INSERT OS/SYSTEM BASELINE>¹⁷

In addition to the requirements to secure systems to the baseline outlined above, all physical and virtual systems must adhere to the following technical requirements:

• All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, Simple Network Management Protocol (SNMP) community strings, etc.) must be changed before a system is installed on the network.

• Unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, SNMP, etc.) must be removed or disabled before a system is installed on the network.

• Only one primary function may be implemented per server or virtual machine to prevent functions that require different security levels from coexisting on the same system.

• Only necessary services, protocols, daemons, etc., may be enabled, and only as required for the function of the system. All unnecessary functionality (such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers) must be disabled

• Additional security features for any required services, protocols or daemons that are considered to be insecure must be documented in Appendix B of this document, justified, and tested to ensure that they do not introduce unnecessary risk or vulnerabilities.

• All security patches identified as <critical, high, or medium> must be applied to systems within SLAs established in this policy.

Network Standards

• Management of network rules and settings may only be performed by authorized members of <ENGINEERING TEAM etc.> and all changes must comply with change Management procedures defined in the Operations Security Policy.

• Network diagrams must be created and kept current. Significant changes (additions or deletions to VPCs and subnets, new external connections, etc.) must be documented in the diagrams; even if no changes occurred, the diagrams will be reviewed at least <annually> for completeness and accuracy, and approved/acknowledged (in version number/date field etc.) by authorized members of <Engineering Team etc.>

• Supported network controls for production networks are <TYPE e.g. AWS NACLs>. Management of production network systems is accomplished through the use of <MANAGEMENT SYSTEM, SSH, ETC>

In the <PRODUCTION ENVIRONMENT>, defined rules and configurations must be enforced to control traffic from untrusted networks (e.g. publicly available services) to internal production networks; additionally, rules must be in place to restrict traffic to and from production networks to untrusted networks, and all inbound and outbound traffic must be evaluated by the the traffic management configuration.

Network control systems must be configured to use default Network Address Translation to prevent the disclosure of internal IP addresses to the Internet. If private IP addresses are used, any disclosure to external parties must be appropriately authorized, documented, and periodically reviewed for business necessity.

Mobile devices connecting to production networks must employ the use of a personal firewall or equivalent (such as endpoint protection with network restrictions enabled). Disabling or bypassing personal firewalls while connected to <Company Name> systems is prohibited. Personal firewalls must be configured to specific standards, including: <disabling the use of split tunneling, configurations to block known malicious sites, blocking of insecure protocols, etc.>.

• All network control systems must be configured with default antispoofing rules to block or deny inbound internal addresses originating from the Internet

• Network control systems may only allow established connections into the internal network and must deny any inbound connections not associated with a previously established session.

• External configurations must limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

• Port and IP ranges are prohibited unless specifically reviewed and justified; all available services must be justified, and support secure configurations, all other ports, services, and network traffic must be specifically denied.

• Use of insecure services and protocols without justification and documentation of additional security features implemented to mitigate risk is prohibited.

• Remote access sessions must be configured to enforce timeout after a specified period of (X hours).

• Remote-access technologies for vendors and business partners used to access production systems must be enabled only when needed for business purposes and immediately deactivated after use.

• Any hybrid networks with both cloud and on-premise access shall be scanned and tested at least annually to ensure that security requirements are maintained¹⁸

• <OTHER COMPANY SPECIFIC REQUIREMENTS>

Specific NACLs, ports, zones, and services allowed in and out of the production environment are defined below: Rules and allowed traffic must be evaluated at least annually and formally approved by <Network Team, Security Engineering, etc.>:

<UPDATE WITH approved/allowed rules/NACLs/Services etc.>

...

APPENDIX A - Configuration and Hardening Standards

Configuration and hardening standards shall be maintained on the internal documentation portal.

Servers and Virtual Machines¹⁶

This is the standard for system-level server and virtual server (VM) configuration hardening. Some customization to these settings may be required to configure the system for its specific target environment, such as setting the proper names, groups, authentication settings, and other personalization options.

<INSERT OS/SYSTEM BASELINE>¹⁷

In addition to the requirements to secure systems to the baseline outlined above, all physical and virtual systems must adhere to the following technical requirements:

• All vendor defaults (including default passwords on operating systems, software providing security services, application and system accounts, Simple Network Management Protocol (SNMP) community strings, etc.) must be changed before a system is installed on the network.

• Unnecessary default accounts (including accounts used by operating systems, security software, applications, systems, SNMP, etc.) must be removed or disabled before a system is installed on the network.

• Only one primary function may be implemented per server or virtual machine to prevent functions that require different security levels from coexisting on the same system.

• Only necessary services, protocols, daemons, etc., may be enabled, and only as required for the function of the system. All unnecessary functionality (such as scripts, drivers, features, subsystems, file systems, and unnecessary web servers) must be disabled

• Additional security features for any required services, protocols or daemons that are considered to be insecure must be documented in Appendix B of this document, justified, and tested to ensure that they do not introduce unnecessary risk or vulnerabilities.

• All security patches identified as <critical, high, or medium> must be applied to systems within SLAs established in this policy.

Network Standards

• Management of network rules and settings may only be performed by authorized members of <ENGINEERING TEAM etc.> and all changes must comply with change Management procedures defined in the Operations Security Policy.

• Network diagrams must be created and kept current. Significant changes (additions or deletions to VPCs and subnets, new external connections, etc.) must be documented in the diagrams; even if no changes occurred, the diagrams will be reviewed at least <annually> for completeness and accuracy, and approved/acknowledged (in version number/date field etc.) by authorized members of <Engineering Team etc.>

• Supported network controls for production networks are <TYPE e.g. AWS NACLs>. Management of production network systems is accomplished through the use of <MANAGEMENT SYSTEM, SSH, ETC>

In the <PRODUCTION ENVIRONMENT>, defined rules and configurations must be enforced to control traffic from untrusted networks (e.g. publicly available services) to internal production networks; additionally, rules must be in place to restrict traffic to and from production networks to untrusted networks, and all inbound and outbound traffic must be evaluated by the the traffic management configuration.

Network control systems must be configured to use default Network Address Translation to prevent the disclosure of internal IP addresses to the Internet. If private IP addresses are used, any disclosure to external parties must be appropriately authorized, documented, and periodically reviewed for business necessity.

Mobile devices connecting to production networks must employ the use of a personal firewall or equivalent (such as endpoint protection with network restrictions enabled). Disabling or bypassing personal firewalls while connected to CloudCard systems is prohibited. Personal firewalls must be configured to specific standards, including: <disabling the use of split tunneling, configurations to block known malicious sites, blocking of insecure protocols, etc.>.

• All network control systems must be configured with default antispoofing rules to block or deny inbound internal addresses originating from the Internet

• Network control systems may only allow established connections into the internal network and must deny any inbound connections not associated with a previously established session.

• External configurations must limit inbound traffic to only system components that provide authorized publicly accessible services, protocols, and ports.

• Port and IP ranges are prohibited unless specifically reviewed and justified; all available services must be justified, and support secure configurations, all other ports, services, and network traffic must be specifically denied.

• Use of insecure services and protocols without justification and documentation of additional security features implemented to mitigate risk is prohibited.

• Remote access sessions must be configured to enforce timeout after a specified period of (X hours).

• Remote-access technologies for vendors and business partners used to access production systems must be enabled only when needed for business purposes and immediately deactivated after use.

• Any hybrid networks with both cloud and on-premise access shall be scanned and tested at least annually to ensure that security requirements are maintained¹⁸

• <OTHER COMPANY SPECIFIC REQUIREMENTS>

Specific NACLs, ports, zones, and services allowed in and out of the production environment are defined below: Rules and allowed traffic must be evaluated at least annually and formally approved by <Network Team, Security Engineering, etc.>:

<UPDATE WITH approved/allowed rules/NACLs/Services etc.>

...

¹ All fields in this document marked by angled brackets < > and highlighted must be filled in.

² Describe your company’s policy for segregation of environments. If you use different categorizations of data (i.e., don’t use “confidential”), then make sure to update those references here.

³ This is a reference to another Vanta policy. If you are not using this policy, describe how “confidential” data is here.

⁴ This is a reference to an appendix included in this document. If you are not using the appendix, remove this reference. Either describe your configuration and hardening standards here or reference another document.

⁵ Documented backup procedures should be referenced, added in the Appendix or this policy language should be tailored.

⁶ Segregation of backups policy added for v2

...

Anchor
_6qk4halfu0ee _6qk4halfu0ee

⁸ Logging content policy added for v2. Aligned to MVSP. Modify as needed.

...