Data Security Policy

Increeks takes the security of your personal data and our clients' business data seriously. This Data Security Policy describes the technical and organisational measures we implement to protect data against unauthorised access, disclosure, alteration, and destruction.

Security is embedded into every stage of our development and operations lifecycle — from infrastructure provisioning and application architecture to employee onboarding and vendor selection. We apply a defence-in-depth approach, layering multiple controls so that no single point of failure can compromise the confidentiality, integrity, or availability of data entrusted to us.

This policy applies to:

• All systems, applications, and services operated by Increeks.
• All personal data processed by Increeks as a data controller or data processor.
• All client data received in the course of delivering Product Studio, Design Studio, or INQB Zone services.
• All employees, contractors, and third-party service providers who access Increeks systems or data.

Increeks leverages leading cloud infrastructure providers with established security certifications to underpin our operations.

Hosting — Vercel

• Our primary web application is hosted on Vercel, which maintains SOC 2 Type II certification. Vercel's infrastructure provides automatic DDoS mitigation, global edge distribution, and built-in HTTPS enforcement.
• Vercel's security controls, including physical data centre security, network segmentation, and redundancy, are independently audited. Vercel's compliance documentation is available at their Trust Centre.

Database & Storage

• Databases and persistent storage are hosted on encrypted cloud providers (currently including services in the AWS and/or Google Cloud ecosystem, depending on the specific service). All providers are selected based on security certifications including SOC 2 Type II and ISO 27001 where available.
• Storage volumes are encrypted at rest by default (see the Encryption section).
• Database instances are not publicly accessible; they are accessible only from authorised application servers within private network boundaries.

Network Security

• All production systems are isolated within virtual private networks (VPCs) with strict inbound and outbound firewall rules.
• Administrative access to infrastructure is restricted to specific IP ranges and protected by multi-factor authentication (MFA).
• Unused ports and services are disabled. We follow the principle of least exposure.

Physical Security

Increeks is a cloud-native organisation and does not operate on-premise servers or data centres. Physical security of all data hosting infrastructure is the responsibility of our cloud providers, who maintain enterprise-grade physical security controls (CCTV, biometric access, 24/7 security personnel, and environmental controls) audited under SOC 2 and ISO 27001 frameworks.

Increeks employs strong encryption for data both in transit and at rest.

Encryption in Transit

• All data transmitted between clients (browsers, mobile apps) and Increeks servers is encrypted using TLS 1.2 or higher. TLS 1.0 and 1.1 are disabled.
• HTTPS is enforced on all public-facing endpoints. HTTP traffic is automatically redirected to HTTPS with HTTP Strict Transport Security (HSTS) headers enforced.
• Internal service-to-service communication within our infrastructure also uses TLS where technically feasible.
• Email in transit is protected by TLS (opportunistic and enforced where supported by the recipient mail server), as well as DKIM, SPF, and DMARC (see our Anti-Spam Policy for details).

Encryption at Rest

• All data stored on our cloud infrastructure (databases, object storage, backups) is encrypted at rest using AES-256 or equivalent industry-standard encryption algorithms.
• Encryption keys are managed by our cloud providers' managed key management services (e.g., AWS KMS, Google Cloud KMS), which provide hardware security module (HSM) backing and automatic key rotation.
• Employee laptops and workstations used for client work are required to have full-disk encryption enabled (FileVault on macOS, BitLocker on Windows).

Restricting access to data is one of our primary security controls. We apply the principle of least privilege across all systems.

Role-Based Access Control (RBAC)

• Access to production systems and client data is granted on a role-based basis. Each employee and contractor is assigned only the minimum permissions required to perform their job function.
• Access rights are reviewed quarterly and immediately upon a change of role, project assignment, or employment status.
• Access for former employees and contractors is revoked within 24 hours of departure.

Multi-Factor Authentication (MFA)

• MFA is mandatory for all administrative access to production systems, cloud consoles, code repositories, and any system storing personal data or client data.
• MFA is enforced at the identity provider level; it cannot be bypassed by individual users.

No Shared Credentials

• Shared passwords or shared administrative accounts are prohibited. Every individual has unique credentials, ensuring a clear audit trail of all access and actions.
• Service accounts (used by automated systems) are separate from human accounts and are granted only the specific permissions they require.

Password Policy

• All accounts are required to use strong, unique passwords managed via an approved password manager.
• Default passwords are changed immediately upon provisioning.
• Passwords are never stored in plain text; all credential stores use industry-standard hashing algorithms (bcrypt, Argon2, or equivalent).

Privileged Access Management

