Compliance

Capitalised terms have the meaning given in the Terms of Service. "SwiftSafe", "we", "us" and "our" mean the SwiftSafe company you contract with: SwiftSafe LLC for customers in the Americas, and SwiftSafe Cybersecurity Technologies India Pvt Ltd for everyone else. This page is for information. It is not a warranty, a certification or legal advice. Our contractual commitments are in the Terms of Service, the Data Processing Addendum, the Module Terms and your Order Form, which prevail over anything on this page.

1. Our compliance status

1.1 No certifications or attestations are currently held

SwiftSafe does not currently hold any formal certification, attestation, accreditation or independent audit report. This includes ISO/IEC 27001, 27701, 27017, 27018 and 42001 certification, a SOC 2 Type I or Type II report, a PCI DSS Attestation of Compliance, a CSA STAR listing, a HIPAA attestation, CMMC or UK Cyber Essentials certification, and FedRAMP authorisation. No regulator or certification body has approved Prava AI or SwiftSafe.

Where this page names a framework, it means that our controls are designed to align with it or mapped to it, or that the Platform supports customers' compliance with it. It does not mean that anyone has independently assessed us against it. Please do not describe SwiftSafe or Prava AI as certified or attested in your own audit, vendor-risk or regulatory documents.

1.2 Statutory laws and international regulatory adherence

