Module terms

Effective date: 9 November 2026. Last updated: 9 November 2026.

1. About these Module Terms

1.1 What these Module Terms are

SwiftSafe is headquartered in India as SwiftSafe Cybersecurity Technologies India Pvt Ltd, a private limited company incorporated under the Companies Act, 2013, and has a United States office, SwiftSafe LLC, a Wyoming limited liability company. Your Order Form names your contracting entity, as determined under the Terms. "SwiftSafe", "we", "us" and "our" mean that entity, and these Module Terms apply to whichever entity you contract with. These Module Terms contain the service-specific terms for each capability Module of the Prava AI Platform. Capitalised terms have the meaning given in the Terms of Service (the "Terms"). "You" means the Customer.

1.2 They add to the Terms

These Module Terms add to the Terms and do not replace them. The Terms, including their provisions on fees, confidentiality, warranties, indemnities, limitation of liability, termination, governing law and dispute resolution, apply to every Module. Where these Module Terms say we are not liable for something, that operates alongside the limitations in the Terms and does not enlarge them, and nothing here limits liability that cannot be limited under Applicable Law. The Data Processing Addendum ("DPA"), the AI and Data Use Policy, the Acceptable Use Policy and the Privacy Policy also apply.

1.3 When a Module's terms apply

Section 2 applies whenever you use any Module. Each of sections 3 to 12 applies from the earlier of the date the Module is enabled for your account (by Order Form, plan, trial or self-service setting) and the date it is first used, and continues while it is enabled. Provisions that by their nature should survive, such as confidentiality, retention and authorisation records, survive after it is disabled. Penetration testing (section 6), active OT activity (section 5) and incident response (section 10) also need a separate signed authorisation, safety plan or engagement letter. Enabling the Module alone does not authorise that work.

1.4 Order of precedence

If documents conflict, the first in this list prevails to the extent of the conflict:

• (a) an Order Form, statement of work, penetration testing authorisation letter or incident response engagement letter signed by both parties, for the engagement it covers and only where it expressly overrides a named provision;
• (b) the DPA, for the processing of Personal Data;
• (c) these Module Terms, for the Module concerned;
• (d) the Terms; and
• (e) our other policies and product documentation.

Rules of engagement and OT safety plans are operational documents. They sit under the relevant authorisation or Order Form and cannot widen its scope unless signed by someone with authority to authorise it. We may update these Module Terms as described in the Terms, but changes do not apply to an authorised engagement already in progress unless Applicable Law requires it.

2. Terms common to all Modules

2.1 Deployment

Deployment may involve installing the Agent, connecting the Platform to cloud accounts, email tenants, identity providers and log sources, placing network sensors, or agreeing scope documents. You must give us accurate information about the assets you own or control, make sure each connection, credential and installation is made by someone with authority, meet the prerequisites in our documentation and, where the environment is critical, pilot deployment first. We may verify that you control a domain, IP range, account or tenant, and may decline to enable a Module where we cannot.

2.2 Customer configuration

You decide which assets are monitored, which data sources are connected, which detections and thresholds apply, who is alerted and, within the options we offer, how long data is kept. Defaults are a starting point, not a recommendation that they suit your environment, risk appetite or legal obligations. You are responsible for your configuration. We are not responsible for consequences of configuration that departs from our documentation, disables recommended safeguards or grants more access than a Module needs.

2.3 Autonomous actions

Several Modules can act without a person approving each step, for example by isolating a host, killing a process, quarantining a file or email, revoking a session, blocking a domain or changing a configuration ("Autonomous Actions").

• You choose the level of autonomy: off, recommend only, approval required or automatic. By enabling automatic actions, you authorise us and the Platform to take them on your systems on your behalf.
• Actions can disrupt operations. A correct action can interrupt legitimate work, and detections can be false positives. Set safety-critical and production-critical assets to approval-only or exclude them.
• Audit and reversal. Every action is logged and, where technically possible, reversible. Some, such as terminating a process, cannot be undone.
• Responsibility. We are responsible for the Platform acting in line with your configuration and our documentation. Subject to the Terms, we are not responsible for the business impact of an action taken in line with your configuration, even if the detection was a false positive, unless caused by our breach, negligence or a defect in the Platform.

2.4 Notices to monitored individuals

Most Modules process Personal Data about your employees, contractors, customers and others whose devices, accounts, messages or activity are monitored. For that Customer Data you are generally the Data Fiduciary (or controller) and we are your Data Processor, as set out in the DPA. You are responsible for:

• having a lawful basis for each Module under Applicable Law, including the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 (together, "DPDP") and, where they apply, the EU or UK GDPR and US state laws such as the CCPA/CPRA;
• giving clear, specific notices, including workplace-monitoring notices, explaining what is monitored, why, by whom (including SwiftSafe as processor), for how long, and how individuals can exercise their rights;
• obtaining and recording any consent the law requires, so that it is free, specific, informed, unconditional and unambiguous;
• complying with employment law and any works-council or collective-agreement requirements; and
• handling requests to withdraw consent, to access, correct or erase data, to nominate someone to act for the individual, or to redress a grievance. We will help as described in the DPA.

Individuals keep all their statutory rights, and nothing obtained for Prava AI may suggest they are waived. If someone withdraws consent, you may need to stop monitoring them and some features may stop working for them. Withdrawal does not affect processing that was lawful before it. Template notice wording we provide is not legal advice.

2.5 Real-time processing, data use and data residency

