Privacy and Security




Bookafy is hosted on Linode fron Amazon’s Web Services (AWS) infrastructure, the leading cloud infrastructure provider. You can read about AWS’s thorough security provisions on their site.



Bookafy’s platform is hosted in Amazon’s US East (N. Virginia) region with servers spread across several availability zones within that region in order to maximize our uptime.



All communication with Bookafy’s website, applications, and API is performed via HTTPS, utilising 128-bit encryption.



For sensitive data where the original values are not needed, such as our own passwords, we hash the data using the BCrypt algorithm. Where the original values are needed, such as authentication details for accessing calendars, the values are encrypted using the AES-256-GCM algorithm using a unique, randomly generated salt for each set of sensitive data.



Only authorized employees are granted access to our production infrastructure and the use of password managers to ensure strong passwords and two-factor authorization when available is mandated across the company.



Bookafy is updated frequently through an automated process with zero downtime.
If any downtime is expected as part of a major change (such as a data center migration) we will communicate it at least 48 hours in advance via Bookafy’s status page.



All access to data via Bookafy is explicitly approved through an OAuth authorization mechanism which grants access tokens that can be revoked at any time.

We don’t sell customer data to anyone.




Is data “encrypted at rest”, e.g. in static backups, databases, file storage?

Not currently, although this is being evaluated by the development team for implementation. All communication to/from

storage is encrypted over HTTPS and access to storage is secured by passwords & secret keys.


Have any significant security breaches or incidents occurred in the past 5 years?


Are employees only provided with access to the network and network services that they have been specifically authorized to use based on their role? What about Client access?

Strictly individuals with assigned access permissions have network and infrastructure services access, the access level is

based on role. Bookafy support employees, professional services personnel, and Clients do not have any network

or infrastructure services access.


Are privileged and generic account access tightly controlled and reviewed on a periodic basis, at least




Are shared user accounts prohibited for employees? What about Clients?

Employees have their own dedicated accounts. Clients also have their own dedicated accounts, with access to their data only.


Does your password construction require multiple strength requirements, i.e. strong passwords and utilizes a random sequence of alpha, numeric and special characters?

We require a minimum 6 characters in passwords on the basic password management level. OWASP and NIST SP 800-63-3 password policy options may be available in the coming year.


Is the network boundary protected with a firewall with ingress and egress filtering?

Yes. All firewalls and load balancing facilities are provided by Linode and Amazon AWS.


Are public facing servers in a well-defined De-Militarized Zone (DMZ)?

Yes, this is inherited from Linode’s default infrastructure zoning.


Is internal network segmentation used to further isolate sensitive production resources such as PCI data?

PCI data is not stored, but network segmentation is employed based on AWS’s default configurations in this respect.


Is network Intrusion Detection or Prevention implemented and monitored?

A broad spectrum of monitoring tools, supplemented by notifications and alerts provided by AWS  and Linode remain constantly on. This includes intrusion detection and email confirmations of network access.


Are all desktops protected using regularly updated virus, worm, spyware and malicious code software?



Are servers protected using industry hardening practices? Are the practices documented?

Security services are utilized regularly to provide system security audits. Clients can also contact us to conduct penetration testing as desired to meet their requirements.


Is there an ongoing program for network and vulnerability scanning, e.g. port scanning?

Hosting partners subscribe to services that conduct internal penetration tests monthly using industry security standard tools and services.


Is there active vendor patch management for all operating systems, network devices and applications?

Yes. This is provided by Linode and AWS automatically via their service.


Are all production system errors and security events recorded and preserved?

Logs are preserved for a minimum of 1 month, with some remaining up to 6 months, depending on severity and action required.


Are security events and log data regularly reviewed?

Yes. Logs are reviewed daily, weekly and monthly – depending upon the nature of the log events.


Is there a documented privacy program in place with safeguards to ensure protection of client confidential information?



Is there a process in place to notify clients if any privacy breach occurs?



Do you store, process, transmit (i.e. “handle”) Personnally Idenfiable Information (PII)?



In what country or countries is PII stored?



Are system logs protected from alteration and destruction?

This is provided by Linode and AWS internally.


Are boundary and VLAN points of entry protected by intrusion protection and detection devices that provide alerts when under attack?

This is provided by Linode and AWS internally.


Are logs and events correlated with a tool providing warnings of an attack in progress?

Monitoring tools provide access to the necessary logging events when seeking correlation to attacks.


How is data segregated from other clients within the solution, including networking, front-ends, back-end storage and backups?

Every client account is logically separated from other clients, through the use of a required persistent tenant identifier on all database records.

Additionally all application code requires this tenant identifier for all operations – both read and write. An automated testing regime is also in place to protect code changes from regressions and possible cross-tenant data contamination.

The tenant identifier is “hard linked” to every user account and logically enforced through fixed “WHERE” clauses on database queries and equivalent measures for file access. A platform user is not able to change or otherwise unlink their session or account from this tenant identifier. Thus there is no logical possibility of a user having login authorization under a different tenant identifier. Even if they tried to access pages using a different tenant’s ID, the system would reject the request due to the user account not being registered to the requested tenant ID.


Do you have an Incident Response Plan?

Yes, a “living document” is maintained in the hosting company’s cloud drive, which outlines disaster and incident response

checklists, contact details and key system facilities for understanding and responding to incidents.


What level of network protection is implemented?

All network level security is managed by Linode and AWS




Does the platform provide reports for Quality of Service (QOS) performance measurements (resource utilization, throughput, availability etc)?

Such metrics are not provided to clients, aside from availability and response timings as per our status page on


Is the disaster recovery program tested at least annually?

Yes, recovery checks and perfoemed and tested annually.


What is the Recovery Time Objective (RTO) and Recovery Point Objective (RPO) of the system?

The RTO is 4 hours , with RPO being 1 hour.


Do you provide backup and restore plans for individual clients?

All aspects are multi-tenanted, so backups are taken across entire client base. Complete file backups are run every 24 hours and benefit from AWS database point in time backups taken every 5 minutes.


What is the maximum time that backups are retained?

Database point-in-time backups are retained for 30 days, with general file backups for 90 days minimum.


What is the expected turnaround time for a data restore?

Any client restore in any non-disaster scenario must be requested and scheduled with us. Turnaround is between 1 and 2 business days.


Can a single entity (e.g. a Form) be restored without impacting the entire platform?

If restoration of a specific record or artefact is required by a client, this can be performed online via a per request basis and is chargeable work. There is no impact on the platform or client account.


Is High Availability provided – i. e. where one server instance becomes unavailable does another become available?

Multiple server instances are running at all system tiers, including database (which is replicated). Failure of a server instance within the data center is handled by Linode and AWS’s load balancers, with the problem instance recycle and/or removed and replaced with a new instance.


Is data stored and available in another location (data center) to meet disaster recovery requirements?

Yes. All data is replicated to a second data center which differs by geographic location.


Is the failover process an active/active, automated switchover process?

Failure of a server instance within the primary data center is handled by Linode and AWS’s load balancers, with the problem instance recycle and/or removed and replaced with a new instance.

In the event that the entire data center were to have a critical failure, then switchover to the secondary center is a manual process, as we need to perform a full assessment of the issue first to ensure there is no simple workarounds to keep the existing primary center presence available. If it is determined that a move to the secondary center is required, then switchover will be initiated manually to meet the target recovery objectives.