Statutory laws are mandatory. Where data protection, cybersecurity and privacy laws apply, SwiftSafe respects and follows them without fail. This includes the Digital Personal Data Protection Act, 2023 (DPDP Act) and DPDP Rules in India, the General Data Protection Regulation (EU/UK GDPR), US federal and state laws (such as CCPA/CPRA), Canadian PIPEDA, the Australian Privacy Act, Japan's APPI, China's PIPL, and Middle Eastern regulations (such as UAE NESA/DESC and Saudi Arabia's NCA ECC). We process Personal Data strictly in accordance with each applicable law, honouring regional data sovereignty and individual rights as described in section 5 and the Privacy Policy.

1.3 Future certifications

We are working towards independent assessment against selected frameworks, but we do not publish target dates. We will publish any certification or attestation here when it is issued, with its scope, issuing body and period. Until it appears here, assume we do not hold it.

1.4 Security documentation on request

Customers and prospective customers can request the following from legal@prava.dev, under a non-disclosure agreement or the confidentiality terms of your agreement with us:

• summaries of our information security policies, such as access control, encryption, logging, vulnerability management, secure development, business continuity, supplier management and incident response;
• a completed standard security questionnaire, and reasonable answers to your own questionnaire not more than once a year;
• an architecture and data-flow overview, including tenant separation and regional data residency;
• our framework control mappings for the frameworks in section 3; and
• where available, summaries of independent penetration tests of the Platform.

These documents describe our programme when issued. They are not audit reports and carry no independent opinion.

2. Shared responsibility

2.1 What SwiftSafe is responsible for

• Security of the infrastructure, software, Agents and models we operate, including encryption, tenant separation, access control and logging, as set out in section 8 of the Data Processing Addendum.
• Controlling and logging access to Customer Data by our personnel and Sub-processors.
• Keeping your data in your region (section 7).
• Secure development and controlled release of Platform and Agent updates.
• Detecting and responding to incidents affecting the Platform, and notifying you of a Personal Data Breach under the Data Processing Addendum.
• Meeting the legal obligations that apply to SwiftSafe in its own right, including as Data Fiduciary or controller for account, website, billing and analytics data.
• Maintaining Compliance module mappings with reasonable care, under section 11 of the Module Terms.

2.2 What you are responsible for

• Deciding which laws and frameworks apply to you and how to meet them.
• Configuring the Platform, including user access, multi-factor authentication, roles, retention settings and Autonomous Actions, and managing your Authorised Users.
• Deploying Agents only on systems you own or are authorised to monitor, and keeping them up to date.
• Giving notices to, and obtaining any consents from, the employees, contractors and end users you monitor, as described in section 2.4 of the Module Terms.
• Acting on alerts, and having a qualified person review Outputs before relying on them for significant decisions.
• Making the regulatory notifications that fall to you (section 8).
• Reviewing policies, evidence and reports before relying on them, and engaging your own auditors, assessors and legal advisers.

2.3 Using Prava AI does not by itself make you compliant

No product can make an organisation compliant on its own. Compliance depends on your governance, people, processes, suppliers and systems, most of which the Platform does not see. Some controls are shared: for example, we offer multi-factor authentication, but you decide whether to require it. A "passing" control or high score in the Platform means only that the checks you configured, or evidence you recorded, met the Platform's criteria at that time. Auditors and regulators decide for themselves what evidence to accept.

3. Information security frameworks

For each framework below, we explain what it is, how our own controls are designed to align with it, and how the Compliance module supports customers. As explained in section 1, we hold no certification against any of them.

3.1 ISO/IEC 27001:2022

ISO/IEC 27001 is the international standard for an information security management system (ISMS), against which accredited bodies certify organisations. The 2022 edition groups its Annex A controls into four themes: organisational, people, physical and technological. Our security programme is designed to align with it: we maintain security policies, risk assessment and treatment, asset and supplier management, personnel screening and training, physical security requirements for the data centres we use, and technological controls such as access management, encryption, logging, vulnerability management, secure development and backup, mapped to the Annex A themes. We are not certified to ISO/IEC 27001. The Compliance module maps Platform checks and evidence to its clauses and Annex A controls, and tracks your Statement of Applicability, risk register and corrective actions. Your certification body decides whether your ISMS meets the standard.

3.2 ISO/IEC 27701

ISO/IEC 27701 extends an ISMS to privacy, with requirements for personal-data controllers and processors. Our privacy controls are designed to align with it, both as a processor of Customer Data and as controller or Data Fiduciary for our own data: records of processing, purpose limitation, Sub-processor management, data residency, rights-request handling and breach notification. We are not certified to it. The Compliance module can map your privacy controls to ISO/IEC 27701 and to the laws in section 5, and track impact assessments and retention schedules.

3.3 ISO/IEC 27017 and ISO/IEC 27018

ISO/IEC 27017 gives security guidance for cloud services; ISO/IEC 27018 is a code of practice for protecting personal data processed by public-cloud processors. Our controls are designed to align with their cloud-specific guidance, for example a documented split of responsibilities (section 2), tenant separation, administrator activity logging, secure deletion at the end of a subscription, disclosure of Sub-processors and data locations, and no use of Customer Personal Data for our own purposes beyond what the AI and Data Use Policy describes. We are not certified to either standard. The cloud monitoring Module checks the posture of your cloud accounts, and the Compliance module can map those checks to the cloud-customer controls in ISO/IEC 27017.

3.4 SOC 2 (Trust Services Criteria)

SOC 2 is an attestation report by an independent CPA firm, under AICPA standards, on a service organisation's controls relevant to the Trust Services Criteria: security, and optionally availability, processing integrity, confidentiality and privacy. Our controls are designed with the criteria for security, availability and confidentiality in mind, but we do not have a SOC 2 report of either type. For vendor reviews, we can provide our questionnaire response and documentation under NDA instead (section 1.4). If you are preparing for your own SOC 2 examination, the Compliance module maps checks to the criteria, collects time-stamped evidence over the review period and exports it for your auditor, who forms its own opinion.

3.5 PCI DSS v4.0

The Payment Card Industry Data Security Standard applies to entities that store, process or transmit cardholder data, or that can affect the security of the cardholder data environment (CDE). SwiftSafe is not a payment processor. Card payments for subscriptions are handled by our third-party payment provider, which collects card data directly, and we do not hold a PCI DSS Attestation of Compliance.

Where you use Prava AI to monitor your CDE, the Platform supports your work on:

• Requirement 5 (protection from malicious software): endpoint protection, malware detection and anti-phishing;
• Requirement 6 (secure systems and software): vulnerability identification and patch-status tracking;
• Requirement 10 (logging and monitoring): log collection, review, alerting and retention support;
• Requirement 11 (regular security testing): vulnerability scanning, authorised penetration testing, and change and intrusion detection; and
• Requirement 12 (policies and programmes): policy management, risk assessment, awareness records and incident response planning.

Prava AI components connected to your CDE may themselves be in scope, so include them in your scoping and discuss them with your Qualified Security Assessor. The Platform is not designed to store full card numbers: configure collection so that cardholder data is not sent to it, and tell us before any deployment that could capture it. Testing through the Platform does not replace the independent testing PCI DSS requires unless your assessor accepts it.

3.6 NIST Cybersecurity Framework 2.0

NIST CSF 2.0 is a voluntary framework organised around six functions: Govern, Identify, Protect, Detect, Respond and Recover. We use it as a reference framework for structuring our security programme, and our controls are mapped to its categories. Prava AI's Modules contribute across all six functions, and the Compliance module helps you build current and target profiles.

3.7 NIST SP 800-53 and NIST SP 800-171

NIST SP 800-53 is a catalogue of security and privacy controls used by US federal agencies and widely adopted elsewhere. NIST SP 800-171 sets requirements for protecting Controlled Unclassified Information (CUI) in non-federal systems. We use selected SP 800-53 control families as a design reference. We do not hold a FedRAMP authorisation or any US government authority to operate. The Compliance module maps evidence to both publications to help you prepare a system security plan. The Platform is not offered for storing or processing CUI, export-controlled technical data or classified information unless we have agreed in writing that a specific deployment is suitable.

3.8 CIS Critical Security Controls v8

The CIS Controls are a prioritised set of safeguards grouped into Implementation Groups 1 to 3. Our internal baselines draw on them. The Platform directly supports many safeguards, including asset and software inventory, continuous vulnerability management, audit log management, malware defences, email protections, penetration testing and incident response, and the Compliance module tracks your progress by Implementation Group.

3.9 CSA Cloud Controls Matrix

The Cloud Security Alliance's Cloud Controls Matrix (CCM) is a cloud control framework, with an associated questionnaire (CAIQ) widely used in vendor reviews. Our cloud controls are mapped to its domains. We are not listed in the CSA STAR registry, but we can provide a CAIQ-based response under NDA. The Compliance module can map your cloud posture evidence to the CCM.

3.10 MITRE ATT&CK mapping

MITRE ATT&CK is a public knowledge base of adversary tactics and techniques. It is not a compliance standard and cannot be certified against. Prava AI maps detections, alerts, threat intelligence, malware findings and incident timelines to ATT&CK where practicable, and shows your detection coverage so you can find gaps. Mappings reflect our analysis and may be incomplete. Coverage of a technique means the Platform has a relevant detection or data source, not that every use of that technique will be detected.

3.11 Continuous server hardening, monitoring & vendor oversight

In alignment with ISO/IEC 27001, SOC 2 and NIST CSF, we implement multi-layered safeguards across our internal operations:

• Server and application security: our servers, production workloads and applications are secured, hardened and patched regularly against established security baselines and benchmarks.
• Continuous systems and log monitoring: all administrative and system activity across infrastructure, networks and applications is logged centrally, synchronised to NTP, tamper-protected and monitored 24/7 for anomalous activity.
• Employee security and access governance: employee access is governed by strict least privilege and mandatory multi-factor authentication (MFA). Personnel complete background checks where permitted and undergo ongoing security and privacy training.
• Third-party and supply-chain security: all sub-processors, cloud hosting providers and external vendors undergo formal security and privacy risk assessments before onboarding and are monitored on an ongoing basis to safeguard and strengthen overall security.

4. AI governance

Prava AI is built around a proprietary large language model and other machine-learning models developed by SwiftSafe. How we train, use and govern them is set out in our AI and Data Use Policy.

4.1 ISO/IEC 42001

ISO/IEC 42001:2023 is the international standard for an AI management system. Our AI governance practices are designed to align with it: defined accountability for AI systems, AI risk and impact assessment, training-data controls (de-identification, pseudonymisation or aggregation where reasonably possible, and automated removal of secrets), evaluation before release, human oversight of Autonomous Actions and monitoring of model performance. We are not certified to ISO/IEC 42001. The Compliance module can map your own AI controls to it.

4.2 NIST AI Risk Management Framework

The NIST AI RMF is a voluntary US framework built around four functions: Govern, Map, Measure and Manage. We use it as a reference for managing risks such as inaccurate Outputs, prompt injection, cross-tenant leakage and over-reliance on automation.

4.3 EU Artificial Intelligence Act

The EU AI Act (Regulation (EU) 2024/1689) sets risk-based obligations for providers and deployers of AI systems, applying in stages. Where it applies to Prava AI, SwiftSafe expects to be the provider and will meet the obligations that apply to us as they take effect, including transparency (making clear that users are interacting with AI and labelling AI-generated Outputs) and AI literacy measures for our personnel. Where a non-EU provider must appoint an authorised representative in the Union, we will do so and publish the details.

Prava AI is designed for cybersecurity and is not intended for any practice the Act prohibits. We make no general claim about its risk classification, because that can depend on how a customer deploys it. Using Outputs for decisions about employees, or as a safety component in critical infrastructure, could fall within the high-risk categories. If you plan such a use, tell us so that we can discuss the support you need for your obligations as a deployer.

4.4 India's AI governance guidelines

We follow the approach of the India AI Governance Guidelines issued by the Ministry of Electronics and Information Technology, which emphasise trust, people-first design, accountability, safety, fairness and understandability. They are not a certification scheme, and we claim no certification against them. We will review our practices as Indian guidance develops.

5. Privacy and data-protection laws by region

For Customer Data, the Customer is generally the Data Fiduciary or controller, and SwiftSafe processes it on the Customer's instructions under the Data Processing Addendum. For account, website, billing and our own analytics data, SwiftSafe is the Data Fiduciary or controller, as described in the Privacy Policy. In every region, data is stored and processed in data centres in the Customer's own region (section 7). Individuals' rights under each law, and how to exercise them, are in our Regional Privacy Notices.

5.1 India

Key laws: the Digital Personal Data Protection Act, 2023 and the Digital Personal Data Protection Rules, 2025 (DPDP); the Information Technology Act, 2000, including sections 43A, 70B and 72A, and its rules to the extent they still apply; and the CERT-In Directions of 28 April 2022. SwiftSafe Cybersecurity Technologies India Pvt Ltd is headquartered in India. We process Personal Data in accordance with DPDP as its provisions take effect, as Data Processor for Customers and Data Fiduciary for our own data, with reasonable security safeguards and a Grievance Officer at grievance@prava.dev. We follow the CERT-In Directions where they apply to us. Residency: data of Customers whose region is India stays in India. Any processing outside India is only as section 16 of DPDP and the DPDP Rules permit, never in a country restricted by Central Government notification, and subject to stricter sectoral rules a Customer notifies to us, such as RBI data localisation directions. Rights: see the Regional Privacy Notices.

5.2 European Union and EEA

Key law: the General Data Protection Regulation (EU) 2016/679 (GDPR), with national supplementing laws and the ePrivacy rules (see the Cookie Policy). Where the GDPR applies, we process Personal Data in accordance with it: as processor under the Article 28 terms in the Data Processing Addendum, and as controller on the lawful bases set out in the Privacy Policy. Where Article 27 requires an EU representative, we will appoint one and publish the details. Residency: data stays in the EU or EEA region. Limited, logged remote support access from India or the United States is covered by the Standard Contractual Clauses incorporated into the Data Processing Addendum, with supplementary measures. Rights: see the Regional Privacy Notices.

5.3 United Kingdom

Key laws: the UK GDPR and the Data Protection Act 2018, as amended by the Data (Use and Access) Act 2025. We process Personal Data in accordance with them on the same basis as for the EU GDPR, and will appoint a UK representative where required. Residency: data stays in the UK region, and any restricted transfer for support is covered by the UK International Data Transfer Addendum. Rights: see the Regional Privacy Notices.

5.4 United States

Key laws: the California Consumer Privacy Act as amended by the California Privacy Rights Act (CCPA/CPRA) and its regulations, other state privacy laws such as those of Virginia, Colorado, Connecticut and Texas, state breach notification laws, and sectoral federal laws. US Customers contract with SwiftSafe LLC. For Customer Data we act as a "service provider" or "processor" under these laws, on the terms in section 16 of the Data Processing Addendum, and we do not sell or share Customer Personal Data for cross-context behavioural advertising.

• HIPAA: if you are a covered entity or business associate and the Platform will process protected health information, a business associate agreement is available on request from legal@prava.dev, and must be signed before you send such information. There is no official HIPAA certification, and we hold no third-party HIPAA attestation.
• GLBA: financial institutions subject to the Gramm-Leach-Bliley Act and the FTC Safeguards Rule must oversee their service providers; our contractual safeguards and documentation (section 1.4) support that oversight.
• COPPA: not applicable. Prava AI is an enterprise service, is not directed to children under 13, and we do not knowingly collect their personal information.

Residency: data of US Customers stays in the United States. Rights: see the Regional Privacy Notices.

5.5 Canada

Key laws: the Personal Information Protection and Electronic Documents Act (PIPEDA); Quebec's private-sector privacy Act as amended by Law 25; and the substantially similar laws of Alberta and British Columbia. Canadian Customers contract with SwiftSafe LLC, and we process personal information in accordance with these laws. We give Customers the information they need for any Quebec privacy impact assessment. Residency: data stays in Canada. Rights: see the Regional Privacy Notices.

5.6 Australia

Key law: the Privacy Act 1988 (Cth), including the Australian Privacy Principles (APPs) and the Notifiable Data Breaches (NDB) scheme. Where it applies, we handle personal information in accordance with the APPs, including APP 11 (security) and APP 8 (cross-border disclosure), and support Customers' breach assessments. Residency: data stays in the Australian region. Rights: see the Regional Privacy Notices.

5.7 New Zealand

Key law: the Privacy Act 2020 and its Information Privacy Principles, including notifiable privacy breaches. Where it applies, we handle personal information in accordance with it, as agent for the Customer and as an agency for our own data. Residency: data is stored in the region set at onboarding and shown in your Order Form. Rights: see the Regional Privacy Notices.

5.8 Japan

Key law: the Act on the Protection of Personal Information (APPI) and the guidelines of the Personal Information Protection Commission (PPC). We process personal information in accordance with the APPI as an entrusted party, with the security control measures it requires, and support Customers' reports to the PPC. Residency: data stays in Japan. Rights: see the Regional Privacy Notices.

5.9 China (mainland)

Key laws: the Personal Information Protection Law (PIPL), the Data Security Law (DSL) and the Cybersecurity Law (CSL), with the Cyberspace Administration of China (CAC) rules on cross-border data. These laws impose data localisation and transfer controls, particularly for important data, critical information infrastructure and large volumes of personal information. We provide Prava AI to customers in mainland China only where in-country hosting is available, so that their data is stored and processed in mainland China. We will not transfer such data out of mainland China, including for remote support, unless the transfer has passed a CAC security assessment, is covered by a filed CAC standard contract or by personal information protection certification, or falls within a regulatory exemption, and any required separate consent and impact assessment are complete. Rights: see the Regional Privacy Notices.

5.10 Singapore

Key law: the Personal Data Protection Act 2012 (PDPA). We process personal data in accordance with its protection and retention obligations as a data intermediary, and notify Customers of breaches so they can assess and report them. Residency: data stays in the Singapore region. Rights: see the Regional Privacy Notices.

5.11 South Korea

Key law: the Personal Information Protection Act (PIPA). We process personal information in accordance with it as an entrusted processor under the Customer's supervision. Residency: data stays in the Korean region. Rights: see the Regional Privacy Notices.

5.12 United Arab Emirates

Key laws: Federal Decree-Law No. 45 of 2021 (PDPL), and in the financial free zones the DIFC Data Protection Law No. 5 of 2020 and the ADGM Data Protection Regulations 2021. We process Personal Data in accordance with whichever applies; DIFC and ADGM Customers should tell us at onboarding. Residency: data stays in the UAE region. Rights: see the Regional Privacy Notices.

5.13 Saudi Arabia

Key law: the Personal Data Protection Law (PDPL) and its implementing and transfer regulations, overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA). We process personal data in accordance with it as a processor, and transfers outside the Kingdom happen only as the transfer regulations permit. Residency: data stays in the Saudi region; some government and critical-infrastructure Customers must keep data in the Kingdom under National Cybersecurity Authority controls. Rights: see the Regional Privacy Notices.

