Trust is our #1 priority

Background

Amoeba AI is committed to ensuring all team members actively address security and compliance in their roles at Amoeba AI.

Purpose

This policy specifies acceptable use of end-user computing devices and technology. Additionally, we provide training (where needed) to ensure that all team members have an understanding of current best practices, the different types and sensitivities of data, and the sanctions associated with non compliance.

Purpose

Amoeba AI policy requires all team members to accept and comply with the Acceptable Use Policy. Amoeba AI policy requires that:

• Background verification checks on all candidates for employees and contractors should be carried out in accordance with relevant laws, regulations, and ethics, and proportional to the business requirements, the classification of the information to be accessed, and the perceived risk.
• Employees, contractors and third party users must agree and sign the terms and conditions of their employment contract, and comply with acceptable use.
• Employees will go through an onboarding process that familiarizes them with the environments, systems, security requirements, and procedures Amoeba AI has in place. Employees will also have ongoing security awareness training that is audited. Employee offboarding will include reiterating any duties and responsibilities still valid after terminations, verifying that access to any Amoeba AI systems has been removed, as well as ensuring that all company owned assets are returned.
• Amoeba AI and its employees will take reasonable measures to ensure no corporate data is transmitted via digital communications such as email or posted on social media outlets.
• Amoeba AI will maintain a list of prohibited activities that will be part of onboarding procedures and have training available if/when the list of those activities changes.
• A fair disciplinary process will be utilized for employees that are suspected of committing breaches of security. Multiple factors will be considered when deciding the response, such as whether or not this was a first offense, training, business contracts, etc. Amoeba AI reserves the right to terminate employees in the case of serious cases of misconduct.

Procedures

Amoeba AI requires all team members to comply with the following acceptable use requirements and procedures, such that:

• All team members are primarily considered as remote users and therefore must follow all system access controls and procedures for remote access.
• Use of Amoeba AI computing systems is subject to monitoring by the Amoeba AI IT team.
• Employees and contractors may not leave computing devices (including laptops and smart devices) used for business purposes, including company-provided and BYOD devices, unattended in public.
• Device encryption must be enabled for all mobile devices accessing company data, such as whole-disk encryption for all laptops. Use only legal, approved software with a valid license. Do not use personal software for business purposes and vice versa. Encrypt all email messages containing sensitive or confidential data.
• Team members may not post any sensitive or confidential data in public forums or chat rooms. If a posting is needed to obtain technical support, data must be sanitized to remove any sensitive or confidential information prior to posting.
• Anti-malware or equivalent protection and monitoring must be installed and enabled on all endpoint systems that may be affected by malware, including workstations, laptops and unmanaged servers.
• All data storage devices and media must be managed according to the Amoeba AI Data Classification specifications.

Purpose

This policy outlines the requirements and controls/procedures Amoeba AI has implemented to manage the deletion of customer data.

Policy For Customers

Customer data is retained for as long as the account is in active status. Data enters an “expired” state when the account is voluntarily closed. Expired account data will be retained for 180 days. After this period, the account and related data will be removed at Amoeba AI’s discretion. Customers that wish to voluntarily close their account should download their data manually via the API prior to closing their account.

If a customer account is involuntarily suspended, then there is a 180 day grace period during which the account will be inaccessible but can be reopened if the customer meets their payment obligations and resolves any terms of service violations.

If a customer wishes to manually backup their data in a suspended account, then they must ensure that their account is brought back to good standing so that the user interface will be available for their use. After 30 days, the suspended account will be closed and the data will enter the “expired” state. It will be permanently removed 180 days thereafter (except when required by law to retain).

Background

Amoeba AI takes the confidentiality and integrity of its customer data very seriously and strives to assure data is protected from unauthorized access and is available when needed.

Purpose

This policy outlines many of the procedures and technical controls in support of data protection.

Scope

Production systems that create, receive, store, or transmit Amoeba AI customer data (hereafter "Production Systems") must follow the requirements and guidelines described in this policy.