By enabling a Module, you agree that we will process Customer Data and Telemetry in real time and on a continuing basis to deliver it, and that we will collect usage analytics. As set out in the Terms and the AI and Data Use Policy, we use Service Data to operate, secure, improve and develop Prava AI, including to train, fine-tune and evaluate our models, de-identifying, pseudonymising or aggregating it where reasonably possible. Security artefacts such as IoCs, malicious URLs and domains, attack patterns and threat-actor infrastructure cannot always be fully anonymised and may be used across our customer base for collective defence, subject to the residency commitment below. We never disclose your Confidential Information, or Personal Data in identifiable form, to other customers. Enterprise customers may agree further restrictions in an Order Form or the DPA, such as opting out of model training on their content.

Data residency. We store and process each Customer's data only in data centres located in that Customer's own region. This covers Customer Data, Telemetry, Personal Data and the module-specific data described below, including forensic evidence, email content, testing evidence and malware samples tied to you. Your region is set at onboarding or in your Order Form and changes only by written agreement. The only data that may leave your region is non-personal security artefacts, such as IoCs, file hashes, signatures and detection rules, once stripped of Personal Data and your Confidential Information, so that they can be shared across regions for collective defence. Our sub-processors are listed at [Sub-processor list], and any that handle your data do so within your region.

Where they apply to us, we keep logs of our own systems as the CERT-In Directions of 28 April 2022 under section 70B of the Information Technology Act, 2000 require, including retaining them within India for a rolling 180 days and synchronising with the specified time sources. Your own obligations under those Directions remain yours, though several Modules can help you meet them.

2.6 Service levels and support

• Pro: standard support during [Pro support hours]; first-response target [Pro first-response target]; monthly availability target [Pro availability target %].
• Max: priority support with a 24x7 line for critical issues and guided onboarding; first-response targets [Max critical first-response target] (critical) and [Max standard first-response target] (other); monthly availability target [Max availability target %].
• Ultra Max: a dedicated team and a service level agreement tailored in the Order Form, including any service credits.

Availability is measured on the Platform console and APIs and excludes maintenance notified [Maintenance notice period] in advance, emergency security maintenance, and causes within your control or beyond our reasonable control. Service credits, where offered, are your sole financial remedy for a missed availability target but do not affect termination rights for material breach. Service levels concern Platform availability and support responsiveness, not detecting or containing any particular threat within any particular time. Contact soc@prava.dev for incidents, hello@prava.dev for general enquiries, and security@prava.dev to report a vulnerability in Prava AI (see the Responsible Disclosure Policy).

2.7 Third-party systems, Outputs and no guarantee

You must make sure that connecting Prava AI to third-party systems, and the actions it takes through them, are permitted under your agreements with their providers. We are not responsible for third-party systems or their API changes, though we will make reasonable efforts to maintain supported integrations. Outputs are probabilistic and may be wrong, so apply human review proportionate to the consequences (see section 12). No security product prevents every attack, and we do not warrant that any Module will detect or prevent every threat.

2.8 Disabling a Module

You may disable a Module at any time, subject to any minimum term in an Order Form. We then stop collecting new data for it, and its Customer Data is returned or deleted as set out in the Terms, the DPA and its "Retention" subsection. You must remove Agents, sensors, connectors and credentials from your environment, and we will give reasonable instructions.

3. Endpoint protection

3.1 What the Module does

The Agent, installed on your laptops, desktops, servers and virtual machines, collects process, file, registry, network and system telemetry. The Platform analyses it to detect malicious behaviour, reconstructs forensic timelines and, where you allow it, takes containment actions: isolating a host, killing a process or quarantining a file. An isolated host keeps sending Telemetry so investigation can continue.

3.2 Data processed

• Device information: hostname, operating system, hardware identifiers, installed software, patch level and logged-in accounts.
• Process telemetry: names, command lines (which can include paths and user-typed arguments), parent-child relationships, hashes and signatures.
• File events and metadata, and copies of files suspected to be malicious.
• Network telemetry: IP addresses, ports, domains and connection volumes, but not the content of encrypted traffic.
• Registry, persistence and security-log events, user names and authentication events, and Agent health data.

File names, command lines and domains can reveal personal information about users. The Agent is not designed to capture keystrokes, screens, camera or microphone input, or personal documents except files collected as suspected malware. All endpoint data is stored and processed in your region.

3.3 Customer responsibilities

Agent licence. Subject to the Terms and payment of fees, we grant you a non-exclusive, non-transferable, non-sublicensable licence, for your subscription term, to install and run the Agent in object-code form on the number of devices your plan or Order Form allows, solely to receive the Modules that use it for your internal business purposes. You must not modify, decompile or reverse engineer the Agent or bypass its tamper protection, except as Applicable Law expressly permits despite this restriction. The Agent is licensed, not sold.

Installation on devices you control. Install the Agent only on devices you own, lease or lawfully control, or whose owner has authorised you in writing, and keep an inventory of protected devices.

BYOD caution. On personally owned devices the Agent may capture information about the owner's private life, so extra risk arises. If you install it on such a device, you must do so only under a written BYOD policy the owner has accepted and where the law permits; give the owner a specific notice of what is collected and what actions may be taken, and obtain any required consent; use the narrowest effective configuration (for example, a work profile only, or no file collection); and remove the Agent when the device is no longer used for work. We recommend managed corporate devices and are not responsible for BYOD deployments that do not meet these conditions.

Containment and uninstallation. Set exclusions and approval requirements where containment would be unacceptable, and allow-list legitimate tools that behave like malware. Keep uninstall tokens secure. Uninstall the Agent from all devices within [Agent removal period] days after the Module ends. Keep operating systems patched and maintain your own backups.

3.4 Our responsibilities

• Provide and maintain the Agent, test updates before release, and design it for low overhead, allowing staged rollout of non-critical updates.
• Provide tamper protection that resists unauthorised attempts, including by malware or local administrators, to stop, remove or modify the Agent, together with an authorised uninstall method through the console or an uninstall token.
• Encrypt Agent communications and stored Telemetry, and make containment actions auditable and, where possible, reversible.
• Tell you promptly about any Agent defect likely to affect stability or security, with a fix or workaround.

