Security Policy

1. Our security commitment

SSDB Tech Services, Inc. is committed to protecting the confidentiality, integrity, and availability of the CORE platform and all data processed through it. We apply a defence-in-depth approach, implementing security controls at every layer — infrastructure, application, data, AI processing pipeline, and people — and continuously reassessing them against evolving threats.

CORE is an AI-powered platform that processes potentially sensitive business information on behalf of enterprise customers. We treat this responsibility with commensurate seriousness. Our security programme is aligned with internationally recognised frameworks including NIST SP 800-53, OWASP Top 10, and ISO/IEC 27001 principles.

2. Platform and infrastructure security

3. Application security

Security is embedded throughout CORE's software development lifecycle:

• Secure development practices: Our engineering team follows OWASP Secure Coding Guidelines and industry best practices. Security requirements are defined alongside functional requirements, not added after build.
• Code review: All code changes undergo peer review that explicitly includes security assessment before merging. Security-sensitive changes require review by a security-designated team member.
• Static analysis: Automated static analysis tools scan code for known vulnerability patterns on every commit. Identified vulnerabilities are triaged and remediated before deployment.
• Dependency management: Third-party libraries and dependencies are monitored for known vulnerabilities using automated tooling. Security patches are applied within defined SLAs based on severity (critical: 24 hours; high: 7 days; medium: 30 days).
• Penetration testing: CORE undergoes independent penetration testing at least annually and after significant architectural changes. Findings are tracked to remediation.
• OWASP Top 10: CORE is designed and tested against the current OWASP Top 10 Web Application Security Risks. Automated scanning for OWASP Top 10 vulnerabilities is integrated into our deployment pipeline.

4. Authentication security

CORE currently authenticates users via enterprise Single Sign-On (SSO) through Microsoft identity services. This approach provides:

• Delegation of credential management and multi-factor authentication to your organisation's identity provider
• No storage of passwords by SSDB Tech — we do not handle, store, or have access to user passwords
• Enterprise-grade session management with token expiry and revocation capabilities
• Automatic revocation of CORE access when a user's account is disabled in your identity provider

As CORE expands to support additional authentication methods, this section will be updated. All authentication methods will be required to support multi-factor authentication.

5. AI pipeline security

CORE processes user inputs through third-party AI model APIs. We apply the following security measures to the AI processing pipeline:

• Transmission security: All data transmitted to AI sub-processors is transmitted over encrypted connections (TLS) and is subject to contractual security requirements under our Data Processing Agreements with each AI provider.
• Input validation and sanitisation: User inputs are validated and sanitised before being passed to AI models to mitigate prompt injection and related attack vectors.
• Output validation: AI-generated outputs are processed through validation layers before being presented to users. Mandatory human review at each workflow stage provides an additional security control layer.
• Sub-processor security requirements: AI sub-processors are required under contract to maintain appropriate security standards. We conduct due diligence on their security practices and review their published security documentation.
• No cross-customer contamination: AI processing sessions are stateless and isolated. No data from one user's session influences another's. AI models used by CORE do not retain or learn from your inputs.

6. Organisational security

Personnel security

All SSDB Tech employees and contractors with access to production systems or customer data undergo background screening appropriate to their role and jurisdiction. Access is provisioned on joining and promptly revoked on departure. Security awareness training is mandatory for all personnel on joining and is refreshed at least annually.

Third-party security management

SSDB Tech exercises due diligence in selecting and onboarding third-party service providers. Providers who access customer data are subject to Data Processing Agreements and must demonstrate appropriate security standards. We review third-party security posture as part of our ongoing supplier management programme.

Incident response

We maintain a documented Security Incident Response Plan covering detection, containment, investigation, notification, and post-incident review. Our response SLAs are:

• Detection and initial response: Within 4 hours of confirmed incident identification
• Customer notification (where data is affected): Within 72 hours of becoming aware of a personal data breach, in compliance with GDPR Article 33 and equivalent obligations
• Regulatory notification: Within required timeframes under applicable law, which in the US may vary by state and sector
• Post-incident review: Within 30 days of incident resolution

7. Security in Core-generated software

When CORE generates software specifications and code, it incorporates security controls appropriate to the requirements specified during the setup process. Depending on the compliance and data sensitivity requirements you specify, Core-generated applications include:

• Role-based access control (RBAC) with granular, least-privilege permission structures
• Secure session management and industry-standard authentication patterns
• Input validation and output encoding to prevent injection vulnerabilities
• Immutable audit trails for compliance-sensitive operations
• Encryption at rest and in transit, configured to the sensitivity level of the data you specify
• Security test cases generated by CORE covering OWASP Top 10 and, where specified, VAPT scenarios
• Compliance framework controls (GDPR, HIPAA, SOC 2, PCI-DSS, ISO 27001, and others as specified)

Important: Security controls built into Core-generated outputs are based on the requirements you specify and approve during the CORE workflow. SSDB Tech does not warrant that generated outputs are free from all security vulnerabilities. Independent security review — including penetration testing and code review — must be conducted before deploying any Core-generated software in a production environment. See our Disclaimer.

8. Your security responsibilities as a user

Security is a shared responsibility. As a CORE user, you are responsible for:

• Maintaining the security of the Microsoft (or other SSO) account used to access CORE, including enabling MFA within your identity provider
• Ensuring that CORE access credentials and session tokens are not shared with unauthorised individuals
• Promptly deprovisioning CORE access for users who leave your organisation or no longer require access
• Not uploading data to CORE that you are not authorised to process or that would be harmful if exposed
• Conducting independent security review and penetration testing of any software deployed from CORE outputs before going live
• Reporting any suspected security vulnerabilities, unauthorised access, or security incidents promptly using the contact details below

9. Responsible disclosure

10. Compliance framework alignment

SSDB Tech's security programme aligns with the following frameworks and standards:

• NIST SP 800-53 — Security and Privacy Controls for Information Systems
• OWASP Top 10 — Web Application Security Risks
• ISO/IEC 27001 — Information Security Management (as a guiding framework)
• SOC 2 Trust Services Criteria — Security, Availability, and Confidentiality principles
• GDPR and UK GDPR — Data protection by design and by default (Article 25)
• CCPA/CPRA — California privacy and security requirements
• EU AI Act — Transparency and risk management requirements applicable to AI systems

11. Updates to this policy

This Security Policy is reviewed at minimum annually and updated to reflect material changes in our security practices, technology, or the regulatory landscape. The "Last updated" date at the top of this page reflects the most recent revision. Material changes will be communicated to active customers by email with reasonable advance notice.