Purpose and Scope

a. The purpose of this policy is to define the organization’s procedures to recover Information Technology (IT) infrastructure and IT services within set deadlines in the case of a disaster or other disruptive incident. The objective of this plan is to complete the recovery of IT infrastructure and IT services within a set Recovery Time Objective (RTO).

b. This policy includes all resources and processes necessary for service and data recovery, and covers all information security aspects of business continuity management.

c. This policy applies to all management, employees and suppliers that are involved in the recovery of IT infrastructure and services within the organization. This policy must be made readily available to all whom it applies to.

Background

a. This policy defines the overall disaster recovery strategy for the organization. The strategy describes the organization’s Recovery Time Objective (RTO), which is defined as the duration of time and service level for critical business processes to be restored after a disaster or other disruptive event, as well as the procedures, responsibility and technical guidance required to meet the RTO. This policy also lists the contact information for personnel and service providers that may be needed during a disaster recovery event (Included in internal policy document)

b. The following conditions must be met for this plan to be viable:

i. All equipment, software and data (or their backups/failovers) are available in some manner.

ii. If an incident takes place at the organization’s physical location, all resources involved in recovery efforts are able to be transferred to an alternate work site (such as their home office) to complete their duties.

iii. The Information Security Officer is responsible for coordinating and conducting a bi-annual (at least) rehearsal of this continuity plan. 

c. This plan does not cover the following types of incidents:

i. Incidents that affect customers or partners but have no effect on the organization’s systems; in this case, the customer must employ their own continuity processes to make sure that they can continue to interact with the organization and its systems.

ii. Incidents that affect cloud infrastructure suppliers at the core infrastructure level, including but not limited to Google, Heroku, and Amazon Web Services. The organization depends on such suppliers to employ their own continuity processes.

Policy

a. Critical Services, Key Tasks and, Service Level Agreements (SLAs)

i. The following services and technologies are considered to be critical for business operations, and must immediately be restored (in priority order):

    1. Primary database for API (Cassandra)
    2. Backend prediction API
    3. Backend API service
    4. SSL certificates for API service
    5. Application frontend

ii. The following key tasks and SLAs must be considered during a disaster recovery event, in accordance with the organization’s objectives, agreements, and legal, contractual or regulatory obligations:

    1. Nanonets will use commercially reasonable efforts to make each Service available with an uptime of 99.5% of each calendar month

b. The organization’s Recovery Time Objective (RTO) is 1 hour. Relocation and restoration of critical services and technologies must be completed within this time period. The Recovery Point Objective (RPO) is 1 hour since backups are taken on hourly basis.

c. Notification of Plan Initiation

i. The following personnel must be notified when this plan is initiated:

  1. (Included in internal policy document)

ii. Manager for the business system for which this plan is initiated is responsible for notifying the personnel listed above.

d. Plan Deactivation

i. This plan must only be deactivated by the Manager for the business system for which this plan is initiated.

ii. In order for this plan to be deactivated, all relocation activities and critical service / technology tasks  as detailed above must be fully completed and/or restored. If the organization is still operating in an impaired scenario, the plan may still be kept active at the discretion of Mr. Prathamesh Juvatkar (CTO).

iii. The following personnel must be notified when this plan is deactivated:

    1. (Included in internal policy document)

e. The organization must endeavor to restore its normal level of business operations as soon as possible.

f. A list of relevant points of contact both internal and external to the organization is enclosed in Appendix A (Included in internal policy document).

g. During a crisis, it is vital for certain recovery tasks to be performed right away. The following actions are pre-authorized in the event of a disaster recovery event:

i. Software Engineer must take all steps specified in this disaster recovery plan in order to recover the organization’s information technology infrastructure and services.

ii. Software Engineer is authorized to make urgent purchases of equipment and services up to (Included in internal policy document).

iii. Software Engineer is authorized to communicate with clients.

iv. Software Engineer is authorized to communicate with the public.

v. Software Engineer is authorized to communicate with public authorities such as state and local governments and law enforcement.

h. Specific recovery steps for information systems infrastructure and services are provided in Appendix B (Included in internal policy document).

Nanonets doesn’t store passwords or credentials, all authentication requests are made directly to a third party service provider auth0 that is ISO27001, SOC 2 Type II, EU-US Privacy Shield Framework, PCI compliant

Nanonets releases product updates every 2 weeks which include both product features, security fixes and bug fixes.

All of our release changes can be viewed here: changelog.nanonets.com

We provide our customers with the ability to host their data exclusively in a region of their chosing like the US or EU etc. In such a setup no data leaves the geography and nobody outside those geographies has the ability to access that data.

All the nanonets services are containerized and we use kubernetes to manage deployment and scaling of these containerized services. So all the services are autoscaled depending on QoS promised.

The autoscaling is configurable

Purpose and Scope

a. The purpose of this policy is to define the methodology for the assessment and treatment of information security risks within the organization, and to define the acceptable level of risk as set by the organization’s leadership.