3.5 Authorisation and consent

By deploying the Agent, you confirm you have authority to install it on each device and to authorise the containment actions you configure, and that the notices and consents required by section 2.4 are in place before installation.

3.6 Limitations

• Containment carries a risk of disruption. Isolating a server, domain controller or point-of-sale terminal can interrupt services; killing a process can lose unsaved work; quarantining a falsely detected file can break applications.
• The Agent cannot see threats below the operating system, on unsupported platforms, or where it is disabled or absent, and may conflict with other low-level software.
• Offline devices receive containment instructions only on reconnection.
• The Module must not be the only safeguard for devices whose failure could cause death, injury or environmental harm.

3.7 Retention

Unless your Order Form says otherwise, raw Telemetry is retained for [Endpoint telemetry retention period], alerts and timelines for [Endpoint alert retention period], and collected files for [Collected file retention period], all in your region. Only hashes, IoCs and signatures derived from malicious files, stripped of Personal Data and your Confidential Information, may be kept longer and shared across regions.

4. Application, server and cloud monitoring

4.1 What the Module does

This Module monitors web applications, APIs, servers and cloud accounts (such as AWS, Azure and Google Cloud). It ingests logs, runtime telemetry, API traffic and configuration, assesses security posture, and detects misconfigurations, exposed resources, risky permissions and attacks. Where you enable it, it remediates, for example by revoking a key or restricting a security group.

4.2 Data processed

• Cloud configuration and inventory, including network, storage, encryption and identity and access management (IAM) settings.
• Cloud audit logs: control-plane API calls, sign-ins and resource changes.
• Application and server logs, which may include IP addresses, user identifiers, URLs and other Personal Data.
• API traffic metadata and, if you enable deeper inspection, request and response content.
• Runtime telemetry, credentials you provide, and posture findings.

Configure your systems so that passwords, card data and secrets not needed for security are not sent. Masking options exist, but you remain responsible for what your systems send. All this data, including stored credentials, stays in your region.

4.3 Customer responsibilities

Read-only versus write credentials. The Module runs read-only by default: it can read configuration, logs and metadata and recommend fixes, but cannot change anything. Write mode lets the Platform make specified changes, such as revoking keys, modifying security groups or disabling compromised users. It is optional, must be enabled by an administrator per account or resource group, and its changes are Autonomous Actions unless you require approval. A mistaken change can cause outages or loss of access, so enable write mode only where automatic remediation is acceptable.

Least-privilege API keys. Grant only the permissions your features need, using our published role definitions; use dedicated roles or service accounts, not personal or administrator credentials; prefer short-lived credentials or federated identity to static keys; scope credentials to in-scope resources; rotate them regularly and immediately on suspected compromise; and revoke them when the Module is disabled.

You must also connect only assets you own or control, confirm monitoring is permitted under your provider agreements, act on findings, and apply change control to write-mode remediations.

4.4 Our responsibilities

Shared responsibility model. Your cloud provider is responsible for security of its cloud (facilities, hardware, hypervisors and managed services). You are responsible for security in the cloud (accounts, identities, data, configurations, applications and decisions on findings). We are responsible for the security of the Prava AI Platform and the credentials and data you give us. This Module helps you manage your share; it does not transfer it to us. We will:

• store credentials encrypted and use them only for the Module, within the permissions granted;
• log every write-mode change for you to review; and
• tell you without undue delay if credentials in our custody are accessed without authorisation.

4.5 Authorisation and consent

By connecting an account or application, you confirm you are authorised to grant that access, and that your privacy notices cover security monitoring of your end users' data by a processor.

4.6 Limitations

• Posture results reflect configuration at the time of each check.
• Detection depends on the logs you connect; gaps, sampling and provider delays limit visibility.
• Remediations may fail, be partly applied or be reversed by your own automation.

4.7 Retention

Unless your Order Form says otherwise, logs and Telemetry are retained for [Log retention period], posture findings for [Posture finding retention period] and write-mode audit logs for [Action audit log retention period], all in your region. If you rely on the Platform to hold logs for 180 days within India under the CERT-In Directions, choose at least 180 days and make sure India is your account's region.

5. IoT and OT device monitoring

5.1 What the Module does

This Module monitors Internet of Things (IoT), operational technology (OT), industrial control and embedded devices. It identifies devices, maps communications, detects anomalous traffic and attack techniques, and flags vulnerable firmware. It works mainly by passively observing traffic through sensors on mirror ports or network taps, and through a lightweight Agent or asset-management integrations where supported.

5.2 Data processed

• Traffic metadata and, where needed, industrial and IoT protocol payloads (for example Modbus, DNP3, BACnet, OPC UA and MQTT), which may reveal process values and commands.
• Device identifiers: MAC and IP addresses, vendor, model, firmware and serial numbers.
• Communication maps, and, where devices relate to individuals (wearables, medical or access-control devices), data identifying those people or their movements.

This data, including packet captures, is stored and processed in your region.

5.3 Customer responsibilities

Safety-critical systems. OT systems often control physical processes where an unexpected change can cause equipment damage, environmental harm, injury or death. Prava AI is a security monitoring tool, not a safety instrumented system, process-control system or medical device, and must not be used as one. You remain solely responsible for the safe design and operation of your processes and safety systems.

No active scanning of OT without a written safety plan. "Active steps" means sending traffic to, querying, scanning, testing, reconfiguring or isolating an OT or safety-relevant IoT device. No active step will be taken unless:

