LEGAL

RITVA — Security Policy

AI Visibility Infrastructure Platform

Version: 2.0
Effective Date: June 12, 2026
Last Updated: June 13, 2026
Platform: ritva.ai
Security Contact: security@ritva.ai

Table of Contents

• Introduction
• Security Philosophy
• Shared Responsibility Model
• Infrastructure Security
• Network Security
• Application Security
• Authentication & Access Control
• Encryption
• Data Protection
• Security Monitoring
• Vulnerability Management
• Incident Response
• Backup & Disaster Recovery
• Vendor & Third-Party Security
• Employee & Internal Access Controls
• Responsible Disclosure
• Security Limitations
• Security Updates
• Contact Information

1. Introduction

This Security Policy describes the technical and organizational measures Ritva applies to protect customer data, platform systems, and operational infrastructure.

It is intended for customers, agencies, procurement teams, business users, and enterprise buyers who need to understand how Ritva approaches security across its AI Visibility Infrastructure Platform.

How this document relates to Ritva's other policies:

• The Privacy Policy describes what data Ritva collects and why.
• The Data Compliance document describes how data is governed, retained, and processed.
• This Security Policy describes how data and systems are protected.

The three documents are complementary. This Policy focuses specifically on the technical controls, organizational practices, and operational processes that constitute Ritva's security posture.

Security is not a single feature or certification. It is an ongoing commitment requiring continuous attention, iteration, and discipline. This Policy reflects Ritva's current security practices and will be updated as those practices evolve.

2. Security Philosophy

Ritva's approach to security is grounded in a set of core principles that inform every layer of the Platform's design and operation.

Security by design
Security is not added to the Platform after the fact. It is considered at the design stage of features, infrastructure changes, and data flows. Before new capabilities are built, their security implications are assessed.

Least privilege
Access to systems, data, and infrastructure is granted at the minimum level required for a given function. Personnel, services, and integrations are not given broad permissions as a default.

Defense in depth
Ritva does not rely on any single security control. Multiple independent layers of protection are applied — at the network, application, authentication, and data levels — so that the failure of one control does not expose customer data or platform operations.

Continuous monitoring
Security is not a one-time configuration. Ritva monitors platform operations, access patterns, and system behavior on an ongoing basis to detect anomalies and respond to threats in a timely manner.

Responsible data handling
Security and privacy are treated as complementary, not competing, concerns. Data that is not collected cannot be breached. Data that is properly isolated, encrypted, and access-controlled is harder to misuse if a control fails.

Transparency over claims
Ritva describes its security practices honestly. Where controls are in place, this Policy says so. Where absolute guarantees cannot be made, this Policy says that too.

3. Shared Responsibility Model

Security on the Ritva Platform is a shared responsibility between Ritva and its users. This section defines where each party's responsibility begins and ends.

Ritva Is Responsible For

• Securing the Platform's infrastructure, hosting environment, and database systems
• Implementing and maintaining authentication systems, session management, and access controls
• Encrypting data in transit and at rest across Platform systems
• Monitoring Platform infrastructure for threats, anomalies, and unauthorized access
• Managing security for all code, services, and systems that make up the Platform
• Evaluating and contracting with vendors and subprocessors who handle customer data
• Detecting, responding to, and notifying users of security incidents affecting Platform systems
• Maintaining the controls described in this Security Policy

Users Are Responsible For

• Protecting the credentials used to access their Ritva account, including passwords and authentication tokens
• Ensuring that access to their account is not shared with unauthorized individuals
• Logging out of the Platform on shared or public devices
• Reporting suspected unauthorized account access promptly to security@ritva.ai
• Exercising appropriate care over the content, URLs, and data they submit to the Platform
• Managing permissions granted to connected third-party integrations and revoking access when no longer needed
• Ensuring that any API keys or access tokens generated through the Platform are stored securely and not exposed in public repositories or insecure environments

Neither party's responsibilities under this model are exhaustive. Where a security issue arises in an area not clearly assigned here, Ritva will act in good faith to investigate and address it.

4. Infrastructure Security

Ritva's Platform is hosted on cloud infrastructure managed by established cloud providers. The following principles govern how that infrastructure is configured and maintained.