Purpose

Amoeba AI policy requires that:

• Data must be handled and protected according to its classification requirements and following approved encryption standards, if applicable.
• Whenever possible, store data of the same classification in a given data repository and avoid mixing sensitive and non-sensitive data in the same repository. Security controls, including authentication, authorization, data encryption, and auditing, should be applied according to the highest classification of data in a given repository.
• Employees shall not have direct administrative access to production data during normal business operations besides in the course of providing standard customer support. Exceptions include emergency operations such as forensic analysis and manual disaster recovery. All Production Systems must disable services that are not required to achieve the business purpose or function of the system.
• All Production Systems must have security monitoring enabled, including vulnerability scanning, as applicable.

Data Protection Implementation and Processes
Customer Data Protection

Amoeba AI hosts on AWS in the US-East 1 (N. Virginia) region by default. Data is replicated for redundancy and disaster recovery.

All Amoeba AI employees adhere to the following processes to reduce the risk of compromising Production Data:

• Implement and/or review controls designed to protect Production Data from improper alteration or destruction.
• Ensure that confidential data is stored in a manner that supports user access logs and automated monitoring for potential security incidents.
• Ensure Amoeba AI Customer Production Data is segmented and only accessible to Customer authorized to access data.
• All Production Data at rest is stored on encrypted volumes using encryption keys managed by Amoeba AI and/or by AWS..
• Volume encryption keys and machines that generate volume encryption keys are protected from unauthorized access. Volume encryption key material is protected with access controls such that the key material is only accessible by privileged accounts.

Access

Amoeba AI employee access to production is guarded by an approval process and by default is disabled. When access is approved, temporary access is granted that allows access to production. Production access is reviewed by the DevOps team on a case by case basis.

Separation

Customer data is logically separated at the database/datastore level using a unique identifier for the customer. The separation is enforced at the API layer where the client must authenticate with a chosen account and then the customer unique identifier is included in the access token and used by the API to restrict access to data to the account. All database/datastore queries then include the account identifier.

Monitoring

Amoeba AI uses Grafana and PagerDuty to monitor the entire cloud service operation. If a system failure and alarm is triggered, key personnel are notified by text, chat, and/or email message in order to take appropriate corrective action.

Protecting Data At Rest
Encryption of Data at Rest

All databases, data stores, and file systems are encrypted according to Amoeba AI’s Encryption Policy.

Protecting Data In Transit

All external data transmission is encrypted end-to-end using encryption keys managed by Amoeba AI. This includes, but is not limited to, cloud infrastructure and third party vendors and applications.

Encryption of Data in Transit

All internet and intranet connections are encrypted and authenticated using a strong protocol, a strong key exchange, and a strong cipher.

Data protection via end-user messaging channels

Restricted and sensitive data is not allowed to be sent over electronic end-user messaging channels such as email or chat, unless end-to-end encryption is enabled.

Background

Amoeba AI understands that all technology contains bugs, including both functional defects and security vulnerabilities.

Purpose and Scope

Amoeba AI allows any public user to highlight bugs and/or vulnerabilities on its public repo on GitHub. This allows Amoeba AI to take advantage of crowd-sourced security researchers to perform penetration testing of Amoeba AI’s platform and its public facing resources.

Policy

• Amoeba AI provides a method for employees and/or customers to report security vulnerabilities.
• Amoeba AI conducts annual penetration tests conducted by an external pen testing company.

Purpose

The purpose of this policy is to define the methodology for the assessment and treatment of information security risks within Amoeba AI, and to define the acceptable level of risk as set by Amoeba AI’s leadership.

Scope

Risk assessment and risk treatment are applied to the entire scope of Amoeba AI’s information security program, and to all assets which are used within Amoeba AI or which could have an impact on information security within it. This policy applies to all employees of Amoeba AI who take part in risk assessment and risk treatment.

Background