• a written safety plan identifies the systems, activities, timing (normally maintenance windows), expected effects, precautions, rollback and emergency stop procedure, and responsible site personnel;
• a person you have named as responsible for the safety of the affected process has approved it in writing; and
• you have obtained any vendor, integrator or regulatory approvals required.

You also decide sensor placement and coordinate with your OT vendors and site safety staff.

5.4 Our responsibilities

• Passive monitoring by default. Sensors are supplied configured for passive monitoring. The Platform does not send packets to, query or reconfigure OT devices, and Autonomous Actions against them are disabled.
• Take active steps only under an approved safety plan, using personnel with OT experience.
• Stop any active step immediately when your site personnel ask, or when we see a safety risk.

5.5 Authorisation and consent

You confirm you are authorised to monitor the networks and devices in scope, and will obtain permission from the owners of any third-party devices (such as tenants, utilities or vendors with remote-maintenance links) before any active step.

5.6 Limitations

• Physical-process impact. If you authorise active steps under a written safety plan, you accept the risk that they may affect devices or the processes they control, even when carried out carefully. To the extent permitted by Applicable Law, we are not liable for loss, damage or interruption to a physical process caused by active steps you authorised and we performed in line with the plan. This does not exclude liability for our gross negligence or wilful misconduct, for death or personal injury caused by our negligence, or any liability that cannot be excluded by law.
• Passive sensors see only traffic that reaches them; serial links, isolated segments and encrypted traffic may be invisible, and proprietary protocol support may be partial.

5.7 Retention

Unless your Order Form says otherwise, traffic metadata is retained for [OT metadata retention period], packet captures for [OT packet capture retention period], inventories for the subscription, and safety plans and records of active steps for [Safety plan record retention period], all in your region.

6. AI-guided penetration testing and attack-surface discovery

6.1 What the Module does

This Module combines AI-guided reconnaissance and automated testing with testing led by SwiftSafe's security professionals. It discovers reachable infrastructure, applications, APIs, identities and cloud resources, identifies weaknesses, chains them into attack paths, validates exploitability and retests after remediation. Engagements may cover networks, web applications, APIs, cloud and identity and, only where expressly agreed, red-team exercises. Continuous attack-surface discovery finds new or forgotten internet-facing assets linked to you. Without the owner's authorisation these activities would be unauthorised access, so they happen only with your written authorisation and within an agreed scope.

6.2 Data processed

Asset information, test credentials, and evidence such as requests and responses, screenshots and, where exploitation reaches it, samples of data on your systems that may include Personal Data or Confidential Information. We access only what is needed to demonstrate impact and copy no more real data than the minimum evidence requires. Findings, reports and evidence stay in your region, and testers access them within that environment.

6.3 Customer responsibilities

Scope. Define scope precisely (domains, IP ranges, applications, APIs, cloud accounts, network segments, roles and test accounts) and list exclusions. Anything not listed is out of scope. If we find an apparently related asset outside scope, we will tell you and not test it unless you add it in writing. Assets found by continuous discovery, which uses passive sources and light non-intrusive checks, are not actively tested until you confirm ownership and add them.

Rules of engagement and testing windows. Agree rules covering permitted testing types, how far exploitation may go, limits on accessing real data, use of test accounts, our source IP addresses and how critical findings are reported. By default, denial-of-service, social engineering, physical intrusion, production payment testing and destructive actions are excluded. Agree testing windows, which may be limited to off-peak hours or maintenance windows, with blackout periods for continuous testing.

Emergency stop contact. Name a contact reachable throughout every window; we will name ours. Either side may stop all testing immediately through the other's contact. If we cannot reach yours when we believe harm is occurring, we stop until contact is restored.

Preparation. Take and verify backups, inform your security operations team and providers, provide non-production environments where possible, and have staff ready if a system becomes unstable.

6.4 Our responsibilities

• Test only within the agreed scope, windows and rules, with qualified personnel overseeing all automated and AI-guided activity, using the agreed source addresses.
• Stop immediately on request or when we identify a risk of serious harm, and pause if we see instability.
• Protect evidence as your Confidential Information, and remove test artefacts, implants and accounts we created when the engagement ends, or tell you where any remain.
• Reporting and retest. Deliver each validated finding with the affected asset, reproduction steps, evidence, impact, attack path and remediation guidance; notify critical findings promptly during testing; and retest the original attack path after remediation, within the retests and period in your Order Form or continuously for ongoing testing.

Reports are your Confidential Information. You may share them in confidence with auditors, regulators, insurers, customers and advisers, but unless we agree in writing they cannot rely on a report as against us.

6.5 Authorisation and consent

Written authorisation letter. No active testing starts until you sign an authorisation letter (or an Order Form or statement of work with the same content) that confirms you own or may authorise testing of every in-scope asset, sets out the scope and rules of engagement, authorises SwiftSafe, its personnel and the Platform to test, and names an authorised signatory, a technical contact and the emergency stop contact.

Third-party and cloud provider permissions. For assets owned or operated by third parties (group companies, clients, managed service providers or SaaS vendors), you must give us their written authorisation or written confirmation that your contract permits testing. Cloud providers, CDNs and hosts have their own testing policies, which may allow some testing freely, require notice or approval for other testing, and prohibit some activities. You must check each relevant provider's current policy, obtain any approval or give any notice it requires, and tell us its restrictions. We will not knowingly test a provider's shared infrastructure beyond what its policy allows, and are not responsible if a provider acts against your account because of in-scope testing.

Safe harbour. By signing the authorisation letter, you confirm that testing within scope and the rules of engagement is done with your permission as owner or person in charge of the systems, including for the purposes of sections 43 and 66 of the Information Technology Act, 2000 and equivalent laws elsewhere. You agree not to complain to any authority that authorised testing was unauthorised access, and to promptly confirm the authorisation if a third party, provider or authority raises a concern. This does not cover activity outside scope or in breach of the rules. You will indemnify us, under the Terms, against third-party claims arising from your lack of the authority you confirmed.

