Data Security Policy

1. Purpose & scope

This policy describes the technical and organisational measures Neurovia Technologies applies to protect data processed through eWorkPulse. It covers our production infrastructure, application, desktop agent, mobile application, APIs and the personnel who operate them.

It supports our commitments in the Privacy Policy and Data Processing Agreement, and reflects the "reasonable security practices and procedures" expected under the Information Technology Act, 2000 and the Digital Personal Data Protection Act, 2023.

2. Security principles

• Least privilege — access is granted only where required for a defined role, and removed when no longer needed.
• Defence in depth — no single control is relied upon alone.
• Data minimisation — the platform is designed so customers can collect less, and defaults are conservative.
• Segregation by default — every record is bound to an organisation and access is scoped to it.
• Transparency — we describe what we actually do, including limitations.

3. Infrastructure

Production runs on Amazon Web Services in the Asia Pacific (Mumbai) region. We rely on AWS for physical and environmental security of the data centres; AWS maintains ISO 27001, SOC 1/2/3 and PCI DSS certifications for that infrastructure.

• Application and database servers run in a private network segment.
• Only necessary ports are exposed publicly; administrative access is restricted.
• Operating system and dependency patches are applied on a regular cycle, and promptly for high-severity vulnerabilities.
• Server and application logs are retained to support investigation.

4. Encryption

Layer	Measure
In transit	All traffic between the agent, browser, mobile app and our servers uses HTTPS with TLS 1.2 or above. Plain HTTP is not accepted for API traffic.
At rest	Database volumes and object storage are encrypted at rest using AES-256 managed encryption.
Passwords	Stored only as bcrypt hashes with a per-password salt. Plaintext passwords are never written to storage or logs, and cannot be recovered by us.
Session tokens	Signed JSON Web Tokens with a bounded lifetime. Web sessions expire after 8 hours; cookies are set HttpOnly and, in production, Secure.
Credentials	Third-party storage credentials supplied by customers are encrypted before storage.

5. Access control

5.1 Customer-facing

• Role-based access separates platform administration from organisation administration.
• Every API request is authenticated; unauthenticated requests are rejected before any data access.
• Password-reset flows use a one-time code with a short expiry window.
• Customers control who within their organisation is granted an administrator account.

5.2 Internal

• Production access is limited to a small number of named engineering personnel with an operational need.
• Access is individually attributed — shared logins are not used for administrative access.
• Access is reviewed periodically and revoked promptly on role change or departure.
• We do not routinely access customer monitoring data. Where support requires it, we act on the customer's request and limit access to what is necessary to resolve the issue.

6. Tenant isolation

eWorkPulse is multi-tenant. Every record — employees, activity logs, screenshots, summaries, policies, invoices — carries an organisation identifier, and every query is scoped to the organisation of the authenticated session. Requests cannot resolve data belonging to another organisation.

Integration APIs are additionally gated by a per-organisation token, so an integration credential grants access only to that organisation's data.

7. Desktop agent security

• The agent transmits only over authenticated HTTPS to our API. It does not accept inbound connections and does not open a listening port.
• It authenticates with a per-device token; a token is scoped to the organisation it was issued for.
• Privacy settings are enforced on the device. When a customer disables a collection category, that data is never captured and never leaves the machine — it is not collected-and-filtered server-side.
• The agent does not record keystrokes, capture passwords, read file or email contents, access the camera or microphone, or track GPS location.
• Agent health is monitored so customers can identify devices that have stopped reporting.

8. Screenshot handling

Screenshots are the most sensitive data the platform handles, and are treated accordingly:

• Screenshot capture can be disabled entirely, per organisation.
• Where enabled, capture interval is customer-configurable.
• Sensitive-content blurring can be enabled so that detected sensitive regions are obscured before the image is stored. Redaction is applied prior to storage, not at display time.
• Images are served only through an authenticated endpoint that verifies the requester belongs to the owning organisation. Raw storage paths are never exposed to clients.
• Screenshots are deleted automatically once the customer's retention period elapses, by a scheduled cleanup job.
• Customers may instead direct screenshots to storage they control (Amazon S3, Google Drive, Microsoft OneDrive). Data placed in customer-controlled storage is secured under that customer's own arrangements.

9. Data minimisation controls