A key element of Amoeba AI’s information security program is a holistic and systematic approach to risk management. This policy defines the requirements and processes for Amoeba AI to identify information security risks. The process consists of four parts: identification of Amoeba AI’s assets, as well as the threats and vulnerabilities that apply; assessment of the likelihood and consequence (risk) of the threats and vulnerabilities being realized, identification of treatment for each unacceptable risk, and evaluation of the residual risk after treatment.

Policy
Risk Assessment

• The risk assessment process includes the identification of threats and vulnerabilities having to do with company assets. The first step in the risk assessment is to identify all assets within the scope of the information security program; in other words, all assets which may affect the confidentiality, integrity, and/or availability of information in the organization. Assets may include documents in paper or electronic form, applications, databases, information technology equipment, infrastructure, and external/outsourced services and processes. For each asset, an owner must be identified.
• The next step is to identify all threats and vulnerabilities associated with each asset. Threats and vulnerabilities must be listed in a risk assessment table. Each asset may be associated with multiple threats, and each threat may be associated with multiple vulnerabilities. For each risk, an owner must be identified. The risk owner and the asset owner may be the same individual.
• Once risk owners are identified, they must assess:

• Impact for each combination of threats and vulnerabilities for an individual asset if such a risk materializes.
• Likelihood of occurrence of such a risk (i.e. the probability that a threat will exploit the vulnerability of the respective asset).
• Criteria for determining impact and likelihood are defined in the tables below.

• The risk level is assessed by determining the impact score. Higher the score, higher the risk.

Description of Impact Levels and Criteria:

Risk Remediation

• As part of this risk remediation process, the Company shall determine objectives for mitigating or treating risks. All high and critical risks must be treated. For continuous improvement purposes, company managers may also opt to treat medium and/or low risks for company assets.
• Treatment options for risks include the following options:

• Selection or development of security control(s).
• Transferring the risks to a third party
• Avoiding the risk by discontinuing the business activity that causes such risk.
• Accepting the risk; this option is permitted only if the selection of other risk treatment options would cost more than the potential impact of the risk being realized.
• Accepting the risk; this option is permitted only if the selection of other risk treatment options would cost more than the potential impact of the risk being realized.

Regular Reviews of Risk Assessment and Risk Treatment

The Risk Assessment Report must be updated when newly identified risks are identified. At a minimum, this update and review shall be conducted once per year.

Reporting

The results of risk assessments, and all subsequent reviews, shall be documented in a Risk Assessment Report.

Background

Access to Amoeba AI systems and applications is limited for all users, including but not limited to employees, volunteers, business associates, contracted providers, and consultants. Access by any other entity is allowable only on a minimum necessary basis. All users are responsible for reporting an incident of unauthorized use or access of the organization's information systems.

Purpose

The purpose of this procedure is to provide a policy and guideline for creating, modifying, or removing access to the company’s network and data by creating, changing or deleting the network account configuration for a User.

Scope

This policy and defined process is used to allow access to the company’s data and systems to individuals who meet the requirements defined in this policy. This policy governs individuals who are granted access that is necessary to support the business. This policy relates to all data used, processed, stored, maintained, or transmitted in and through the company’s systems.

Access Establishment and Modification

Requests for access to Amoeba AI Platform systems and applications are made formally using the following process:

• An Amoeba AI team member initiates the access request by submitting a JIRA ticket request.
  a.User identities must be verified prior to granting access to new accounts.
• The relevant account administrator will grant or reject access to systems as dictated by the employee's job title. If additional access is required outside of the minimum necessary to perform job functions, the requester must include a description of why the additional access is required as part of the access request.
• If the request is rejected, it goes back for further review and documentation.
• If the review is approved, the request is marked as “Done”, and any pertinent notes are added.

Access Reviews

All access to Amoeba AI systems and services is reviewed and updated on an annual basis to ensure proper authorizations are in place commensurate with job functions.

Workforce Clearance

• The level of security assigned to a user to the organization's information systems is based on the minimum necessary amount of data access required to carry out legitimate job responsibilities assigned to a user's job classification.
• All access requests are treated on a "least-access principle."
• Amoeba AI maintains a minimum necessary approach to access to Customer data.