b. Risk assessment and risk treatment are applied to the entire scope of the organization’s information security program, and to all assets which are used within the organization or which could have an impact on information security within it.

c. This policy applies to all employees of the organization who take part in risk assessment and risk treatment.

Background

a. A key element of the organization’s information security program is a holistic and systematic approach to risk management. This policy defines the requirements and processes for the organization to identify information security risks. The process consists of four parts: identification of the organization’s assets, as well as the threats and vulnerabilities that apply; assessment of the likelihood and consequence (risk) of the threats and vulnerabilities being realized, identification of treatment for each unacceptable risk, and evaluation of the residual risk after treatment.

Policy

a. Risk Assessment

i. The risk assessment process includes the identification of threats and vulnerabilities having to do with company assets.

ii. The first step in the risk assessment is to identify all assets within the scope of the information security program; in other words, all assets which may affect the confidentiality, integrity, and/or availability of information in the organization. Assets may include documents in paper or electronic form, applications, databases, information technology equipment, infrastructure, and external/outsourced services and processes. For each asset, an owner must be identified.

iii. The next step is to identify all threats and vulnerabilities associated with each asset. Threats and vulnerabilities must be listed in a risk assessment table. Each asset may be associated with multiple threats, and each threat may be associated with multiple vulnerabilities.

iv. For each risk, an owner must be identified. The risk owner and the asset owner may be the same individual.

v. Once risk owners are identified, they must assess:

    1. Consequences for each combination of threats and vulnerabilities for an individual asset if such a risk materializes. 

    2. Likelihood of occurrence of such a risk (i.e. the probability that a threat will exploit the vulnerability of the respective asset).

    3. Criteria for determining consequence and likelihood are defined in Tables 1 and 2.

vi. The risk level is calculated by adding the consequence score and the likelihood score.

Table 1: Description of Consequence Levels and Criteria

Table 2: Description of Likelihood Levels and Criteria

b. Risk Acceptance Criteria

i. Risk values 0 through 2 are considered to be acceptable risks.

ii. Risk values 3 and 4 are considered to be unacceptable risks. Unacceptable risks must be treated.

c. Risk Treatment

i. Risk treatment is implemented through the Risk Treatment Table. All risks from the Risk Assessment Table must be copied to the Risk Treatment Table for disposition, along with treatment options and residual risk.

ii. As part of this risk treatment process, the CEO and/or other company managers shall determine objectives for mitigating or treating risks. All unacceptable risks must be treated. For continuous improvement purposes, company managers may also opt to treat other risks for company assets, even if their risk score is deemed to be acceptable.

iii. Treatment options for risks include the following options:

    1. Selection or development of security control(s).

    2. Transferring the risks to a third party; for example, by purchasing an insurance policy or signing a contract with suppliers or partners.

    3. Avoiding the risk by discontinuing the business activity that causes such risk.

    4. Accepting the risk; this option is permitted only if the selection of other risk treatment options would cost more than the potential impact of the risk being realized.

iv. After selecting a treatment option, the risk owner should estimate the new consequence and likelihood values after the planned controls are implemented.

d. Regular Reviews of Risk Assessment and Risk Treatment

i. The Risk Assessment Table and Risk Treatment Table must be updated when newly identified risks are identified. At a minimum, this update and review shall be conducted once per year. It is highly recommended that the Risk Assessment and Risk Treatment Table be updated when significant changes occur to the organization, technology, business objectives, or business environment.

e. Reporting

i. The results of risk assessment and risk treatment, and all subsequent reviews, shall be documented in a Risk Assessment Report.

Purpose and Scope

a. The purpose of this policy is to ensure that the organization establishes objectives, plans and, procedures such that a major disruption to the organization’s key business activities is minimized.

b. This policy applies to all infrastructure and data within the organization’s information security program.

c. This policy applies to all management, employees, and suppliers that are involved in decisions and processes affecting the organization’s business continuity. This policy must be made readily available to all whom it applies to.

Background

a. The success of the organization is reliant upon the preservation of critical business operations and essential functions used to deliver key products and services. The purpose of this policy is to define the criteria for continuing business operations for the organization in the event of a disruption. Specifically, this document defines:

b. Within this document, the following definitions apply:

Policy

a. Business Risk Assessment and Business Impact Analysis

b. Disaster Recovery Plan

c. Data Backup and Restoration Plans

Purpose and Scope

a. This log management and review policy defines specific requirements for information systems to generate, store, process, and aggregate appropriate audit logs across the organization’s entire environment in order to provide key information and detect indicators of potential compromise.

b. This policy applies to all information systems within the organization’s production network.

c. This policy applies to all employees, contractors, and partners of the organization that administer or provide maintenance on the organization’s production systems. Throughout this policy, these individuals are referred to as system administrators.

Background

