This information is provided to give a high level overview of our approach to Data Security
- We recognise that Data Security is a core component of our product offering, and take it seriously. Data security is everyone’s responsibility. - Policy is lead by the Chief Security Officer, who is a member of the senior management team - We expect to protect our client data, and that of their customers (Respondents), to a level at least as great as the client would themselves. - We are advocates for Data Security. We believe it is our role to ensure secure practises are followed, even if there is no awareness by (or requirement from) the client for the need to do so. - We approach Data Security using the common CIA framework (Confidentiality, Integrity, Availability)
- Cloud services by AWS, Dublin (Under European data privacy laws) AWS operates a shared responsibility model AWS manages security of the cloud, security in the cloud is the responsibility of BigEars https://aws.amazon.com/compliance/shared-responsibility-model/ AWS is certified to comply with multiple industry and government security standards, including ISO 27001 and PCI DSS Level 1. See the AWS Compliance website at http://aws.amazon.com/compliance/ for full details.
- Encrypted Redundant (2 availability zones) Postgres Aurora Database - ssh /sftp/ssl access for clients using key pairs - Option for pgp encryption on the transferred file as well. - Password policies and management and MFA in place for staff - TLS for emailed feedback alerts is available
At BigEars we have policies and processes in place to ensure that passwords, encryption keys and other access tokens are of acceptable strength and are managed appropriately.We use the strongest credentials practical and store them securely so an attacker who compromises one system cannot easily use it as a vector to compromise others.
- Access to all BigEars systems must require strong credentials, e.g. a suitably complex password or (preferred) a password-protected private key. - Credentials should be unique to each user and must never be shared even within the company. Staff members are personally responsible for the security of their credentials and are accountable for all actions performed under their user logins. - Staff should use an approved password manager to ensure Maximum password complexity Frequent expiration of pwds do not impact on productivity or undermine security Default password complexity is to use a pwd generator set to 15 chars, with mixed case, numbers and special chars, which must include all character types. It is okay to exclude ambiguous chars. If a system cannot support all these options, then the strongest options available should be used. - Passwords and key files must never be stored in plain text without an additional layer of protection, whether on developer workstations, on production servers, embedded in software or inside databases. This applies particularly to any temporary files created as part of credential maintenance (e.g. during key generation or SSL certificate creation). - Use Two-Factor Authentication where available.
Least Access Principle
- Any person or system that does not require access to data should not have access to that data. - We should only be given data, or collect data, that we need to perform our services.
Type of Data Held
- We do not receive any highly sensitive information about respondents such as credit card information or passwords.
- We do need respondent contact information such as mobile number and email address in order to send feedback requests
- We often use first names to personalise communications but do not generally need full names.
- Feedback responses (comments left by respondents) hardly ever include personally identifying information, and have only once in over a decade included highly sensitive information (a credit card number) that a respondent has included in their feedback response. We do have a process in place for isolating that should it occur.
- Wherever possible, data should be encrypted in flight and at rest.
- Our contract includes confidentiality clauses that protect client and respondent data.
- Our staff and contracted transcribers, developers, and support staff all operate under confidentiality
- Transcribers only have access to individual calls and only while they are transcribing them (no search or browsing, and no access to meta-data).
Employee background checks
- All our employees are subject to periodic credit and criminal background checks.
- Transcribers are long term, part time contractors, almost always recruited through personal referral, and are subject to credit background checks.
- The data we collect on your behalf belongs to you
- We have default data retention policies in place for all the information assets we hold on behalf of clients, and variations on these policies can be incorporated into the contract
- All data assets and associated risks are tracked via our Information Asset Register
Business Continuity Planning
- With all our infrastructure hosted on highly available, often redundant, AWS infrastructure that can be built/rebuilt from script and backups, even in a totally different region, our robustness to adverse events is the envy of most of our clients.
- Our AWS-based database is fully replicated and regularly backed up to s3, and apps can be and are regularly built /rebuilt and deployed from script/backup as part of our Continuous Improvement Development /deployment cycle.
- The nature of our service is that even high levels of disruption to sending feedback requests do not have a significant impact on the client business, as we could always "catch up" during the month. - Our core service provision does not require staff involvement in the day to day process, other than transcribers and curation services (if applicable). This means the service can continue for some time without impact if staff are unavailable. - Transcription is not essential to provision of the service in any case - We have a high degree of flexibility with our transcriber resource as all are part time, so we could expand capacity for short periods in a crisis - We have transcription teams in NZ and UK, providing geographical and timezone robustness if the client allows that.
- All key systems are automated and able to be managed remotely. In our tests we have moved all personnel to new location in under 1.5hrs, with zero service disruption.
- Our company policy is that the legal and ethical rights of feedback respondents should always be respected. - Respondents offer their feedback so that our client can learn from their experience, and potentially put right mistakes that have been made. - Respondent have the following expectations about your use of their data that you will share the feedback collected freely throughout the client organisation, to maximise the learning you achieve from it. - That you may follow up with them about the feedback if it is in their interests for you to do so. - That you would NOT make non-anonymous feedback public, without explicit further permission i.e. playing feedback clips as endorsements on your external website. - Respondents who have opted out of marketing communications from you should not be denied the right to give feedback without their consent.
- We have clients operating in a range of industries, including banking, insurance, central and local Government.
BigEars takes into account all applicable laws and regulations relating to the processing of personal data and privacy, including where applicable guidance and codes of practice issued by supervisory authorities, as well as legislation in any relevant jurisdiction.We regard the European GDPR regulations as the current best practise standard and use those regulations as a guide across our global operations.
Detailed information on our Data Security practices are available should you wish to conduct a review/audit of our processes. This review process is available free of charge to all clients upon purchasing services for a period of 2 or more years. For shorter term projects we reserve the right to charge Professional Services for the often significant time required to reconfigure the information we provide to a custom client-specific format, for example if a client would like us to enter our information in a client-specific form on behalf of the client.