Security is not only about protecting data — it is also about not collecting it. Customers can switch off application tracking, web-usage tracking, idle tracking and screenshots independently. We encourage enabling only what a documented business purpose requires.

Internally, our reporting is built on pre-aggregated daily summaries rather than repeatedly scanning raw activity records, which limits how widely detailed data is read during normal operation.

10. Retention & deletion

• Screenshot retention is customer-configured, defaulting to 30 days, and enforced by an automated job.
• Activity and analytics data is retained for the subscription term unless deleted earlier by the customer.
• On termination, customer data is deleted or irreversibly anonymised within 90 days, except where law requires retention.
• Backups are purged on their own rotation, within 35 days.

11. Backup & recovery

• Automated database backups are taken daily and retained on a rolling basis.
• Backups are encrypted at rest and held in the same jurisdiction as production.
• Restore procedures are documented and periodically exercised.

This policy does not commit to a specific recovery time objective (RTO) or recovery point objective (RPO). Customers requiring formal RTO/RPO commitments should raise this during contracting so it can be agreed in the order form.

12. Secure development

• All code changes are version-controlled with attributable history.
• Changes are reviewed before reaching production.
• Dependencies are monitored for known vulnerabilities and updated as advisories require.
• Secrets and credentials are supplied through environment configuration, not committed to source control.
• Development and production environments are separated. Production data is not used for development or testing.

13. Sub-processor management

We engage a small number of sub-processors — principally cloud hosting, email delivery and payment processing. Before engagement we assess their security posture and data-protection commitments, and we bind them contractually to confidentiality and to processing only on our instructions.

A current list of sub-processors is available on request to contact@eworkpulse.com. Customers on a signed Data Processing Agreement receive advance notice of changes as set out there.

14. People & training

• Personnel with access to production are bound by written confidentiality obligations.
• Access is granted on a need-to-know basis and revoked promptly on departure or role change.
• Personnel receive guidance on secure handling of customer data, phishing awareness and incident escalation.
• Devices used to access production must be password-protected and encrypted.

15. Incident response

We maintain a documented process for identifying, containing and remediating security incidents.

Stage	Commitment
Detect & triage	Assess severity, scope and affected organisations.
Contain	Immediate steps to stop ongoing exposure, including revoking credentials or suspending access.
Notify customers	Affected customers notified without undue delay and within 72 hours of confirming a personal-data breach, with the facts known at that point.
Notify regulator	Reported to the Data Protection Board of India as required by the DPDP Act, 2023.
Remediate & review	Root-cause analysis and corrective action, with a written summary provided to affected customers on request.

Because we act as processor for employee monitoring data, notification to affected individuals is generally made by the customer as Data Fiduciary. We will give them the information needed to do so.

16. Your security responsibilities

Security is shared. You are responsible for:

• choosing strong, unique passwords and not sharing administrator accounts;
• granting administrator access only to those who genuinely need it, and revoking it when staff change roles or leave;
• configuring collection settings and retention proportionately to your purpose;
• securing any third-party storage you connect (S3, Google Drive, OneDrive), including its access permissions;
• protecting exported reports and downloaded screenshots once they leave the platform;
• giving lawful notice to monitored individuals, as required by our Terms & Conditions.

17. Certifications & assurance

Our production infrastructure runs on Amazon Web Services, which maintains ISO 27001, SOC 1/2/3 and PCI DSS certification for the underlying platform and data centres.

At the application layer we operate the controls described throughout this policy, and we continue to invest in our security programme as the platform grows. Independent certification of the eWorkPulse application is on our roadmap.

We keep detailed security documentation for customer review. If your procurement process requires a security questionnaire, architecture detail or assurance evidence beyond this policy, contact us at contact@eworkpulse.com — we are happy to provide it under NDA and to discuss specific requirements before contracting.

18. Reporting a vulnerability

If you believe you have found a security vulnerability, please report it to contact@eworkpulse.com with enough detail to reproduce it.

We ask that you give us reasonable time to investigate and remediate before public disclosure, and that you avoid accessing, modifying or deleting data belonging to others while testing. We will acknowledge reports within 72 hours and keep you informed of progress. We will not pursue legal action against researchers who report in good faith and act within these limits.

Security reports, privacy & grievances, general support	contact@eworkpulse.com