#  User Account Management

##  Roles

###  Access Owner/Administrator

The person in the Platform.sh organisation who bears final responsibility for
determining and implementing security access control, authorisation, and for
granting security access to critical systems. The  _Access
Owner/Administrators_ table evidences Platform.sh personnel and their
corresponding backups.

##  User Access Request & Approval

The foundation of access management is the process defined for approving and
granting access and privileges to systems. There are numerous Platform.sh and
third party systems that require user access approval and provisioning. These
systems include, but are not limited to, applications, operating systems,
databases, internal network infrastructure, and mobile devices.

For new hires and active Platform.sh team members, certain systems are pre-
approved based upon the team they have been assigned to work in. If a role is
not pre-approved, the Access Owner/Administrator must approve access additions
to the system via the ticketing system prior to granting access to the system
to help ensure that only authorized personnel have access to the system. The
access ticket must include which systems access, privileges, and roles are
requested to be provisioned.

For new Platform.sh members, user credentials must be distributed only after
an employee’s has started working at Platform.sh. If credentials are
forgotten, Platform.sh team members must request new credentials via automated
or manual mechanisms, and receive those credentials in a secure manner.

All user access request tickets must be retained for at least 1 year after the
access addition ticket is marked complete for Platform.sh team members or the
business relationship has ended for contractors, employee contractors,
interns, partners or vendors.

Third party vendor remote access must only be activated based upon business
need, and revoked immediately after use is complete.

###  Changes to User Access

If Platform.sh Personnel change job functions, their access to systems must be
reviewed and adjusted to reflect the level of access required for their new
job function. The user, departing manager, or hiring manager must submit an
access change request in the ticketing system.

###  Revoking User Access

When Platform.sh Personnel are terminated from Platform.sh, it is critical
that access is revoked within 24 hours to protect Platform.sh property,
systems, and data. As terminations are often involuntary, both the timeliness
of termination procedures and confidentially of termination information are
very important.

The Hiring Manager creates a termination ticket and notifies the Access

Owner/Administrators of employee terminations. The Access Owner/Administrator
must revoke the terminated employee’s access to the system within 24 hours of
receiving the termination notification. If the employee was aware of passwords
to system, service and/or default accounts, those passwords must be changed.
Platform.sh assets must be collected.

###  User Access Review

A review of user and administrator access listings must be performed by the
Access Owner/Administrator and Information Security Team to help ensure that
only authorized personnel have access to the systems and data. The access
review includes both whether the user or administrator is authorized to access
the system and whether they are authorized to have their current level of
access privileges.

###  Assignment of Passwords

A user account must be assigned an initial password. The initial password
assigned must be changed upon first use of the user account. Systems must
enforce this change upon first use when systematically possible. If systemic
enforcement for the password change is not possible, the user must change
their password upon first login if the system permits the user to change their
password. When it is not systematically possible to enforce password change
upon initial login, employees must work with the access administrator to
change their password.

The user account and password must be sent to the user separately via email or
chat. This is also true for administrative passwords, or when a user account
and password needs to be re-issued.

###  User Account and Password Use

A user account, in conjunction with a password, enables a user to authenticate
to a system. At Platform.sh, there are user accounts for employees, employee
contractors, contractors, interns, vendors, and partners.

All users are responsible for the security of data, accounts, and systems
under their control. passwords must be kept secure. Users shall not share
account or password information with anyone, including other employees,
family, or friends. Similarly, users are forbidden from performing any
activity with user accounts belonging to other users.

Additionally:

  * If a user suspects that somebody else may know his or her password, the password must be changed immediately. 

  

  * Users must not ask for customer passwords. 

  

  * Users must not store fixed passwords in any computer files, such as login scripts or computer programs, unless the passwords have been encrypted. 

  

###  Password Requirements

Password requirements help ensure that unauthorized personnel do not gain
access to Platform.sh systems and data. Password requirements should be
systematically enforced when possible, manually if not. For systems where
multi-factor authentication is in place, the manual password requirements are
superseded by this stronger authentication method.:

###  Password Storage