5.14 Brazil

Key law: the Lei Geral de Proteção de Dados (LGPD) and the regulations of the national authority (ANPD). Brazilian Customers contract with SwiftSafe LLC, and we process personal data in accordance with the LGPD as operator for Customers and controller for our own data, using the ANPD's standard contractual clauses for international transfers where required. Residency: data stays in the Brazilian or South American region. Rights: see the Regional Privacy Notices.

5.15 South Africa

Key law: the Protection of Personal Information Act, 2013 (POPIA). We process personal information in accordance with it as an operator, with the security safeguards section 19 requires, and notify Customers of security compromises as section 21 requires. Residency: data stays in the South African region. Rights: see the Regional Privacy Notices.

5.16 Other countries

We also serve customers in other countries with data protection laws, such as Mexico, Argentina, Switzerland, Turkey, Kenya, Nigeria, Indonesia, Malaysia and Thailand. In each case we process Personal Data in accordance with the law that applies to us, apply the safeguards in the Data Processing Addendum, and keep data in the region set at onboarding. If a local law requires in-country storage or a particular transfer mechanism, tell us before onboarding. Where we cannot meet it, we will say so rather than offer the Services on terms that would not comply.

6. Sector and cybersecurity regulations

For each regulation below, the Platform supports customers' alignment with it by monitoring relevant controls, collecting evidence and supporting incident response. We do not claim that SwiftSafe or the Platform complies with, or is approved under, any of them. Responsibility for meeting each one stays with the regulated entity.

