Details submitted via the platform are stored in a secure database, along with further case notes and files.
The data is stored using Amazon AWS RDS Infrastructure, below are the technical details:
All production plans (Standard, Premium, Private and Shield) are encrypted at rest with AES-256, block-level storage encryption. Keys are managed by Amazon, and individual volume keys are stable for the lifetime of the volume.
https://docs.aws.amazon.com/
In transit (including during user login) we https encrypt, SHA-256.
https://www.heroku.com/policy/
Both the intermediate and end-entity certificates (where the signatures matter) use SHA-256.
Files are stored in AWS S3 and are only accessible through the use of a specific Identity and Access Management (IAM) policy which is used by the application and is not exposed to users of the platform.
As a managed service, Amazon S3 is protected by the AWS global network security procedures that are described in the Amazon Web Services: Overview of Security Processes. (https://d1.awsstatic.com/whitepapers/aws-security-whitepaper.pdf
The Supplier will treat all personal data in accordance with the requirements of the Information Commissioner’s Office.
The data is stored in AWS RDS and AWS S3 (Ireland). You can find out more about the security principles in place by visiting the link below.
Yes, a copy of the data centre’s certificate can be viewed by visiting the link below:
https://d1.awsstatic.com/certifications/iso_27001_global_certification.pdf
A system administrator can submit a request for account deletion at any time. The account will be deleted within 30 days of receiving the request. Expired subscriptions will result in account deletion following an inactive period of 2 years. At this point, all personal information is removed.
System administrators are able to periodically review the data and remove it in the event that they are requested by a client to do so.
Personal information relating to a specific case and case management information such as; notes and/or any pertinent document is both stored on the database server and transmitted via the service as outlined in ‘Is the service secure?’ above.
Katala uses pg:backups to capture backups, data is backed up daily at midnight.
The database is located in EU-West-1 (Ireland).
All backups captured via pg:backups are stored in the U.S. regardless of where the database is located.
All passwords stored securely, and are hash encrypted over multiple iterations, along with a random salt.
Iterations describe the number of times the algorithm is run over the hash. Salt is the random seed used and the hash is the result of the one-way function.
We use the PBKDF2 algorithm with a SHA256 hash, a password stretching mechanism recommended by NIST (https://www.nist.gov/).
Users of the application must obtain consent from their contacts if they intend to reprocess their details for the purposes of marketing.
Marketing consent can be attributed to system contacts via the attribution of a custom tag.
The administrating organisation must complete a DPIA if they intend to use their instance to collect special category data (such as information relating to the client’s health, disability, sexuality, racial or ethnic origin etc.)
You can find more information about what classifies as special category data here.
The Supplier accepts that all names, contact details, activity data and other statistical data accruing from the subscriber’s instance are the sole property of the Client.
The Supplier undertakes that they will not be used for any other purpose whatsoever, other than the proper fulfilment of the Project in accordance with the license agreement, or as otherwise directed in writing by the Client.
All materials, information, research, designs, concepts and the like furnished to the Supplier by the Client during the term of this Agreement or created, developed or obtained by the Client or the Supplier or both of them as a result of the performance of the Project, and which relate exclusively to the Clients business, shall be the sole and exclusive property of the Client.
User data transiting networks should be adequately protected against tampering and eavesdropping.
The data is stored (at rest) on Heroku, below are the technical details:
All production plans (Standard, Premium, Private and Shield) are encrypted at rest with AES-256, block-level storage encryption. Keys are managed by Amazon, and individual volume keys are stable for the lifetime of the volume.
https://docs.aws.amazon.com/
In transit (including during user login) we https encrypt, SHA-256.
https://www.heroku.com/policy/
Both the intermediate and end-entity certificates (where the signatures matter) use SHA-256.
User data, and the assets storing or processing it, should be protected against physical tampering, loss, damage or seizure.
Details submitted via the platform are stored in a secure database, along with further notes and files.
The data is stored (at rest) on Heroku, below are the technical details:
All production plans (Standard, Premium, Private and Shield) are encrypted at rest with AES-256, block-level storage encryption. Keys are managed by Amazon, and individual volume keys are stable for the lifetime of the volume. https://docs.aws.amazon.com/
In transit (including during user login) we https encrypt, SHA-256. https://www.heroku.com/policy/
Both the intermediate and end-entity certificates (where the signatures matter) use SHA-256.
Files are stored in AWS S3 and are only accessible through the use of a specific Identity and Access Management (IAM) policy which is used by the application and is not exposed to users of the platform.
As a managed service, Amazon S3 is protected by the AWS global network security procedures that are described in the Amazon Web Services: Overview of Security Processes. (https://d1.awsstatic.com/whitepapers/aws-security-whitepaper.pdf)
The Supplier will treat all personal data in accordance with the requirements of the Information Commissioner’s Office.
A malicious or compromised user of the service should not be able to affect the service or data of another.
This is achieved by enforcing individual user accounts in our terms of use, and assigning user roles which are as follows:
User
Can read and update their own user information, such as; as name, email and job title.
Can update their own password.
Can read user teams.
Can create, read, update and delete communication activities.
Can create, read, update and delete tasks.
Can attribute communication activity to contacts, organisations and projects.
Can attribute tasks to related activities.
Can create, read and update contacts, organisations and projects
Can create, read, update and delete networks.
Can add, read, update and delete contact details of contacts and organisations.
Can create and read tags which belong to existing custom fields.
Can read keywords.
Can create and read goals.
Can read priorities and strategies.
Can read outcome statements.
Can read and update interest, influence and importance ratings.
Can read contact detail labels.
Can read contact, organisation and project types.
Can read activity, task, organisation and project statuses.
Can create, read, update and delete their own time entries.
Can create, read, update and delete their own cost entries.
Can read project budgets and costs in percentages.
Can read reports shared with Users, or specifically with the user.
Manager
In addition to the permissions of a User, a Manager has the following permissions;
Can create, update and archive tags.
Can create, update and archive custom fields.
Can create, update and delete keywords.
Can create, update and archive strategies, priorities and goals.
Can create, update and delete outcome statements.
Can create and delete interest, influence and importance ratings.
Can create, update and delete contact detail labels.
Can create, update and delete contact, organisation and project types.
Can create, update and delete activity, task, organisation and project statuses.
Can create, update and delete user teams.
Can access reports shared with Managers.
Finance Manager
In addition to the permissions of a Manager, a Finance Manager has the following permissions;
Can create, read, update and delete time entries on behalf of all users.
Can create, read, update and delete cost entries on behalf of all users.
Can read the hourly rate of all users.
Can create, update and delete project budgets.
Can read project costs in currency value.
Can access reports shared with Finance Managers.
Admin
In addition to the permissions of a Finance Manager, an Admin has the following permissions;
Can create, read, update and archive users.
Can create, update and delete hourly rates of all users
Can create, read, update and delete user work schedules.
Can manage user permission levels.
Can access reports shared exclusively with admin users.
Application Owner
With the granted permission of an Admin, an Application Owner Can access the subscribers live system to perform the following tasks;
Configure the application and create the initial administrators.
Investigate reported issues which cannot be replicated using the test database.
Conduct system training sessions which require demonstration of their specific system configuration.
The service provider should have a security governance framework which coordinates and directs its management of the service and information within it. Any technical controls deployed outside of this framework will be fundamentally undermined.
Our security governance framework is grounded on the following principles:
Policy:
Our internal policy is that access to the application and data is restricted to authorised individuals. In normal circumstances, the authorised individuals are limited to the Data Protection Officer (DPO) who has access to the platform in case of emergency. This access is a matter of ensuring the integrity and availability of the platform cannot be undermined, and the access is not utilised without prior consent of the Administrating Organisation. In circumstances where other internally employed individuals require access to the platform for investigative or development purposes, a request must be made to the DPO which will be recorded and considered. All other avenues for carrying out the works will be considered before access is provided, and no access will be provided without the consent of the Administrating Organisation. Following the completion of works, the employee will be required to provide a report to the DPO on works carried out, warrant that no data was modified or extracted, and further access will be revoked. No third party individual will be granted access to the platform.
Due to the way we maintain a test environment for the platform which contains no real-world personal data, no access has had to be provided by the DPO.
Program:
Roles and Responsibilities:
Data Protection Officer:
Manages access to the platform and ensures that no unauthorised access from employees of the Supplier.
Project Manager:
Liaises with the Administrating Organisation to ensure they understand their responsibilities
Technical Director:
Responsible for the security auditing and ongoing maintenance works of the platform. Does not have access to data without following the Policy.
Developer:
Responsible for carrying out works on the platform. Does not have access to data without following the Policy.
Test Analyst:
Responsible for carrying out tests to ensure that works carried out on the platform are correct and appropriate. Responsible for ensuring that the User Level Access Policy is maintained. Does not have access to data without following the Policy.
Risk Assessment:
Risk: Unauthorised Data Access
Who this affects: Supplier, Administrating Organisation, Application Users, Platform Service Beneficiaries
Risk Evaluation: Unauthorised access to the platform carries risk for all interested parties of the platform who stand to suffer the consequences of unauthorised access to sensitive data.
Supplier, Administrating Organisation, Application Users – may face prosecution or fines as well as a loss of credibility in circumstances where data is exposed through negligence.
Platform Service Beneficiaries – may face persecution, harassment or an incalculable risk to their safety should sensitive information about them be exposed.
Mitigation: A security and compliance policy is in place to ensure that every step is taken to maintain data integrity and security in response to threats from third parties. A User Level Access Policy is in place to ensure that platform data access is restricted to authorised users as outlined by the Administrating Organisation. The Administrating Organisation is responsible for their own policies in managing data and special category data that the platform hosts.
Risk Manager: Data Protection Officer
Risk: Denial of Service
Who this affects: Supplier, Administrating Organisation, Application Users, Platform Service Beneficiaries
Risk Evaluation: Denial of service through any means carries risk for all interested parties of the platform.
Supplier, Administrating Organisation – faces a loss of credibility and a potential breach of any Service Level Agreement if the platform is unavailable for a lengthy time period.
Application Users – may not be able to fulfil their duty of care to their beneficiaries through an inability to operate efficiently.
Platform Service Beneficiaries – may not have access to the support they require which could have an incalculable detrimental effect on their wellbeing, safety and general circumstance.
Mitigation: The applications are routinely monitored to ensure high availability. They are hosted on scalable architecture to cope with rising traffic demands. We recommend to all of our Administrating Organisations that they allow us to manage their domain records through Cloudflare, who offer leading industry level Denial of Service protection.
https://www.cloudflare.com/en-gb/ddos/
Risk Manager: Technical Director
Policies and Training:
Policies:
Data Protection Officer:
Do not access the Platform without written consent from the Administrating Organisation
Do not provide access to the Platform to employees unless it is appropriate and you have written consent from the Administrating Organisation
All other employees:
Do not attempt to access the Platform without written consent from the Data Protection Officer
Do submit a request for access to the Data Protection Officer if you feel it is required to carry out your responsibilities
Developer:
Do not develop features that do not adhere to the User Level Access Policy without prior consent from the Project Manager
Do not develop features that modify existing application data without prior consent from the Project Manager
Do not develop features which provide new access routes to the platform without written consent from the Data Protection Officer
Do not deploy new application features without having the feature approved by the Test Analyst and the Technical Director
Test Analyst:
Do not pass tests for features that provide new access routes to the platform without written consent from the Data Protection Officer
Do not pass tests for features that modify existing application data without prior consent from the Project Manager
Do not pass tests for features that do not adhere to the User Level Access Policy without prior consent from the Project Manager
Project Manager
Do not provide consent to develop features that provide new access routes to the platform without written consent from the Data Protection Officer
Do not provide consent to develop features that modify existing application data without prior consent from the Data Protection Officer
Do not provide consent to develop features that do not adhere to the User Level Access Policy without prior consent from the Data Protection Officer
Technical Director
Do not provide consent to deploy new features which have not been assessed for conformance to our security and compliance policy
Training
All employees who work on the platform are required to receive an instructional walk through of our policies as defined by this document carried out by the Data Protection Officer, the Project Manager and the Technical Director.
Response:
In the event of a suspected data breach carry out the following:
The service needs to be operated and managed securely in order to impede, detect or prevent attacks. Good operational security should not require complex, bureaucratic, time consuming or expensive processes.
This is achieved by carrying out the policies defined in our Governance framework
Services should be designed and developed to identify and mitigate threats to their security. Those which aren’t may be vulnerable to security issues which could compromise your data, cause loss of service or enable other malicious activity.
This document outlines our security and compliance policy as well as our approach to secure development, and works alongside the policies outlined in our Governance framework to ensure that the application and our operational practices continually take steps to mitigate the risk of malicious activity.
The service provider should ensure that its supply chain satisfactorily supports all of the security principles which the service claims to implement.
We only utilise suppliers for the provision of service, and those are restricted to Heroku (Salesforce) and Amazon Web Services. These suppliers are leading organisations and publish their practices in immense detail. They provide evidence of all of their accreditations and compliance, links to which can be found elsewhere in this document.
Your provider should make the tools available for you to securely manage your use of their service. Management interfaces and procedures are a vital part of the security barrier, preventing unauthorised access and alteration of your resources, applications and data.
The application comes bundled with a full featured administration platform through which the Administrating Organisation can manage all data in the system including users and their permissions.
All access to service interfaces should be constrained to authenticated and authorised individuals.
The Administrating Organisation are responsible for ensuring the authentication and authorisation of Platform Users.
All external or less trusted interfaces of the service should be identified and appropriately defended.
There are no external or less trusted interfaces of the service.
Systems used for administration of a cloud service will have highly privileged access to that service. Their compromise would have significant impact, including the means to bypass security controls and steal or manipulate large volumes of data.
All access to systems for administrating provision of service is restricted to the Data Protection Officer in line with our Governance framework. The passwords for these systems are all unique, very strong and are stored in a leading enterprise level security vault.
You should be provided with the audit records needed to monitor access to your service and the data held within it. The type of audit information available to you will have a direct impact on your ability to detect and respond to inappropriate or malicious activity within reasonable timescales.
Some change management auditing is available by default. Administrating Organisations can request additional auditing functionality and we will enable this in line with their requirements.
The security of cloud services and the data held within them can be undermined if you use the service poorly. Consequently, you will have certain responsibilities when using the service in order for your data to be adequately protected.
This document outlines all of the responsibilities in place for Administrating Organisations and Platform Users
Katala does not currently support 2FA.
An administrator can submit a request for an IP to be blocked from accessing their account’s subdomain by contacting support.
Katala does not currently support VPN.
Katala is not currently IL rated. However, we are moving towards becoming IL2 compliant.
Katala is not currently available on the G-cloud platform.
