Close

Referral System.

Below are our frequently asked questions regarding security and compliance of the Referral System.

We help you to identify your areas of responsibility as a Referral System administrator, what documentation and processes you are required to implement to your users and subscribing organisations via your terms of use documentation.

Existing subscribers may be willing to help you with this process, based on their experience as a system administrator. Email us to be put in touch with existing Referral System administrators.

Data Management.

Case details submitted via the platform are stored in a secure database, along with further case 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/AWSEC2/latest/UserGuide/EBSEncryption.html

 

In transit (including during user login) we https encrypt, SHA-256.
https://www.heroku.com/policy/security

 

Both the intermediate and end-entity certificates (where the signatures matter) use SHA-256.

 

Case 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. You can find out more about the security principles in place by visiting the link below.

 

https://aws.amazon.com/compliance/gdpr-center/

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

Entries are anonymised 2 years after the creation date.

 

At this point, all personal information is removed.

 

Data retained for statistical analysis is limited to:

 

  1. Title
  2. Date of Birth
  3. Voicemail Consent
  4. Text Consent
  5. Town
  6. County
  7. Partial Postcode
  8. Urgency
  9. Issues
  10. Has checked criteria
  11. Client consent
  12. Consent date
  13. Email notifications consent
  14. Created by username
  15. Updated by username
  16. Status
  17. Status Updated date / time
  18. Created by staff
  19. Updated by staff
  20. Referred to organisation
  21. Created by organisation

 

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.

The password attribute of a User object is a string in this format:

 

<algorithm>$<iterations>$<salt>$<hash>

 

Those are the components used for storing a User’s password, separated by the dollar-sign character and consist of: the hashing algorithm, the number of algorithm iterations (work factor), the random salt, and the resulting password hash.

 

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/). This is very secure, requiring massive amounts of computing time to break.

Consent Management.

Users of the application must obtain consent from the client before processing their details.

Confirmation of consent is required via a checkbox before a case can be submitted. Users of the application are also required to provide the date when consent was granted.

The administrating organisation of the referral system must complete a DPIA if their instance of the referral system collects 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.

Ownership of Data.

The Supplier accepts that all names and addresses and other personal data accruing from the Project 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.

National Cyber Security Centre Cloud Security Principals.

The points below detail how the Referral System has been built to encompass the Cloud Security Principals outlined by the National Cyber Security Centre.

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/AWSEC2/latest/UserGuide/EBSEncryption.html

 

In transit (including during user login) we https encrypt, SHA-256.

https://www.heroku.com/policy/security

 

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.

 

Case details submitted via the platform are stored in a secure database, along with further case 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/AWSEC2/latest/UserGuide/EBSEncryption.html

 

In transit (including during user login) we https encrypt, SHA-256.
https://www.heroku.com/policy/security

 

Both the intermediate and end-entity certificates (where the signatures matter) use SHA-256.

 

Case 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 enforced user roles which are as follows:

 

Super User

 

Can access the live system to configure the application and create the initial root administrators.

 

To investigate reported issues which cannot be replicated using the test database.

 

Administrator

 

An existing user can only be made a system administrator upon request to support@hutfortytwo.co.uk

 

Their permissions are as follows:

 

Can create and edit issue types.
Can define what classifies an ‘urgent’ referral.
Can set an overdue threshold.
Can set a global inactive logout timer.

Can create, manage and suspend organisations within the application.

Can create, manage, activate and suspend users within the application.
Can add users to organisations.
Can unlock users who have been denied access to the system.
Can create referrals on behalf of any sending organisation.
Can update the status of all referrals.
Can remove notes and files from referrals.
Can clone referrals.
Can print referrals.
Can export referrals.

 

Organisation Lead

 

An existing user can be made an organisation lead by a system administrator or an existing organisation lead for the organisation in question.

 

Their permissions are as follows: 

 

Can manage their own organisation’s name.

Can edit/remove staff from their own organisation.

Can change referral acceptance status for their own organisation.

Can view and update referrals sent to their organisation.

Can export and print referrals sent to or from their organisation.

 

User w/ Referral Acceptance

 

An existing user can be granted permission to control their organisation's capacity to accept referrals by a system administrator or an organisation lead from the same organisation.

 

User

 

A user can only be created by a system administrator, a user can be added to and organisation as 'staff' by either and organisation lead or a system administrator.

 

Can manage their login details (username, email, password).
Can update their position and phone number.
Can view and update referrals sent to their organisation.
Can export and print referrals sent to or from their organisation.

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:

  1. Data Protection Officer: Move the application into maintenance mode to mitigate the risk of a further breach. Request access to the platform if required
  2. Project Manager: Inform the Administrating Organisation of the possibility of a breach, supplying full available details
  3. Technical Director: Request access to the platform if required. Analyse the information available to ascertain whether there has been a breach and if so, identify the cause of the breach, data that is likely to have been exposed and document the findings
  4. Project Manager: Relay the outcome of the investigation including 
  5. Technical Director: Develop a plan for mitigating the potential for a further breach
  6. Developer: Request access to the platform if required. Carry out the plan.
  7. Test Analyst: Test the works to ensure system and policy integrity is maintained
  8. Technical Director: Test the works to ensure the risk has been mitigated, and the security and compliance policy is still in force
  9. Developer: Receive approval from the Test Analyst and Technical Director before deploying
  10. Project Manager: Provide a full report of investigations and works carried out
  11. Data Protection Officer: Move the application out of maintenance mode. Revoke all non-essential access to employees

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

Where service provider personnel have access to your data and systems you need a high degree of confidence in their trustworthiness. Thorough screening, supported by adequate training, reduces the likelihood of accidental or malicious compromise by service provider personnel.
 
This is achieved by carrying out the processes 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

Other.

Our referral system is not currently IL rated. However, we are moving towards becoming IL2 compliant.

Our referral system is not currently available on the G-cloud platform.

The Referral System does not currently support 2FA.

The Referral System does not currently support VPN.

The Referral System does not currently support IP blocking.

Looking for a software development partner?

We’re extremely proud of the work we produce and are always on the lookout for new opportunities and partnerships.

Leave us a message below and we’ll get back to you as soon as we can.

Other ways to reach us