Unique User Identification

• Access to the Amoeba AI Platform systems and applications is controlled by requiring unique User Login IDs and passwords for each individual user and developer.
• Passwords requirements mandate strong password controls.
• Passwords are not displayed at any time and are not transmitted or stored in plain text.
• Default accounts on all production systems, including root, are disabled.
• Shared accounts are not allowed within Amoeba AI systems or networks except for systems@Amoeba AI.com.
• Automated log-on configurations other than the company’s approved Password Management provider that store user passwords or bypass password entry are not permitted for use with Amoeba AI workstations or production systems.

Automatic Logoff

Users are required to make information systems inaccessible by any other individual when unattended by the users (ex. by using a password protected screen saver or logging off the system).

Employee Workstation Use

All employee workstations at Amoeba AI are company owned, and all are laptop products running Windows, Mac OSX or Linux.

• Workstations may not be used to engage in any activity that is illegal or is in violation of organization's policies. Access may not be used for transmitting, retrieving, or storage of any communications of a discriminatory or harassing nature or materials that are obscene. Harassment of any kind is prohibited. No messages with derogatory or inflammatory remarks about an individual's race, age, disability, religion, national origin, physical attributes, sexual preference, or health condition shall be transmitted or maintained. No abusive, hostile, profane, or offensive language is to be transmitted through the organization's system.
• Information systems/applications also may not be used for any other purpose that is illegal, unethical, or against company policies or contrary to organization's best interests.
• Solicitation of non-company business, or any use of organization's information systems/applications for personal gain is prohibited. Users may not misrepresent, obscure, suppress, or replace another user's identity in transmitted or stored messages. Workstation hard drives must be encrypted
• All workstations have firewalls enabled to prevent unauthorized access unless explicitly granted.

Employee Termination/Offboarding Process

• The Human Resources Department (or other designated department) and their supervisors are required to notify the IT and DevOps upon completion and/or termination of access needs and facilitate completion of the "Offboarding Checklist".
• The Human Resources Department, users, and supervisors are required to notify IT and DevOps to terminate a user's access rights if there is evidence or reason to believe the following (these incidents are also reported to the department VP):
  a: The user has been using their access rights inappropriately;
  b: A user's password has been compromised (a new password may be provided to the user if the user is not identified as the individual compromising the original password);
• The IT and DevOps team will terminate users' access rights within 1 business day of termination/separation, and will coordinate with the appropriate Amoeba AI employees to terminate access to any non-production systems managed by those employees.
• The DevOps team audits and may terminate access of users that have not logged into the organization's information systems/applications for an extended period of time.

Purpose

This policy will assist employees and other third-parties with understanding the Company’s information labeling and handling guidelines. It should be noted that the sensitivity level definitions were created as guidelines and to emphasize common sense steps that you can take to protect sensitive or confidential information (e.g., Company Confidential information should not be left unattended in conference rooms).

Scope

Information covered in this policy includes, but is not limited to, information that is received, stored, processed, or transmitted via any means. This includes electronic, hardcopy, and any other form of information regardless of the media on which it resides.

Policy Definitions

Confidential/Restricted Data:

Generalized terms that typically represent data classified as Sensitive or Private, according to the data classification scheme defined in this policy.

Internal Data:

• All data owned or licensed by Amoeba AI.

Public Information:

• Any information that is available within the public domain.

Data Classification Scheme

Data classification, in the context of information security, is the classification of data based on its level of sensitivity and the impact to Amoeba AI should that data be disclosed, altered, or destroyed without authorization. The classification of data helps determine what baseline security controls are appropriate for safeguarding that data. All data should be classified into one of the three following classifications.

1. Confidential/Restricted Data

