Security starts with how we operate.

Data architecture

Customer program data is held in a managed environment we operate, with a documented model for what is stored, why it is needed and who inside SecureC can reach it.

• Data collected for a stated purpose in the service
• Documented internal ownership for each data category
• Separation between production data and development environments

To be confirmedHosting regions and any data-residency options offered to customers.

Tenant isolation

Each customer's program data is logically separated, and access paths are scoped so one customer's users cannot reach another customer's records.

To be confirmedThe isolation model as implemented, described at a level that helps a buyer assess it without becoming a map for an attacker.

Encryption

Data is encrypted in transit over public networks and at rest in our managed storage. We publish the fact of encryption rather than configuration detail that would help an attacker narrow their approach.

To be confirmedEncryption in transit and at rest as implemented, at a level of detail the security owner approves.

Access control

Internal access follows least privilege. Access is granted by role for a business reason, reviewed periodically, and removed when someone changes role or leaves.

• Role-based access rather than standing broad permissions
• Multi-factor authentication for internal administrative access
• Periodic access review with a named reviewer
• Joiner, mover and leaver process tied to access removal

Integration permissions

Integrations used for evidence collection request read-only access wherever the source system supports it, scoped to what the control test actually needs.

To be confirmedThe current integration list and the exact permission scopes each one requests.

Secure development

Changes go through peer review before release, dependencies are monitored for known vulnerabilities, and secrets are kept out of source control and out of client bundles.

• Peer review required before production release
• Dependency and secret scanning in the pipeline
• Security considerations recorded for significant changes

Monitoring and logging

We log security-relevant events for our own environment and review them, so that unusual administrative or access activity can be investigated.

To be confirmedLog retention period for our own environment, and the review cadence.

Backups and resilience

Customer program data is backed up, and restoration is tested rather than assumed. We describe our approach without publishing recovery objectives we have not committed to contractually.

To be confirmedBackup frequency, restore-test cadence and any recovery objectives the business is willing to commit to.

Subprocessors

We use third-party providers to operate the service. Each is selected for a specific purpose, reviewed before use, and covered by appropriate contractual terms.

To be confirmedThe subprocessor list itself: entity, purpose, and processing location for each. It is not published here until confirmed.

AI data use

SecureC AI answers from your approved program information and cites the evidence it used. Output requires a named human approver, and it never issues a compliance verdict or accepts risk on your behalf.

To be confirmedThe explicit position on whether customer data is used to train models, stated plainly and contractually.

Retention and deletion

Data is kept while it is needed for the service and for obligations that outlive the engagement, then deleted. Customers can request export and deletion.

To be confirmedRetention periods per data category and the deletion timeline after termination.

Certifications

We list a certification or attestation only once it has been issued and we can provide evidence of it. Until then this page names none, and you will not find badges anywhere on this site. We would rather be asked than assumed.