Managed cloud hosting
Ritva uses managed cloud services that provide underlying physical security, hardware maintenance, and infrastructure redundancy. Physical security of data center facilities is the responsibility of the relevant cloud provider.

Environment isolation
Production systems — the systems that store and process customer data — are logically separated from development and testing environments. Customer data is not used in non-production environments.

System hardening
Platform systems are configured to minimize the attack surface. Unnecessary services, ports, and access pathways are disabled. Default credentials are never used in production.

Dependency management
Platform infrastructure and application dependencies are maintained with current, supported versions. The use of deprecated or unsupported components is actively avoided.

Configuration security
Infrastructure configuration is managed programmatically where possible, reducing the risk of manual error and enabling configuration to be reviewed, versioned, and audited.

5. Network Security

TLS encryption in transit
All communication between user clients and the Ritva Platform is encrypted using TLS 1.2 or higher. Plain HTTP connections are not accepted; all requests are redirected to HTTPS.

Network-level protection
Ritva utilizes Cloudflare network security services and infrastructure-level protections to help secure public-facing services. These protections may include traffic filtering, bot mitigation, challenge rules, rate limiting, and distributed denial-of-service (DDoS) mitigation.

Additional network security controls may be deployed as operational requirements evolve.

Network segmentation
Internal Platform services that do not need to be publicly accessible are not exposed to the internet. Database infrastructure and internal APIs operate within private network segments.

Firewall controls
Inbound and outbound traffic to Platform infrastructure is controlled by firewall rules that permit only expected and necessary connections.

6. Application Security

Input validation
User-supplied input is validated at the application layer before processing. Inputs are not passed directly to database queries, file systems, or shell commands in ways that could enable injection attacks.

Output encoding
Application outputs are encoded appropriately to prevent cross-site scripting (XSS) and related injection vulnerabilities where content is rendered in user interfaces.

Authentication enforcement
Access to protected Platform features and data requires authenticated sessions. Unauthenticated requests to protected resources are rejected.

Session protection
User sessions are managed with secure, randomly generated identifiers. Session tokens are transmitted only over HTTPS, are not accessible via JavaScript where technically avoidable, and expire after periods of inactivity.

Permission controls
The application enforces that users can access only their own account data. Cross-account data access is not possible through the Platform's application layer.

Secure development practices
Security considerations are integrated into the Platform's development process. Code changes that introduce new attack surfaces or affect authentication, authorization, or data handling are reviewed for security implications before deployment.

Dependency security
Third-party libraries and packages used in the Platform's application code are monitored for known vulnerabilities. Security patches for dependencies are applied in a timely manner.

7. Authentication & Access Control

Password security
User account passwords are hashed using a strong, industry-standard hashing algorithm before storage. Ritva does not store passwords in plain text or in reversibly encrypted form. Users are encouraged to use strong, unique passwords for their Ritva accounts.

Role-based access (internal)
Internal Ritva personnel are assigned access roles corresponding to their operational function. Access to production systems and customer data is restricted to personnel whose role requires it.

Multi-factor authentication (internal)
Access to Ritva's production infrastructure, database systems, and internal administrative tools requires multi-factor authentication for all personnel. MFA is enforced, not optional, for privileged access.

Session management
Authenticated sessions are time-limited. Sessions expire after periods of inactivity and can be terminated by the user at any time. Persistent login sessions are cryptographically bound to the issuing device and are invalidated on password change or explicit logout.

Access revocation
When a team member's role changes or they leave the organization, their access to internal systems is revoked promptly. Access reviews are conducted periodically to verify that active permissions remain appropriate.

API access controls
Where the Platform issues API keys or access tokens, those credentials are scoped to specific operations and can be revoked by the user at any time from within their account settings.

8. Encryption

Encryption in transit
All data transmitted between user browsers and the Platform is encrypted using TLS. This applies to authentication, data submission, AI feature requests, and all other Platform interactions. Connections that do not support current TLS standards are not accepted.

Data transmitted from the Platform to subprocessors — including AI providers, database services, and email delivery infrastructure — is encrypted in transit using the protocols specified and maintained by those providers.