6.1 EU NIS2 Directive

Directive (EU) 2022/2555 requires essential and important entities to take cybersecurity risk-management measures, including supply-chain security, and to report significant incidents in stages. The Platform supports customers' alignment with NIS2 through risk evidence, vulnerability handling, detection and DFIR support for staged reporting. Managed security services can themselves fall within NIS2, and we are reviewing how it and national transposing laws apply to SwiftSafe's own services in the Union.

6.2 EU Digital Operational Resilience Act (DORA)

Regulation (EU) 2022/2554 sets ICT risk, incident reporting, resilience testing and third-party risk requirements for financial entities. For DORA customers, SwiftSafe is an ICT third-party service provider, and the Platform supports customers' alignment with DORA. Contract terms required by Article 30 can be agreed in an Order Form or addendum on request. SwiftSafe has not been designated a critical ICT third-party service provider.

6.3 UK Cyber Essentials

Cyber Essentials is a UK government-backed scheme covering firewalls, secure configuration, user access control, malware protection and security update management, certified by accredited certification bodies. The Platform supports customers' alignment with Cyber Essentials and Cyber Essentials Plus by checking these controls and collecting self-assessment evidence. SwiftSafe does not hold Cyber Essentials certification.

6.4 US SEC cybersecurity disclosure rules

