QUASR Security Policy

Last Updated : July 20, 2022

Security is broadly classified into Data Security and Application Security to understand the implementation better.

Data Security

Data security concerns the user and process data that our customers entrust us with to meet their business requirements. We achieve data security by not processing unencrypted data outside the application context.

We accomplish this in the following manner.

We serve QUASR over an HTTPS connection to ensure that all the data transfers between the client browser and our servers happen over an encrypted channel. Users can verify the certificates and confirm they belong to QUASR.

We encrypt the primary database at rest. In simpler terms, gaining access to the database server machine or hard disk would lead to encrypted data. We will need appropriate keys to decrypt and retrieve the data.

    1. ● We store the encryption keys as part of a keychain provided by the cloud provider.
    2. To access the cloud provider key chain, a malicious actor would need to access our cloud provider account.
    3. We protect our cloud control panels with a 2FA (two-factor authentication) requiring our mobile devices.
    4. All our database backups are encrypted as well.

The application server connects to the database over an encrypted connection. In other terms, gaining access to our network is still insufficient to gain any usable database stored data.

Application Security

Application security is concerned with gaining unauthorized access to the application in an elevated role. Unauthorized accesses to the application happens due to compromised user passwords or malicious code injected into the application.


We address this in the following manner.


    1. ● We base our technical stack on top of a very robust, highly maintained projects with a large community of users and backed by well funded, industry-leading organizations.
    2. ● We continuously monitor and update the stack to ensure all the latest patches to the various aspects of our system are applied and are up-to-date.
    3. ● All our code follows strict best practices guidelines both in terms of performance and in terms of security.
    4. ● We frequently run vulnerability scans on all our application code and on our server infrastructure to ensure they are robust.
    5. ● We have enabled much monitoring on the infrastructure to ensure any malicious activity such as repeated attempts to access the servers are flagged and notified for us to block them immediately.
    6. ● Only a secured port is accessible to the external world. All the other servers and ports are internal to our network.
    7. ● We continuously monitor and patch the operating systems to ensure there are no unaddressed vulnerabilities.


While all these methods sufficiently mitigate a chance of a security incident, we do understand that no system is fully secure. We will work to ensure that any untoward incident is detected early and mitigated quickly to reduce the overall impact of such incidents.



In the age of social media and the variety of data privacy violations cropping up all around us, privacy is a serious issue that all cloud solutions seek to address. The point is even more critical for us since we are providing services in the healthcare domain, where breaches have severe impacts.

Our approach to this problem is as follows:

    1. ● We do not own the data. Our clients own all the data recorded by their respective systems.
    2. ● Any processing of data is only done on behalf of the client to meet their patient safety requirements.
    3. ● We adhere to both the GDPR guidelines and multiple regional PDPA requirements prevalent in the region.
    4. ● Our guidelines have adequate measures to ensure we do not process the data other than for what we agree to, without explicit consents.


One of the significant advantages of choosing a cloud-based solution is the scalability that is implicit in the architecture. Our application can scale as you grow to accommodate more users, to accommodate more information and process them, to meet burst demands which arise from time to time. The application framework is architected for best cloud performance and to benefit from the underlying infrastructure scalability (elasticity) that our vendor extends to us. Additionally, our application infrastructure is architected for very minimal downtime. We achieve this continuous monitoring and auto-spawning servers to meet demands or address any failures in the services. To ensure business continuity, we back up all our servers periodically.


Integration And Interoperability

A question that we frequently hear from our customers is whether we can integrate with their existing systems, say their HR system for user data or their current identity management systems like Active Directory. While the application or the architecture poses no limitation in enabling these integrations, we currently do not offer integrations off-the-shelf. Please do check with us as we have mechanisms to address each of these requests on a case-basis. At the moment, there may be a strong case against integrating a critical on-premise system such as an IDMS with a cloud-based solution. Technology to address these integrations are evolving every day. When we see a promising solution that offers these integrations with minimal security exposure, we would be amongst the first to leverage these for our customers.