Security

NS360 is a new company. We do not currently hold an ISO/IEC 27001 certificate or a SOC 2 report. This page describes the practices we follow instead, and we will answer your security questionnaire.

We would rather show you how we work than point at a badge. Everything below is our policy: practices we follow on every engagement, which you can ask us to demonstrate and write into a contract.

Our security program is written down. It covers people and access, devices, secrets, how we build software, the services we rely on and how we handle incidents. Rule 8 of India’s IT (Reasonable Security Practices and Procedures and Sensitive Personal Data or Information) Rules, 2011 describes reasonable security practices as a documented program like this. Ours has not been certified or independently audited. For the wider legal picture, see Compliance.

People and access

• Least privilege. People get the access their role on your project needs, and no more. Administrator rights are the exception: granted for a task, time-limited where your platform supports it, and removed when the task is done.
• Multi-factor authentication on every account. Email, code hosting, cloud consoles and any access you give us all require a second factor. We prefer passkeys or hardware security keys to SMS codes. If a system you give us access to cannot enforce a second factor, we tell you and agree a compensating control.
• Access per project, removed at the end. Access is granted per engagement, to named people, and recorded in an access register you can see on request. When someone leaves your project or the engagement ends, we remove the access we control on the same business day, ask you to remove the rest, and confirm it in writing.
• Confidentiality in writing. Everyone who works on client projects is bound by written confidentiality and intellectual-property terms. We do not bring subcontractors onto your work without your written agreement.

Devices and secrets

• Managed, encrypted work devices. Client code and data are handled only on company-managed computers with full-disk encryption, automatic screen lock, a supported operating system and prompt security updates. Phones used for work email, chat or sign-in prompts have a screen lock and current updates, and are never used to store client code or data. A lost or stolen device is reported at once and handled as a security incident.
• Secrets live in a secrets manager. Passwords, API keys, tokens and certificates are kept in a secrets manager, yours if you have one. They never go into repositories, chat, tickets or email. A secret that is exposed is rotated and treated as an incident.
• A short list of established services. We rely on a small number of established services for email, code hosting and file sharing, each protected by multi-factor authentication. We will tell you which of them would touch your data before the project starts.

Your data

• Only where the work requires it. We handle client data only when the engagement needs it, and where possible inside environments you control: your cloud accounts, your identity provider, your devices or virtual desktops if you require them. We do not copy it to our own systems unless you agree.
• No production data in local development without your explicit approval. We develop and test with synthetic or masked data. If you approve an exception, we take the minimum needed, protect it like production, and delete it when the task is done.

On every project, unless we agree to use your process instead, secure development looks like this:

• Threat modeling for sensitive features. Before we build authentication, payments, boundaries between customers in a shared platform, anything that handles personal data, or AI features that can take actions, we write down what could go wrong and how the design prevents it. The notes stay in your repository.
• Peer review on every change. Every change is reviewed by a second engineer, ours or yours, before it merges. We ask for branch protection on your repositories so that nobody can merge their own code unreviewed, and we tell you if your platform or plan cannot enforce it.
• Automated checks on every pull request. Dependency vulnerability scanning, secret scanning and static analysis run in CI alongside the tests. Findings are fixed, or accepted with a written reason, and never silently ignored.
• Least-privilege service accounts. Applications and pipelines get their own narrowly scoped identities. We prefer short-lived credentials, such as OpenID Connect federation from CI to your cloud, over long-lived keys.
• Separate environments. Development, staging and production are kept apart, in separate cloud accounts or projects where possible, and production access is limited to the people who need it.
• Infrastructure as code. Cloud resources are defined in code, reviewed like application code and reproducible. No hand-built production servers that nobody can rebuild.
• Healthy dependencies. Lockfiles pin exact versions. We update on a regular schedule and apply security fixes promptly.
• A software bill of materials on request. We can produce an SBOM for the software we deliver, in SPDX or CycloneDX format.
• Security review before launch. Before a system goes live, we review authentication and authorization, input handling, secrets, security headers, logging (without secrets or unnecessary personal data), backups and restores, and who is contacted when something breaks. We use OWASP guidance, such as the Application Security Verification Standard (ASVS), as our checklist, and share the findings and how each was resolved.

Lock-in is a security risk as well as a commercial one. If only your vendor can reach your systems, your vendor is a single point of failure. So we set things up the other way round.

• Code in your repositories from the first commit. We work inside your organization on your code-hosting platform. The canonical copy never lives anywhere else.
• Infrastructure in your cloud accounts. Resources are created in accounts you own and pay for. Our access is granted by you and can be removed by you at any time.
• Accounts in your name. Domains, app store listings, third-party services and API keys are registered to your organization. If you do not have an account yet, we help you open it in your name; we do not hold it for you.
• Credentials handed back at the end. When the engagement ends, we hand over every credential we managed, help you rotate anything we had access to, remove our own access and confirm it in writing.
• Your data returned or deleted. Unless our agreement says otherwise, any copy of your data we hold, including working copies of your code on our devices, is returned or deleted within 30 days of the engagement ending, sooner if you ask, and we confirm deletion in writing. We keep only what the law requires us to keep, such as contract and accounting records and security logs, and only for as long as it requires.
• Documentation you can use without us. Architecture notes, runbooks and setup instructions live alongside the code.