a. In order to measure an information system’s level of security through confidentiality, integrity, and availability, the system must collect audit data that provides key insights into system performance and activities. This audit data is collected in the form of system logs. Logging from critical systems, applications, and services provides information that can serve as a starting point for metrics and incident investigations. This policy provides specific requirements and instructions for how to manage such logs.

Policy

a. All production systems within the organization shall record and retain audit-logging information that includes the following information:

i. Activities performed on the system.

ii. The user or entity (i.e. system account) that performed the activity, including the system that the activity was performed from.

iii. The file, application, or other object that the activity was performed on.

iv. The time that the activity occurred.

v. The tool that the activity was performed with.

vi. The outcome (e.g., success or failure) of the activity.

b. Specific activities to be logged must include, at a minimum:

i. Information (including authentication information such as usernames or passwords) is created, read, updated, or deleted. 

ii. Accepted or initiated network connections. 

iii. User authentication and authorization to systems and networks.

iv. Granting, modification, or revocation of access rights, including adding a new user or group; changing user privileges, file permissions, database object permissions, firewall rules, and passwords.

v. System, network, or services configuration changes, including software installation, patches, updates, or other installed software changes.

vi. Startup, shutdown, or restart of an application. 

vii. Application process abort, failure, or abnormal end, especially due to resource exhaustion or reaching a resource limit or threshold (such as CPU, memory, network connections, network bandwidth, disk space, or other resources), the failure of network services such as DHCP or DNS, or hardware fault.

viii. Detection of suspicious and/or malicious activity from a security system such as an Intrusion Detection or Prevention System (IDS/IPS), anti-virus system, or anti-spyware system.

c. Unless technically impractical or infeasible, all logs must be aggregated in a central system so that activities across different systems can be correlated, analyzed, and tracked for similarities, trends, and cascading effects. Log aggregation systems must have automatic and timely log ingest, event and anomaly tagging and alerting, and ability for manual review.

d. Logs must be manually reviewed on a regular basis:

i. The activities of users, administrators and system operators must be reviewed on at least a monthly basis.

ii. Logs related to PII must be reviewed on at least a monthly basis in order to identify unusual behavior.

e. When using an outsourced cloud environment, logs must be kept on cloud environment access and use, resource allocation and utilization, and changes to PII. Logs must be kept for all administrators and operators performing activities in cloud environments.

f. All information systems within the organization must synchronize their clocks by implementing Network Time Protocol (NTP) or a similar capability. All information systems must synchronize with the same primary time source.

Customer Data collected during your use of the Subscription Service is retained in accordance with the provisions of the DPA and is retained for as long as you have a paid Subscription and/or remain an active customer in your portal. Your data is deleted upon your written request or after an established period following the termination of all customer agreements.

In addition enterprise customers can request specific retention policies that will be added to their enterprise contract. We provide for periodic retention and deletion in these cases.

All data sent to or from Nanonets is encrypted in transit using 256 bit encryption. Our API and application endpoints are TLS/SSL only. This means we only use strong cipher suites and have features such as HSTS and Perfect Forward Secrecy fully enabled.

Nanonets is served 100% over https. Nanonets runs a zero-trust corporate network

If you have a paid Nanonets subscription, you may conduct a security test of your model and API endpoints for your model.

Submit penetration testing request

To conduct a security test, please notify us in advance by writing an email to . Nanonets requires at least 14 days notice prior to your test's planned start date.

If the test is isolated to your infrastructure (that is, there will be no testing of Nanonets services), you do not need to notify Nanonets.

Information required

Please provide the following information in the support ticket when requesting approval for testing:

• The specific dates/times of the test and timezone

• The high level scope of the test

• IP address(es) the scan will come from

• The Nanonets models(s) involved

• Two (2) contacts who will be available during the entire test period in case we need to contact you. If we have any questions, we will make a reasonable attempt to contact you. If you cannot be reached, we reserve the right to take measures to protect the service, which may include shutting down or blocking your model and/or the source of the intrusion traffic.

Test requirements

Nanonets requires that:

• The test be restricted to only your model(s)

• You disclose any suspected findings to the Nanonets Security team for explanation/discussion

Restrictions

• You may not conduct any (such as Denial of Service testing) per the load testing policy.

• You may not conduct any penetration testing targeting our management dashboard. Management and Authentication APIs are allowed.

• You may not conduct any penetration testing targeting models that we have not approved.

Purpose and Scope

a. This security incident response policy is intended to establish controls to ensure detection of security vulnerabilities and incidents, as well as quick reaction and response to security breaches.

b. This document also provides implementing instructions for security incident response, to include definitions, procedures, responsibilities, and performance measures (metrics and reporting mechanisms).

c. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.

Background

a. A key objective of the organization’s Information Security Program is to focus on detecting information security weaknesses and vulnerabilities so that incidents and breaches can be prevented wherever possible. The organization is committed to protecting its employees, customers, and partners from illegal or damaging actions taken by others, either knowingly or unknowingly. Despite this, incidents and data breaches are likely to happen; when they do, the organization is committed to rapidly responding to them, which may include identifying, containing, investigating, resolving , and communicating information related to the breach.