Data should be classified as Restricted or Confidential when the unauthorized disclosure, alteration, or destruction of that data could cause a significant level of risk to Amoeba AI or its customers. Examples of Sensitive data include data protected by state or federal privacy regulations (e.g. PHI & PII) and data protected by confidentiality agreements. The highest level of security controls should be applied to Restricted and Confidential Data:

• Disclosure or access to Restricted and Confidential data is limited to specific use by individuals with a legitimate need-to-know. Explicit authorization by the Security Officer is required for access to because of legal, contractual, privacy, or other constraints. Must be protected to prevent loss, theft, unauthorized access, and/or unauthorized disclosure.
• Must be destroyed when no longer needed. Destruction must be in accordance with Company policies and procedures. Will require specific methodologies, procedures, and reporting requirements for the response and handling of incidents.

2. Internal Use Data

Data should be classified as Internal Use when the unauthorized disclosure, alteration, or destruction of that data could result in a moderate level of risk to Amoeba AI or its customers. This includes proprietary, ethical, or privacy considerations. Data must be protected from unauthorized access, modification, transmission, storage or other use. This applies even though there may not be a civil statute requiring this protection. Internal Use Data is restricted to personnel who have a legitimate reason to access it. By default, all data that is not explicitly classified as Restricted/Confidential or Public data should be treated as Internal Use data. A reasonable level of security controls should be applied to Internal Use Data.

3. Public Data

Data should be classified as Public when the unauthorized disclosure, alteration or destruction of that data would result in little or no risk to Amoeba AI and its customers. It is further defined as information with no existing local, national, or international legal restrictions on access or usage. While little or no controls are required to protect the confidentiality of Public data, some level of control is required to prevent unauthorized alteration or destruction of Public Data.

Calculating Classification

The goal of information security, as stated in the Information Security Policy, is to protect the confidentiality, integrity, and availability of Corporate and Customer Data. Data classification reflects the level of impact to Amoeba AI if confidentiality, integrity, or availability is compromised. If a classification is not inherently obvious, consider each security objective using the following table as a guide. All data are to be assigned one of the following four sensitivity levels:

HANDLING CONTROLS PER DATA CLASSIFICATION

Purpose

Amoeba AI has a duty to protect our client’s information. Any event involving information security should be well documented and used to improve the security of the system and any relevant procedures and processes. The purpose of this document is to:

• Outline what steps should be taken in the event of an information Security Incident

Scope

This document identifies the policies relevant to all technical incidents within Amoeba AI. It will direct the reader how to assess the incident and gather the information required to guide personnel through the application of procedures that must be followed as a result of the incident.

As such, this policy will apply to all events where client confidentiality is deemed to have been breached, or put at risk by Amoeba AI or its team members.

Definitions

Incident

An incident is defined as an unplanned interruption to an IT service or reduction in the quality of an IT service or a failure of a configuration item that has not yet impacted an IT service. This may be the result of a software failure of a product or platform performing in an unknown or unexpected manner (“SW incident”) or a process failure where a process or policy is not robust enough or was not followed adequately to accommodate a situation which has occurred (“Process incident”).

A SW Incident may be internal to Amoeba AI, external to Amoeba AI which includes failure of 3rd-party software or service such as tools used within our products or tools used by platform providers such as AWS Services, or finally a negative interaction between Amoeba AI products and 3rd-party tools.

An incident may also occur as the result of infrastructure anomalies (“Infra incident”) such as physical or logical failure of the hosting provider services.

Security Incident

A Security Incident is defined as an attempt to access Amoeba AI data by exploiting vulnerabilities in existing technology or controls, or attempts to access Amoeba AI data which has not been defined as “public”, which is not adequately protected via technology or process.

Security Exposure

A Security Exposure is defined as awareness to platform environment situations which has a significant probability of compromising business operations and threatening information security.

Incident Management

A defined process for logging, recording and resolving Incidents. The aim of Incident Management is to restore service as quickly as possible.

Breach

A breach is a confirmed Security Incident in which sensitive, confidential or otherwise protected data has been accessed and/or disclosed in an unauthorized fashion. Data breaches may or may not involve personally identifiable information (PII), trade secrets or intellectual property.

