Security / Standards FAQs

Outline your information security framework, policies, standards and guidelines

All Workaware employees have signed standard NDAs.  All client information is uniquely password protected for the Workaware administrative account access.  All server database access is restricted to the development team and restricted to designated IP addresses.  VPN gateways and RSA certificates are in place.  Additional information can be supplied if required.  Workaware would additionally be amicable to signing any ancillary privacy agreements.

Supply a current threat and risk assessment for the service

Regular testing and review is conducted by Amazon.  Reports can be shared at the clients request.

Supply a current privacy impact assessment for the service

Do you perform regular risk / security / penetration / vulnerability assessments on the service? If so, what is the frequency of audits?

Are you able to provide a copy of a recent audit? If you do not conduct testing, are you willing to submit to a penetration test commissioned by the customer? If not, why not?

Our solution security has been fully vetted by entities such as the Government of Alberta, Sony Picture Entertainment, and Netflix to name a few.  Additional information can be supplied if required.

Do you have appropriate privacy and information security policies, procedures, and governance in place?  Please provide.

Our policy can be accessed at: https://workaware.atlassian.net/wiki/spaces/WOR/pages/319586305/Privacy+Policy

How do you address security escalation and notification process for addressing concerns and incidents, physical security, physical access controls, firewalls and intrusion detection, maintenance activity logging, secure data disposal?

Notifications and metrics are derived and disseminated via AWS.  Logs can be integrated with their SIEM.

Do you use other cloud services to support / operate your service? To what standards are they held? How is this assured?

We utilize Amazon Web Services for IaaS.

What is your security patch management process and timeline?

Security patches are released immediately and cumulative software updates are released on a bi-weekly basis.

Are you PIPEDA Standards Compliant?

yes

Do you have an identified privacy officer?

Not specifically.

Do you or a third party run the data centre facility in which your solution resides? Please identify any third-party providers.

The data is housed in various services of AWS.

Does the facility in which your solution runs maintain security compliance certifications (e.g. SSAE 16 SOC1 and AT-101 SOC2 Type II Reports, ISO 27001)?

https://aws.amazon.com/compliance/programs/

Have you experienced any security breaches? Please describe the breach and your response.

No

Providers are required to notify the customer of any breaches or incidents of unauthorized access or disclosure. What is your established incident/breach protocol?

Notification would be immediate upon discovery.  At that point all authentication tokens would be revoked and all server access further restricted.  All public APIs would be shut down.

Does the service require authentication?

Yes

What are the service’s password rules?

Min 12 letters, or minimum 5 word passphrase.

Are passwords stored in non-reversible format?

Yes

Is two-factor authentication available?

Yes

Does the solution support single sign on? What forms of SSO are supported?

Yes - Our Oauth2 service allows for custom external providers

Is data encrypted at rest?

Yes

Are backups encrypted?

Yes

Who controls the encryption keys?

Senior Development

Is data encrypted in transit (is transport based security / encryption offered)?

all communication is encrypted with TLS

Does the customer retain ownership of all data that is entered in the system? Is this clearly stated in the contract / terms of service / user agreement?

Yes. As outlined in our privacy policy.

Is it clear that you have no claim against the data and cannot use for data for your own purposes (e.g. re-selling data, advertising against data)?

Yes. As outlined in our privacy policy.

Do your staff have access to the customer’s data and metadata?

Only staff that require access to our databases. Networking, devops, security.

Do you have appropriate controls to audit, track and prevent data theft, loss, unauthorized use, copying, use, modification, disclosure or disposal? Please provide details.

Yes, Access restrictions and authorizations including but not limited to secure VPN gateways, IP whitelisting and partitioning

Can data access and transfers (by your staff and customer staff and administrators) be audited within the application? Can customer administrators access the audit trail?

modifications and data writes are auditable from the AWS portal but are not accessible from within the app.

Can the customer’s data be exported from your system on-demand and on a regular schedule if required? What format is the data provided in? Is the format non-proprietary?

Yes.

Excel or CSV for data. Forms can be extracted as PDFs.

Yes.

Can the customer maintain a local backup of their data?

You could backup data dumps from exports if you would like. Backups of the databases are not accessible to non-senior staff.