Platform.sh personnel must store their individual user account and passwords
in an encrypted password management vault. Passwords should never be stored
electronically in a document. Passwords must not be written down.

###  Default Passwords

All default passwords must be changed upon system install. Knowledge of the
account password needs to be restricted to authorized personnel based upon
their job responsibilities.

_**Hardcoded Passwords** _

Passwords must not be hardcoded in an unencrypted manner into an application.

_**Masking** _

Passwords must be in a masked format when entered into an Platform.sh system.

###  Administrator, Internal, and External Password Policy

The Platform.sh  _Password Policy_ defines the requirements for Platform.sh
systems and third party systems where Platform.sh administers the password
policy

###  Customer Responsibilities

  * Customers are responsible for requesting multi-factor authentication for additional security to access the Platform.sh web user interfaces. 

  

  * Customers are responsible for ensuring the confidentiality of any user accounts and passwords assigned to them for use with Platform.sh’s system. 

  

  * Customers are responsible for ensuring their application meets industry best practices for strong authentication requirements. 

  

####  Segregation of Duties

Access privileges adhere to the principles of separation of functions.
Administrative users must have an additional end user account for logging in
as an end user to perform his or her job function.

####  Role Based Security

Role based security must be utilized for systems access. The role(s) assigned
should only include the least access privileges necessary for a user to
perform his or her job function. Access privileges typically include
privileges such as read, write, and delete. In certain systems, access
privileges may allow or not allow access to specific screens or fields or
functions within the system.

####  Administrator Access

Administrator access permits powerful systems access that could include the
ability to add and remove users, change or delete data, and implement code.
Administrator access to systems must absolutely be restricted to only those
personnel that require this level of access to perform their job functions
including, but not limited to, the following teams:  
  
<table>  
<tr>  
<th>

AWS Console

</th>  
<th>

Support, Engineering, Operations

</th> </tr>  
<tr>  
<td>

Server Operating System (O/S)

</td>  
<td>

Support, Engineering, Operations

</td> </tr>  
<tr>  
<td>

Application

</td>  
<td>

Authorized Access Owners/Administrators

</td> </tr> </table>

####  Computer Screen Lockout

If there has been no activity on a computer terminal, workstation or personal
computer (PC) for 15 minutes, a password protected screen saver must
automatically lock the screen. Reestablishment of the session will take place
only after the user has provided the proper user account and password for
authentication. Employees are required to lock their screen if they leave
their computer unattended.

####  Public Content and Permitted Actions without Authentication

Unauthenticated users are only permitted to view certain publicly accessible
content via Platform.sh external user interfaces. The content must be
classified as ‘public’. Role based security is utilized to prevent the
disclosure of restricted or internal use only data.

Platform.sh team members are responsible for reviewing and posting content to
public facing mediums.

#  Networks & Services

Users shall have direct access only to the networks and services that they
have been specifically authorized to use. Platform.sh employees operate with 6
varieties of credentials

  * LDAP credentials 

  

  * Google Apps credentials 

  

  * Amazon IAM credentials 

  

  * Platform SSH public key credentials 

  

  * Atlassian (JIRA/HipChat) credentials 

  

  * Accounts/Zendesk credentials 

  

##  LDAP Credentials

An LDAP account allows access to the interlan Platform.sh web based
infrastructure management and monitoring applications hosted on
admin.platform.sh.

##  Google Apps

Platform.sh utilizes Google applications for company email and contacts,
documents, and conferencing. Google Apps credentials require two-factor
authentication.

##  Amazon IAM

Platform.sh utilizes Amazon IAM (Identity and Access Management) credentials
in order to operate all Amazon Web Service resources for Platform.sh Cloud.
IAM credentials require two-factor authentication.

##  SSH public key

Platform.sh utilizes SSH public key authentication to control access to
virtual machine (VM) and container resources running Platform.sh services and
customer applications.

Privileged access to Platform.sh VMs and containers is restricted to users
accessing via our 'jump' box (admin server, aka bastion host).

##  Atlassian (JIRA/HipChat)