Intellectual property in the work we create for you is assigned to you under your signed agreement; our standard position is summarized under Contracts. How we hand over is described in Approach. Our website Terms cover this site only, not client work.

For us, an incident is anything that puts the confidentiality, integrity or availability of your code, data, credentials or systems at risk: a leaked secret, a lost laptop, access nobody expected, a vulnerability being exploited. We treat a suspected incident as real until we know otherwise.

How we respond

1. 01Contain. Revoke access, rotate credentials and isolate what is affected.
2. 02Assess. Establish what happened, what was affected and whose data is involved, preserving logs and evidence as we go.
3. 03Notify. Tell every affected client, as described below.
4. 04Fix. Remove the cause, not only the symptom.
5. 05Learn. Write a blameless post-incident review and share it with the clients affected.

When we tell you

We notify affected clients without undue delay, and in any case within 24 hours of becoming aware of an incident that affects their data or systems, or sooner if our agreement sets a shorter window. If an early warning sign could start one of your own legal deadlines, we tell you as soon as we see it, before anything is confirmed.

Our notice says what happened, what we know is affected, what we have done, what we recommend you do, and who to contact. We keep you updated until the incident is closed.

Legal reporting duties

• CERT-In. The CERT-In Directions of 28 April 2022, issued under section 70B(6) of the Information Technology Act, 2000, require specified cyber incidents to be reported to CERT-In within 6 hours of noticing them or being told about them. We report incidents in our own systems where the Directions require it. We keep logs of our own systems for at least 180 days, and for one year where the DPDP Rules require it from May 2027, setting retention where a service allows it and exporting logs where it does not. When the affected systems are yours, we give you the facts and timeline you need to report on time.
• Personal data under Indian law. When we process personal data for you, we act on your instructions as your Data Processor; you usually remain the Data Fiduciary. India’s Digital Personal Data Protection Act, 2023 and the DPDP Rules, 2025 require Data Fiduciaries to tell affected people and the Data Protection Board about personal data breaches. Those duties take effect in May 2027, and our notice is designed to help you meet them.
• Personal data under the EU GDPR. Where the GDPR applies to your processing, for example when it involves people in the European Union, we act as your processor and notify you without undue delay, as Article 33(2) requires, so you can meet your own 72-hour deadline for notifying the supervisory authority.

If you think something involving NS360 has gone wrong, tell your project contact and use the form on our Contact page.

We would rather answer detailed questions than be waved through. On request, and under NDA where the detail is sensitive, we provide:

• Answers to your security questionnaire, in your format.
• An architecture overview of our own setup: the services we use, how access and devices are managed, and where client data can and cannot go.
• Our written information security and incident response policies.
• The list of third-party services that would touch your data on your project.
• For software we deliver: architecture overviews, threat-model notes and a software bill of materials.

If your own program (ISO/IEC 27001, SOC 2, the DPDP Act, the GDPR or your internal standards) needs evidence for controls we operate on your behalf, we provide it for your audits. Where we cannot meet a requirement, we say so plainly.

To start a review, use the form on our Contact page, or ask your project contact.

Do you hold ISO/IEC 27001 certification or a SOC 2 report?

No. NS360 is a new company. We hold no ISO/IEC 27001 certificate or SOC 2 report, and no third party has yet audited our practices or penetration-tested our systems. Instead, we offer the practices on this page, straight answers to your questionnaire and evidence for the controls we run for you. If that changes, this page will say so, once it has happened and not before.

Will you sign an NDA or a data processing agreement?

Yes. We will sign your NDA before you share anything sensitive; the contact form lets you ask for one first. For personal data, we sign your data processing agreement or provide ours. Where the GDPR applies, that includes Article 28 processor terms and, for access from India, the EU Standard Contractual Clauses. See Compliance.

Where will our code live?

In your repositories, from the first commit. While we work, copies exist only on our managed, encrypted devices, and they are deleted within 30 days of the engagement ending (see You own it). Deployed systems run in your cloud accounts, in the regions you choose, including India or the EU if your data needs to stay there.

Can you work within our security policies and tooling?

Yes, and we prefer to. We can work through your single sign-on, code hosting, secrets manager, ticketing and scanners, and on your devices or virtual desktops if you require it. Where your policy is stricter than ours, yours applies. If you need something not described here, such as your approval of each person on the project, or background verification, raise it during scoping and we will tell you plainly whether we can meet it.

Do you use AI coding tools on client code?

