Business information only
The Demo Form requests organizational contact details and a high-level product requirement. Do not submit sensitive investigative material or credentials.
CyberSaathi
Security begins with separation, control and traceability.
CyberSaathi’s public product layer should be cleanly separated from operational applications, APIs, data, credentials and non-production environments.
SEP
Environment Separation
Keep the public website, production APIs, staging systems, development services and operational data isolated from one another.
IAM
Controlled Access
Use application authentication, licensing and access controls appropriate to the deployed CyberSaathi environment.
AUD
Traceability
Preserve relevant audit records and operational history so system actions can be reviewed where the product supports it.
CFG
Configuration Isolation
Maintain separate production and non-production credentials, databases, Firebase configuration and API secrets.
MIN
Data Minimization
Use only the data required for the authorized purpose and avoid placing sensitive case information in public website forms.
UPD
Secure Maintenance
Treat dependency updates, backups, logs, deployment review and credential rotation as ongoing operational responsibilities.
How customer information is protected
Separate the website enquiry from operational investigation data.
These website-specific arrangements are distinct from security controls that must be confirmed for each operational product deployment.
Validated request processing
The supplied PHP workflow is designed to validate requests, rate-limit submission attempts and keep enquiry files outside the public document root when configured correctly.
Configured email routing
Demo submissions are intended to notify the authorized sales mailbox and send the requester an acknowledgement. Successful live delivery depends on the cPanel SMTP configuration.
Deployment-specific controls
Authentication, roles, encryption, retention, audit records and backup/recovery responsibilities must be verified for the customer’s actual build and hosting arrangement.
No certification is implied. Ask for evidence of any specific compliance, penetration-test or security-certification claim during procurement. Review deployment responsibilities →
Security statements on this website are architecture principles and product-direction commitments—not claims of a certification unless that certification is independently achieved and can be evidenced.
Recommended public architecture
Separate public marketing, operational systems and test environments.
The diagram below describes recommended trust boundaries; it is not a deployment topology or a claim about your current customer configuration.
PUBLIC
Public website
Public product pages and business enquiry form, isolated from operational case data.
API
Protected application
Application services and investigative data belong in separately authorized environments.
STAGING
Separate testing
Testing and staging should use different credentials, accounts and synthetic data.
DOCS
Restricted documentation
Documentation access should follow the customer and operator authorization model.