How we secure the platform that secures you.

1. Our security commitment

ShadowMap is built and operated by Security Brigade InfoSec Private Limited, a cybersecurity firm working in offensive security since 2006 and CERT-In empanelled in 2008. The same red teams that break into other people's estates for a living test ours, which is a meaningful advantage and also the reason we hold the platform to an uncomfortable standard.

Two things follow from what ShadowMap is. First, we hold a standing, continuously refreshed model of our customers' external estates — the exact document an attacker would most like to read. Second, we hold credential and infostealer-derived material, which is sensitive in its own right. The controls below are scoped to those two facts rather than to a generic SaaS threat model.

2. Governance and frameworks

• Security leadership. An appointed CISO owns security posture, policy enforcement and incident response oversight, reporting to senior leadership.
• Information Security Management System. A documented ISMS covering acceptable use, access control, cryptography, physical and environmental security, operations and communications security, supplier relationships, incident management and business continuity. Policies are reviewed at least annually.
• Risk assessment. Annual enterprise-wide risk assessment and threat modelling, with more frequent review of high-risk areas including customer data handling and platform infrastructure.
• Security committee. A cross-functional committee reviews security metrics, audit findings, emerging threats and policy changes.

Our Information Security Management System is certified to ISO/IEC 27001, and the certificate is available on request. Control design also follows the NIST Cybersecurity Framework, and application-security work follows the OWASP Testing Guide and ASVS. A SOC 2 Type II attestation is in progress. Section 17 sets out what we can put in front of a procurement team.

3. Tenancy and data separation

• Per-customer tenants. Each customer's assets, findings, evidence, workflow history and audit records live in that customer's own tenant. Users authenticate into their own organisation's tenant and see only what that tenant contains.
• Attribution gates what a tenant contains. A tenant surfaces material correlated to that customer's identities and assets. The platform is not a searchable index over our collection corpora, and no customer can query it for another organisation's exposure or for an arbitrary individual.
• Role-based access inside the tenant. Fine-grained roles decide who sees what. A vendor manager can be scoped to vendor findings alone while the security team retains full access.
• Private deployment where separation must be physical. Customers who cannot accept a shared environment can be provisioned as a customer-specific private-cloud deployment. Arrangements are confirmed during onboarding and recorded in the order form.
• Internal access is not open. Our own personnel do not have standing access to customer tenants; access is role-based, least-privilege, logged and reviewed (Section 4).

4. Access control

• Least privilege by default. Role-based access control across production systems and internal tooling, granted for a defined purpose rather than by seniority.
• Multi-factor authentication is mandatory for all production systems and for any access to customer personal data. Hardware security keys (FIDO2 / WebAuthn) are supported for privileged access.
• Privileged access is restricted to a limited set of authorised personnel, logged, and reviewed.
• Access reviews are conducted on a defined cycle, and access is revoked within one business day of a person leaving or changing role.
• Customer-side authentication. SAML and OIDC single sign-on, group-claim mapping, session management and per-user audit trails are available so that your identity provider — not ours — remains the source of truth for who your users are.

5. Encryption and key management

• At rest. AES-256 or equivalent industry-standard cryptography for stored data, including database volumes, object storage and backups.
• In transit. TLS 1.2 or higher with strong cipher suites, HSTS, and deprecated protocols disabled. Certificate pinning is applied where applicable.
• Key management. Hardware security modules or cloud KMS equivalents, with rotation per industry standards.
• Credentials. Authentication secrets are stored hashed with an appropriate work factor. Plaintext credentials are never stored.

6. Hosting and data residency

We operate from Tier-3 or better colocation facilities. Those facilities hold their own ISO/IEC 27001 and/or SOC 2 audits — that is the facility operator's certification, describing the building, not ours. Operator names and facility details are disclosed under non-disclosure on request; colocation operators provide physical hosting and environmental security only and do not process customer personal data.

Regions currently available are Mumbai, Paris, Singapore and Dubai, with further regions on request. Where a customer elects data localisation we configure storage and backup locations accordingly, backups can be region-locked to the customer's elected region, and a customer-specific private-cloud deployment is available where region selection is not sufficient. Deployment and residency arrangements are confirmed during onboarding and recorded in the order form. See the DPDP page for the Indian localisation position and the GDPR page for cross-border transfer mechanisms.