b. This policy requires that all users report any perceived or actual information security vulnerability or incident as soon as possible using the contact mechanisms prescribed in this document. In addition, the organization must employ automated scanning and reporting mechanisms that can be used to identify possible information security vulnerabilities and incidents. If a vulnerability is identified, it must be resolved within a set period of time based on its severity. If an incident is identified, it must be investigated within a set period of time based on its severity. If an incident is confirmed as a breach, a set procedure must be followed to contain, investigate, resolve, and communicate information to employees, customers, partners and other stakeholders.

c. Within this document, the following definitions apply:

i. Information Security Vulnerability: a vulnerability in an information system, information system security procedures, or administrative controls that could be exploited to gain unauthorized access to information or to disrupt critical processing.

ii. Information Security Incident: a suspected, attempted, successful, or imminent threat of unauthorized access, use, disclosure, breach, modification, or destruction of information; interference with information technology operations; or significant violation of information security policy.

Policy

a. All users must report any system vulnerability , incident, or event pointing to a possible incident to the Information Security Manager (ISM) as quickly as possible but no later than 24 hours. Incidents must be reported by sending an email message to with details of the incident.

b. Users must be trained on the procedures for reporting information security incidents or discovered vulnerabilities, and their responsibilities to report such incidents. Failure to report information security incidents shall be considered to be a security violation and will be reported to the Human Resources (HR) Manager for disciplinary action.

c. Information and artifacts associated with security incidents (including but not limited to files, logs, and screen captures) must be preserved in the event that they need to be used as evidence of a crime.

d. All information security incidents must be responded to through the incident management procedures defined below.

e. In order to appropriately plan and prepare for incidents, the organization must review incident response procedures at least once per year for currency, and update as required.

f. The incident response procedure must be tested on at least twice per year

g. The incident response logs must be reviewed once per month to assess response effectiveness.

Procedure For Establishing Incident Response System

a. Define on-call schedule and assign an Information Security Manager (ISM) responsible for managing incident response procedure during each availability window.

b. Define notification channel to alert the on-call ISM of a potential security incident. Establish company resource that includes up to date contact information for on-call ISM.

c. Assign management sponsors from the Engineering, Legal, HR, Marketing, and C-Suite teams.

d. Distribute Procedure For Execute Incident Response to all staff and ensure up-to-date versions are accessible in a dedicated company resource.

e. Require all staff to complete training for Procedure For Executing Incident Response at least twice per year.

Procedure For Executing Incident Response

a. When an information security incident is identified or detected, users must notify their immediate manager within 24 hours. The manager must immediately notify the ISM on call for proper response. The following information must be included as part of the notification:

i. Description of the incident

ii. Date, time, and location of the incident

iii. Person who discovered the incident

iv. How the incident was discovered

v. Known evidence of the incident

vi. Affected system(s)

b. Within 48 hours of the incident being reported, the ISM shall conduct a preliminary investigation and risk assessment to review and confirm the details of the incident. If the incident is confirmed, the ISM must assess the impact to the organization and assign a severity level, which will determine the level of remediation effort required:

i. High: the incident is potentially catastrophic to the organization and/or disrupts the organization’s day-to-day operations; a violation of legal, regulatory or contractual requirements is likely.

ii. Medium: the incident will cause harm to one or more business units within the organization and/or will cause delays to a business unit’s activities.

iii. Low: the incident is a clear violation of organizational security policy, but will not substantively impact the business.

c. The ISM, in consultation with management sponsors, shall determine appropriate incident response activities in order to contain and resolve incidents.

d. The ISM must take all necessary steps to preserve forensic evidence (e.g. log information, files, images) for further investigation to determine if any malicious activity has taken place. All such information must be preserved and provided to law enforcement if the incident is determined to be malicious.

e. If the incident is deemed as High or Medium, the ISM must work with the VP Brand/Creative, General Counsel, and HR Manager to create and execute a communications plan that communicates the incident to users, the public, and others affected.

f. The ISM must take all necessary steps to resolve the incident and recover information systems, data, and connectivity. All technical steps taken during an incident must be documented in the organization’s incident log, and must contain the following:

i. Description of the incident

ii. Incident severity level

iii. Root cause (e.g. source address, website malware, vulnerability)

iv. Evidence

v. Mitigations applied (e.g. patch, re-image)

vi. Status (open, closed, archived)

vii. Disclosures (parties to which the details of this incident were disclosed to, such as customers, vendors, law enforcement, etc.)

g. After an incident has been resolved, the ISM must conduct a post mortem that includes root cause analysis and documentation any lessons learned.

h. Depending on the severity of the incident, the Chief Executive Officer (CEO) may elect to contact external authorities, including but not limited to law enforcement, private investigation firms, and government organizations as part of the response to the incident.

i. The ISM must notify all users of the incident, conduct additional training if necessary, and present any lessons learned to prevent future occurrences. Where necessary, the HR Manager must take disciplinary action if a user’s activity is deemed as malicious.