Encryption at rest
Customer data stored within the Platform's primary database infrastructure is encrypted at rest. Encryption at rest protects stored data in the event of unauthorized access to storage media or backup files.

Secrets management
Sensitive configuration values — including API keys, database credentials, and service tokens used within the Platform's infrastructure — are restricted to authorized operational environments and protected through access controls and encryption where applicable. Ritva continuously improves secret management practices as infrastructure evolves.

9. Data Protection

AI processing security
Customer inputs transmitted to AI systems are sent only to authorized AI processing providers required to deliver requested functionality. Ritva applies contractual, technical, and operational safeguards designed to protect customer inputs during AI processing workflows. AI providers are selected based on their privacy and security commitments. Where available, Ritva uses providers that represent customer inputs are not used for provider model training or that offer contractual controls restricting such use.

Data minimization
Ritva collects and retains only the data necessary to deliver the Platform's services. Data that is no longer required for operational or legal purposes is deleted in accordance with the retention schedules described in the Data Compliance document.

Logical data isolation
Customer accounts are logically isolated within the Platform's data architecture. Data belonging to one account is not accessible to other accounts. Platform queries are scoped to the authenticated user's account by design.

Access restrictions
Direct access to production databases by internal personnel is restricted and logged. Routine operational tasks do not require direct database access.

Secure AI processing
Customer inputs transmitted to AI processing systems are handled under contractual protections that prohibit subprocessors from using that data for their own model training. See Section 14 for details on AI vendor security.

Customer content protections
Customer data — including submitted URLs, content, prompts, and generated outputs — is processed solely to deliver the Platform's services. It is not sold, shared for advertising, or used for purposes outside the scope of those services. A full description of customer content protections is provided in the Data Compliance document.

10. Security Monitoring

Ritva monitors Platform systems and operations on an ongoing basis to detect threats, anomalies, and potential security incidents.

Security logging
Ritva maintains security-related audit logs for authentication events, account security actions, access-control events, and other operational security activities. Audit records are used for security monitoring, incident investigation, abuse prevention, and operational review. Access to logs is restricted to prevent tampering.

Access and activity logging
Significant Platform events — including authentication attempts, access to sensitive resources, administrative actions, and configuration changes — are logged. Logs are retained for a defined period and are available for security review and incident investigation.

Infrastructure monitoring
Platform infrastructure is monitored for availability, performance anomalies, and unexpected behavior. Monitoring systems may generate alerts when conditions indicate potential operational or security concerns.

Error and exception tracking
Application errors and exceptions are captured by automated tracking systems. Patterns of unusual errors — which may indicate attempted attacks or unexpected behavior — are surfaced for review.

Anomaly detection
Access patterns, usage volumes, and system behaviors are monitored for anomalies that may indicate unauthorized access, account compromise, or abuse of Platform features.

Log integrity
Access to logs is restricted to prevent tampering. Logs are treated as an investigative resource and are not exposed to general internal access.

11. Vulnerability Management

Risk assessment
Ritva assesses the security risk of new features, infrastructure changes, and third-party integrations before they are deployed to production. Identified risks are addressed prior to or alongside deployment.

Patch management
Security patches and updates for Platform software, infrastructure components, and application dependencies are applied on a timely basis. Critical patches for high-severity vulnerabilities are prioritized and applied as quickly as practicable.

Dependency monitoring
Application and infrastructure dependencies are monitored for newly disclosed vulnerabilities using automated tooling. When a dependency used by the Platform is found to have a known security issue, the team is alerted and remediation is initiated.

Issue prioritization
Identified vulnerabilities are classified by severity and potential impact. Critical and high-severity issues are addressed with priority. Lower-severity issues are tracked and addressed within a defined remediation cycle.

Penetration testing
Ritva may conduct or commission security assessments of Platform components to identify vulnerabilities that automated tools may not detect. The scope, frequency, and outputs of such assessments are internal. Enterprise customers with specific assessment requirements are invited to contact security@ritva.ai.

Responsible disclosure
Ritva maintains a responsible disclosure process that enables external security researchers to report vulnerabilities. This process is described in Section 16.

12. Incident Response

