Security Overview

ORS AI is built for hospital operating environments where reliability, traceability, and access discipline matter as much as raw functionality. Our security posture is shaped around least privilege, practical auditability, defense in depth, and minimization of the data required for the product to be useful.

This page provides a summary of our security approach. It is not a complete statement of every control in use, and more detailed materials may be shared under NDA where appropriate.

ORS AI is designed for deployment on AWS infrastructure with primary data residency in Mumbai, India wherever practicable. Environments are logically separated to reduce the risk of inappropriate cross-customer access and to maintain clearer operational boundaries.

Infrastructure choices, deployment topology, and environment layout may vary depending on customer agreements, module scope, and integration requirements, but our default posture favors managed services and controlled operational surfaces over broad administrative sprawl.

ORS AI uses layered controls intended to limit unauthorized network and application access, including controlled exposure of services, environment separation, request validation, and change management around internet-facing components.

Because ORS AI operates alongside hospital systems, the security posture also depends on disciplined integration boundaries, scoped credentials, source-system hygiene, and careful handling of interfaces with customer infrastructure.

Data is encrypted in transit using TLS and is protected at rest using industry-standard encryption mechanisms supported by the relevant infrastructure components. Administrative and service credentials are managed through controlled secret-handling processes rather than ad hoc storage practices.

Encryption and secret controls are reviewed as part of infrastructure and deployment changes, especially where new integrations, vendor dependencies, or operational workflows are introduced.

Administrative access to ORS AI systems is restricted to authorized personnel who need it for engineering, support, security, or operational purposes. Access is intended to follow role-based and least-privilege principles and may be time-bound, environment-scoped, or approval-dependent depending on the sensitivity of the action.

Customers are responsible for managing their own internal user lifecycle, source-system accounts, and endpoint posture, but ORS AI supports role-based access patterns inside the product to help reduce overexposure of operational views.

ORS AI maintains logging and monitoring practices designed to detect operational anomalies, diagnose incidents, trace important changes, and support review of privileged activity. Monitoring coverage may include application behavior, infrastructure health, integration failures, and security-relevant signals.

Changes to the platform and underlying infrastructure are expected to move through review and deployment processes intended to reduce accidental regressions and preserve auditability in production environments.

Security review is incorporated into product and infrastructure change workflows. This includes attention to dependency risk, authentication and authorization boundaries, input handling, logging discipline, deployment safety, and exposure of sensitive operational surfaces.

Vulnerability findings are prioritized according to severity, exploitability, and operational impact. Remediation timing depends on risk level and business context, but issues with credible security implications are expected to move through an expedited path.

ORS AI maintains backup and continuity practices intended to support recovery from infrastructure failure, operational error, or service disruption. Recovery posture may differ by environment and customer agreement, but the aim is to restore service in a controlled way while preserving integrity and minimizing unnecessary exposure.

Business continuity planning also includes escalation procedures, operational runbooks, and recovery coordination where customer-specific deployment requirements apply.

ORS AI maintains incident response procedures for identifying, triaging, containing, investigating, and remediating security or availability issues affecting the platform. Incidents are handled with attention to evidence preservation, communication discipline, and coordinated mitigation.

If a confirmed incident materially affects customer data or service commitments within ORS AI’s responsibility boundary, we aim to notify the relevant customer contact without undue delay and provide follow-up information as it becomes reasonably available.

Some aspects of security remain within the customer’s control, especially source-system permissions, endpoint hardening, internal access approvals, network environment, data-quality choices, and the organizational processes used around the product.

ORS AI can support good security practice, but it cannot fully compensate for insecure source systems, excessive user access, weak credential discipline, or inappropriate sharing of sensitive data into channels not designed for it.

Where customers need deeper diligence, ORS AI may provide supporting security materials under NDA, such as architecture summaries, security questionnaires, implementation notes, or evidence of operational controls appropriate to the stage and scope of the relationship.

Availability of materials may depend on the sensitivity of the request, customer status, and the need to avoid overexposure of security-sensitive implementation detail.

If you believe you have identified a security issue relating to ORS AI, please report it promptly to security@orsai.app with enough detail for us to reproduce and investigate the issue. We ask that reporters act in good faith, avoid privacy harm, and avoid disrupting customer environments.

General security enquiries, customer diligence requests, or questions about this summary may also be directed to security@orsai.app.