Security & Trust Center

NDesk implements a defense-in-depth security strategy across our entire platform. Our security programme is designed to protect the confidentiality, integrity, and availability of customer data at every layer of our architecture.

1. Purpose

This policy establishes the framework for identifying, assessing, and managing risks associated with third-party vendors and service providers that have access to, process, or store NDesk customer data. It satisfies SOC 2 Trust Service Criteria CC9.2 (Risk Assessment of Third Parties) and ISO 27001 Control A.15.1 (Information Security in Supplier Relationships).

2. Scope

This policy applies to all third-party vendors, service providers, and subprocessors that:

• Process, store, or transmit NDesk customer data
• Have access to NDesk production systems or infrastructure
• Provide critical services that affect NDesk platform availability
• Deliver software components integrated into the NDesk platform

3. Vendor Classification

Vendors are classified by risk tier based on their level of access and criticality:

4. Assessment Process

Before onboarding any new vendor, the following due diligence steps are performed:

• Security Questionnaire: Vendors must complete NDesk's security assessment questionnaire covering data handling, encryption, access controls, and incident response.
• Compliance Verification: Review of vendor's SOC 2 reports, ISO 27001 certificates, or equivalent security certifications.
• Data Flow Analysis: Mapping of what customer data the vendor will access, how it flows, where it's stored, and retention policies.
• Contractual Review: Ensuring Data Processing Agreements (DPAs), confidentiality clauses, and liability provisions are in place.
• Business Continuity: Evaluation of vendor's disaster recovery plans and SLA commitments.

5. Ongoing Monitoring

• Continuous monitoring of vendor security posture through automated tools
• Periodic reassessment based on vendor tier classification
• Immediate reassessment triggered by security incidents or significant changes
• Annual review of all active vendor relationships by the security team

6. Current Vendor Register

1. Purpose

This policy mandates regular security reviews of all external libraries, frameworks, and third-party services integrated into the NDesk platform. It ensures that supplier relationships do not introduce unacceptable security risks and that all external dependencies meet NDesk's information security standards.

2. Supplier Security Requirements

All suppliers and external service providers must:

• Maintain security certifications: SOC 2 Type II, ISO 27001, or equivalent industry-recognised certifications
• Provide transparency: Make security documentation, audit reports, and incident history available upon request
• Implement encryption: Encrypt data at rest and in transit using industry-standard algorithms (AES-256, TLS 1.2+)
• Support data deletion: Provide mechanisms for data deletion upon contract termination or customer request
• Notify of incidents: Report any security incidents affecting NDesk data within 24 hours of detection

3. External Library Review Process

For all third-party libraries and dependencies (npm packages, CDN scripts, etc.):

• Pre-integration review: Security assessment before adding any new dependency, including licence review, vulnerability history, and maintainer reputation
• Automated scanning: Continuous dependency vulnerability scanning using automated tools integrated into the CI/CD pipeline
• Version pinning: All production dependencies are version-pinned to prevent supply chain attacks from unexpected updates
• Quarterly audit: Full review of all third-party dependencies for known vulnerabilities and update status
• SRI consideration: Where feasible, Subresource Integrity (SRI) hashes are used for externally-hosted scripts. For dynamically-generated CDN scripts (such as appllm-lib.js), alternative controls including CSP directives are enforced

4. Specific Service Reviews

1. Purpose

This policy outlines the secure coding practices, security controls, and development standards followed in the NDesk platform. Built on the Next.js framework, the platform implements multiple layers of security to protect against common web vulnerabilities as classified by OWASP.

2. Security Architecture

The NDesk platform implements the following security controls at the application layer:

2.1 Content Security Policy (CSP)

A strict Content Security Policy is enforced via HTTP response headers on every request. The policy restricts script sources to trusted domains only, prevents inline script execution where possible, and blocks unauthorized resource loading. CSP violation reports are collected and monitored.

2.2 Input Validation & Sanitisation

• All user inputs are validated and sanitised on the server side before processing
• A centralised validateAndSanitize utility enforces type-specific validation rules (email, phone, text, password, subdomain)
• Malicious input detection (XSS, SQL injection, command injection patterns) is applied to all API endpoints
• Detected injection attempts are logged with severity ratings for security team review
• HTML content (such as ticket descriptions) is sanitised using a comprehensive sanitizeHtmlContent function that strips dangerous tags and attributes

2.3 Authentication & Session Management