US public companies must disclose material cybersecurity incidents on Form 8-K (Item 1.05) and describe their cybersecurity risk management and governance annually (Regulation S-K Item 106). The Platform supports customers' alignment with these rules by producing incident timelines, impact information and governance records. Whether an incident is material, and what to disclose, is the registrant's decision.

6.5 US CMMC

The Department of Defense's Cybersecurity Maturity Model Certification applies to defence contractors handling Federal Contract Information or CUI, and draws on NIST SP 800-171. The Platform supports customers' alignment with CMMC by mapping evidence to its practices. SwiftSafe holds no CMMC certification and is not a certified third-party assessment organisation, and the Platform is not offered for CUI without our written agreement (section 3.7).

6.6 India: RBI, SEBI and IRDAI

• Reserve Bank of India: the cyber security framework for banks, the Master Direction on IT Governance, Risk, Controls and Assurance Practices, and the directions on outsourcing of IT services. Contract terms regulated entities need, such as access and audit rights for the entity and RBI, can be agreed in an Order Form.
• Securities and Exchange Board of India: the Cybersecurity and Cyber Resilience Framework (CSCRF), including continuous monitoring, security operations and cyber audit requirements.
• Insurance Regulatory and Development Authority of India: the Information and Cyber Security Guidelines for insurers and intermediaries.

