please notify us by opening an issue on GitHub.
The following roles have been identified in our organization.
The Management/Leadership team is ultimately responsible for the information security in the organization; it is not “outsourced” to anyone else.
Day-to-day responsibility for checking that process/procedures for information security are followed/met belongs to the
The Data Controller (“DC”).
The Application Developer(s) (“Devs”) are responsible for implementing the code and systems which have the protection of people’s personal data at heart.
Additionally Devs should make reasonable efforts to keep their knowledge and skill current and keep track of security reports/advisories which are relevant to the code which has been included/used in the application.
localStorage(where it can be “stolen” by an “XSS” attack)
Under no circumstances should a developer merge her/his own change/feature/bugfix. Segregation of duties should exist wherever practical to ensure accountability.
The Quality Assurance (QA) person (or team) is responsible for checking/testing features of the application while they are being built and before they are released to the “live” environment. QA is the “gate keeper” between application developers and end-users.
Wherever possible/practical there should be a segregation of duties between the people who write the code and those who review it.
QA should not write code unless the team is small and the QA/developer roles are being alternated.
All the components of our application are run on the Amazon Web Services (AWS) “Cloud” Computing Platform-as-a-Service (PaaS).
Access to the “Production” AWS account is restricted to the Data Controller (DC). The DC grants access to the DevOps person as required to perform their tasks (e.g: updating the certificate on the server cluster) and once the task is complete access is revoked.
A full audit trail of actions performed in the AWS Console is recorded in case an involuntary (or malicious) negative action is performed.
For detail on AWS’s compliance with relevant security standards see: https://aws.amazon.com/compliance/soc-faqs/
Production data of client will never be used in staging or other test environment of the Ambassify platform.
The following applies to company owned and “Bring Your Own Device” (BYOD) equipment.
We require that all devices:
All members of staff and contractors are required to notify the Data Controller immediately in the event of loss or theft of any device.
In the event of loss or theft the passwords for all accounts should be reset as a precautionary measure and the incident should be reported to the policy (or other relevant authority).
Removable media is not permitted in the organisation. Where files need to be shared they are done through Google Drive which has good access controls, audit logs and encrypted transmission.
The only exception for using removable media is for making backups.
In the event any file has to be transfered over an insecure channel (email, local network, …), at least AES-256 encryption should be applied and the password transfered over a different communication channel as described in the data-protection policy. Any software supporting AES-256 encryption may be used to apply the encryption.
We have the following password/passphrase policy:
all employees and contractors are required to watch the following security and privacy awareness training videos:
The policies and procedures contained within this document will be reviewed annually in the first week of October. A 2 hour block time has been scheduled on an annual basis and calendar invite has been sent.
Note: Any additional people who are relevant/interested/available will be invited closer to the time.
The policies may be updated in response to a change in systems or service providers.
When a new technology or system is introduced into the company e.g. a new piece of hardware or 3rd party service provider is being considered we will review the requirements of the policies contained herein and ensure compliance.
Where an amendment is required it will first be discussed in a Github “issue”