Export data

If you would like to export your data from Nanonets there are a several ways you can do this.

Use the Import/Export Extension

You can use our Import/Export Extension to export nearly all data in your Nanonets account.

Use the API

If you want to export certain sets of data programmatically, use the API endpoints.

Transfer data

Nanonets will not transfer data from one Nanonets account to another. This applies to both Public Cloud and Private Cloud customers.

All data in your Nanonets account is always under your control and is available through the Management portal and API at any time.

All of our servers have control lists (ACLs) that prevent unauthorized requests getting to our internal network.

Multiple authorization levels are used when granting access to sensitive systems, including those storing and processing data. Processes are in place to ensure that authorized users have the appropriate authorization to access any data.

Customers have access only to their own data.

Access to customer data is limited to authorized employees who require it for their job. We are following access management and restrictions based on the need-to-know principle. All our employees and contractors are bound by the non-disclosure agreements.

Nanonets has procedures in place to ensure that requested authorization changes are implemented only in accordance with the guidelines.

Data processing systems used to provide the Nanonets Services must be prevented from being used without authorization. Measures:

• Multiple authorization levels are used when granting access to sensitive systems, including those storing and processing Personal Data. Processes are in place to ensure that authorized users have the appropriate authorization to add, delete, or modify users.

• All users access Nanonets systems with a unique identifier (user ID).

• Nanonets has procedures in place to ensure that requested authorization changes are implemented only in accordance with the guidelines (for example, no rights are granted without authorization).

  If a user leaves the company, his or her access rights are revoked.

• Nanonets has established a password policy that prohibits the sharing of passwords, governs responses to password disclosure, and requires passwords to be changed on a regular basis and default passwords to be altered.

• Personalized user IDs are assigned for authentication. All passwords must fulfil defined minimum requirements and are stored in encrypted form. In the case of domain passwords, the system forces a password change every 3 months in compliance with the requirements for complex passwords.

• Each computer has a password- protected screensaver.

• The company network is protected from the public network by firewalls.

• Nanonets uses up–to-date antivirus software at access points to the company network (for e- mail accounts), as well as on all file servers and all workstations.

• Security patch management is implemented to ensure regular and periodic deployment of relevant security updates.

• Full remote access to Nanonets’ corporate network and critical infrastructure is protected by strong authentication.

Physical Access Controls

Unauthorized persons are prevented from gaining physical access to premises, buildings or rooms where data processing systems that process and/or use Personal Data are located. Measures: 11.1. Nanonets protects its assets and facilities using the appropriate means based on a security classification.

In general, buildings are secured through access control systems (e.g., smart card access system). 11.3. As a minimum requirement, the outermost entrance points of the building must be fitted with a certified key system including modern, active key management.

Depending on the security classification, buildings, individual areas and surrounding premises may be further protected by additional measures. These include specific access profiles, video surveillance, intruder alarm systems and bio metric access control systems.

Access rights are granted to authorized persons on an individual basis according to the System and Data Access Control measures. This also applies to visitor access. • Guests and visitors to Nanonets buildings must register their names at reception and must be accompanied by authorized Nanonets personnel.

Policy

All customer data should be disposed of when it is no longer necessary for business use, provided that the disposal does not conflict with our data retention policies, our customers data retention policies, a court order, or any of our regulatory obligations.

• All employees, clients, vendors and contractors are instructed to not use the following media to store confidential information.

  • paper-based media

  • USB Drives or External Backup programs

  • CD ROM drives.

• All cloud based storage media being decommissioned should be sanitized when it is no longer necessary, provided that there is a backup of customer data on production systems to comply with our customers data retention and contractual obligations.

• Laptop based storage media may not be donated or sold. All laptop based storage media should be sanitized prior to transfer of ownership to a co-worker or prior to destruction.

Scope

The following table displays the forms of storage media currently in use.

Removal Classifications

A) Clearing

If comprehensive data removal from the media is not required, then non-specialist staff or contractors may carry out clearing. Typical clearing programs use sequential writes of patterned data, ensuring that data is not easily recovered using standard techniques and programs. To ensure that historical data is thoroughly removed it is advisable to make as many passes as is practicable.

B) Purging

Purging is a more advanced level of sanitization that renders media unreadable even through an advanced laboratory. After removal of media from its current security context there must be sufficient care taken to ensure that data is irretrievable. If purging of the media is required, a minimum of seven passes qualifies as a purging process.

C) Destroying

Destroying renders media unusable. Destruction techniques include but are not limited to disintegration, incineration, pulverizing, shredding and melting.

Media Destruction Techniques

Storage Media, which is being decommissioned, will be passed to a specialist contractor for secure disposal.

A) Hard Disk Destruction

Degaussing is a simple method that permanently destroys all data and disables the drive. Degaussing uses a high-powered magnetic field that permanently destroys data on the platters. The recommended specification for data destruction is the SEAP 8500 Type II standard used for classified government material.