Can the customer’s data be safe-harboured (that is a 3rd party stores the data separately from the cloud provider to guard against data loss / or business failure)

same as B.7

Is the data in the systems accessible by customer administrators for back-end updates or modifications? Is it possible to make back-end system wide data modifications?

We have a set of REST and OData APIs that can be used for automated tasks.

At termination of contract (either initiated by the customer or the provider) can the full data can be extracted? What is the method for extraction? Are any costs associated with this?

Yes, it can. The data would need to be extracted by the development team. Any incurred costs would depend on any agreements outlined in the service contract and the nature of the contract termination.

How long will it take for the customer to get their data at contract termination? For how long will the data be available post termination?

Data can be gathered up and delivered in under 24 hours. Post termination, the data will reside on our servers for the remainder of the billing cycle.

In what format can the data be extracted?

see B.6

At contract termination, will the customer’s data be deleted? Within what timeframe? How is the deletion confirmed?

The data will remain on our server for the remainder of the billing cycle.

Do you have a regular release cycle? If so, please outline the general cycle and schedule. Explain the types of changes released in major and minor releases?

Hotfixes and security patches are released immediately. General cumulative releases are bi-weekly.

Can clients opt in/out of upgrades? Are some upgrades mandatory?

Updates* are mandatory

What operating systems does your solution support?

We have clients for Windows, iPhone and Android as well as an online version to cover Mac and *nix users.

Does the solution support all required browsers? (Chrome, Firefox, Edge, IE and Safari browser support is required for customer facing solutions)

The online client supports all modern, standards compliant, browsers.

What mobile browsers are supported (currently and in future)?

Any modern, standards-compliant browser is supported. The online client is built to be responsive.

What are bandwidth requirements for good client performance?

The online client requires a constant, decent internet connection. The Windows and Mobile clients will use caching queues if they lose their connectivity.

Can performance of the system be tested (in a realistic scenario) before purchasing?

We offer demo accounts.

What is the availability of the service (e.g. 24x7x52).

We strive for 100% uptime.

How can GP monitor service performance?

With access to our API endpoints you can set up any metrics you like.  For example, you can use the basic ‘timestamp’ endpoint to create a ‘heartbeat’ monitoring service.

Please describe the incident management process. What are SLA targets for performance and resolution of incidents?

Incidents resulting in support tickets are addressed, during business hours, in < 1 hour. Incidents resulting in unexpected downtime have yet to occur. Our processes have a lot of oversite to mitigate the chances of such an event occurring. We target 99.9% uptime.

What logs are kept? Who can access them? Can they be accessed by GP to analyze an incident?

Various metrics, exceptions and insight data are kept to analyze, debug and track usage scaling. senior staff have access to them.

Can you share historical performance metrics? What is the longest time that your service has been down for?

Historical data is not available without some formal request to the development department. The service has yet to be unavailable for any significant length of time.

How is customer data backed up? Where and how are the backups stored? What is the frequency of backups? What are the restore capabilities? What is the restore procedure?

We back up documents as a ‘blob’ which is redundantly stored and versioned. The ‘data’ is stored in a SQL server which is backed up to a remote store once a day. The query log allows us to backup to any point in time down to the minute.

Do you have a documented disaster recovery plan?

Yes

What is the DR plan’s Recovery Time Objective? What is its Recovery Point Objective?

We can spin up a new infrastructure and be back on line in under 24 hours in the event of a disaster. DR recovery would be to the last logical backup time. The server can be deployed to Azure, AWS, or other alternative cloud services in the event of catastrophic failure of one provider.

Do you have a documented change management procedure?

Yes

Do you have specific planned windows when system maintenance will occur? When are they? What services are impacted?

System maintenance does not require any down time.

What notification do you provide for maintenance work?

We try to notify as far in advance as reasonably possible.

Do you provide protection, or receive protection from a third party for denial-of-service attacks against your solutions?

We have some HA best practices implemented in our AWS backend.

Do you provide customers with a secondary non-production environment? If so what types of environments? Are there any limitations on their use? Can data / changes be synchronized between environments?

Demo accounts are available. The demo account has no limitations compared to a regular  account.

Generally data is not synchronized between accounts though custom process development is possible.