Data Protection Policy

Customer Data Protection

Our enterprise architecture is hosted on Amazon Webs Services (AWS) and is designed to provide 99.99% availability.  Our database is managed by Amazon RDS, ensuring redundancy, high availability and trustworthy automated, encrypted backups.

As a global leader in web hosting, AWS is certified for a growing number of compliance standards and controls, and undergoes several independent third party audits to test for data safety, privacy, and security.  Read more about the specific certifications on the AWS compliance page.

Social Workshop Ltd hosts customer data in AWS EU-West region by default.  Data is replicated or backed up across multiple regions for redundancy and disaster recovery.

All Social Workshop Ltd 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 Customer Production Data is segmented and only accessible to Customer authorized to access data.
• All systems and services are equipped with integrated failover and fault tolerance with multiple availability zones for redundancy.
• All Production Data at rest is stored on encrypted volumes using industry standard AES-256 encryption.  Our backups of your data are also encrypted.
• Whenever Customer Production Data is in transit between you (or your users) and us, everything is secured with TLS 1.2 encryption and sent using HTTPS.

Access

Social Workshop Ltd employee access to Production Data 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 Compliance Team on a case by case basis.

Separation
Customer Production Data is logically separated at the database/datastore level using a unique identifier for the customer.

The separation is also 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

Social Workshop Ltd uses AWS Cloudwatch 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.

Confidentiality/Non-Disclosure Agreement (NDA)

Social Workshop Ltd uses confidentiality or non-disclosure agreements (NDAs) to protect confidential information using legally enforceable terms.  NDAs are applicable to both internal and external parties.  NDAs will have the following elements:

• Definition of the information to be protected
• Duration of the agreement
• Required actions upon termination of agreement
• Responsibilities and actions to avoid unauthorized disclosure
• Ownership of information, trade secrets and intellectual property
• Permitted use of the confidential information and rights to use information
• Audit and monitor activities that involve confidential information
• Process of notification and reporting of unauthorized disclosure or information leakage
• Information return or destruction terms when agreement is terminated
• Actions in case of breach of agreement
• Periodic review

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.
• Messages must be protected from unauthorised access, modification or denial of service.
• Messages must be reviewed prior to sending to ensure correct addressing and transportation of the message.
• The reliability and availability of the messaging channel must be verified.
• All applicable legal requirements will be adhered to.
• Use of external public services such as instant messaging, social networking or file sharing will require prior approval and authorisation.
• Publicly accessible networks will be controlled by stronger authentication.

Event Logs

All Social Workshop Ltd systems that handle confidential information, accept network connections, or make access control (authentication and authorisation) decisions will record and retain audit-logging information sufficient to answer the following questions:

• What activity was performed?
• Who performed it?
• Where, when, and how (with what tools) was it performed?
• And, what was the status, outcome, or result of the activity?

Logged Activities

The logs will be updated whenever the system is asked to perform any of the following activities:

• Create, read, update, or delete confidential information, including confidential authentication information such as passwords;
• Create, update, or delete information not covered in above;
• Initiate a network connection;
• Accept a network connection;
• User authentication and authorization for activities covered above such as user login and logout;
• Grant, modify, or revoke access rights, including adding a new user or group, changing user privilege levels, changing file permissions, changing database object permissions, changing firewall rules, and user password changes;
• System, network, or services configuration changes, including installation of software patches and updates, or other installed software changes;
• Application process startup, shutdown, or restart; and
• Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as for CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault.

Log Elements

Each log will identify or contain at least the following elements, directly or indirectly (unambiguously inferred):

• Type of action – examples include authorize, create, read, update, delete, and accept network connection.
• Subsystem performing the action – examples include process or transaction name, process or transaction identifier.
• Identifiers (as many as available) for the subject requesting the action – examples include user name, computer name, IP address, and MAC address.  Note that such identifiers should be standardized in order to facilitate log correlation.
• Before and after values when action involves updating a data element, if feasible.
• Date and time the action was performed, including relevant time-zone information if not in Coordinated Universal Time.
• Whether the action was allowed or denied by access-control mechanisms.
• Description and/or reason-codes of why the action was denied by the access-control mechanism, if applicable.
• The system will also ensure clock synchronization for the accuracy of audit logs.  A network time protocol will be used to keep all of the servers in synchronization with the master clock.

Administrators and Operator Logs

To safeguard and prevent manipulation of logs by privileged users the following will be implemented where appropriate and possible:

• System administrators are not permitted to erase or de-activate logs of their own activities.
• Real-time copying of logs to a system outside the control of a system administrator or operator.
• Monitoring system and network administration activities by using an intrusion detection system managed outside of the control of system and network administrators.
• Frequent review of logs to maintain accountability of privileged users.