1.Purpose and scope
This page summarizes Pikorua Security's Information Security Policy and the standards beneath it. The full policy set and our SOC 2 Type II report are available under NDA in the Trust Center.
The policy applies to every Pikorua Security employee and contractor in the United States and India, to every system that stores or processes customer data, and to the vendors we rely on to run the service.
2.Governance and ownership
Rahul Saxena, CISSP, Head of Security & Compliance, owns the program and reports to our CTO, Siddharth Menon. A security committee made up of the CEO, CTO, Head of Security & Compliance and VP Product meets monthly to review risks, incidents, audit findings and policy exceptions.
Every policy has a named owner and is reviewed at least once a year. An exception requires written approval, a compensating control and an expiry date.
3.Risk management
We run a formal risk assessment every year and whenever we make a significant change to our architecture, vendors or business processes. Each risk is scored for likelihood and impact, recorded in a risk register with an owner and a treatment plan, and reviewed by the security committee until it is closed or formally accepted.
4.Asset management and data classification
We keep an inventory of production systems, laptops and SaaS tools. Data is classified as Public, Internal, Confidential or Restricted. Customer data is Confidential. Taxpayer identification numbers, credentials and encryption keys are Restricted and carry extra controls, including field-level encryption and masked display.
5.Access control
- Access follows least privilege and is granted by role. Staff sign in through single sign-on with phishing-resistant multi-factor authentication (FIDO2 security keys).
- There is no standing staff access to customer data. Production access is time-limited, approved for each session and logged.
- Access is reviewed every quarter, adjusted within 24 hours of a role change and revoked on the day someone leaves.
- Inside the application, the Project Manager, Risk Manager, Accountant, Admin and Broker guest roles apply the same least-privilege principle to customer users.
6.Personnel security
We run background checks before hire where local law allows, in both the United States and India. Every employee and contractor signs confidentiality and acceptable use agreements at onboarding. Security and privacy training happens at hire and every year after, with phishing simulations each quarter. Engineers also complete secure coding training each year.
7.Encryption and key management
- AES-256 encryption at rest for databases, object storage, backups and queues, with keys managed in AWS Key Management Service and rotated annually.
- Field-level envelope encryption for taxpayer identification numbers, using a separate data key for each customer tenant.
- TLS 1.3 for connections to the application, API and upload links, with HTTP Strict Transport Security enforced.
- Secrets stored in AWS Secrets Manager and never committed to source code; automated scanning blocks any commit that contains one.
8.Infrastructure and network security
Production runs in AWS us-east-1 across multiple Availability Zones, with failover to us-west-2. Workloads sit in private subnets; only load balancers face the internet, behind a web application firewall. Infrastructure is defined as code and reviewed like application code.
Production, staging and development run in separate AWS accounts, and customer data never enters non-production environments.
9.Secure development lifecycle
Every change is reviewed by a second engineer in a pull request and passes automated checks: static analysis, dependency scanning, secrets detection and infrastructure policy checks. Changes that touch authentication, permissions or encryption also need a security review. Deployments are automated, logged and can be rolled back in minutes.
10.Vulnerability management and penetration testing
We scan dependencies and container images continuously, run authenticated infrastructure scans every week, and commission an independent penetration test every year, plus targeted tests after major releases. Findings are tracked to closure against the remediation targets below, measured from the time a finding is confirmed.
| Severity | Remediation target | Typical examples |
|---|---|---|
| Critical | 7 days | Remote code execution, authentication bypass, cross-tenant data access |
| High | 30 days | Privilege escalation inside a tenant, stored XSS in an authenticated view |
| Medium | 90 days | Missing rate limit on a non-sensitive endpoint, verbose error messages |
| Low | 180 days | Hardening recommendations, informational scanner findings |
11.Logging and monitoring
Application, infrastructure and access logs are centralized, protected from modification, kept online for 1 year and archived for up to 7 years. Alerts for suspicious sign-ins, privilege changes and unusual export volumes page the on-call engineer around the clock.
12.Incident response
Our incident response plan defines severity levels, roles, escalation paths and communication templates, with on-call coverage 24 hours a day, 7 days a week. When an incident affects customer data, we notify affected customers without undue delay and within 48 hours of becoming aware of it, as our Data Processing Addendum commits. Every significant incident gets a written post-incident review within 10 business days, and we test the plan with a tabletop exercise twice a year.
13.Business continuity and disaster recovery
Databases are backed up continuously with point-in-time recovery for 35 days, and encrypted copies are replicated to us-west-2. Our targets for the core service are a recovery point objective of 1 hour and a recovery time objective of 4 hours. We test regional failover at least once a year and record the results.
14.Vendor risk management
Vendors are reviewed before onboarding and every year after, at a depth that matches the data they can reach: SOC 2 or ISO/IEC 27001 reports, security questionnaires and contract terms that include data protection clauses. Vendors that process customer data are listed on our Subprocessors page.
15.Physical security
Production runs in AWS data centers, whose physical controls are covered by AWS's own independent audits. Our Delhi office uses badge access, visitor logs and CCTV. Customer data is never stored on office networks; staff work on managed, fully encrypted laptops that can be locked and wiped remotely.
16.Data retention and disposal
Customer data is kept under each customer's retention settings and our Privacy Policy. Deleted data is removed from production within 30 days and ages out of backups within a further 35 days. Returned laptops are wiped with a cryptographic erase before reuse.
17.Compliance and audit
An independent CPA firm audits our controls every year for SOC 2 Type II, covering the Security, Availability and Confidentiality trust services criteria. Our security team tests key controls internally every quarter. Breaches of this policy can lead to disciplinary action, up to and including termination of employment or contract.
18.Reporting a vulnerability
If you believe you have found a vulnerability, email security@pikoruasecurity.com. Our contact details and disclosure policy are also published at /.well-known/security.txt. We acknowledge reports within 2 business days and will not pursue legal action against researchers who act in good faith, avoid privacy violations and service disruption, and give us reasonable time to fix the issue before disclosure.