A breach may be the result of unauthorized individuals exploiting vulnerabilities or misconfigurations of technical systems to gain access to Amoeba AI information or information entrusted to Amoeba AI for the use of providing business services to customers (Technical breach).

A breach may also be the result of an unauthorized individual viewing information they should not be exposed to. This may be as simple as reading over another individual’s shoulder, poor password hygiene, Phishing attacks or confidential information discarded in a wastebasket (Process breach).

Severity Levels

Severity levels are a useful tool helping to identify the relative importance of an action, code defect (“bug”) or incident. The levels are identified as L1 (“critical”), L2 (“major”) and L3 (“minor”) and each may be assigned different treatments and timelines.

Timelines for remediation can vary depending on severity but should be based on the following matrix:

Severity Level

Policy

Notification of Incident

Upon first learning of a potential Security Incident, whether by external notification by client or by internal discovery, the organization’s DevOps Team Leads and CTO should be notified. The DevOps Team Leads are the acting principals in the matter, and the CEO may act or involve other groups as needed.

If applicable, the Development Team Leads,CTO/CEO, and the Support Team Leads may also be notified through the course of handling the matter.

Classification of Incident

After receiving notification of a potential incident, the DevOps Team Leads will begin an investigation into the reported incident. This should include:

• Whether the incident is still active, regardless of cause,
• Whether the incident meets the criteria of a Security Incident,
• Whether the incident meets the criteria of a Breach,
• If applicable:
  Creation of an incident report or breach report, summarizing all prior findings
  Identification of whether PII classified data is at risk (eg. if we have a signed BAA with the customer, there is potential that PII classified data is affected) and if so, ensure that details are recorded in the HIPAA Breach Template
• The scope of the incident, if applicable
• Assign a severity level to the incident (L1 through L3)

Mitigation

If a incident is found to have occurred, the DevOps Team Leads will:

• Mitigate the cause of the Incident, if applicable
• Mitigate the cause of the Security Exposure, if applicable
• Mitigate the cause of the Security Incident, if applicable
• Terminate any active Breach, if applicable
• If PII data is compromised
  Documentation of PII exposure and scope must be followed.
  Notification to required parties if PII data has been compromised. This will include Amoeba AI Executive and Covered Parties.

Notification of Affected Parties

If a Security Incident is identified, the CTO will communicate the scope of the incident to the Amoeba AI Executive team who will in turn develop an official Amoeba AI communication for distribution identifying the incident and its impact. This notification document must be produced for distribution within timelines specified by relevant regulations or company practice, whichever is more stringent. The breadth of disclosure for regulatory notification will be per regulatory guidelines.

Documentation

• All events identified as a Security Incident or Breach must be documented using the approved incident reporting template.
• All events identified as a Security Exposure must be documented and forwarded to the Software Security Lead.
• In the event of a Breach including PII, all related documentation and requests for PII disclosure by approved entities will be maintained in a file vault for the minimum required term of 6 years. Further all requests for disclosure must be retained including, at minimum, the date of disclosure, requesting the entity who received the disclosed information, purpose of the disclosure and a description of the disclosed information.

Post-Incident Activities

After the incident has been mitigated, a formal post-mortem activity will be overseen by the CTO/CEO, and will review the incident report to determine what actions can be taken to prevent future incidents of similar nature. If it is determined a change is required, change tickets will be created and acted on by the appropriate teams, including: (1) in the event of a software related incident, the Development Team, or (2) in the event of an infrastructure related incident, the DevOps Team.

Purpose

This policy defines the high-level requirements for providing business program managers, business project managers, technical project managers, and other program and project stakeholders guidance to support the approval, planning, and life-cycle development of [Cloud-Control] software systems.

• Outline what steps should be taken in the event of an information Security Incident

Policy

Amoeba AI must establish and maintain processes for ensuring that its computer applications or systems follow an SDLC process which is consistent and repeatable.

