Audits
Selltics has no external auditor, so it audits itself and publishes what that produces. The programme has two halves. Automated checks run in the delivery pipeline and against the running environment, on every change or continuously, and block or revert what they catch. Manual reviews take one surface or one standard at a time and check what is written against what the code and the deployment configuration actually do.
CadenceEvery proposed change, in seven of twenty repositories
Type checks, linting, format checks or unit suites run before the image build and are not allowed to fail, so a change that fails them never produces a deployable build. In the shared contract package the test suite gates publication of the package. The other thirteen repositories raise no pipeline on a proposed change.
- Automated
Secret scanning
CadenceEvery proposed change, in one repository
Two independent scanners run with a rule set covering the credential formats this platform issues, and a hit fails the change rather than warning about it. No other repository has an equivalent check.
CadenceContinuous, product environment only
A controller compares every object it manages against the declared files, puts back anything that differs and removes objects a package no longer declares, so an edit made by hand to a declared workload does not survive. Objects created by hand that no declaration covers are not tracked and not removed, and the separate estate serving the public information sites has no such controller.
CadenceEvery minute
A checker running outside the product platform probes the entry points listed on the public status page and records success, failure and response time, publishing ninety days of daily history. The checked set is a configured list rather than every surface Selltics operates. The checks publish; they page nobody.
CadenceStarted by hand; no schedule
Every product repository plus the chart, delivery and deployment configuration is read against an external standard and its acceptable-use terms, clause by clause, and the result is a written report and a numbered, sequenced set of remediation items. One such review has been completed.
CadenceStarted by hand; no schedule
One surface of the product is taken at a time and every displayed figure is checked against what the platform can actually produce. Screens showing invented figures are deleted rather than wired to placeholder data, and defects found on the way are fixed first. Three such reviews have been completed.
CadenceWhenever a security claim is written or changed
Each sentence Selltics intends to publish is checked against the source, the configuration or the deployment definition, and the file and line that prove or disprove it are recorded beside it. A sentence that cannot be proved that way is lowered in status or published as an absence. This page is the output of that rule.
A finding becomes a numbered item with its scope, its acceptance criteria and the file and line that proves it, and is then filed as an issue in the repository it belongs to. The delivery pipeline can advance an issue along a fixed status ladder once the issue exists, when its change merges and again when the version carrying it reaches the environment, but that bookkeeping is best-effort by design, never blocks a deploy, and one rung of the ladder is set by hand. The sixty-eight items the September 2026 review produced have not been filed yet and none of that remediation has merged, so Selltics claims no tracked-to-closure guarantee, no remediation deadline and no service level for closing a finding.
Manual
Data protection review
- Scope
- Every product repository plus the chart, delivery and deployment configuration, read against an external marketplace data-protection standard and its acceptable-use terms, from a named baseline commit.
- Method
- In-house, measured against an external standard, with a file and line citation behind every finding.
- Outcome
- Sixty-eight sequenced remediation items across twelve repositories in five waves. The first wave is the withdrawal of published statements the code does not support, twelve of which were found. None of the remediation has merged, none of the items has been filed as a tracked issue yet, and the report and the item set are internal working documents. Selltics states the review's date, scope and size, and does not describe its open items.
Manual
Billing review
- Scope
- The billing surface end to end: the customer-facing billing screens, the ledger service behind them and the commercial model itself.
- Method
- In-house, screen by screen against what the backend can produce.
- Outcome
- A defect that could have returned another organization's balance was found and corrected first, and the fix is in the image the environment runs. Screens presenting figures no backend produced were removed rather than wired to placeholder data, with the two figures that were real moved onto a screen that reads them live. The resulting work is implemented and merged across nine repositories and the control plane.
Manual
Product surface review
- Scope
- Two sections of the operator dashboard, with every displayed figure checked against what the backend can actually produce.
- Method
- In-house, panel by panel.
- Outcome
- One section was deleted as unbacked and its two real figures relocated to a live screen. The other was converted from placeholder data to live reads, so every panel now shows a live value or an explicit not-available, and never a zero standing in for a reading that has not answered.
No review cadence
Nothing in the platform's delivery or scheduling configuration triggers a security review. There is no annual, quarterly or other cycle, and each review so far was started by hand. The dates above are a record, not a commitment to future reviews.
No independent party has checked any of this
Every review described here was performed by the operator on the operator's own platform. No independent party has examined the code, the configuration or the findings, and no finding has been validated by anyone outside the company. Any internal re-checking is a check on rigour, not a substitute for independence.
The reports are not published
No review report is published and none is offered to customers on request today. The September 2026 review produced a written report and a numbered item set; both are internal working documents written for the operator, and neither is yet held under version control with the platform's configuration. The three earlier reviews produced no report at all, so the descriptions on this page are the only account of them a reader has.
The current findings are not tracked issues
The sixty-eight items the September 2026 review produced exist only as a file. None has been filed as an issue in the repository it belongs to, and none of the remediation has merged.
An earlier review recorded a control the configuration does not support
The September 2026 review found that an earlier pass had recorded a log-retention control the deployment configuration disproves. That is why a code citation per sentence is now the rule, and why this page carries no log retention figure.
No risk register and no annual cycle
There is no formal risk register and no documented annual risk-assessment cycle. What a review produces is a list of remediation items, not a maintained inventory of risks with owners and review dates. Writing a risk-assessment register is itself a recorded remediation item.