Platform.sh utilizes JIRA and HipChat, both of which are sotfware as a servce
products maintened by Atlassian. JIRA is used to track internal issues
affecting the business and product. HipChat is used for real-time
communication between employees and customers.

##  Accounts/Zendesk

Zendesk is the Platform.sh customer facing issue and support tracking system.
This is a software as a service maintained by the company of the same name,
Zendesk.

Platform.sh utilizes a self hosted Drupal instance (called Accounts) to manage
customer and employee access to Zendesk and Platform.sh Standard UI. Account
credentials require twofactor authentication.

#  Operating Systems

##  Cloud Infrastructure

Platform.sh has standardized on using Debian Linux for virtual machine (VM)
and container resources running Platform.sh services and customer
applications.

Hosts are accessible using only (Secure Shell) SSH with public key
authentication.

##  Employee Workstations

Platform.sh does not dictate the type of operating system employees use on
workstations. Any operating system capable of securely accessing the Internet
via a Web Browser and SSH console is suitable.

Platform.sh employees are responsible for self-managing access to personal
workstations in order to remain compliant with Platform.sh policies.

#  Applications

Platform.sh employees and customers utilize many diffrent types specific
applications to gain access to manage cloud infrastrure and services. Some
common use cases include:

##  Web Browser

May be used to access any web based services such as Google Apps, Zendesk,
JIRA, HipChat, Accounts, and Platform UI.

This includes well-known desktop web browsers such as Mozilla Firefox, Google
Chrome, Opera, Safari, and Internet Explorer, mobile devices, or any HTTPS
client application capable of rendering modern HTML/CSS/Javascript.

##  Secure Shell Client

Used to connect to and manage hosts and container resources remotely via the
command line. Most Platform.sh employees and customers are utilizing the
widely known OpenSSH client included in UNIX based operating systems. Users of
the Microsoft Windows Operating system have several commercial and open source
alternative solutions available, for example PuTTY.

##  AWS Command Line Interface Tools

Platform.sh personal who require access to AWS instance management and
configuration via a command line console use the official Python based AWS
Command Line Interface Tools provided by Amazon. Complete details about access
control with the AWS CLI is found in the official documentation
_http://aws.amazon.com/documentation/cli/_ .

#  Mobile computing and teleworking

Platform.sh is a virtual office enviroment. Most employees work remotely over
the Internet using the aforementioned applications, networks, and services
with company provided hardware.

The employee is responsible in ensuring his/her workstation and personal
network is properly secured from unauthorized access. At minimum, hard disk
drive encryption is enabled.

**Platform.sh**

Information Security Policy

Version 0.1.1

Updated: 2016-03-30

##  Purpose

Platform.sh is a customer centric organization. We strive each day to provide
the best products and services to our customers. This in turn enables our
customers to be successful in their business. Platform.sh has a creed that
employees live by each day to ensure we meet our customers expectations:

  1. Do the right thing 

  

  2. Jump in and own it 

  

  3. Committed to awesome 

  

  4. Give back more 

  

  5. Inspire a little crazy 

  

  

Platform.sh has an Information Security and Compliance Program that provides
the security, control, and transparency that our customers expect. The purpose
of this policy is to ensure the highest level of integrity, confidentiality
and availability of Platform.sh and customer systems and data. Platform.sh
understands that information security is extremely important to our customers
and us.

##  Scope

The Information Security Policy is one component of a comprehensive
Information Security and Compliance Program at Platform.sh and must be
followed by all Platform.sh employees, employee contractors, interns,
contractors, vendors, customers, and partners utilizing Platform.sh system
resources. The policy includes key security and operational requirements in
areas that include, but are not limited to, the following:

  * Authentication 

  

  * Access Management 

  

  * Logging and Monitoring 

  

  * Application Development 

  

  * Backup 

  

  * Configuration Management 

  

  * Patch Management 

  

  * Vulnerability Management 

  

  * Anti-virus Protection 

  

  * Perimeter Defenses 

  

  * Asset Management 

  

  * Incident Management 

  

  * Physical Security 

  

  * Environmental Security 

  

  * Third Party Vendor Management 

  