• Production database access for engineers is mediated through a privileged access management (PAM) tool with session logging and automatic session expiry.
• All privileged actions in production environments are logged and subject to periodic review.

Increeks integrates security practices into every stage of the software development lifecycle (SDLC).

OWASP Top 10 Mitigations

Our development practices address the OWASP Top 10 most critical web application security risks, including:

• Injection (A03): All database queries use parameterised statements or prepared queries. User input is never interpolated directly into SQL or other query languages.
• Broken Authentication (A07): Session tokens are generated using cryptographically secure random number generators, have appropriate expiry, and are invalidated on logout.
• XSS (A03): All user-controlled data rendered in the browser is contextually escaped. We use framework-level auto-escaping where available.
• CSRF (A01): State-changing requests require CSRF tokens or use SameSite cookie attributes to prevent cross-site request forgery.
• Security Misconfiguration (A05): Default configurations are reviewed and hardened before deployment. Debug modes are disabled in production.
• Vulnerable Components (A06): Third-party dependencies are scanned for known vulnerabilities as part of our CI/CD pipeline (see below).

Input Validation

All input received by our applications — from web forms, API endpoints, and file uploads — is validated on both the client side and the server side. Server-side validation is the authoritative control; client-side validation is for user experience only and cannot be relied upon as a security control.

Security Headers

All Increeks web applications serve the following security headers:

Dependency Scanning

• Our CI/CD pipeline includes automated dependency vulnerability scanning on every pull request and on a nightly schedule, using tools such as npm audit, Snyk, or equivalent.
• Critical and high-severity vulnerabilities in dependencies block deployment until resolved.

Code Review

All code changes require peer review before merging to the main branch. Security implications are explicitly considered as part of the review checklist. No direct commits to the production branch are permitted.

Increeks uses a curated set of third-party service providers (sub-processors) to deliver our services. We apply rigorous security standards to all vendor relationships.

• Data Processing Agreements (DPAs): We enter into a Data Processing Agreement with every sub-processor that processes personal data on our behalf, as required by GDPR Article 28. DPAs specify the nature of processing, data subject rights procedures, security obligations, and sub-processor restrictions.
• Security assessment: Before onboarding a new vendor with access to personal data or client data, we assess their security posture, including review of their security certifications (SOC 2, ISO 27001, or equivalent), privacy policies, and DPA terms.
• Annual review: All sub-processor relationships are reviewed annually to ensure continued compliance with our security and privacy standards.
• Minimum security requirements: Vendors must demonstrate encryption in transit and at rest, access controls, and incident notification procedures consistent with our own standards.
• Sub-processor list: A current list of sub-processors is maintained and made available to clients and data subjects upon request at hello@increeks.com.

Human error is a leading cause of security incidents. Increeks invests in continuous security awareness education for all team members.

• Onboarding training: All new employees and contractors complete mandatory security awareness training covering data handling, phishing recognition, password hygiene, incident reporting, and acceptable use of company systems before being granted access to production systems.
• Annual refresher: All team members complete annual security awareness training. Training content is updated to reflect current threat landscapes.
• Developer security training: Engineers and designers with access to production code or systems receive role-specific security training covering OWASP Top 10, secure coding practices, and relevant regulatory requirements.
• Phishing simulation: We periodically conduct simulated phishing exercises to test and reinforce awareness. Results are used to inform targeted training, not for punitive purposes.
• Policies & acceptable use: All team members acknowledge our Information Security Policy, Acceptable Use Policy, and Data Protection Policy upon joining and annually thereafter.

Increeks maintains a documented Incident Response Plan (IRP) to ensure that security incidents are identified, contained, investigated, and communicated in an organised and timely manner.

Incident Response Phases

1. Identification: Potential security incidents are identified through monitoring alerts, vulnerability scans, employee reports, or third-party notifications. All suspected incidents are reported immediately to the designated Security Lead.
2. Containment: Upon confirmation of an incident, immediate steps are taken to contain the breach — including isolating affected systems, revoking compromised credentials, and blocking malicious traffic.
3. Eradication: The root cause of the incident is identified and eliminated. Affected systems are cleaned, patched, and hardened before restoration.
4. Recovery: Systems are restored from clean backups or rebuilt from verified source code. Recovery is monitored to confirm the incident has been fully resolved.
5. Post-incident review: A post-mortem is conducted within 5 business days of resolution, documenting the timeline, root cause, impact, and corrective actions. Lessons learned are incorporated into security controls and training.

Breach Notification

In the event of a personal data breach, we will notify affected individuals and relevant authorities in accordance with applicable law:

Breach notifications will include: the nature of the breach, categories and approximate number of individuals and records affected, likely consequences of the breach, and measures taken or proposed to address the breach and mitigate its effects.

Increeks maintains robust backup procedures to ensure the availability and integrity of data and to support rapid recovery from incidents, infrastructure failures, or disasters.

• Backup frequency: All production databases are backed up daily. Transaction logs are captured continuously for point-in-time recovery where supported.
• Encryption: All backups are encrypted at rest using AES-256. Backup encryption keys are stored separately from the backup data.
• Retention: Daily backups are retained for 30 days. Additional monthly snapshots are retained for 12 months for compliance and disaster recovery purposes.
• Geographic redundancy: Backups are stored in at least one geographically separate region from the primary data store, to protect against regional infrastructure failure.
• Restore testing: Backup restoration procedures are tested quarterly to verify that backups are complete, uncorrupted, and recoverable within our defined Recovery Time Objective (RTO) and Recovery Point Objective (RPO).
• RTO / RPO targets: Our target RTO (time to restore service) is 4 hours for critical systems. Our target RPO (maximum tolerable data loss) is 24 hours for standard data, and near-zero for systems with continuous transaction log capture.

Increeks maintains an ongoing programme of security testing to proactively identify and remediate vulnerabilities before they can be exploited.

Automated Scanning

• CI/CD pipeline scanning: Static application security testing (SAST) and dependency vulnerability scanning run on every code commit.
• Dynamic scanning (DAST): Automated dynamic application security testing is run against staging environments on a weekly basis.
• Infrastructure scanning: Cloud infrastructure configuration is scanned for misconfigurations and policy violations using automated cloud security posture management (CSPM) tools.

Manual Code Review

In addition to automated scanning, security-focused manual code review is performed for all new features and significant changes to authentication, authorisation, data handling, or cryptography code.

Penetration Testing

• We conduct an independent third-party penetration test annually, covering web application, API, and infrastructure attack surfaces.
• Findings are triaged by severity. Critical and high findings are remediated within 30 days; medium findings within 90 days.
• Pentest reports are available to enterprise clients under NDA upon request.

Vulnerability Disclosure

We operate a responsible disclosure programme — see the Report a Vulnerability section for details.

Increeks aligns its security practices with the following regulatory frameworks and standards:

Compliance documentation, including our Data Processing Register, sub-processor list, and DPA template, is available to clients and partners upon request at hello@increeks.com.

Increeks operates a responsible disclosure programme. If you have discovered a potential security vulnerability in any Increeks system or application, we encourage you to report it to us privately so we can address it before it is exploited.

How to Report

• Email: security@increeks.com
• PGP encryption: If you wish to send a sensitive report securely, our PGP public key is available on request at the same address. Please request the key before sending confidential details.

What to Include

1. A description of the vulnerability and its potential impact.
2. The affected system or URL.
3. Step-by-step instructions to reproduce the issue.
4. Any proof-of-concept code (if applicable), attached as a file rather than embedded in the email body.
5. Your name and contact details (optional — anonymous reports are accepted, but providing contact details enables us to ask follow-up questions).

Our Responsible Disclosure Commitments

• Acknowledgement: We will acknowledge receipt of your report within 2 business days.
• Status updates: We will provide updates on our investigation and remediation progress at least every 7 days.
• Remediation window: We request a 90-day responsible disclosure window from the date of acknowledgement to investigate and remediate the issue before public disclosure. We will work to meet this timeline and will communicate proactively if additional time is needed.
• No legal action: We will not pursue legal action against security researchers who report vulnerabilities in good faith and in accordance with this policy.
• Credit: With your permission, we will acknowledge your contribution in our security hall of fame or release notes upon remediation.

Scope

In-scope for vulnerability disclosure:

• increeks.com and all sub-domains operated by Increeks.
• Increeks-operated APIs and application endpoints.

Out of scope:

• Social engineering attacks targeting Increeks employees.
• Physical attacks against Increeks offices or team members.
• Vulnerabilities in third-party services not directly controlled by Increeks (please report those to the relevant vendor).
• Denial-of-service attacks or volumetric testing against production systems.

For questions about this Data Security Policy, to request compliance documentation, or to notify us of a security concern:

• Security vulnerabilities: security@increeks.com
• General security enquiries & compliance documentation: hello@increeks.com

Increeks
Bengaluru, Karnataka, India

This policy was last updated on 31 March 2026 and is effective from 1 April 2026. We review and update this policy at least annually, or following any significant changes to our security architecture or applicable regulatory requirements.