DebugInit
Secure internal tools with control, isolation and auditability.
Security architecture, access control, data protection, observability, secure development and incident management.
Public claims must match implemented controls and verified operational evidence.
What this page does and does not claim
Below is the security architecture of the platform: the controls it implements and the mechanisms a buyer can inspect. It is a description of how the system works.
It is not a compliance claim. DebugInit holds no certification it has not published, and this page carries no framework badge, audit report or attestation. When one exists, it will appear here with its scope, its date and its auditor — and until then its absence is the accurate signal.
Capabilities
Implemented in the platform, so every Business Foundation and customer system inherits them rather than reimplementing them.
Access control
Role and permission models with segregation of duties, least privilege by default, and access that is reviewable per tenant rather than per system.
Isolation
Tenant boundaries enforced in the data layer, not only in the interface, so a query cannot cross them by accident.
Data protection
Encryption in transit and at rest, key handling appropriate to the deployment model, and retention rules applied consistently across Business Foundations.
Auditability
An immutable record of who did what, when, and under which policy — including actions taken by automations and agents.
Secure development
Reviewed changes, dependency and vulnerability scanning in the build, and environments separated so a test cannot touch production data.
Incident management
A defined path for detection, containment, customer notification and post-incident review, with the disclosure route published.
Evidence and documentation
Each item below is published here when it exists, carrying its scope, its date and who produced it. Nothing on this list is claimed today.
- pendingThird-party audit reports, with scope and period
- pendingPenetration test summaries and remediation status
- pendingArchitecture and data-flow documentation
- pendingSubprocessor list, with location and purpose
- pendingData processing addendum
- pendingVulnerability disclosure policy and contact
- pendingIncident history and post-incident reviews
Certifications
- SOC 2 — Not currently certified
- ISO/IEC 27001 — Not currently certified
- Other independent security certifications — None currently published
Debuginit has no material security incident publicly disclosed as of the publication date. This statement does not constitute a guarantee that security events cannot occur.
A trust page listing evidence it does not have is more useful than one implying evidence it does not have. This list is the commitment; the dates will fill in.
Shared responsibility
Security fails at the seams. These are the seams, written down before an engagement rather than after an incident.
| Area | DebugInit | You |
|---|---|---|
| Identity and access | Permission model, enforcement, audit trail | Who has which role, and reviewing that periodically |
| Data | Storage, encryption, isolation, retention mechanics | Classification, retention policy, lawful basis |
| Configuration | Safe defaults and guardrails | Workflow, approval and policy decisions |
| Infrastructure | Managed deployments: patching, backup, monitoring | Self-hosted deployments: the same, on your estate |
| Integrations | Connectors, credential handling, rate limits | Third-party terms and the data you choose to share |
| Incidents | Detection, containment, notification, review | Internal escalation and regulatory reporting |
Scroll the table sideways to see every column.
Procurement information
Security questionnaires, architecture documentation, subprocessor lists and data-flow descriptions are provided during evaluation, scoped to the deployment model you are considering. Ask for them directly rather than inferring them from this page.
If your review requires evidence we cannot yet provide, we will say so in writing rather than answer around it. That is a more useful basis for a decision than a confident questionnaire.
Reporting a vulnerability
If you believe you have found a security vulnerability, tell us before you tell anyone else. Report it through the contact form under "Security disclosure", which routes to a monitored queue. Good-faith research conducted under this policy is welcome.
- Safe harbour
- We will not pursue or report good-faith research that follows this policy and stops at the first sign of access to another party's data.
- In scope
- The DebugInit website and the authenticated product surface at this domain. If you are unsure whether a system is in scope, ask before testing it.
- Not permitted
- No denial-of-service or load testing, no social engineering or phishing, no physical attacks, and no accessing, modifying or deleting data that is not yours. Use test accounts and stop at proof of concept.
- What to include
- The affected system or URL, the steps to reproduce, the impact you believe it has, and any proof-of-concept. Enough for us to reproduce it, and nothing more than needed.
- What to expect
- We aim to acknowledge a report promptly, keep you updated on our assessment, and credit you if you would like once a fix is released.
- Coordinated disclosure
- Please give us a reasonable window to investigate and remediate before any public disclosure, and coordinate the timing with us.
Bring your security review to us
Send the questionnaire, the architecture questions or the deployment constraint you have to satisfy, and we will answer against what is actually implemented.