Ritva maintains documented procedures for detecting, containing, investigating, and resolving security incidents.

Detection
Security incidents may be detected through automated monitoring, internal review, user reports, or third-party disclosure. All suspected incidents are treated seriously regardless of the detection source.

Containment
Upon confirming a suspected incident, Ritva's immediate priority is containment — limiting the scope of impact and preventing further unauthorized access or data exposure.

Investigation
Ritva investigates the nature, cause, and extent of the incident, including which systems were affected, what data may have been accessed or exposed, and how the incident occurred.

Remediation
Following investigation, Ritva implements corrective measures to address the root cause, close the vector exploited, and strengthen controls to reduce the likelihood of recurrence.

Notification
Where a security incident results in unauthorized access to or disclosure of personal data, Ritva will notify affected users and, where required by applicable law, relevant regulatory authorities. Notifications will be issued without undue delay and will include information about the nature of the incident, the data involved, and the steps taken in response.

Post-incident review
Following a material security incident, Ritva conducts a review to identify contributing factors, assess the effectiveness of the response, and implement improvements to prevent recurrence.

Incident response timelines and notification requirements under GDPR, India's Digital Personal Data Protection Act, and other applicable frameworks are governed by the legal obligations applicable to each event.

13. Backup & Disaster Recovery

Regular backups
Critical Platform data — including customer account data, audit outputs, and configuration — is backed up on a regular schedule. Backup frequency is calibrated to the operational importance and rate of change of each data category.

Backup security
Backups are stored with encryption and access controls equivalent to the protections applied to production data. Backup storage is logically separated from primary storage.

Backup integrity
Backup integrity is verified periodically to confirm that backup data is complete, uncorrupted, and restorable. A backup that cannot be restored does not serve its purpose.

Recovery procedures
Ritva maintains documented procedures for restoring Platform operations and data from backups in the event of data loss, infrastructure failure, or a significant operational incident. Recovery procedures are reviewed and maintained alongside infrastructure changes.

Business continuity
In the event of a significant Platform outage or infrastructure failure, Ritva's recovery priority is to restore access to the Platform and protect the integrity of customer data. Ritva will communicate with affected users during significant outages through available channels.

14. Vendor & Third-Party Security

Ritva depends on third-party providers for key components of the Platform's infrastructure, including AI processing, database hosting, CDN, and payment handling. The security of these vendors is a component of the Platform's overall security posture.

Vendor evaluation
Before engaging a vendor or subprocessor that will handle customer data or play a critical role in Platform operations, Ritva evaluates the vendor's security practices. This evaluation includes review of the vendor's security documentation, certifications, and data processing terms.

Contractual protections
All vendors and subprocessors that handle customer data are engaged under contracts that include data protection obligations, restrictions on secondary use of customer data, breach notification requirements, and requirements to maintain appropriate security controls.

AI provider security
AI subprocessors — including large language model providers — are contractually required to process customer inputs solely for the purpose of providing the requested AI function, and are prohibited from using customer data for their own model training. Ritva's current AI providers maintain recognized security certifications and compliance programs.

Ongoing review
Vendor security postures are periodically reviewed. Material changes to a vendor's security practices, certifications, or compliance status that affect Ritva's security commitments will be assessed and addressed.

Subprocessor list
A current list of Ritva's subprocessors is maintained in the Data Compliance document.

15. Employee & Internal Access Controls

Need-to-know access
Internal access to customer data and production systems is granted based on operational necessity. Personnel are given access to the data and systems their role requires and no more.

Role-based permissions
Internal permissions are structured by role. Access grants are specific to function and do not accumulate over time without review.

Multi-factor authentication
All internal personnel with access to production infrastructure or customer data are required to use multi-factor authentication. MFA is enforced at the infrastructure and tooling level, not left to individual discretion.

Access reviews
Access permissions are reviewed periodically as operational requirements evolve. Permissions that are no longer appropriate are identified and revoked.

Offboarding
When personnel access is no longer required, access to Ritva systems — including infrastructure, internal tools, and third-party services used in the delivery of the Platform — is revoked promptly through established operational procedures.

No standing database access
Direct access to production databases by internal personnel is restricted. Where database access is required for operational or investigative purposes, it is granted through a controlled process and is logged.