6.6 Limitations

• Testing may cause outages. Even careful testing within the rules can degrade performance or cause crashes, lockouts, alerts and, rarely, data loss. To the extent permitted by Applicable Law, we are not liable for interruptions, outages or data loss caused by testing within the agreed scope and rules of engagement, except to the extent caused by our negligence, wilful misconduct or breach of those rules.
• A test covers a defined scope over a defined period and will not find every vulnerability. Unvalidated AI hypotheses are labelled as such, and a clean result does not mean your systems are secure.

6.7 Retention

Unless your Order Form says otherwise, findings and reports are retained for the subscription and [Pentest report retention period] after it; raw evidence for [Pentest evidence retention period] after the report; and authorisation letters and rules of engagement for [Authorisation record retention period]. All are held in your region. Generalised attack techniques, stripped of Personal Data and your Confidential Information, may be used for model improvement and collective defence.

7. Threat intelligence and dark-web intelligence

7.1 What the Module does

This Module monitors open, deep and dark-web sources (forums, marketplaces, paste and leak sites, Telegram channels and code repositories) and internet infrastructure such as domain registrations and certificates. It identifies leaked credentials, exposed data, brand abuse, lookalike domains and threat-actor activity, correlates them with your assets, and delivers analyst-reviewed findings with recommended responses.

7.2 Data processed

• Your watchlist: domains, brands, trademarks, executive names, IP ranges and keywords.
• Collected posts, listings and documents relating to your watchlist, with source, date and actor handle.
• Leaked data relating to you: user names, email addresses, passwords or hashes, tokens, documents and database extracts.
• Threat-actor handles, infrastructure, tactics and indicators.

This may include Personal Data already leaked by others and Personal Data about threat actors. Your watchlist, findings and leaked data relating to you are stored and processed only in your region.

7.3 Customer responsibilities

• Limit your watchlist to identifiers you are entitled to monitor, and do not use the Module to track individuals' private activity.
• Act on findings, for example by resetting exposed credentials.
• Decide whether a leak must be reported, for example to the Data Protection Board of India and affected Data Principals under DPDP or to CERT-In within 6 hours (see section 10).
• Keep intelligence confidential and do not redistribute leaked data except as needed to respond.
• For takedowns, authorise us to act for you, confirm you hold the rights asserted, and supply any authority letter or trademark evidence requested.

7.4 Our responsibilities

Passive collection only. We observe and record. We do not buy or pay for stolen data or access; engage, negotiate or communicate with threat actors or take part in crime; pay threat actors or meet extortion demands; hack threat-actor infrastructure or any other system; or use leaked credentials to log in anywhere, unless you authorise in writing a limited check against your own systems. Research accounts on closed sources are used only to observe, in line with Applicable Law.

Leaked personal data. We collect only what is needed to tell you what leaked and help you respond, storing passwords masked, truncated or hashed and keeping samples rather than full datasets where practicable. We notify you through the Platform with the affected accounts, source, date and data types. We do not redistribute, publish or sell leaked data, except as the law requires or to a recipient you name in writing. Data about other organisations found incidentally is not given to you; we may notify the affected organisation or an authority where appropriate and lawful.

Takedown assistance. Where your plan includes it, we prepare and submit evidence-based removal requests for phishing sites, lookalike domains, fake profiles and leaked content to registrars, hosts and platforms, including notices under the Information Technology (Intermediary Guidelines and Digital Media Ethics Code) Rules, 2021 where they apply. Court orders and domain disputes need your own counsel, though we can supply evidence.

Legal requests. For authority requests concerning your Customer Data, including under sections 69, 69B and 70B of the Information Technology Act, 2000, we check validity, disclose only what the law requires and notify you unless prohibited. We may share non-personal intelligence that does not identify you, such as actor infrastructure and IoCs, with CERT-In, law enforcement and industry sharing bodies.

7.5 Authorisation and consent

If your watchlist names individuals, such as executives monitored for impersonation, you must inform them and obtain any consent the law requires.

7.6 Limitations

• We cannot monitor every source; criminal communities are often closed or short-lived.
• Actor claims are often false. A listing does not prove a breach, and no finding does not prove there was none. Attribution is an assessment with a stated confidence.
• We may not disclose how intelligence was obtained, to protect analysts and sources, and cannot guarantee any takedown.

7.7 Retention

Unless your Order Form says otherwise, findings are retained in your region for [Threat intelligence finding retention period]. Leaked Personal Data is kept in minimised form for [Leaked data retention period], or less on request unless an investigation needs it. Non-personal actor infrastructure and IoCs that do not identify you may be kept longer and shared across regions.

8. Phishing defence

8.1 What the Module does

This Module analyses inbound, outbound and internal email and, where integrated, collaboration messages. It assesses content, intent, sender identity, headers, authentication results, links, landing pages and attachments to detect phishing, business email compromise, invoice fraud, impersonation and malicious payloads, and can flag, banner, quarantine or remove messages. It also handles user-reported phishing and, if enabled, simulated phishing campaigns.

8.2 Data processed

• Message content: subjects, bodies, images and attachments.
• Metadata: addresses, display names, headers, routing, timestamps and SPF, DKIM and DMARC results.
• Linked pages and attachment behaviour observed in controlled environments.
• Directory and correspondence patterns, phishing reports, release requests and simulation interactions.

Messages may contain sensitive Personal Data, privileged communications and personal correspondence. Content is processed automatically. Analysts view it only to investigate a detection, resolve a false-positive dispute, handle a report or support request, or as you instruct, and that access is logged. Email content, attachments and quarantined messages stay in your region, including during detonation.

