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.

DataSecurity.sections.infrastructure.content

DataSecurity.sections.encryption.content

DataSecurity.sections.access-control.content

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:

Header	Purpose
Content-Security-Policy (CSP)	Restricts sources of scripts, styles, images, and other resources to prevent XSS.
Strict-Transport-Security (HSTS)	Enforces HTTPS connections and prevents downgrade attacks.
X-Frame-Options	Prevents clickjacking by disallowing the page to be embedded in iframes.
X-Content-Type-Options	Prevents MIME-type sniffing attacks.
Referrer-Policy	Controls referrer information sent with requests to protect user privacy.
Permissions-Policy	Restricts browser feature access (camera, microphone, geolocation) to those explicitly required.

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.

DataSecurity.sections.vendor-management.content

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:

Jurisdiction	Obligation	Timeframe
European Union / EEA (GDPR)	Notify supervisory authority (Art. 33); notify affected data subjects if high risk (Art. 34)	72 hours of becoming aware (authority); without undue delay (individuals)
United Kingdom (UK GDPR)	Notify ICO; notify individuals if high risk	72 hours (ICO); without undue delay (individuals)
India (DPDP Act 2023)	Notify Data Protection Board of India and affected data principals	As prescribed by the Board (rules forthcoming); we target notification within a reasonable time
United States (State laws)	Notify affected residents per applicable state breach notification laws	Varies by state; generally within 30–72 hours of discovery

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.

DataSecurity.sections.data-backup.content

DataSecurity.sections.audit.content

DataSecurity.sections.compliance.content

DataSecurity.sections.report-vulnerability.content

DataSecurity.sections.contact.content