The Platform supports customers' alignment with each of these through security operations, incident reporting support and audit evidence.

6.7 Australia: SOCI Act and the Essential Eight

The Security of Critical Infrastructure Act 2018 requires responsible entities to maintain a risk management program and report cyber security incidents to the Australian Signals Directorate (ASD). The ASD's Essential Eight is a set of mitigation strategies assessed against maturity levels. The Platform supports customers' alignment with both, for example through OT and IoT monitoring, incident reporting support, and tracking of patching, multi-factor authentication, administrative privileges, application control and backups.

6.8 Singapore: MAS Technology Risk Management Guidelines

The Monetary Authority of Singapore's Technology Risk Management Guidelines, with its notices on cyber hygiene and outsourcing, set expectations for financial institutions. The Platform supports customers' alignment with them through security monitoring, vulnerability management, penetration testing and incident evidence.

6.9 UAE: NESA/IAS and DESC

The UAE Information Assurance Standards, originally issued by the National Electronic Security Authority and now overseen by the UAE Cyber Security Council, apply to government entities and critical sectors. The Dubai Electronic Security Center (DESC) sets requirements, including its Information Security Regulation, for Dubai government entities and suppliers. The Platform supports customers' alignment with both by mapping controls and collecting evidence.

6.10 Saudi Arabia: NCA Essential Cybersecurity Controls