7. How we behave against your estate

Most security pages describe how a vendor protects its own systems. For a platform that actively probes your infrastructure, how it behaves toward you matters just as much.

• Discovery is outside-in. No agent, no credentials into your environment, no network access. An evaluation starts from an apex domain, which is also why it can start without a change on your side.
• Scope is authorised, and it is yours. Monitoring runs against the scope established through your agreement, the licence terms, onboarding and the associated scope configuration and approvals. You can add, exclude or withdraw identifiers at any time.
• Validation is introduced gradually, not at go-live. Discovery and enumeration run first to build and validate the external inventory. Adversarial validation is then enabled progressively and under monitoring.
• Payloads are non-destructive. Validation logic is purpose-built per capability rather than run from generic public exploit code, automated check layers govern the process, and targeting is bounded to discovered and attributed inventory.
• Fragile systems get accommodated. Exclusions, rate limits and a non-intrusive scan depth are available and we will apply them where you ask.
• Vendor monitoring is outside-in only. Third-party exposure is assessed from publicly observable information using the same methodology. It requires no vendor cooperation and involves no access to vendor systems.
• Takedowns pass a human gate. Every takedown request is reviewed and approved by a person before dispatch, with per-provider rate limiting so that abuse desks are not flooded and liveness checking so that dead targets are not re-notified.

8. Handling exposure and credential data

ShadowMap holds material that would be dangerous in the wrong hands: recovered credentials, session cookies and tokens, leaked secrets and keys, and device-level infostealer artefacts. How we treat it:

• Credentials are surfaced for revocation, never for use. An exposed credential is treated as compromised regardless of how briefly it was public, and the recommended action is always rotate or revoke. We test credentials only against a customer's own authorised in-scope estate, never against a third party.
• Compromise is presented as a case, not a spreadsheet. Artefacts belonging to one infected machine are assembled into a single coherent compromise case, which is what lets a security team separate a stale personal password from a live session against a corporate cloud tenant.
• Access is controlled and logged. This material sits under the same role-based access control and access logging as everything else, and every disposition decision taken on a finding is recorded in the audit log.
• No transmission to third-party model providers. ShadowMap's AI features do not send customer personal data to third-party large language model providers. That is a contractual commitment in our Data Processing Agreement.
• Automated triage does not destroy evidence. Findings filtered by automated review move to a filtered queue rather than being deleted. They stay visible, searchable and auditable with their verdict attached, and an analyst can return anything to the working workflow at any time.

9. Logging, monitoring and audit

• Centralised logging of access to customer personal data, with security monitoring and alerting including for anomalous access patterns.
• Log retention sufficient to meet statutory and regulatory requirements.
• In-product activity logs and audit logs are available to customers, alongside SLA-compliance records, accepted-risk records and the decision trail behind every disposition — the evidence auditors ask for when they want proof that a control actually operated.
• Dated scan windows and session identifiers, so a monitoring activity can be evidenced by scope, date and result.

10. Secure development

• A documented secure software development lifecycle governs ShadowMap and our internal tooling.
• Threat modelling during design for new capabilities.
• Mandatory peer code review before merge, with security-focused review for authentication, authorisation and data-handling code, and security testing of changes affecting personal data.
• Automated static analysis and dependency vulnerability scanning in the build pipeline.
• Dynamic application security testing against staging and production environments.

11. Vulnerability management

• External testing. An external penetration test of our own infrastructure is conducted annually.
• Internal testing. Our own assessment teams test the platform with the same rigour they apply to customer engagements — the practical benefit of the platform being built inside an offensive-security firm.
• Patching. Operating systems and applications are patched to a defined SLA: critical patches within 72 hours of release, high-severity within 7 days, with compliance tracked and reported.
• Endpoint and network controls. Endpoint detection and response on workstations and servers, segmented networks, firewalling with strict ingress and egress rules, and intrusion detection.

12. Incident response