Only with your agreement, and only under your policies. If you allow it, we use only approved tools, through company-managed accounts whose terms do not let your code be used to train models; we never paste secrets or personal data into them; and AI-assisted changes go through the same review and scanning as every other change. If you do not allow it, we do not use them on your code. See Responsible AI for the full policy.

Pages are built ahead of time and served over HTTPS from Cloudflare’s network. There are no logins and no user accounts. The only things the site accepts from visitors are the contact form and the enterprise enquiry form, and their submissions are kept in a single inquiries database on Cloudflare D1 (see our Privacy Policy).

Security headers

• Content Security Policy. Scripts, connections and frames may load only from our own domain and the few third-party services the site needs.
• HTTPS only. Plain HTTP requests are redirected to HTTPS, browsers are told to use HTTPS for this site for two years, and any insecure resource request is upgraded.
• No framing. Other sites cannot embed our pages (frame-ancestors 'none' and X-Frame-Options: DENY), which prevents clickjacking.
• Less leakage. A strict referrer policy, so other sites see only our domain when you follow a link; no content-type sniffing; and other sites’ windows cannot get a handle on ours.
• Browser features switched off. Camera, microphone, location, payment and USB access are disabled, and so are browser advertising-interest APIs.

One honest limitation: our Content Security Policy allows inline scripts and inline styles. The framework we use delivers page data as inline scripts, and a stricter nonce-based policy would stop pages from being served pre-built. The rest of the policy is restrictive.

Tracking and analytics

• No advertising trackers. No ad networks, remarketing tags or social-media pixels.
• No analytics. The site does not run any analytics scripts at the moment.

The contact form

• Hidden traps. A field that only bots fill in, and a signed timestamp that rejects forms sent too quickly to have been filled in by a person.
• Rate limiting and validation. A per-network limit on how often the form can be sent, and strict server-side checks with length limits on every field.
• Kept in one place. An inquiry that passes every check is saved once, in our inquiries database on Cloudflare D1, which only the people who handle inquiries can open (see our Privacy Policy). It holds no IP address or browser details, and the form’s code logs only a reference number and an outcome, never your name, email address or message.

What the form collects, and why, is explained in our Privacy Policy.

We welcome reports from security researchers and anyone else who spots a problem. To report one, use the form on our Contact page. This policy is also referenced from our security.txt file.

What to include

• The website, address or system affected.
• What the vulnerability is, and what an attacker could do with it.
• Steps to reproduce it, with any proof-of-concept code, requests or screenshots.
• How to reach you, and whether you would like to be credited.

The contact form takes up to 5,000 characters and cannot take attachments. Start your message with “Security report” and, where the form asks what you need, choose Not sure yet. Describe the issue there, and we will reply with a way to send files and longer proof-of-concept material.

Plain text is fine. A clear report matters more than a polished one. If you need to send sensitive details, ask us for a secure channel first.

Scope

In scope: websites and systems that NS360 owns and operates, including this website. That includes misconfigurations in our own accounts on services we use, such as a public repository or an exposed file share. Testing this website’s application is in scope; attacks on Cloudflare’s platform itself are not.

Out of scope: systems we build or run for clients, and the products shown in our Work section. They belong to their owners, so please report issues to them directly through their own security contacts. If you cannot find one, tell us and we will try to pass your report on.

Also out of scope: the platforms of third-party services we use (report those to the provider), denial-of-service or load testing, social engineering or phishing of our people or clients, physical attacks, and automated or bulk submissions through the contact form.

We usually treat these as low priority unless you can show a real impact: missing headers or best-practice suggestions, clickjacking on pages with no sensitive actions, self-XSS and version banners. We still read every report.

Testing in good faith

• Do not access, change or delete data that is not yours. If you reach personal or confidential information, stop, do not keep or share it, and tell us.
• Do not degrade the service: no denial-of-service attempts and no high-volume automated scanning.
• Do not use social engineering against our people, clients or suppliers.
• Give us reasonable time to fix the issue before you publish. We will agree a disclosure date with you, normally within 90 days of your report.

Safe harbor

If you act in good faith and follow this policy, we will treat your research as authorized, and we will not take legal action against you or ask law enforcement to act against you because of it. We cannot authorize testing of systems we do not own, including the platforms of our service providers.

This does not override our legal duties. If the law requires us to report an incident, for example to CERT-In, we will say that the activity was authorized good-faith research under this policy. If someone else takes legal action against you over research that followed this policy, we will make that known.

What you can expect from us

• An acknowledgment within 3 business days.
• An honest assessment of the issue, and updates while we investigate and fix it.
• Word from us when it is fixed and, if you would like it, public credit.

No paid bug bounty. We do not run a paid bug bounty program and cannot offer rewards for reports. We can offer thanks, credit and a fix.

When our practices change, we update this page and record the change in the version history. A material change, for example a certification or a change to how we notify clients, is always noted there.

For security questions, reports and anything else, use the form on our Contact page.

This page is published by NETSPHERE360 SOLUTIONS PRIVATE LIMITED, India.