C) Solid-State Devices

Solid-state devices normally require the complete physical destruction of the device to ensure that any recovery of data is impossible. Incineration will melt SD cards. Devices such as USB thumb drives should be physically destroyed using brute force methods. As long as appropriate safety methods are in use, non-specialist staff can destroy these devices.

D) Cloud Based(AWS) Devices

“When AWS determines that media has reached the end of its useful life, or it experiences a hardware fault, AWS follows the techniques detailed in Department of Defense (DoD) 5220.22-M (“National Industrial Security Program Operating Manual”) or NIST SP 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process.” P.39 AWS Security Best Practices White paper

Data Removal and Destruction Management

Once a specialist company or contractor has processed the media, there should be a procedure for verification of data removal. ​It is important to maintain an effective method of managing the process of data destruction. This ensures that all media requiring cleaning or destruction is correctly organized and properly audited. Tracking of hard disk serial numbers should be used a bare minimum for individual component tracking.

Nanonets recognizes that customers may occasionally need to perform load tests against its production cloud service. In order to ensure a successful test and maintain a high quality of service for all customers, Nanonets has established the following guidelines. Any load testing in Nanonets must be conducted in accordance with this Policy.

Only customers who have purchased an Enterprise subscription may conduct load testing. Free, Developer, Pro and other non-Enterprise customers may not conduct load testing. Customers with an Enterprise subscription may request one load test (with up to 2 repeats) per year against an Nanonets production model. Performance and load testing is only allowed with Nnaonets' prior written approval. Once approved, testing can only target tenants that we have approved.

Nanonets reserves the right to reject the load test request or ask for modifications. Failure to abide by this policy may result in temporary blocking of access to a tenant until the issue is remediated.

Submit load testing request

You must file a load testing request by email to [email protected].

To be considered for approval, the request must:

• Be filed at least 2 weeks prior to the desired test date; in many cases, Nanonets encourages one 1 month of advance notice to ensure time for a thorough review and any required modifications.

• Be approved in writing before any testing is conducted.

• Stay within our published production rate limits.

• Include all information described below.

Information to include in requests

The load testing request must include the following:

• A description of the test to be done

• The name and region of the Nanonets model to be used during the test

• The requested date and time of the test, including time zone

• The requested duration of the test (2 hour maximum)

• The platforms to be used for the test (desktop/laptop, iOS, Android, other)

• The Nanonets features used during the test

• The Nanonets API methods and endpoints to be used (for example GET /api/v2/models)

• The maximum requests per second for each type of request or endpoint

• The types of Nanonets connections involved in the test

• The peak load, specified in requests-per-second, expected for each API endpoint or Nanonets feature involved in the test

• An explanation/justification for the peak load numbers, including the size of the target user population and realistic estimates of logins per hour

• The ramp-up rate for the test

Test requirements

Load testing windows are subject to availability so advance notice is highly recommended. Once approved, load testing windows will have a scheduled start and end time not to exceed two (2) hours in duration. All testing must begin and end during this window.

Nanonets strongly recommends including a brief "ramp up" period to the desired load test target numbers. For example, a load test request of 10 RPS might be preceded by three five minute periods: 5 minutes at 1 RPS, 5 minutes at 2 RPS, and 5 minutes at 5 RPS. This ramp up period allows Auth0 and the customer to observe and compare effects at increasing RPS levels prior to peak RPS. If a ramp up period is not possible, please indicate why.

Purpose and Scope

a. The purpose of this policy is to define requirements for proper controls to protect the availability of the organization’s information systems.

b. This policy applies to all users of information systems within the organization. This typically includes employees and contractors, as well as any external parties that come into contact with systems and information controlled by the organization (hereinafter referred to as “users”). This policy must be made readily available to all users.

Background

a. The intent of this policy is to minimize the amount of unexpected or unplanned downtime (also known as outages) of information systems under the organization’s control. This policy prescribes specific measures for the organization that will increase system redundancy, introduce failover mechanisms, and implement monitoring such that outages are prevented as much as possible. Where they cannot be prevented, outages will be quickly detected and remediated.

b. Within this policy, an availability is defined as a characteristic of information or information systems in which such information or systems can be accessed by authorized entities whenever needed.

Policy

a. Information systems must be consistently available to conduct and support business operations.

b. Information systems must have a defined availability classification, with appropriate controls enabled and incorporated into development and production processes based on this classification.

c. System and network failures must be reported promptly to the organization’s lead for Information Technology (IT) or designated IT operations manager.

d. Users must be notified of scheduled outages (e.g., system maintenance) that require periods of downtime. This notification must specify the date and time of the system maintenance, expected duration, and anticipated system or service resumption time.

e. Prior to production use, each new or significantly modified application must have a completed risk assessment that includes availability risks. Risk assessments must be completed in accordance with the Risk Assessment Policy (reference (a)).