The scope of this policy includes information security controls and safeguards
that protects Platform.sh, customer systems, and data. Security in the cloud
is a shared responsibility between different service providers and the
customer. Within the roles and responsibilities section of this policy
Platform.sh describes the shared responsibility model and references customers
and Amazon Web Services (AWS) responsibilities.

##  Management Commitment and Applicability

The Platform.sh Executive Team will fully commit to and support policies and
procedures. The Platform.sh Data Management Officer will ensure all
organizational entities coordinate to effectively implement and disseminate
these policies and procedures.

##  Definitions  
  
<table>  
<tr>  
<th>

**Term**

</th>  
<th>

**Definition**

</th> </tr>  
<tr>  
<td>

Security Logging

</td>  
<td>

Security logging is the recording in a log file of security events that
occurred on the system.

</td> </tr>  
<tr>  
<td>

Service Account

</td>  
<td>

A service account is an account that is utilized by the system for an
automated process.

</td> </tr>  
<tr>  
<td>

Default Account

</td>  
<td>

A default account is an account that is part of the installation of the
particular system. For example, the ‘root’ administrator account for a Linux
system.

</td> </tr>  
<tr>  
<td>

Third Party Vendor

</td>  
<td>

A third party vendor provides goods or services to Platform.sh in exchange for
payment from Platform.sh.

</td> </tr>  
<tr>  
<td>

Complementary

Control

</td>  
<td>

A secondary control that serves the same purpose in reducing a given risk as
the primary control. This control is meant to ‘complement’ the primary control
in reducing the risk.

</td> </tr>  
<tr>  
<td>

PCI-DSS

</td>  
<td>

Payment Card Industry Data Security Standard (PCI-DSS) – A set of standard
security requirements established by the payment brands (AMEX, VISA,
MasterCard, etc.) to ensure security for the storage, processing or
transmission of cardholder data.

</td> </tr> </table>

##  Roles and Responsibilities  
  
<table>  
<tr>  
<th>

**Role**

</th>  
<th>

**Responsibility**

</th> </tr>  
<tr>  
<td>

Product Owner

</td>  
<td>

The Product Owner is responsible for approving the release for implementation
into the production environment via the ticketing system.

</td> </tr>  
<tr>  
<td>

Director of Operations

</td>  
<td>

Director of Operations is responsible for approving and scheduling
maintenance, operational incident response, and overall management and
oversight of Support and Operations Personnel.

</td> </tr>  
<tr>  
<td>

Hiring Manager

</td>  
<td>

The Hiring Manager/Manager is responsible for requesting new hires access or
access modifications for existing employees to Platform.sh systems and
employment checks.

</td> </tr>  
<tr>  
<td>

Human Resources

Personnel

</td>  
<td>

Human Resources (HR) personnel are responsible for current, new and terminated
employees processing tasks.

</td> </tr>  
<tr>  
<td>

Access Owner / Administrator

</td>  
<td>

Responsible for certain access administration tasks, facilitating the access
addition / modification, revocation processing, and performing quarterly
access reviews

</td> </tr>  
<tr>  
<td>

Platform.sh

Contact for the

Third Party Vendor

</td>  
<td>

The Platform.sh Contact for the Third Party Vendor is responsible for being
the point of contact for the third party vendor, which may include, but is not
limited to, service and maintenance requests, feature requests, assisting
finance with billing or payment questions, requesting compliance audit
documentation.

</td> </tr>  
<tr>  
<td>

Platform.sh Personnel

</td>  
<td>

Platform.sh personnel include employees, employee contractors, contractors,
and interns and are responsible for complying with the requirements outlined
in the Information Security Policy.

</td> </tr>  
<tr>  
<td>

Executive Team / Leadership

</td>  
<td>

A collection of senior leaders and executives at Platform.sh responsible for
making key strategic and operational decisions for Platform.sh.

</td> </tr>  
<tr>  
<td>

Product Manager

</td>  
<td>

The Product Manager is responsible for documenting user stories, grooming and
prioritizing the change and feature requests, and leading sprint review
meetings.

</td> </tr>  
<tr>  
<td>

Risk Owner

</td>  
<td>

