How we keep data secure
We understand that when it comes to processing data from or relating to the people in your organisation, you can’t take any risks. That’s why we have gone beyond the legal requirements and regulations to provide the most secure reporting system available to our partners and the people they represent.
This means you can implement Culture Shift with the confidence of knowing all collected data is securely stored and managed. It also means that you can give the people in your organisation the same assurances ahead of them making a report.
User account protection
Amazon Cognito Advanced Security is applied to the log-in flow to protect against brute-force attempts to log in to a user’s account. For more information on this, please see Amazon’s product documentation. We encourage all users to set up two-factor authentication using a TOTP-compatible authenticator app. Alternatively, an organisation can choose to use their single-sign on system, in which case any additional brute-force protection is delegated to that system.
Secure by design
We are accredited with Cyber Essentials, and have completely isolated our office network from the reporting site network to minimise the risk to any customer data.
The application uses a Serverless architecture combined with AWS CloudFormation, meaning that developers need no direct access to the infrastructure running the application. This makes management completely automated and auditable, and in the most part, directly managed by Amazon Web Services. Developers have no direct access to the database, all direct changes made must be made through deploying code, which is audited and reviewed before being permitted to run.
By using the Serverless architecture, and making use of Amazon Virtual Private Cloud networking, we eliminate the risk of vulnerabilities and out-of-date software in the OS and networking level. You can find out more about Amazon’s security policies on their website.
Our development practice is structured around a continuous delivery pipeline. To manage vulnerabilities and out-of-date patches in the application, automated scanning tools provided by the Node Security Project are used in this pipeline. These scans run regularly on each change made to the application, and any vulnerabilities are immediately flagged to the developer who must resolve them before they can make any further feature changes. Each change must also be manually reviewed by another developer before being accepted in the mainline, and automated tests are used to check for regressions, with new features and especially security critical code paths having additional tests written to cover them.
There are a number of options based on other partner approaches that you may wish to take when it comes to developing a privacy notice.
One key consideration is whether you will redact any identifiable information that may be shared in free text boxes within an anonymous report. There are two different approaches that we have seen across our partner base:
- Including information that identifiable information will be kept confidential on the system in accordance with the organisation’s retention schedule, to inform prevention but also effectively address risk if there are multiple anonymous or identifiable reports in a particular area, or against an individual.
- Alternatively, the organisation may wish to redact information that is provided within free text boxes. This information is permanently deleted from the system and cannot be recovered.
The Culture Shift Platform has been penetration tested, and is periodically re-tested to maintain confidence in the application. Penetration testing happens at least yearly, or if there are any risky changes to the application that would benefit from further investigation.
Reports for each penetration test are available on request.
All public-facing services use HTTPS configured with the “modern” TLS cipher suite, meeting current industry standards for encryption. Inter-component encryption also uses HTTPS communication with the same configuration backed by AWS IAM roles and further locked down by AWS security groups, which are both configured with a “deny-by-default” policy and a whitelist of only permitted services. Database connections also use TLS 1.2 encryption in “verify full” mode, which is the strongest level supported by the AWS RDS database.
All data stored is also encrypted at rest using AES-256 following Amazon’s best practice for doing so. The only exception to this is uploaded images that are used on the public-facing website in support articles and for branding, which are not encrypted.