f. Capacity management and load balancing techniques must be used, as deemed necessary, to help minimize the risk and impact of system failures.

g. Information systems must have an appropriate data backup plan that ensures:

h. Information systems must have an appropriate redundancy and failover plan that meets the following criteria:

i. Information systems must have an appropriate business continuity plan that meets the following criteria:

Table 1: Recovery Time and Data Loss Limits

Purpose and Scope

This Policy defines the key responsibilities and processes associated with resource changes within the Force – new starters & leavers to the organisation. These responsibilities are key to safeguarding Nanonets' physical and data assets and ensuring the security of those assets at all times.

Background

In order to minimize the risk of information loss or exposure (from both inside and outside the organisation), the organisation is reliant on the principle of least privilege. Account creation and permission levels are restricted to only the resources absolutely needed to perform each person’s job duties. When a user’s role within the organisation changes, those accounts and permission levels are changed/revoked to fit the new role and disabled when the user leaves the organisation altogether.

Policy

a. During onboarding:

HR services shall:

1. Ensure that the appropriate pre-employment checks and screening are undertaken. Where access to more sensitive information or information systems is required, further vetting processes against standards shall be required;

2. Ensure that Employees commence employment with the appropriate paperwork and checks are completed and received;

3. Ensure that Employees security risks are effectively managed through robust security processes to ensure actions are in accordance with Nanonets' legal obligations;

4. Provide a legally binding contract of employment. The contract of employment shall explicitly state all applicable roles, benefits and responsibilities bestowed on the employee by Nanonets. From an information security perspective, it shall include the expected Employee Code of Conduct, confidentiality clauses, required compliance to legal requirements, policies and procedures, and the consequences of noncompliance and subsequent information breaches;

5. Ensure that prior to recruitment the security responsibilities are outlined to the candidates. This includes embedding these responsibilities appropriately into each job description.

Managers shall:

1. Ensure they understand the needs of the Starter and what is expected of them, including all relevant policies

2. Ensure the Starter shall not have access to the Nanonets systems until they have read and signed all the relevant policies

3. Manager creates a checklist of ICT assets, systems, accounts and permission levels needed for that role.

4. Prepare a comprehensive induction programme covering: the role, the responsibilities assigned to the individual, the Nanonets Information Governance Policy and associated policies, the assets associated with the role, and the access permissions granted

5. Identify relevant training for the individual, including Information Security Training

6. Ensure the employee is familiar with all relevant information security policies, including the Information Security Incident Reporting and Management Policy

7. Provide the Starter with an overview of information handling within the department, including electronic and paper

8. Manager works with the owner of each resource to set up the user.

a. During offboarding:

HR services shall:

1. Facilitate the Leaver process with the Manager in a timely manner. 

2. Notifying of other relevant functions such as payroll and conducting of an exit interview.

Managers shall:

1. Explain the Leaver process to the Employee and clarify any questions they may have

2. Initiate the Leaver process and action all elements of the Leaver process in a timely manner

3. Remind the leaver of their Terms and Conditions of employment, including Information Governance obligations – namely, that they must not leave with Nanonets information in any format. In addition, they shall respect confidentiality agreements and personal information requirements

4. Ensure that the Employee understands their post termination responsibilities under the appropriate governing laws

5. Identify Nanonets assets to which the Leaver has, or has had access, and ensure these are all returned, and access removed prior to, or on, the leave date

6. Ensure that a robust handover is completed, and contact lists are updated, recorded and communicated to appropriate areas

7. Return the completed termination checklist to HR Support confirming that all stages of the process have been actioned and ensuring that an exit interview is carried out

8. Ensure, with the Head of department, that the Systems Administrator has been informed that the Employee is no longer entitled to access any internal system or equipment or data and information

9. Report any non-compliance of the Policy to the relevant Head of department.

Purpose and Scope

a. The purpose of this policy is to define requirements for establishing and maintaining baseline protection standards for company software, network devices, servers, and desktops.

b. This policy applies to all users performing software development, system administration, and management of these activities within the organization. This typically includes employees and contractors, as well as any relevant external parties involved in these activities (hereinafter referred to as “users”). This policy must be made readily available to all users.

c. This policy also applies to enterprise-wide systems and applications developed by the organization or on behalf of the organization for production implementation.

Background

a. The intent of this policy is to ensure a well-defined, secure and consistent process for managing the entire lifecycle of software and information systems, from initial requirements analysis until system decommission. The policy defines the procedure, roles, and responsibilities, for each stage of the software development lifecycle.

b. Within this policy, the software development lifecycle consists of requirements analysis, architecture and design, development, testing, deployment/implementation, operations/maintenance, and decommission. These processes may be followed in any form; in a waterfall model, it may be appropriate to follow the process linearly, while in an agile development model, the process can be repeated in an iterative fashion.

Policy

a. The organization’s Software Development Life Cycle (SDLC) includes the following phases:

i. Requirements Analysis

ii. Architecture and Design

iii. Testing

iv. Deployment/Implementation

