Cloud infrastructure can be requisitioned and rebuilt from code in approximately 2 hours. We estimate around 1 hour is required to start this process in an emergency. Giving Return Time Objective (RTO) of 3 hours. Recovery Point Objective (RPO) for databases is 1 hour, while files uploaded to customer site as attachments have separate RPO of 24 hours. Client instances and backups are stored across multiple Availability Zones within each region. AWS Business Continuity Plans have been developed and tested in alignment with ISO 27001 standards.

Users are required to have a valid username and password. Risk Wizard system administrator (nominated person) can define customer's username and password. Once logged in the user can reset their password. Access to the application is via https (128 bit SHA1/RSA)

Password are stored in the database as salted SHA1 hash. Risk Wizard provides for case sensitive minimum length passwords.

Access to the web application is always via HTTPS (256 bit, SHA/RSA/AES). Emails generated by the application use Transport Layer Security (TLS) through SMTP relay. Passwords are stored in the database as a salted SHA1 hash. Data is encrypted at rest within SQL backups and file backups within S3 using SSE-S3 technology with a 256-bit AES-256 standard. Transferring of backup data is done using Secure Sockets Layer (SSL).

Risk Wizard operates role based security and record level security. Role based security determines what modules/products the user can access (Risk, Compliance, Reporting etc.) and in what capacity they can access records (read/update/delete/). Record level security determines what records the user can access through security permission groups.

Risk Wizard offers hosting on dedicated virtual machines or shared virtual machines. Shared machines are used strictly for Risk Wizard client hosting. This ensures high performance levels, ensures system integrity and reduces the attack surface of the machine. Risk Wizard uses Windows Server 2012 R2 and separate application pools per customer with application pool identities to provide application and data isolation in shared environments. We can restrict access to the hosted service via IP address/ranges via an external firewall on a dedicated machine or via IIS in a shared environment.

Risk Wizard uses AWS owned servers housed in different data centres across multiple regions. Exact locations are kept secret for security reasons. Clients can define these regions based on regions operated by AWS. Refer to http://docs.aws.amazon.com/general/latest/gr/rande.html

Risk Wizard has no physical access to data centres. Also, refer to AWS security whitepaper, which details AWS security procedures: https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf

Constant monitoring of site uptime and server infrastructure with automated alarms. All IIS logs are monitored in real time, accessing IP addresses are logged and mapped to geo-locations. These are routinely checked for outliers from regular usage patterns. This helps us identify any potential probing by unauthorized parties, DoS or DDoS attacks on Risk Wizard infrastructure before they occur.

Employees have no access to data unless customer grants access e.g. to deal with a support issue or advise customer on configuration. All work relating to customer data is done at the Risk Wizard office.

There is no system data visible from AWS consoles. Regarding the application, Risk Wizard transfers the system admin access codes to the customer when the system is handed over so no data can be visible to Risk Wizard staff from that time unless access is subsequently granted by customer.

When incidents/events are reported they are reviewed by the IT team to determine whether it is a security incident. The team then work together to limit any damage, diagnose reasons for incident and isolate/remove any potentially affected systems from relevant environments. Once 'all clear' is agreed then affected systems are restored. Team feedback loop sessions are held after security incidents to discuss how to improve systems/response. At all times, we have an open communicative approach within the team to ensure appropriate resources are aware of the incident and the best course of action implemented for the particular incident which has arisen.