Overview:
Considering Nectar as a Vendor
.png)
%20(1).png)
Our actions prove our intentions; here are measures we have taken to establish a strong security & compliance posture:
The remainder of this paper will address point #3 in detail, describe our policies and how they match practice, and ideally show that, overall, we take reasonable steps to ensure the confidentiality, integrity, and reliability (availability) of your data and platform experience.
As previously mentioned, GDPR and U.S. privacy (including CCPA/CPRA) compliance is a priority to us. Though we are not a company located in the EU nor California, we do business with many customers who in turn have users that are located or do business in said locations. The types of data, our data subprocessors (vendors we use), how data is collected and handled, and similar topics can be found within the following legal documents (and are signed when starting business with Nectar). A summary of some of this information was provided in the “Choosing Nectar as a Vendor” section previously.
Our application and data are hosted and managed within Google Cloud Platform (GCP) secure data centers. These data centers have been accredited under:
We make extensive use of the capabilities and services provided by GCP to increase privacy and control network access throughout our system. Documents that provide more details about GCP security are available at Google Security Whitepaper.
We use Google and AWS fully-managed infrastructure, and don’t use self-maintained infrastructure; in other words, we transfer the risk of running our own infrastructure to AWS and GCP - we use their fully managed services, such as GCP GKE Autopilot, GCP CloudSQL, AWS SQS, and AWS Transfer (SFTP integration). We do not run specific compute instances, nor do we host our own physical datacenter. We manage our own containers, software, and runtime processes.
We use encryption in transit (no data is transferred unencrypted in our platform; we support TLS 1.2 at a minimum as well as TLS 1.3) and encryption at rest (all data is stored in Google Cloud Platform (“GCP”) encrypted by default with a minimum strength of AES-256). We use firewalls - both a Cloudflare WAF and at the database layer to ensure our database is not publicly accessible.
We maintain encrypted backups for one month, and we are able to restore data to any exact point-in-time within the past month if needed. We perform daily backups. Backup data is fully expunged after one month. As per GDPR and CCPA, we are able to provide our users with create, read, update, delete (“CRUD”) functionality in regards to their data, as well as providing transparency into what data is collected with the ability to opt out (i.e. stop using the Nectar application).
Most compliance frameworks we are familiar with do not require a specific timeframe regarding data backups; some countries require specific days, but a lot err on the side of MAX retention only. With this in mind:
We feel we are being reasonable with a 30 day data retention practice, as our RPO policy is 24 hours; thus we provide many extra days in the case of severe emergencies to go back and recover data from within the last month. We frequently simulate a disaster recovery scenario where we are able to recover within 24 hours.
Our log retention is set to 15 days for a similar reason; our RTO is 24 hours, thus we provide many extra days in the case of severe emergencies to go back and examine issues and audit trails in our platform through logs. We have not had a customer support issue where we were unaware of an issue for more than 15 days that we could not find sufficient logging/auditing for. We use Datadog to collect, search, and manage logs as well as security events.
Nectar has mandatory, regular security training programs for all Nectar employees. All security-related policies are mandatory to read and accept. Nectar also has all employees sign confidentiality agreements and we conduct appropriate background and/or verification checks.
On the technology controls side, though we do not handle any sensitive data (as previously mentioned), we still follow the principle of “least privilege” and implement helpful technological controls including RBAC to prevent unnecessary access amongst our employees. We use Jamf as a mobile device management (“MDM”) solution so that we can ensure controls such as an anti-virus software running, locking employee screens, and ability to remotely wipe devices.
Our Information Security and Risk Management programs are a set of policies, practices, controls, and key performance indicators (“KPI”s) that give an accurate assessment of Nectar’s risk posture, in regards to security, compliance, legal liability, etc. Our most critical asset is data, and not all data is equally important; our Information Security roadmap starts and ends with understanding, managing, and securing our data.
We emphasize internal threat modeling and penetration testing and vulnerability scanning to identify (and then remediate) risks. External penetration testing compliments our internal efforts. Incident Management is a top priority, particularly our non-repudiation efforts.
Through our use of KPIs, we can measure how we’re moving the needle over time. We take a very practical approach and prioritize actual security over simply “check the box” activities. Example KPIs include NIST CSF compliance, a framework we chose to use as a best-practice to help us see the effectiveness of our policies and practices, and how well policy matches practice.
Nectar supports several secure SSO standards, including SAML, PingIdentity, OpenID, Azure, etc. This is the preferred product authentication method. Retry-limited username+password logins are also supported. These passwords are never transferred or stored in a form that can be read in plain text (hashed). Authentication sessions are invalidated when users change key information and sessions automatically expire after a period of inactivity. We enforce password complexity requirements.
We provide multiple user roles with different permissions levels within the product. Roles vary from account admins to users and thus follow the principle of least privilege and RBAC.
For Nectar infrastructure, we require ourselves to use Google SSO and MFA on our tooling, such as GCP, AWS, Cloudflare, Datadog, etc. Again, we follow the principle of “least privilege” and implement helpful technological controls including RBAC.
Production database access (aside from the user web application) is limited to the CTO and a handful of senior engineers to administer it. They are whitelisted on our firewall and are the only personnel who may access the database directly, which still requires username+password authentication, using passwords with a minimum length of 12 characters and a combination of numbers, letters, and upper-case numbers.
Nectar is built with fault tolerance capability and is highly-available. Each of our services is fully redundant with replication, failover, and backups. Services are distributed across multiple GCP availability zones. These zones are hosted in physically separate data centers, protecting services against single data center failures. Our historical uptime has been 99.95%.
If you have any concerns or discover a security issue, please email us at security@nectarhr.com and we will quickly investigate. We request that you do not publicly disclose any issue you discovered until after we have addressed it.