...
Anchor
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 apply 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 at a 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.
Secure Development Policy
Policy Owner: <Policy owner>
Effective Date: <Effective date>
Policy Owner: Principal Engineer
Effective Date: 2023-05-01
| Anchor | ||||
|---|---|---|---|---|
|
To ensure that information security is designed and implemented within the development lifecycle software engineering process for applications and information systems.
| Anchor |
|---|
...
|
...
|
All <Company Name> CloudCard applications and information systems that are business critical and/or process, store, or transmit Confidential data. This policy applies to all internal and external engineers and developers of <Company Name> CloudCard software and infrastructure.
| Anchor |
|---|
...
|
...
|
Anchor
...
| Anchor |
|---|
...
|
...
Changes to systems within the development lifecycle engineering process shall be controlled by the use of formal change control procedures. Change control procedures and requirements are described in the <Company Name> CloudCard Operations Security Policy.
Significant code changes must be reviewed and approved by <who can approve code changes, e.g., a developer or manager within the Review Board> at least one other member of the engineering team before being merged into any production branch in accordance with the <name of process, e.g., Check In Process> found here: <link to process outline in company wiki>
Change control procedures shall ensure that development, testing and deployment of changes shall not be performed by a single individual without approval and oversight.
...
| Anchor |
|---|
...
|
...
All <Company Name> CloudCard software is version controlled and synced between contributors (developers). Access to the central repository is restricted based on an employee’s role. All code is written, tested, and saved in a local repository before being synced to the origin repository.
...
| Anchor |
|---|
...
|
...
When operating platforms are changed, business critical applications shall be reviewed and tested to ensure that there is no adverse impact on organizational operations or security.
...
| Anchor |
|---|
...
|
Principles for engineering secure systems shall be established, documented, maintained and applied to any information system implementation efforts.
At a minimum, the following secure-by-design and privacy-by-design principles shall be applied4:
Secure-by-design principles:
...
Proactive not Reactive; Preventative not Remedial
Privacy as the Default Setting
Privacy Embedded into Design
Full Functionality – Positive-Sum, not Zero-Sum
End-to-End Security – Full Lifecycle Protection
Visibility and Transparency – Keep it Open
Respect for User Privacy – Keep it User-Centric
Engineering documentation and technical references can be found in the <name of page with documents, e.g., Development Process Confluence Page> here: <link>
Anchor
...
Anchor
Software typically relies on other modules, components, or libraries for its functions. Any of these may contain security vulnerabilities. The application developer should use the latest possible version in order to ensure that all known vulnerabilities with available patches will be addressed.
Dynamic Inclusion of Software: CloudCard software should not dynamically include other software from other sources at runtime, such as a web application that causes the user’s web browser to fetch JavaScript from a third-party over which CloudCard has no control. If external code is required by a browser application, it should be reviewed by CloudCard and copied into a CloudCard controlled location from which the web browser can fetch the code.
Developers should also consider the following sections of NIST SP 800-53 Revision 5:
Engineering documentation and technical references can be found in the https://sharptop.atlassian.net/wiki/spaces/CCD.
| Anchor | ||||
|---|---|---|---|---|
|
CloudCard shall establish and appropriately protect environments for system development and integration efforts that cover the entire system development life cycle. The following environments shall be logically or physically segregated:
...
Production
Contains applications ready and approved for use by customers and storage of customer data.
Changes are controlled and subject to prior approval and testing.
Access is restricted to users who have fulfilled the requirements of access to customer data and have a business need.
Test
Contains applications not fully approved for use by customers or storage of customer data.
Available for customers to perform validation or acceptance tests.
Must not contain customer data, except data provided by customers for the purpose of validating functionality
Changes are coordinated to ensure no conflicts between team members in use of the environment.
Segmented from production and does not access or share production resources.
Local Development
Segmented from production and does not access or share production resources.
Contains applications under active modification. Typically operated on a developer’s desktop or laptop.
Must not contain customer data.
| Anchor | ||||
|---|---|---|---|---|
|
CloudCard shall supervise and monitor the activity of outsourced system development. Outsourced development shall adhere to all <Company Name> CloudCard standards and policies.
...
| Anchor |
|---|
...
|
Testing of security functionality shall be performed at defined periods during the development life cycleengineering process. No code shall be deployed to <Company Name> CloudCard production systems without documented, successful test results and evidence of security remediation activities.
...
| Anchor |
|---|
...
|
...
Application code should be scanned prior to deployment. Patches to address application vulnerabilities that materially impact security should be deployed within 90 days of discovery.
| Anchor |
|---|
...
|
...
|
...
Acceptance testing programs and related criteria shall be established for new information systems, upgrades and new versions.Anchor
Prior to deploying code, a Release Checklist MUST be completed which includes a checklist of all Test Plans which show the completion of all associated tests and remediation of identified issues.
...
| Anchor |
|---|
...
|
...
Customer Data
Test data shall be selected carefully, protected and controlled. Confidential customer data shall be protected in accordance with all contracts and commitments. Customer data shall not be used for testing purposes without the explicit permission of the data owner and the <approver of use of customer data as test data, e.g., VP of Engineering>Managing Director.
| Anchor |
|---|
...
The acquisition of third-party systems and software shall be done in accordance with the requirements of the <Company Name> Third-Party Management Policy9.
...
|
Software developers shall be provided with secure development training appropriate to their role at least annually. Training content shall be determined by management but shall address the prevention of common web application attacks and vulnerabilities. The following threats and vulnerabilities should be addressed as appropriate:
prevention of authorization bypass attacks
prevention of the use of insecure session IDs
prevention of Injection attacks
prevention of cross-site scripting attacks
prevention of cross-site request forgery attacks
prevention of the use of vulnerable libraries
| Anchor |
|---|
...
|
...
|
Requests for an exception to this Policy must be submitted to the <approver of exceptions to this policy, e.g., VP of Engineering> Principal Engineer for approval.
| Anchor |
|---|
...
|
...
|
...
Any known violations of this policy should be reported to the <receiver of reported violations to this policy, e.g., VP of Engineering>Principal Engineer. 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
Version | Date | Description | Author | Approved by |
1. |
0 |
2020- |
11- |
24 |
<First Version>
<OWNER>
<APPROVER>
1 All fields in this document marked by angled brackets < > and highlighted must be filled in.
2 This is a reference to another Vanta policy. If you are not planning on using this policy, describe your company’s change control procedures and requirements here.
3 Describe your company’s version control use here
4 Security and privacy by design principles added for v2
5 Tailor this section to describe your company’s development environment and SDLC
6 This section references outsourced development. If you company does not use outsourced development, remove this section.
7 Application vulnerability management added for v2
8 Describe your company’s acceptance testing process here
9 This is a reference to another Vanta policy. If you are not planning on using this policy, describe your company’s third-party systems and software acquisition processes
...
First Version | Luke Rettstatt | |||
2.0 | 2023-03-26 | Update to SOC Template | Ryan Heathcote | Tony Erskine |
3.0 | 2024-08-02 | Annual Review | Ryan Heathcote | Tony Erskine |