The National Cybersecurity Authority's Essential Cybersecurity Controls (ECC) apply to government organisations, critical national infrastructure operators and other designated entities. The Platform supports customers' alignment with the ECC. Hosting and data-location requirements may need in-Kingdom deployment, which you should raise before onboarding.

6.11 Japan: FISC Security Guidelines

The Security Guidelines on Computer Systems for Financial Institutions, published by the Center for Financial Industry Information Systems (FISC), are widely used by Japanese financial institutions, including for cloud arrangements. The Platform supports customers' alignment with them by mapping controls and collecting evidence.

6.12 Other regulations

The Compliance module can be configured with custom controls for other frameworks. Mappings are guidance only, and we do not warrant that they are complete, current or accepted by any regulator, as explained in section 11 of the Module Terms.

7. Data residency and sovereignty

7.1 Local data centres and foreign storage prohibition

We use your local regional data centres to process and store customer data, without storing in foreign countries. This covers Customer Data, Telemetry, Personal Data, forensic evidence, email content, malware samples, compliance evidence, backups, and any model training on that data. Customer data is processed and retained within your designated country or region, ensuring strict compliance with local data sovereignty mandates and preventing unauthorized cross-border exposure. Your region is set at onboarding or in the Order Form and cannot be changed without your prior written agreement. Sub-processors operating in your region are contractually bound to the same strict residency standards.

7.2 What may be used across regions

Only non-personal security artefacts (indicators of compromise, hashes, signatures and malicious infrastructure, stripped of Personal Data and Customer Confidential Information) and anonymised, aggregated model parameters are used across regions, for collective defence.

7.3 Remote support access

Personnel outside your region, including at the other SwiftSafe company, may occasionally need remote access for support or incident response. Access is limited, approved, time-bound and logged, data is viewed in place wherever possible, and any transfer is covered by section 10 of the Data Processing Addendum. Data hosted in mainland China follows the stricter rule in section 5.9.

7.4 CERT-In log retention for systems in India

The CERT-In Directions require logs of ICT systems to be kept for a rolling 180 days within India, with clocks synchronised to NTP time sources. We keep these logs in India for SwiftSafe's own systems located in India. This does not bring Customer Data from other regions into India. The Platform can help Customers subject to the Directions retain their own logs in India, but that retention remains the Customer's responsibility.

7.5 Sovereignty requirements

Government bodies, critical infrastructure operators and financial institutions may face stricter localisation or sovereignty rules. Where we can meet them, measures such as a dedicated deployment, customer-managed keys or restricted support access can be agreed in an Order Form. Please raise them before onboarding.

8. Incident and breach reporting timelines

8.1 Who notifies whom

Where SwiftSafe is a processor of Customer Data, the duty to notify regulators and affected individuals generally rests with the Customer as controller, Data Fiduciary or regulated entity. SwiftSafe notifies the Customer of a Personal Data Breach under section 12 of the Data Processing Addendum, without undue delay and in any event within 24 to 48 hours after confirming it, with an earlier warning where a short regulatory deadline may be affected, and shares the logs and timelines the Customer needs. Where SwiftSafe is controller or Data Fiduciary, or a law places a duty on SwiftSafe directly, we report ourselves. Incidents the Platform detects in your own environment are not breaches of SwiftSafe; you decide whether they are reportable.