• A documented incident and personal-data-breach response procedure covering detection, containment, eradication, recovery and notification, tested and reviewed at least annually.
• 24x7 incident response capability.
• Affected customers are notified within 72 hours of our becoming aware of a personal data breach, with the nature of the breach, the categories and approximate number of records affected, likely consequences, measures taken, and a contact point. Where information is not all available at once, it follows in phases without further delay.
• CERT-In mandatory incident reporting under Indian law is complied with separately, including the six-hour window in the directive of 28 April 2022 where an incident falls within its scope.
• Every incident is followed by a blameless post-mortem, and the findings feed back into policy, detection and training.

13. Backups and continuity

• Encrypted backups stored in geographically separated facilities, region-locked to the customer's elected region where localisation has been chosen.
• Documented business continuity and disaster recovery plans, tested at least annually.
• Redundant infrastructure, with recovery objectives for your deployment recorded in your order form or service-level schedule.

14. Personnel security

• Background verification for all roles with access to customer data, prior to onboarding.
• Mandatory data-protection and information-security training at onboarding and annually thereafter, plus periodic phishing simulation.
• Written confidentiality undertakings binding all personnel, contractors and authorised testers.
• Specialised handling training for anyone working with credential and exposure material.
• Access revoked within one business day of departure or role change.

15. Sub-processors and supply chain

Our sub-processors are named in Annex C of the Data Processing Agreement and reproduced on our privacy page: Cloudflare, Amazon Web Services, SendGrid, Mailtrap, Twilio, Exotel, Microsoft and Google. Each is bound by written data-protection obligations no less protective than our own, and each is reviewed annually.

We give at least thirty days' notice before adding or replacing a sub-processor, and customers may object on reasonable data-protection grounds. Deliberately not sub-processors: our source control, error tracking, internal audit management and CRM run self-hosted on our own infrastructure; large language model providers, because customer personal data is not transmitted to them; colocation operators, which provide physical hosting only; and background-check vendors, which process our own personnel data.

16. Retention and destruction

• Customer tenant data is retained for the subscription term. On termination or expiry, destruction completes within thirty days for live production systems and copies, and within ninety days for backup and archival systems.
• Customer-supplied personal data can be returned in a machine-readable format before destruction if you elect that in writing before termination or within thirty days after.
• Data retained under a statutory or regulatory obligation is kept for the shorter of the required period and seven years.
• Dark-web and stealer-log source material is retained on a permanent basis as a research corpus held outside customer tenants, so that historical material can be reprocessed against new identifiers. This is what makes a compromise that predates a customer relationship visible at all.
• Digital destruction follows standards consistent with NIST SP 800-88 (Guidelines for Media Sanitization), and written certification is provided on request.

17. Assurance and documentation

What we can put in front of a procurement or risk team without a call:

• Our Data Processing Agreement, published in full, including Annex B (technical and organisational measures) and Annex C (sub-processors). We also accept customer-provided DPAs.
• The EU Standard Contractual Clauses and the UK International Data Transfer Addendum, incorporated by reference into that DPA.
• Audit rights under the DPA, including on-site inspection where documentation is not sufficient, and additional inspection rights following a personal data breach.
• Completed security questionnaires, architecture and residency detail, and colocation operator names under non-disclosure, on request from security@shadowmap.com.
• Our ISO/IEC 27001 certificate, on request. A SOC 2 Type II attestation is in progress; we will not quote a completion date for it until there is one to quote.
• Certification of destruction on offboarding, on request.

Separately, ShadowMap output is frequently used the other way round — as evidence in a customer's own ISO 27001, SOC 2 or regulator-facing programme: asset-inventory currency, external vulnerability identification, monitoring cadence, incident workflow and remediation timelines, each with a dated record behind it.

18. Reporting a vulnerability

If you believe you have found a vulnerability in ShadowMap, in shadowmap.com, or in anything else we operate, we want to hear about it before anyone else does.

Security team
Email: security@shadowmap.com
We acknowledge receipt within one business day.

Please include enough detail to reproduce the issue, and give us reasonable time to remediate before publishing. We will not pursue legal action against researchers who report in good faith, act within the scope of their own testing, avoid privacy violations and service disruption, and do not access, modify or exfiltrate data belonging to others.

For data protection questions rather than security reports, contact dpo@securitybrigade.com. For contractual questions, legal@securitybrigade.com.