Responsible for making decisions regarding Platform.sh risks and assigning
remediation activities to their teams. Ultimately responsible for the risks
within their business unit.

</td> </tr>  
<tr>  
<td>

Operations Personnel

</td>  
<td>

Responsible for many different security and operations activities, that
includes but are not limited to, systems administration, backup, configuration
management, patch management and anti-virus.

</td> </tr>  
<tr>  
<td>

ISMS Committee / InfoSec Team

</td>  
<td>

Responsible for performance and oversight of different information security
activities at Platform.sh

</td> </tr> </table>

##  Shared Responsibility Model

###  Platform.sh Responsibilities

Platform.sh is responsible for the security and availability of the
Platform.sh PaaS Platform and Internal Platform.sh Systems. This includes the
operating system and database layers of the architecture. This includes, but
is not limited to, server level patching, vulnerability management,
penetration testing, security event logging & monitoring, incident management,
operational monitoring, 24/7 support, and ensuring customer site availability
in accordance with SLA’s. In addition, Platform.sh is responsible for managing
server firewall configurations

(IPTables) and perimeter firewall configurations (security groups). If a
customer has the Platform.sh CLI tool, security updates to core and
contributed modules will be made available for testing via an automated
process. Deployment to production by Platform.sh requires customer testing and
approval.

###  Customer Responsibilities

The customer is primarily responsible for the security of their application
hosted on the Platform.sh Platform. This would include ensuring a secure
configuration and coding of the website application, and related security
monitoring activities including penetration testing and vulnerability scans of
the customer site on a periodic basis. Platform.sh offers professional
services and works with third party partners to assist customers with building
their website application and assume some of these responsibilities. In
addition, Customers are also responsible for the security of their users, the
granting of privileged access to their configuration (Platform UI) and
application (hosted web application).

###  AWS Responsibilities

AWS is responsible for security of the network including routing, switching,
and perimeter network security via firewall systems and intrusion detection
systems (IDS). AWS is responsibly for physical security to the data centers
hosting the Platform.sh PaaS, and environmental security to ensure proper
power, cooling, and mechanism controls are in place. AWS is responsible for
the bare metal infrastructure that is running the Platform.sh PaaS.
Platform.sh PaaS is built within Amazon's AWS data centers and uses Amazon's
Elastic Compute Cloud (EC2), Amazon Simple Storage Service (S3) and Elastic
Block Store (EBS) services.

##  Policy

###  Information Classification

Information is a critical resource at Platform.sh that must be appropriately
classified and handled to help ensure the following:

  * Platform.sh meets customer, industry, regulatory and privacy standards. 

  

  * Protection of customer data. 

  

  * Reduce the risk that internal use only or restricted information is released to unauthorized personnel. 

  

####  6.1.1 Roles and Responsibilities

Platform.sh has established three different information classifications to
help ensure the protection of Platform.sh and customer information:  
  
<table>  
<tr>  
<th>

**Public**

</th>  
<th>

Information that can be viewed by the general public.

</th> </tr>  
<tr>  
<td>

**Internal Use Only**

</td>  
<td>

Information that must be kept internal to Platform.sh personnel. Platform.sh
internal use only information includes, but is not limited to:

  * Intellectual Property: Source code and system diagrams 

  

  * Sales Data: Prospective customer company, name, phone number, email, address 

  

  * Platform.sh Human Resources Data: Platform.sh Personnel names, addresses, salary information 

  

</td> </tr>  
<tr>  
<td>

**Restricted**

</td>  
<td>

Restricted information must not be viewed by Platform.sh personnel unless
explicit permission is provided by the customer. Platform.sh restricted
information includes, but is not limited to:

  * Customer Data: Data stored on the customer database. 

  

  * Cardholder Data: Full magnetic stripe or personal account number (PAN) plus any of the following: Cardholder name, expiration date, service code. 

  

  * Classified Data: Information that has been determined pursuant to Executive Order 13526 or any predecessor order to require protection against unauthorized disclosure and is marked to indicate its classified status when in documentary form. (Reference: CNSSI 4009, EO 13526) 

  

  * Personally Identifiable Information (PII) Definitions: Reference: State Data Privacy Laws 

  

  * Personal Health Information (PHI): Protected health information (PHI) is any information in the medical record or designated record set that can be used to identify an individual and that was created, used, or disclosed in the course of providing a health care service such as diagnosis or treatment. 

  

