1. Security Programme
ContractX is intended to operate a risk-based information security programme proportionate to the sensitivity of contractual, commercial, schedule, claims, and project information processed through the platform.
The security programme is designed around defence in depth, least privilege, need-to-know access, tenant isolation, secure-by-default configuration, auditability, confidentiality, integrity, availability, resilience, and continual improvement.
2. ISO/IEC 27001:2022 Alignment
ContractX intends its production information security management system (“ISMS”) to be designed and operated in alignment with ISO/IEC 27001:2022 principles for establishing, implementing, maintaining, and continually improving information security management.
The control framework should address risk assessment and treatment, access control, asset management, supplier security, secure development, vulnerability management, logging, incident management, cryptography, business continuity, information classification, and governance.
ContractX will not claim ISO/IEC 27001 certification unless and until certification has been formally issued by an appropriately accredited independent certification body for the applicable scope.
3. SOC 2 Readiness and Assurance
ContractX intends to design and document controls suitable for SOC 2 readiness, including controls relevant to security, availability, confidentiality, processing integrity, and privacy where applicable.
The initial assurance objective may include SOC 2 Type 1 readiness followed by independent examination when operational maturity and commercial requirements justify formal attestation.
ContractX will not represent that it holds a SOC 2 Type 1 or Type 2 report unless an independent licensed audit firm has completed the applicable examination and issued the report.
4. Independent VAPT
The production Service is intended to undergo independent third-party Vulnerability Assessment and Penetration Testing (“VAPT”) before material production launch and thereafter periodically on a risk-based basis, including after significant architectural or security-sensitive changes where appropriate.
Testing should cover relevant web application, API, authentication, authorisation, access-control, tenant-isolation, session-management, input-validation, configuration, and infrastructure attack surfaces within the authorised scope.
Material findings should be severity-ranked, assigned remediation owners, tracked through closure, and retested where appropriate.
Detailed VAPT reports may be treated as confidential security information and disclosed only under appropriate confidentiality arrangements.
5. Secure Software Development Lifecycle
ContractX intends to operate a secure software development lifecycle incorporating security requirements, peer review, dependency management, secrets management, vulnerability scanning, environment separation, change control, testing, deployment controls, and security review for high-risk changes.
Production secrets, service-role credentials, signing keys, privileged database credentials, and equivalent material must not be embedded in client-side code or exposed through public browser variables.
Development, test, staging, and production environments should be separated according to risk and operational maturity.
6. Encryption and Secrets Management
ContractX intends to use industry-standard encrypted transport for data transmitted over public networks and appropriate encryption mechanisms for stored data where supported by the relevant infrastructure.
Sensitive secrets and privileged credentials should be stored using dedicated secure environment or secret-management controls and subject to rotation and restricted access.
7. Identity, Authentication, and Least Privilege
Access should be controlled through authenticated identities, role-appropriate permissions, project membership, tenant isolation, and least-privilege principles.
Administrative and privileged access should be restricted, monitored, and separated from ordinary end-user access.
Multi-factor authentication may be required for privileged functions, Enterprise environments, or accounts assessed as higher risk.
ContractX may enforce password resets, session revocation, additional verification, or access suspension in response to suspected compromise.
8. Tenant and Project Isolation
ContractX is designed as a multi-customer platform in which project data should be logically isolated by authenticated identity, organisation, project membership, access policy, and database-level controls.
Security testing should specifically address insecure direct object reference, broken access control, privilege escalation, and cross-tenant data exposure risks.
9. Logging, Monitoring, and Threat Detection
ContractX may maintain security and audit logs covering authentication events, account changes, privileged actions, project access, uploads, exports, system events, error conditions, and suspicious activity.
Logs may be used for security monitoring, forensic investigation, abuse detection, service reliability, incident response, and enforcement of contractual obligations.
Access to sensitive logs should itself be restricted and monitored.
10. Security Incident Response
ContractX intends to maintain documented procedures for identifying, containing, investigating, remediating, recovering from, and learning from material security incidents.
Where a personal-data breach or other security incident triggers a legal or contractual notification obligation, ContractX will seek to provide required notifications within applicable timeframes using information reasonably available at the time.
Incident details may be disclosed on a need-to-know basis to affected customers, regulators, insurers, law enforcement, professional advisers, or service providers where required or reasonably necessary.
11. Supplier and Subprocessor Security
ContractX intends to apply risk-based due diligence to material vendors and subprocessors that handle sensitive information or provide security-critical services.
Assessment may consider security certifications, audit reports, privacy commitments, incident history, encryption, access controls, data-location practices, contractual protections, service criticality, and operational resilience.
Material supplier relationships should be reviewed periodically according to risk.
12. AI Security Guardrails
AI-enabled features should be designed to reduce unnecessary disclosure of sensitive Customer Data and to restrict model or provider access to the minimum reasonably necessary for the requested functionality.
ContractX may implement input validation, output review controls, prompt-injection safeguards, model-provider restrictions, logging, rate limits, and other measures intended to reduce misuse or unauthorised extraction of system information.
Users must not attempt to extract hidden prompts, system instructions, proprietary orchestration, protected configuration, credentials, or other security-sensitive information.
13. Marketplace and Platform Security
ContractX may be distributed through Microsoft Marketplace, Apple App Store, Google Play, and other authorised channels. Security controls and disclosures should remain consistent with the actual architecture and platform-specific requirements.
Where marketplace distribution requires HTTPS endpoints, verified support information, account deletion, secure authentication, privacy disclosures, or additional technical controls, ContractX will seek to maintain those requirements for the relevant listing.
14. Backup, Recovery, and Business Continuity
ContractX intends to maintain backup, restoration, continuity, and recovery procedures proportionate to service criticality and contractual commitments.
Recovery objectives, backup frequency, geographic redundancy, and availability commitments may differ by plan and may be specified in Enterprise service-level agreements.
15. Security Testing and Remediation
ContractX may conduct internal and external vulnerability scanning, code review, dependency analysis, configuration review, penetration testing, and other security assessments appropriate to risk.
Security findings should be classified by severity, assigned remediation owners, tracked to closure, and validated where appropriate.
Customers or researchers must not conduct penetration testing or vulnerability exploitation against ContractX without prior written authorisation and an agreed testing scope.
16. Accuracy of Security and Compliance Claims
ContractX will seek to ensure that security, certification, audit, VAPT, and compliance statements are accurate, supportable, and current.
Terms such as “ISO/IEC 27001 certified”, “SOC 2 Type 1”, “SOC 2 Type 2”, “independently penetration tested”, or similar assurance claims will only be used publicly when supported by the relevant current certificate, attestation, report, or completed assessment for the stated scope.
Readiness, alignment, planned controls, or target-state programmes must not be represented as completed certification or attestation.
17. Responsible Security Reporting
Suspected vulnerabilities should be reported responsibly to ContractX and must not be publicly disclosed before ContractX has had a reasonable opportunity to investigate and remediate them.
Until a dedicated security contact is published, security concerns may be directed to info@contractx.co.