8.2 Timelines by regime

These are simplified planning summaries. They depend on thresholds and definitions in each law, may change, and should be confirmed with your advisers.

• India, CERT-In: report specified cyber security incidents within 6 hours of noticing them. SwiftSafe reports incidents on its own systems where the Directions apply.
• India, DPDP: inform the Data Protection Board and each affected Data Principal without delay, then give the Board a detailed report within 72 hours, or a longer period it allows.
• EU and UK GDPR: notify the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in risk, and individuals without undue delay where risk is high.
• EU NIS2: early warning within 24 hours, incident notification within 72 hours, final report within one month.
• EU DORA: for a major ICT-related incident, initial notification within 4 hours of classification and no later than 24 hours after awareness, an intermediate report within 72 hours, and a final report within one month.
• US SEC: Form 8-K within 4 business days of determining that an incident is material.
• US HIPAA: notify individuals without unreasonable delay and within 60 days of discovery. State laws set their own timelines.
• Australia: under the NDB scheme, assess a suspected eligible data breach within 30 days and notify the OAIC and individuals as soon as practicable. Under the SOCI Act, report critical infrastructure incidents to the ASD within 12 or 72 hours depending on impact.
• Canada, PIPEDA: report breaches creating a real risk of significant harm to the Privacy Commissioner and individuals as soon as feasible, and record all breaches. Quebec's Law 25 has similar prompt-notice rules.
• Japan, APPI: a preliminary report to the PPC promptly, generally within 3 to 5 days, and a final report within 30 days (60 days for wrongful acts).
• Singapore, PDPA: notify the PDPC within 3 calendar days of assessing a breach as notifiable.
• Brazil, LGPD: notify the ANPD and affected individuals within 3 business days, under the ANPD's incident regulation.

8.3 How the Platform supports reporting

The DFIR and Compliance Modules support these timelines with synchronised time stamps, incident timelines, indicator lists, evidence preserved with chain of custody, and draft incident reports. Drafts must be reviewed by your responsible personnel before submission.

9. How the Compliance module helps

The Compliance and policy management Module is governed by section 11 of the Module Terms. It provides:

• Continuous control monitoring: automated checks against connected systems and other Modules, such as endpoint coverage, patch status, multi-factor authentication, cloud configuration and logging, with alerts when a control drifts.
• Evidence collection: automated and manual evidence, such as configuration exports, access reviews and training records, stored in your region with preserved time-stamps.
• Policy management: drafting, approval, publication and acknowledgement of policies, with version history. Generated policies are drafts for your review and approval.
• Framework mapping: one control mapped to many frameworks, including those in sections 3 and 6, showing when each mapping was last reviewed.
• Auditor exports: evidence packages for your auditors, assessors and regulators.

The Compliance module does not certify compliance. It does not certify, attest to or guarantee compliance with any law or framework, and SwiftSafe is not your auditor, certification body, assessor or legal adviser. Mappings reflect our interpretation, and automated checks test only what connected systems expose.

10. Requesting documents and contact

10.1 Requesting documents

To request security documentation, a questionnaire response, our architecture overview, a business associate agreement, DORA or RBI contract terms, or a signed Data Processing Addendum, email legal@prava.dev with your organisation's name, whether you are a customer or prospective customer, and what you need. We will send a non-disclosure agreement where needed, and may decline requests that would put the Platform or other customers at risk.

10.2 Contacts

• Legal and compliance: legal@prava.dev
• Privacy: privacy@prava.dev (see also our Regional Privacy Notices)
• Grievance Officer: grievance@prava.dev
• Security vulnerability reports: security@prava.dev (see responsible disclosure)

10.3 Company details

• Headquarters (India): SwiftSafe Cybersecurity Technologies India Pvt Ltd
• United States office: SwiftSafe LLC
• Product: Prava AI

10.4 Changes to this page

We will update this page when our compliance status changes, including when any certification is issued, and when laws or frameworks change. Our other legal documents are listed in the Legal centre.