</td> </tr> </table>

###  Data Handling

Platform.sh has established different areas of responsibility to reduce
opportunities for unauthorized or unintentional modification or misuse of
data.  
  
<table>  
<tr>  
<th>

**Public**

</th>  
<th>

Information that can be viewed by the general public.

</th> </tr>  
<tr>  
<td>

**Internal Use Only**

</td>  
<td>

Information that must be kept internal to Platform.sh personnel. Platform.sh
internal use only data handling includes, but is not limited to:

  * Intellectual Property: Must not be posted to public forums, or shared over unencrypted communications mechanisms (e.g. Chat or email) ● Sales Data: Must not be posted to public forums. 

  

  * Platform.sh Human Resources Data: Access should be restricted to only authorized human resources personnel. 

  

</td> </tr>  
<tr>  
<td>

**Restricted**

</td>  
<td>

Restricted information must not be viewed by Platform.sh personnel unless
explicit permission is provided by the customer. Platform.sh restricted data
handling includes, but is not limited to:

● Customer Data: Must not be viewed by Platform.sh personnel unless explicit
permission is provided by the customer.

</td> </tr>  
<tr>  
<td>

</td>  
<td>

●

</td>  
<td>

Cardholder Data: Must be stored within the Platform.sh PCI-DSS compliant
virtual private cloud (VPC) offering and include data encryption and a full
multi-tier setup.

</td> </tr>  
<tr>  
<td>

</td>  
<td>

●

</td>  
<td>

Classified Data: Platform.sh is not authorized to handle or store classified
information.

</td> </tr>  
<tr>  
<td>

</td>  
<td>

●

</td>  
<td>

Personally Identifiable Information (PII): Should be stored with the
Platform.sh PII offering and include data encryption.

</td> </tr>  
<tr>  
<td>

</td>  
<td>

●

</td>  
<td>

Personal Health Information (PHI): Must be stored within the HIPAA VPC
offering and include data encryption. In addition, customer must sign a
Business Associate Agreement (BAA).

</td> </tr> </table>

Platform.sh Responsibilities

  * The data on retired Platform.sh technology assets must be deleted and/or degaussed prior to disposal of the asset. 

  

  * Employees must lock computer workstation screens when unattended. In addition, systemic controls must be configured to lock computer workstations after 15 minutes of inactivity. 

  

  * Locked shredding bins must be located in the main office facility to help ensure that sensitive data is securely disposed. Documents that contain internal use only or restricted information must be disposed of in the shredding bins. A third party must collect the shred bin materials on at least a quarterly basis and securely shred the contents onsite. A shredding certificate must be required from the third party provider. 

  

  * A cross-cut shredder or secure shredding service must be located at each of the remote Platform.sh office facilities. Documents that contain Platform.sh internal use only or restricted information must be disposed of utilizing the cross-cut shredder. 

  

  * Access to the HR, legal, and security file shares and hard copy file folders must be restricted to authorized personnel based on role to help ensure that documentation is only available to personnel that require access to perform their job function. 

  

  * Hardcopy documentation containing HR sensitive data including but not limited to, PII, compensation information, and health information must be securely locked via lock and key and accessible only by authorized HR personnel. 

  

  * System documentation stored in the Cloud must be appropriately protected with access controls. 

  

  * Documentation containing restricted information that is transmitted electronically across public networks or wirelessly must use access control methods and strong encryption protocol of 128 bit strength or greater. Internal use only information should not be stored, accessed or transported outside of Platform.sh office facilities unless it is securely transmitted or located at a third party service provider approved through the third party management process. 

  

AWS Responsibilities

  * AWS is responsible for installation, maintenance, disposal of physical server infrastructure supporting Platform.sh operations. 

  