8.3 Customer responsibilities

Mailbox access scopes. The Module connects through APIs, journaling or mail-flow connectors. Permissions may include reading messages in all or selected mailboxes, moving or deleting messages, adding banners and reading the directory. Grant only what your features need, using our published permission sets; exclude mailboxes that law, privilege or policy require you to exclude; and revoke access when the Module is disabled.

Quarantine and false positives. Quarantine is an Autonomous Action. Legitimate, time-sensitive messages such as payment instructions or legal notices may be held, and malicious ones may get through. Decide who can release messages, review quarantine regularly, use allow-lists carefully and keep your own payment-verification procedures.

Simulated phishing campaigns. Because simulations deceive users, each campaign must be authorised by someone in your organisation with authority to approve it, involving HR, legal or employee representatives where required. Your workforce must have been told in general terms that simulations may occur. Campaigns may go only to your own personnel, must not unlawfully impersonate real third parties or cause real distress (such as false messages about bereavement, health or layoffs), and any disciplinary use of results must be fair and lawful.

8.4 Our responsibilities

• Process message content only to deliver the Module, investigate and support you, and as described in section 2.5.
• Analyse links and attachments in isolated environments, and provide tools to review, release and audit quarantine.
• User-reported phishing. Assess reported messages, including their content and the reporter's identity, and remove matching messages across your organisation. Reported messages stay in your region and are never disclosed to other customers; only derived URLs, domains, hashes, sender infrastructure and patterns, stripped of Personal Data and your Confidential Information, are used for collective defence.
• Design simulation landing pages to record a submission without storing passwords entered.

8.5 Authorisation and consent

You confirm you are authorised to grant access to, and have content processed from, every mailbox in scope, that the notices in section 2.4 tell users their messages are analysed automatically, and that each simulation is authorised as section 8.3 requires. For privileged or regulated mailboxes, you decide whether to include them.

8.6 Limitations

• We are not liable for losses caused by a message being quarantined or delayed in line with your configuration, or by a malicious message being delivered, except to the extent caused by our breach of the Terms or our negligence.
• Messages from genuinely compromised trusted accounts, and content that behaves differently under analysis, may evade detection. Only connected channels are analysed.

8.7 Retention

Unless your Order Form says otherwise, metadata and verdicts are retained for [Email metadata retention period]; content only of quarantined, reported or investigated messages for [Email content retention period]; unreleased quarantine for [Quarantine retention period]; and simulation results for [Simulation result retention period], all in your region. Non-personal artefacts such as malicious URLs, domains and hashes may be kept longer and shared across regions.

9. Malware analysis and reverse engineering

9.1 What the Module does

This Module analyses suspicious files submitted by you or captured by other Modules. Static analysis examines structure, strings, imports and packing; dynamic analysis detonates the sample in an isolated, instrumented sandbox and records its behaviour. Results are mapped to attacker techniques and turned into IoCs, YARA and Sigma rules and signatures. Where your plan includes it, SwiftSafe analysts perform manual reverse engineering.

9.2 Data processed

Samples (executables, scripts, documents, archives and memory extracts), the context you provide, and analysis results such as behavioural reports, sandbox network captures, indicators and rules. Samples may contain Personal Data or Confidential Information, such as a real invoice used as a lure, so remove it before submission where practicable. Samples tied to you are stored, detonated and analysed only in your region and are not transferred out of it.

9.3 Customer responsibilities

Sample submission warranties. When you submit a sample, you warrant that you obtained it lawfully and may submit it; that you submit it for genuine security purposes, not to develop malware or evade controls; that submission breaches no confidentiality obligation, licence or law binding on you (or, for third-party software, that you rely on a lawful exception in section 9.5); and that you have minimised Personal Data and Confidential Information in it where practicable.

Handle downloaded samples only in isolated environments with trained staff, test generated rules before deployment (section 12.3), and tell us before submitting a sample linked to a sensitive investigation, because detonation may alert the attacker.

9.4 Our responsibilities

• Sandbox handling. Store and detonate samples only in isolated environments designed to protect you, our systems and third parties; encrypt samples at rest and limit access to authorised personnel; and route any sandbox internet access through monitored infrastructure designed to prevent attacks on others, or run with no internet access on request.
• Sharing IoCs and signatures for collective defence. Hashes, IoCs, behavioural patterns and YARA and Sigma rules derived from analysis, stripped of Personal Data and your Confidential Information, may be used across our customer base and regions, in our models, and in intelligence shared with CERT-In, industry sharing bodies, vendors and researchers. We will not share artefacts from samples you mark confidential in a way that identifies you.
• No redistribution of live malware. We do not distribute live malware tied to you except as the law requires or you instruct in writing. Authorised users can download samples from the Platform only in password-protected or neutralised form, with warnings.

9.5 Authorisation and consent

Lawful reverse engineering. We reverse engineer code, and you may instruct it, only for lawful purposes: understanding, detecting and defending against threats, and achieving the interoperability and security of systems.

• Section 52(1)(ab) and (ac) of the Copyright Act, 1957 allow a lawful possessor of a computer program to do what is necessary to obtain information essential for interoperability with an independently created program, and to observe, study or test the program's functioning to determine its underlying ideas and principles. For third-party software rather than malware, we rely on these and other available exceptions and on your confirmation that you lawfully possess it.
• Analysis is done with the authorisation of the owner of the systems where samples were found, in isolated environments we control, so that it is not unauthorised access or damage under sections 43 and 66 of the Information Technology Act, 2000, or tampering with source documents under section 65.
• Where a licence restricts reverse engineering, you must confirm analysis is permitted under the licence or a statutory exception it cannot override.

You must not use any sample, report or rule to create, modify, distribute or deploy malware, or for any purpose the Acceptable Use Policy prohibits.