Security awareness
Personnel with access to sensitive systems are expected to be aware of phishing risks, credential hygiene, and responsible handling of customer data. Security practices are communicated as part of internal onboarding and operational processes.

16. Responsible Disclosure

Ritva welcomes reports from security researchers, customers, and the security community who identify vulnerabilities in the Platform, its infrastructure, or its application code.

How to report a vulnerability

Please submit vulnerability reports to: security@ritva.ai

Include in your report:

• A clear description of the vulnerability and the potential impact
• Steps to reproduce the issue, including any relevant URLs, payloads, or screenshots
• The affected component or Platform area
• Your contact information for follow-up

Our commitments to reporters

• We will acknowledge receipt of your report within 5 business days
• We will investigate the reported issue promptly and in good faith
• We will keep you informed of the status of our investigation where appropriate
• We will not take legal action against researchers who report vulnerabilities in good faith, in accordance with this process, and without causing damage to Ritva's systems or customers

Scope

Reports should concern vulnerabilities in Ritva's own Platform, infrastructure, and applications. Vulnerabilities in third-party software used by Ritva should be reported to the relevant vendor directly; you are welcome to notify us as well so we can assess our exposure.

Out of scope

The following are out of scope for responsible disclosure:

• Denial-of-service attacks against Platform infrastructure
• Spam or social engineering
• Physical security
• Vulnerabilities in third-party services not specific to Ritva's configuration

Ritva does not currently operate a bug bounty program. We appreciate responsible disclosures and acknowledge reporters where appropriate and with their consent.

17. Security Limitations

Ritva applies reasonable technical and organizational safeguards to protect the Platform and customer data. However, no system connected to the internet can be made completely secure, and Ritva does not represent that its security measures are impenetrable or that data breaches are impossible.

What this means in practice:

• Ritva's security posture reduces risk but cannot eliminate it
• Novel attack techniques, zero-day vulnerabilities, and unforeseen failure modes may affect any platform regardless of the controls in place
• Ritva's security controls are effective against known and reasonably anticipated threats; they may not anticipate every possible future threat
• Ritva cannot control the security of user devices, browser environments, or third-party platforms that users choose to connect

Users should:

• Use strong, unique passwords and enable any available account security features
• Keep their own devices and browsers updated
• Be cautious about phishing attempts that may impersonate Ritva
• Contact security@ritva.ai immediately if they suspect unauthorized access to their account

Ritva's liability in connection with security incidents is limited as described in the Terms of Use. This limitation does not affect Ritva's commitment to respond to incidents diligently and to notify affected users as required.

18. Security Updates

Ritva's security practices and controls evolve as the Platform grows, as new threats emerge, and as best practices in the industry develop.

This Security Policy will be updated to reflect:

• Material changes to the Platform's security architecture or controls
• New or expanded use of third-party vendors that affects the security posture
• Changes in applicable legal obligations related to security and incident response
• Significant improvements or changes to internal security processes

Updated versions of this Policy will be published at ritva.ai/security with a revised effective date. For material changes, Ritva will notify customers via email or in-platform notification.

Enterprise customers or procurement teams requiring advance notice of changes to specific security controls are invited to contact security@ritva.ai to discuss their requirements.

19. Contact Information

Security vulnerabilities and responsible disclosure:
security@ritva.ai

Privacy and data protection inquiries:
privacy@ritva.ai

Legal and compliance inquiries:
legal@ritva.ai

General support:
support@ritva.ai

Mailing address:
Pavan Kumar (Sole Proprietorship)
80/1, Krishnaleela nilayam, Amar Jyoti colony
New Bowenpally, Secunderabad,
Telangana, 500011,
India

Ritva aims to acknowledge all security-related communications within 5 business days. For urgent matters — including active security incidents or critical vulnerability reports — please indicate the urgency clearly in the subject line.

*This Security Policy is subject to legal and technical review and may be updated prior to commercial launch. Ritva recommends that all security and compliance documents be reviewed by qualified legal counsel and, where appropriate, a security professional before publication.*

© 2026 Ritva. All rights reserved.
ritva.ai — Security Policy v1.0