Customer Responsibilities

  * Customers are responsible to provide Platform.sh knowledge of restricted information that will be stored, processed or transmitted on the Platform.sh PaaS platform. 

  

  * Customers are responsible for selecting the services required for the storage, processing or transmission of restricted information to ensure restricted information is being handled according to Platform.sh policy. 

  

  * Customers with cardholder data on the platform are responsible for ensuring legal, regulatory, and business requirements are met regarding the retention of cardholder data. In addition, customers are responsible for setting retention, deletion, and review processes for cardholder data. 

  

##  Risk Management

_ISO 27001: 6.1.2 – Information security risk assessment_

_ISO 27001: 6.1.3 – Information security risk treatment_

The Information Security Program at Platform.sh is a risk-based program.
Platform.sh values the necessary balance between risk and control, and
understands that the intent of the Information Security Program at Platform.sh
is to reduce risk to an acceptable level. Security control can never eliminate
risk entirely.

To facilitate the risk decision process at Platform.sh, various Risk Owners
have been identified. These Risk Owners are Platform.sh Team members that are
responsible for the risks identified within their respective business units.
For a given risk, the Risk Owner must evaluate the likelihood and impact on
confidentiality, integrity and availability and must make one of the following
decisions regarding the risk:

  * **Remediate** \- Address the risk and fix the issue based on risk rating. 

  

  * **Monitor** \- Monitor the risk until such time a decision can be made for the risk. 

  

  * **Transfer** \- Transfer the risk to a third party or place reliance on a complementary control. 

  

  * **Accept** \- Accept the risk and do nothing to address the risk. 

  

The quantification of risk helps enable the Risk Owner to make a decision
regarding the risk. Critical and High risks are required to be remediated.

The risk assessment results must be documented and distributed to key
stakeholders within the Platform.sh organization.

##  Corporate Governance

A corporate governance framework is in place at Platform.sh to help ensure
continuity and monitor quality of the Information Security Program. The
Paltform.sh Executive Team is committed to supporting and evangelizing the
importance of the Information Security Program. Platform.sh has the following
groups established to facilitate corporate governance:

  * **Board of Directors** – A board of directors is in place and meets on at least a quarterly basis to help ensure oversight for management strategy and operations. 

  

  * **Audit Committee** – An audit committee is in place and meets on at least a quarterly basis to help ensure that an independent body can provide sound corporate governance in corporate matters. 

  

  * **Governance, Risk and Compliance (GRC) Council** – A GRC Council is established with members of the Platform.sh Executive team to help ensure that organizational risks are prioritized and addressed, accepted or transferred. The GRC council meets on at least a quarterly basis. 

  

**Information Security Program Monitoring** : Paltform.sh personnel must
perform a risk assessment on an annual basis or where there is a significant
change in the environment to help monitor that the Platform.sh Information
Security Program is operating effectively.

**Information Security Architecture** : Information Security must be designed
into the Platform.sh Product as an inherent component of the system. The
architecture must include security components that help to ensure the
confidentiality, integrity and availability of customer systems and data.
Security architecture diagrams must be reviewed at least annually or whenever
there is a significant security architecture change.

**Policy, Plan & Procedure Review ** : The policy, plan and procedure owners
must perform a review and update of their policy, plans and procedures on at
least an annual basis to help ensure that policy, plan, and procedure
documentation is up to date.

**External Third Party Audits** : Information security controls must be
evaluated on an annual basis by an independent third party audit firm to
ensure controls are designed and operating effectively.

##  Security Awareness & Training

Platform.sh personnel must attend security awareness training as part of new
hiring training employee onboarding process and on an annual basis thereafter
to help ensure that security best practices are owned and followed by
Platform.sh personnel. In addition, Platform.sh personnel must attend
department specific training to help ensure they know how to properly perform
their job function. Security awareness training content is to be reviewed on
an annual basis or when there has been a significant change to help ensure
that content relevant and current. Data Management Officer will ensure that
personnel have completed security awareness training. When required, the Data
Management Officer will send out emails regarding security issues.

Operations, Support and Engineering personnel must attend platform specific
security training upon assuming a Platform.sh role, upon significant changes
to the platform that would necessitate a retraining, and on an annual basis.
Training completion documentation must be logged and tracked for at least one
year.