v. Operations/Maintenance

vi. Decommission

b. During all phases of the SDLC where a system is not in production, the system must not have live data sets that contain information identifying actual people or corporate entities, actual financial data such as account numbers, security codes, routing information, or any other financially identifying data. Information that would be considered sensitive must never be used outside of production environments.

c. The following activities must be completed and/or considered during the requirements analysis phase:

i. Analyze business requirements.

ii. Perform a risk assessment. More information on risk assessments is discussed in the Risk Assessment Policy (reference (a)).

iii. Discuss aspects of security (e.g., confidentiality, integrity, availability) and how they might apply to this requirement.

iv. Review regulatory requirements and the organization’s policies, standards, procedures and guidelines.

v. Review future business goals.

vi. Review current business and information technology operations.

vii. Incorporate program management items, including:

    1. Analysis of current system users/customers.

    2. Understand customer-partner interface requirements (e.g., business-level, network).

    3. Discuss project timeframe.

viii. Develop and prioritize security solution requirements.

ix. Assess cost and budget constraints for security solutions, including development and operations.

x. Approve security requirements and budget.

xi. Make “buy vs. build” decisions for security services based on the information above.

d. The following must be completed/considered during the architecture and design phase:

i. Educate development teams on how to create a secure system.

ii. Develop and/or refine infrastructure security architecture.

iii. List technical and non-technical security controls.

iv. Perform architecture walkthrough.

v. Create a system-level security design.

vi. Create high-level non-technical and integrated technical security designs.

vii. Perform a cost/benefit analysis for design components.

viii. Document the detailed technical security design.

ix. Perform a design review, which must include, at a minimum, technical reviews of application and infrastructure, as well as a review of high-level processes.

x. Describe detailed security processes and procedures, including: segregation of duties and segregation of development, testing and production environments. 

xi. Design initial end-user training and awareness programs.

xii. Design a general security test plan.

xii. Update the organization’s policies, standards, and procedures, if appropriate.

xiv. Assess and document how to mitigate residual application and infrastructure vulnerabilities.

xv. Design and establish separate development and test environments.

e. The following must be completed and/or considered during the development phase:

i. Set up a secure development environment (e.g., servers, storage).

ii. Train infrastructure teams on installation and configuration of applicable software, if required.

iii. Develop code for application-level security components.

iv. Install, configure and integrate the test infrastructure.

v. Set up security-related vulnerability tracking processes.

vi. Develop a detailed security test plan for current and future versions (i.e., regression testing).

vii. Conduct unit testing and integration testing.

f. The following must be completed and/or considered during the testing phase:

i. Perform a code and configuration review through both static and dynamic analysis of code to identify vulnerabilities. 

ii. Test configuration procedures.

iii. Perform system tests.

iv. Conduct performance and load tests with security controls enabled.

v. Perform usability testing of application security controls.

vi. Conduct independent vulnerability assessments of the system, including the infrastructure and application.

g. The following must be completed and/or considered during the deployment phase:

i. Conduct pilot deployment of the infrastructure, application and other relevant components.

ii. Conduct transition between pilot and full-scale deployment.

iii. Perform integrity checking on system files to ensure authenticity.

iv. Deploy training and awareness programs to train administrative personnel and users in the system’s security functions.

v. Require participation of at least two developers in order to conduct full-scale deployment to the production environment.

h. The following must be completed and/or considered during the operations/maintenance phase:

i. Several security tasks and activities must be routinely performed to operate and administer the system, including but not limited to:

    1. Administering users and access.

    2. Tuning performance.

    3. Performing backups according to requirements defined in the System Availability Policy 

    4. Performing system maintenance (i.e., testing and applying security updates and patches).

    5. Conducting training and awareness.

    6. Conducting periodic system vulnerability assessments.

    7. Conducting annual risk assessments.

ii. Operational systems must:

    1. Be reviewed to ensure that the security controls, both automated and manual, are functioning correctly and effectively.

    2. Have logs that are periodically reviewed to evaluate the security of the system and validate audit controls.

    3. Implement ongoing monitoring of systems and users to ensure detection of security violations and unauthorized changes.

    4. Validate the effectiveness of the implemented security controls through security training as required by the Procedure For Executing Incident Response.

    5. Have a software application and/or hardware patching process that is performed regularly in order to eliminate software bug and security problems being introduced into the organization’s technology environment. Patches and updates must be applied within ninety (90) days of release to provide for adequate testing and propagation of software updates. Emergency, critical, break-fix, and zero-day vulnerability patch releases must be applied as quickly as possible.

i. The following must be completed and/or considered during the decommission phase:

i. Conduct unit testing and integration testing on the system after component removal.

ii. Conduct operational transition for component removal/replacement.

iii. Determine data retention requirements for application software and systems data.

iv. Document the detailed technical security design.

v. Update the organization’s policies, standards and procedures, if appropriate.

vi. Assess and document how to mitigate residual application and infrastructure vulnerabilities.