9.6 Limitations

• Sophisticated malware may detect the sandbox and hide its behaviour. A "benign" verdict means only that no malicious behaviour was observed.
• Family classification and attribution are assessments, and generated rules may produce false positives or negatives.

9.7 Retention

Unless your Order Form says otherwise, reports and rules are retained for the subscription and samples in your region for [Malware sample retention period], after which samples not confirmed malicious are deleted. Samples containing your Confidential Information can be deleted on request, subject to legal hold. Hashes, IoCs and signatures from confirmed malware, stripped of Personal Data and your Confidential Information, may be kept indefinitely and shared across regions.

10. Digital forensics and incident response

10.1 What the Module does

The DFIR Module combines the Platform with SwiftSafe's human responders: evidence collection from disks, memory, logs and cloud environments, chain of custody, root-cause analysis, containment and recovery support, and incident reporting support. It is delivered under a retainer with agreed response times or as an emergency engagement.

10.2 Data processed

Forensic images, memory captures, mailboxes, logs and cloud artefacts, which may contain anything on the affected systems, including sensitive Personal Data and Confidential Information, plus interview notes, attacker tools and our reports. Where practicable we will agree targeted collection, filtering or exclusions to limit the Personal Data reviewed.

Evidence storage. All forensic evidence, including disk images, memory captures, log extracts, cloud artefacts and any devices or media you ship to us, is stored and processed only in data centres or secure facilities in your region. Responders based elsewhere access it only within that environment and do not copy it out of your region.

10.3 Customer responsibilities

Engagement activation. Work starts when an authorised contact activates a retainer through the 24x7 incident hotline on [24x7 incident hotline number] or at soc@prava.dev; when you sign an emergency engagement letter setting out scope, rates and authorisations (subject to responder availability); or when your counsel engages us (section 10.5). Keep your authorised-contact list current, because we verify identity and authority before acting. You must also provide timely access to systems, logs and staff; preserve evidence, including by suspending routine deletion; decide on containment, recovery, notifications and public statements; and notify your insurers.

Regulatory reporting. Reporting obligations are yours. They may include reporting specified incidents to CERT-In within 6 hours of noticing them under the CERT-In Directions of 28 April 2022; intimating a personal data breach to the Data Protection Board of India and affected Data Principals under DPDP, with the detailed report within the period the DPDP Rules, 2025 set; reporting to the Reserve Bank of India, the Securities and Exchange Board of India, the Insurance Regulatory and Development Authority of India or other sector regulators within their timelines; and notifications under the EU or UK GDPR or US state laws where they apply.

10.4 Our responsibilities

• Respond within your retainer's times or, for emergency engagements, as soon as reasonably practicable.
• Evidence acquisition. Use forensically sound methods suited to the circumstances, such as write-blocked imaging, verified memory acquisition and preserved cloud logs, and hash evidence on acquisition. Live response can alter some data or interrupt services; we will discuss trade-offs first where practicable.
• Chain of custody. Record who handled evidence, when, where it was stored and what was done, and limit access to authorised personnel. On request, provide documentation supporting admissibility, such as hash records and, where appropriate, a certificate of the kind contemplated by section 63 of the Bharatiya Sakshya Adhiniyam, 2023. Admissibility is for the court or tribunal.
• Regulatory reporting support. Supply timely facts, draft content and technical details for the reports in section 10.3. We will not file a report for you without written instructions. If we have our own legal duty to report, we will tell you where lawful.
• Keep you informed, treat incident information as your Confidential Information, and provide a written report where agreed.

10.5 Authorisation and consent

You authorise us to acquire evidence from the systems and accounts you identify, and confirm you are entitled to do so, including for devices used by your personnel, and that any required notice or consent has been given or is not required in the circumstances. Tell us before collection if a device is personally owned, belongs to a third party or holds privileged material.

Legal privilege. If you ask, your counsel can engage and instruct us so that counsel can advise you on actual or anticipated litigation or regulatory proceedings. We will then mark work product as prepared at counsel's request, direct it as counsel instructs, and keep it separate from routine Platform Outputs. Whether privilege applies is a question of law that we cannot guarantee, and you and your counsel are responsible for structuring the engagement to protect it.

10.6 Limitations

• No guarantee of attribution or recovery. We use professional skill and care, but do not guarantee we will find the root cause, identify or attribute the attacker, recover encrypted, deleted or stolen data, restore systems within a set time, or prevent further attacks. Attribution is an assessment with a stated confidence.
• No ransom negotiation or payment. SwiftSafe does not negotiate with threat actors or make, arrange or facilitate ransom or extortion payments, unless separately agreed in writing for a specific service that is lawful in every relevant jurisdiction, including under sanctions, anti-money-laundering and anti-terrorist-financing laws. Any decision to pay is yours, taken with your own legal advice, insurers and, where relevant, law enforcement. We can supply technical facts to inform it.
• Expert-witness services are charged separately. Expert reports, testimony, hearings and responses to subpoenas or court orders are not included in DFIR fees and are charged at rates agreed in writing, plus expenses.
• Findings may change as evidence emerges, and our work does not replace legal advice.

10.7 Retention

Unless your Order Form or counsel's instructions say otherwise, forensic evidence is retained in your region for [Forensic evidence retention period] after closure, then returned or securely destroyed as you choose, with written confirmation on request. Incident reports and chain-of-custody records are retained in your region for [Incident record retention period]. Evidence subject to a legal hold or investigation is kept until the hold is lifted.

11. Compliance and policy management

11.1 What the Module does