Software Development Phases and Approach Standard

A Software Development Project consists of a defined set of phases:

Determine System Need Phase

The Determine System Need phase is the period of time in which an information system need is identified and the decision is made whether to commit the necessary resources to address the need.

Define System Requirements Phase

The Define System Requirements phase is the period in which the User Requirements are broken down into more detailed requirements which can be used during designing and coding.

Design System Component Phase

The Design System Components phase transforms requirements into specifications to guide the work of the Development phase. The decisions made in this phase address how the system will meet the functional, physical, interface, and data requirements. Design phase activities may be conducted in an iterative fashion, producing a system design that emphasizes the functional features of the system and technical detail.

Build System Component Phase

The Build phase transforms the detailed system design into complete coded software units and eventually, into an integrated product for release. Each software unit and subsequent integrated units are tested thoroughly. System documents that support installation and operations are also developed in this phase.

Evaluate System Readiness Phase

This Evaluate phase is to ensure that the system as designed and built satisfies the requirements of the user. Whenever possible, independent testers measure the system's ability to perform the functions that are required by the customer and ensure an acceptable level of quality and performance. Once the phase is complete, it will be evident whether or not the system is ready for operation or redevelopment.

System Deployment Phase

System Deployment phase is the final phase of the development life cycle, when the system is released initially to a Staging site and then into the production environment. All necessary training for using the system is accomplished.

The sequence of the phases depends on the software development approach taken. These approaches include but are not limited to:

• Agile Development
• Iterative Development
• Staged Delivery Development

Based on the approach for and the size of the software development, some of the phases can be combined. In Iterative Development there may be multiple Cycles (iterations) of the above phases before the final software is released.

SDLC Control Guidelines

The SDLC process will adhere to the following controls:

• Modification of code or an emergency release will follow the change control standard.
• All software deployed on Hosted infrastructure must prevent security issues including but not limited to those covered by OWASP.
• Code changes are reviewed by individuals other than the originating code author and by individuals who are knowledgeable in code review techniques and secure coding practices.
• Application development activity should be separated from the production and test environments. The extent of separation, logical or physical, is recommended to be appropriate to the risk of the business application or be in line with customer contractual requirements. The level of separation that is necessary between production, development, and test environments should be evaluated and controls established to secure that separation.
• All changes to production environments should strictly follow change control procedures, including human approval of all changes, granted by an authorized owner of that environment. Automated updates should be disallowed without such approval.
• Active production environments should not be re-used as test environments. Inactive and/or decommissioned production environments should not be used as test environments unless all private data has been removed. Test environments should not be re-used as production environments without going through a decommissioning and recommissioning process that cleans all remnants of test data, tools, etc.
• Custom accounts and user IDs and/or passwords should be removed from applications before applications become active or are released to customers.
• Production data should not be used in testing or development environments.
• Security controls that are in place for the production copy in the test system should be production quality (e.g. mirroring the production controls over the data).
• When conducting quality assurance (QA) testing prior to the release of a new feature requiring user input where constraints on user input may be reasonably understood, feature acceptance tests must include testing of edge and boundary cases.

For situations demonstrating that testing needs to use production data, the requirements are the following:

• The VP of Engineering will provide approval before production data can be used for testing purposes. Wherever possible, the production data should be tokenized or anonymized instead of using production data. Testing and parallel runs should use a separate copy of production data and the test location or destination should be acceptable.
• The data should not be extracted, handled, or used by the test process in a manner that subjects the data to unauthorized disclosure. The data should be accessed on a need-to-know basis.
• Normal test activities should not use production data. In cases where test activity requires access to production data, access to production data should be restricted to only those individuals who have a documented business need. Only the information with the documented business need should be accessible by those users.
• Production data used for testing should be securely erased upon completion of testing.
• Test data and accounts will be removed before being placed into production.
• Restricted/Protected Information will be encrypted according to the Encryption Standard while at rest or in transit. Error messages must be handled securely and they must not leak sensitive information.