Security overview

1. Scope

This document covers the production environment of the pPULSE platform, our marketing website, our internal systems used to operate the Services, and our staff who have access to any of these. It does not cover individual customers' own networks, devices, or third-party integrations they choose to enable.

2. Tenancy and isolation

pPULSE is a multi-tenant software-as-a-service platform. Each customer organisation is provisioned into a logically isolated tenancy. Application code routes every request to the correct tenancy based on the authenticated user's organisation membership; cross-tenancy reads and writes are denied at the data-access layer.

Tenancies are not commingled in shared records. Indexes, foreign keys, and queries are constructed so that one customer cannot, through any normal use of the application, see or modify data belonging to another.

3. Identity and access

3.1 Staff access

Internal access to production systems is granted on a least-privilege basis to a limited number of named individuals. Access requires multi-factor authentication and is reviewed at least quarterly. Privileged actions are logged and reviewed.

3.2 Customer access

Customers manage their own users through an admin console. The platform supports role-based access control with a default set of system roles (SuperAdmin, Org Admin, Org Viewer) and an unlimited number of custom roles per organisation. Each role is bound to a granular permission matrix that controls every permissioned action in the application.

3.3 Single sign-on

Customers can connect Google Workspace and Microsoft 365 OAuth single sign-on for their authorised users. Additional identity-provider integrations are on the roadmap.

4. Authentication for end users

Authorised users authenticate with email and password protected by a modern password-hashing algorithm, or through single sign-on. Multi-factor authentication using time-based one-time passwords is supported and can be enforced by administrators per role or organisation. Session tokens are short-lived; refresh tokens are bound to the device.

Candidates and other external participants do not create accounts. They access screening invitations, document-upload portals, offer-letter signing, and referral submissions through one-time signed tokens that expire after a configurable period or on first use, depending on the workflow.

5. Encryption

In transit. All connections between end users and the Services use TLS 1.2 or higher with modern cipher suites and certificate pinning where supported. HTTP traffic is redirected to HTTPS, and HSTS is enforced for the production domain.

At rest. Backing storage and backups are protected using the encryption-at-rest features of the underlying cloud infrastructure provider. Field-level encryption for sensitive identifiers is on our security roadmap and is not represented as currently in place.

6. Network and application security

• Production traffic is fronted by a managed CDN and web-application firewall that filters common application-layer attacks.
• Rate limiting protects authentication, document-upload, and high-cost endpoints against abuse.
• Public application endpoints set strict transport security, frame ancestors, and a content security policy that disallows untrusted scripts.
• Internal services communicate over private networks; only explicit ingress/egress points are exposed.

7. Audit logging

The Services maintain an append-only audit log of administrative and security-sensitive events, organised into nine event categories. Each entry records the actor, action, target, timestamp, and a categorisation of severity. Customers can review and export their organisation's audit log for compliance and forensic purposes. Logs are retained for at least twelve (12) months.

8. Vulnerability management

We monitor first-party and third-party dependencies for known vulnerabilities and apply patches according to severity:

• Critical: patched within seven (7) days of confirmation.
• High: patched within thirty (30) days.
• Medium and below: patched on a routine cadence as part of regular release cycles.

We perform internal security testing on every significant release and engage independent third-party penetration testers periodically. Summary letters are available to customers under non-disclosure once available.

9. Secure software development

• All production code changes pass peer review before merge.
• Continuous integration runs automated tests, dependency scans, and static analysis on every change.
• Secrets and credentials are kept out of source control and are managed through a dedicated secrets store.
• Engineers receive periodic security awareness and secure-coding training.

10. Backup and continuity

Customer data is backed up on a continuous basis to durable storage in the same regional infrastructure. Backups are tested for restorability on a regular cadence. Recovery objectives are documented internally and we are willing to share specifics under mutual non-disclosure with prospective enterprise customers.

11. Incident response

We maintain a written incident-response plan that defines severity levels, on-call rotations, internal communications, customer notification, and post-incident review. In the event of a confirmed personal-data breach, we notify affected customers without undue delay in accordance with our DPA and applicable law.

12. Personnel security

• Employment offers are subject to background checks where permitted by law.
• All staff sign confidentiality and acceptable-use agreements as a condition of employment.
• Access to production systems is removed promptly on offboarding.
• Workstations are managed and protected with disk encryption and endpoint security software.

13. Sub-processors

We use a small number of carefully selected sub-processors for hosting, email delivery, error monitoring, calendar/video integrations (only when customers connect them), large-language-model resume parsing, and customer-support tooling. Each sub-processor is bound by data-protection terms at least as protective as our own. The current list and a description of each sub-processor's role is available on request from security@ppulse.com.

14. Compliance roadmap

We are working toward formal third-party attestations and certifications. As of the "Last updated" date at the top of this page, our public commitments are:

• SOC 2 Type II: in progress. We will publish the report on the Trust center when available, under mutual non-disclosure.
• ISO/IEC 27001: in scoping. We have not yet been audited.
• India DPDP Act, 2023: readiness assessment ongoing. The full Act is being phased in by rule; we track changes and will update this page as obligations come into force.
• EU GDPR: we offer standard contractual clauses to EU customers and act as a processor under our DPA.

We do not claim certifications we have not yet received. If a procurement questionnaire requires evidence of a control or certification not described here, please reach out and we will tell you exactly where we stand.

15. Reporting a security issue

We appreciate responsible disclosure. If you believe you have found a vulnerability or other security issue in the Services, please email security@ppulse.com with a description of the issue, steps to reproduce, and any other relevant context. We commit to acknowledging your report within five (5) business days and will not pursue legal action against good-faith researchers who follow this process and avoid privacy violations, service disruption, or destruction of data during testing.

16. Contact

Kaaspo Enterprises Private Limited
Attn: Security
Chennai, Tamil Nadu, India
Email: security@ppulse.com