This Module continuously monitors controls, collects audit evidence, helps you write, approve and publish policies, and enforces technical policies through other Modules. It maps controls to frameworks such as ISO/IEC 27001, SOC 2, NIST CSF 2.0, PCI DSS, HIPAA, the GDPR, DPDP, the CERT-In Directions and cybersecurity guidance from the Reserve Bank of India, the Securities and Exchange Board of India and the Insurance Regulatory and Development Authority of India, and produces dashboards, gap analyses, evidence packages and draft policies.

11.2 Data processed

Control-status data from connected systems; evidence such as screenshots, exports, access reviews, training records and vendor assessments, which may include Personal Data about your personnel; policies and risk registers; and records of approvals, acknowledgements and exceptions. All of this is stored and processed in your region.

11.3 Customer responsibilities

You remain responsible. You are responsible for complying with Applicable Law and any framework you adopt, deciding which obligations apply and how to meet them, and checking that evidence is accurate and complete before relying on or sharing it. Generated policies are drafts that you must review, adapt and approve through your own governance. Engage qualified auditors and assessors where certification or attestation is needed.

11.4 Our responsibilities

• Collect and store evidence securely, preserving time-stamps and source records.
• Maintain framework mappings with reasonable care, show when each was last reviewed, and make reasonable efforts to update them as frameworks change.
• Make evidence exportable, and on reasonable request (at your cost) explain to your auditors how the Platform collects it.

11.5 Authorisation and consent

Where evidence or acknowledgements include Personal Data about your personnel, you are responsible for the notices required by section 2.4.

11.6 Limitations

• Prava AI does not certify compliance. It helps you produce evidence and policies; it does not certify, attest to or guarantee compliance, and SwiftSafe is not acting as your auditor, certification body, assessor or legal adviser. A "passing" control or high completion score means only that configured checks or recorded evidence met the Platform's criteria at that time.
• Auditor reliance. Auditors and regulators decide what evidence to accept and may require independent verification. Unless agreed in writing, we owe them no duty of care.
• Framework mappings are guidance. They reflect our interpretation, frameworks change and may be read differently, and we do not warrant that mappings are complete, current or accepted by any auditor or regulator.
• Automated checks only test what connected systems expose; many controls need manual evidence and judgement.

11.7 Retention

Unless your Order Form says otherwise, evidence and control history are retained in your region for the subscription and for [Compliance evidence retention period] afterwards so you can export them. You must keep your own copies for the periods your frameworks and laws require.

12. Prava AI assistant and LLM

12.1 What the Module does

The assistant is a natural-language interface built on our proprietary large language model and other models. It answers questions about your environment, triages alerts, summarises investigations, recommends actions, and generates rules, queries, scripts, configuration, policies and reports. Where you enable it, it can propose or start actions through other Modules.

12.2 Data processed

Prompts and Outputs. "Prompts" are the questions, instructions and files you give the assistant. Prompts and the Customer Data the assistant retrieves are processed in real time to generate Outputs. As between us, and subject to the Terms, you own your Prompts and the Outputs generated for you. Similar Outputs may be generated for others, and you gain no exclusive rights in generic content such as standard rules. Prompts, Outputs and feedback form part of Service Data and may be used to improve and train our models as described in section 2.5 and the AI and Data Use Policy, subject to any restriction in your Order Form or DPA. They are processed only in your region, where inference for your account runs. Do not include secrets, passwords or data you may not share with a processor.

12.3 Customer responsibilities

Human review. A suitably qualified person must review an Output before you rely on it for any significant decision, including decisions about individuals (such as discipline based on an investigation summary), production changes, disclosures to regulators or customers, and closing an incident. Assistant-initiated actions are Autonomous Actions; we recommend requiring approval for production systems.

Generated code, scripts and rules must be tested before deployment. Generated detection rules, scripts, infrastructure-as-code and configuration may contain errors that cause outages, data loss, weaknesses or excessive alerts. Before deploying, review and understand them, test them in a non-production or monitoring-only mode, deploy through your change management, and make sure you can roll back. Check licensing where generated code resembles open-source code.

Do not use the assistant for purposes the Acceptable Use Policy prohibits, including generating malware, attacking systems you may not test, or trying to extract other customers' data or our model weights, training data or system instructions.

12.4 Our responsibilities

• Limit the assistant to your tenant and to the requesting Authorised User's permissions.
• Apply safeguards against harmful or inaccurate Outputs and prompt injection, recognising no safeguard is complete.
• Label Outputs as AI-generated, show sources where practicable, and log assistant-initiated actions.

12.5 Authorisation and consent

Where Prompts or retrieved data include Personal Data, for example during an investigation into an employee's account, your section 2.4 notices must cover AI processing and the human review applied.

12.6 Limitations

• Outputs may be wrong. They are probabilistic and can be inaccurate, incomplete, out of date or invented while sounding confident, and may differ for the same Prompt.
• No reliance for legal advice. Summaries of laws, frameworks or reporting obligations are general information, not legal advice, and create no lawyer-client relationship. Do not rely on the assistant to decide whether, when or how to notify a regulator or individuals, or to assess legal liability.
• To the extent permitted by Applicable Law, we are not liable for deploying generated code, scripts or rules that were not reviewed and tested as section 12.3 requires.
• Content the assistant analyses may contain attacker instructions, so do not let it act automatically on untrusted content without approval.

12.7 Retention

Unless your Order Form says otherwise, conversation history is retained in your region for [Assistant conversation retention period], and you can delete conversations at any time, subject to backups and legal holds. Logs of assistant actions are kept for [Action audit log retention period]. De-identified, pseudonymised or aggregated data may be retained for model improvement under the AI and Data Use Policy.

Questions about these Module Terms: legal@prava.dev. Questions about Personal Data: privacy@prava.dev. Grievances: our Grievance Officer at grievance@prava.dev. All our legal documents, including the Cookie Policy, are in the Legal centre.