##  Human Resources

The Data Management Officer at Platform.sh is responsible for the new and
terminated employee processes including, but are not limited to, recruitment,
new hire training, termination notification, termination asset lifecycle
management, and facilitating the completion of required new hire
documentation.

_**Code of Conduct and Ethics** _

_**Preventing Harassment** _

###  Acceptable Use

New Platform.sh personnel must read the Platform.sh Acceptable Use policy and
confirm their receipt and understanding of this policy with their sign-off.

###  Non-disclosure agreements

New Platform.sh personnel must read and sign the Non-Disclosure Agreement
(NDA) as part of the offer letter process and confirm their receipt and
understanding of this agreement with their signature. The NDA includes clauses
for non-solicitation and intellectual property.

###  Information Security Policy

New Platform.sh personnel must read the Platform.sh Information Security
Policy and confirm their receipt and understanding of this policy with their
sign-off.

_**Security Awareness Training Completion** _

Data Management Officer must confirm that each new employee completed
training.

_**Employment Checks** _

###  Job Descriptions

The Hiring Managers are responsible for ensuring documented positions
descriptions are maintained that outline roles and responsibilities for
Platform.sh Personnel and prospective candidates. In addition, the Hiring
Manager is responsible for periodically reviewing and updating the position
descriptions.

###  Exit Interview

Data Management Officer must discuss information security topics including
returning information technology assets and that the employee system access
will be revoked as a component of the termination process.

###  Termination Processing

Data Management Officer must collect Platform.sh technology assets as a
component of the termination process. A termination checklist within the
ticketing system must be utilized to help ensure that employee termination
procedures are completed.

_**Transfer Processing** _

###  Customer Responsibility

Customers are responsible to review and understand and abide by the external
user acceptable use policy listed on the Platform.sh webpage.

##  Access Management

Further detail on access management is evidenced within the User Account
Management section of the Platform.sh  _System Access Control_ policy.

##  Security Audit Logs

Security audit logs of must be available for both real time security event
monitoring and forensic security event investigations. A comprehensive
illustration on logging events and elements is evidenced within the
_Platform.sh Logging Event Table_ .

Security Audit Log Monitoring is critically important to effectively use the
data provided by security audit logs. Without a review of security audit logs,
there is an increased risk that a security event could go undetected. Further
detail on log monitoring in available on the  _Logging and Monitoring
Procedure_ document.

If the review of the security event indicates that there is an intrusion or
breach then the Platform.sh Incident Response Plan must be activated.

##  System Development Life Cycle (Change Management)

Platform.sh product and engineering teams perform system development
activities. These teams each participate in the Agile system development
lifecycle (SDLC). To build new product capabilities, Platform.sh follows agile
process. The Platform.sh application development lifecycle includes a number
of controls to help ensure development efforts are coded well and securely.

###  Ideation

The purpose of the Ideation phase is to assess and get buy-in for new product
investment opportunities with Product, Engineering, Sales, Finance, and Legal
leadership before any product development begins.

###  Pre-Development planning EPICs

EPICs must be documented to define the engineering requirements that will be
broken out into ‘User Stories’.

###  User Stories

User stories document the detailed use cases related to the EPIC. These user
stories are often a one to many relationship between a ‘EPIC’ and the ‘User
Stories’. User stories must be documented and prioritized in the ticketing
system by the Product Managers. The user stories include the development
'tasks' that are required for the release.

###  Bugs / Tickets

Bug / Ticket requests relate to a specific issue that requires the engineering
team to investigate and/or intervene. They are generated by engineering
personnel and must be documented in the ticketing system and include, but are
not limited to, the following information:

  * Project 

  

  * Description 

  

  * Issue Type 

  

  * Priority 

  

  * Status 

  

  * Assignee 

  

###  Sprint Review Meetings

Engineering and product teams have several different review meetings as part
of the Agile software development process including:

  * **Daily ‘scrum’ meetings** : Daily meetings to discuss progress. 

  

  * **Additional Meetings** : Architecture meetings, release review meetings are held as needed.