• Authentication powered by NextAuth.js with secure session handling
• Passwords hashed using bcrypt with appropriate salt rounds
• Strong password policy enforced: minimum 8 characters, uppercase, lowercase, number, and special character required
• Brute-force protection with progressive account lockout after failed attempts
• Session tokens are HTTP-only, secure, and have appropriate expiry
• Google SSO available as an additional secure authentication method

2.4 Multi-Tenancy & Data Isolation

• Complete data isolation between tenants enforced at the database query level
• Every API request validates tenant context from the authenticated session
• Role-based access control (RBAC) with distinct permission levels: Customer, Agent, Admin, Super Admin
• Tenant-scoped database queries prevent cross-tenant data leakage

2.5 HTTP Security Headers

The following security headers are set on all responses via middleware:

• Strict-Transport-Security: HSTS with max-age 63072000, includeSubDomains, preload
• X-Content-Type-Options: nosniff
• X-XSS-Protection: 0 (CSP is the primary XSS defence)
• Referrer-Policy: strict-origin-when-cross-origin
• Permissions-Policy: Restrictive feature policy

2.6 Secure Coding Standards

• TypeScript for compile-time type safety across the entire codebase
• Parameterised database queries via Prisma ORM — no raw SQL concatenation
• Environment variables for all secrets and credentials — never hardcoded
• Server-side rendering (SSR) for sensitive operations to prevent client-side exposure
• API routes validate authentication and authorisation before processing any request

1. Purpose

NDesk incorporates AI-powered features to enhance helpdesk operations, including ticket categorisation, smart reply suggestions, similar ticket detection, and AI-assisted chat. This policy defines the controls that ensure customer data is processed accurately, completely, and without unauthorised data leakage when using these AI capabilities.

2. AI Features & Data Handling

3. Data Protection Controls

• Data Minimisation: Only the minimum data necessary for the AI feature to function is sent to the LLM provider. Full customer records are never transmitted.
• Tenant Isolation: AI processing is strictly scoped to the requesting tenant. Cross-tenant data is never included in AI prompts or context.
• No Training on Customer Data: The LLM provider (Abacus AI RouteLLM) does not use NDesk customer data for model training. All API calls are stateless processing requests.
• Secure Transmission: All data sent to AI services is transmitted over encrypted HTTPS connections with API key authentication.
• Output Validation: AI-generated outputs (categories, replies, etc.) are validated before being applied to ensure data integrity and prevent prompt injection attacks.

4. Accuracy & Quality Controls

• Human Review: AI suggestions (reply suggestions, categorisation) are presented as recommendations — agents always have the final decision
• Audit Trail: All AI-assisted actions are logged in the ticket audit trail, clearly marked as AI-generated
• Feedback Loop: Agents can override and correct AI suggestions, which improves future accuracy
• Fallback Handling: If the AI service is unavailable, all features gracefully degrade — no ticket processing is blocked

5. Risk Mitigation

• Regular review of LLM provider's data handling and privacy practices
• Monitoring of AI response quality and accuracy metrics
• Prompt injection prevention through input sanitisation before AI processing
• Rate limiting on AI endpoints to prevent abuse

NDesk processes customer data in accordance with applicable data protection regulations. For detailed information about how we handle personal data, please refer to ourPrivacy Policy andData Processing Agreement.

• Data Residency: Customer data is stored in secure, SOC 2 certified data centres
• Data Retention: Data is retained only as long as necessary for service delivery and legal compliance. Customers can request data deletion at any time.
• Data Portability: Customers can export their data in standard formats at any time through the platform
• Breach Notification: In the event of a data breach, affected customers will be notified within 72 hours as required by applicable regulations

NDesk maintains a documented incident response plan to ensure swift and effective response to security events. Our process follows these key phases:

1. Detection & Triage: Automated monitoring and security event logging enable rapid detection. Events are triaged by severity (Critical, High, Medium, Low).
2. Containment: Immediate actions to contain the threat, including account lockouts, IP blocking, and service isolation as needed.
3. Investigation: Thorough analysis of the incident scope, root cause, and affected data using audit logs and security event records.
4. Recovery: Restoration of affected services with verified integrity. All recovery actions are documented.
5. Notification: Affected customers are notified within 72 hours of confirmed data breaches, with details on the incident and remediation steps.
6. Post-Mortem: After resolution, a post-mortem review identifies improvements to prevent recurrence.