Our infrastructure and security team includes people who’ve played lead roles in designing, building, and operating highly secure Internet facing systems at companies ranging from startups to large public companies.
Incident Response Plan
We have implemented a formal procedure for security events and have educated all our staff on our policies.
When security events are detected they are escalated to our emergency alias, teams are paged, notified and assembled to rapidly address the event.
After a security event is fixed we write up a post-mortem analysis.
The analysis is reviewed in person, distributed across the company and includes action items that will make the detection and prevention of a similar event easier in the future.
Nanonets will promptly notify you in writing upon verification of a security breach of the Nanonets services that affects your data. Notification will describe the breach and the status of Nanonets’s investigation.
You can see more details about our incident reponse plan here https://nanonets.com/help/security/what-is-nanonets-incident-response-plan
Build Process Automation
We have functioning, frequently used automation in place so that we can safely and reliably rollout changes to both our application and operating platform within minutes.
We typically deploy code dozens of times a day, so we have high confidence that we can get a security fix out quickly when required.
All of our services run in the cloud. Nanonets does not run our own routers, load balancers, DNS servers, or physical servers.
All of our services and data are hosted in AWS and GCP facilities and protected by AWS and GCP security, as described at http://aws.amazon.com/security/sharing-the-security-responsibility and https://cloud.google.com/security. Nanonets services have been built with disaster recovery in mind.
All of our servers are within our own virtual private cloud (VPC) with network access control lists (ACL’s) that prevent unauthorized requests getting to our internal network.
Nanonets uses a backup solution for datastores that contain customer data.
All customer data is stored in the USA.
Customer data is stored in multi-tenant datastores; we do not have individual datastores for each customer. However strict privacy controls exist in our application code that are designed to ensure data privacy and to prevent one customer from accessing another customer’s data (i.e., logical separation). We have many unit and integration tests in place to ensure these privacy controls work as expected. These tests are run every time our codebase is updated and even one single test failing will prevent new code being shipped to production.
Each Nanonets system used to process customer data is adequately configured and pathed using commercially-reasonable methods according to industry-recognized system-hardening standards.
Nanonets engages certain subprocessors to process customer data. These subprocessors are listed here: List of Subprocessors, as may be updated by Nanonets from time to time.
All data sent to or from Nanonets is encrypted in transit using 256-bit encryption.
Our API and application endpoints are TLS/SSL only and score an "A+" rating on SSL Labs' tests. This means we only use strong cipher suites and have features such as HSTS and Perfect Forward Secrecy fully enabled.
We also encrypt data at rest using an industry-standard AES-256 encryption algorithm.
Nanonets is served 100% over https.
There are no corporate resources or additional privileges from being on Nanonets’s network.
We have two-factor authentication (2FA) and strong password policies on Google, AWS to ensure access to cloud services are protected.
Nanonets enables permission levels to be set for any employees with access to Nanonets.
Permissions and access can be set to include app settings, billing, user data, or the ability to send/edit manual messages and auto messages.
On an application level, we produce audit logs for all activity, ship logs to our service providers for analysis, and use S3/Glacier for archival purposes.
All access to Nanonets applications is logged and audited.
Bastion hosts are used to login to devices.
All actions taken on production consoles or in the Nanonets application are logged.
We bi-annually engage with well-regarded third-party auditors to audit our code-base, and work with them to resolve potential issues.
We use technologies to provide an audit trail over our infrastructure and the Nanonets application. Auditing allows us to do ad-hoc security analysis, track changes made to our setup and audit access to every layer of our stack.
We are in the process of obtaining an SOC 2 Type II report.
Information about AWS security certifications and obtaining copies of security reports from AWS is available at http://aws.amazon.com/compliance/pci-data-privacy-protection-hipaa-soc-fedramp-faqs/
All payment instrument processing for purchase of the Nanonets services is performed by Stripe. For more information on Stripe’s security practices, please see https://stripe.com/docs/security/stripe.
Managing your own user accounts and roles from within the Nanonets services.
Protecting your own account and user credentials by using two-factor authentication for all of your employees accessing the Nanonets services.
Compliance with the terms of your services agreement with Nanonets, including with respect to compliance with laws.
Promptly notifying Nanonets if a user credential has been compromised or if you suspect possible suspicious activities that could negatively impact security of the Nanonets services or your account.
You may not perform any security penetration tests or security assessment activities without the express advance written consent of Nanonets.