Trust Center

• Permissions are data

  What a member may do is decided by an explicit list of capability keys attached to their role and stored as data. The code that guards a customer-facing operation checks for a capability, not for a role name.

• One organization per request

  Each request acts in exactly one organization, and which one is decided server-side from the caller's memberships. A caller who names an organization they do not belong to is refused, and a request that cannot be resolved to an organization is refused rather than sent on unscoped.

• Access narrowed to named profiles

  Within an organization a member can be restricted to named advertising profiles. A restricted member with no profiles receives an empty answer rather than an unrestricted one, and a write naming a profile they were not granted is refused outright.

• Credentials stored one way only

  Passwords are kept only as argon2id hashes, with older bcrypt hashes replaced at the next sign-in, and long-lived session tokens only as one-way hashes, all checked by recomputation. The services' and data stores' deployment secrets are read from a managed parameter store, and the one credential that reaches it enters version control only as ciphertext that nothing but the receiving cluster can open.

• Datastores off the internet

  Public traffic arrives through one managed edge path over a tunnel the cluster opens outbound. No database, cache or message broker is published to the internet or appears on the list of hostnames the edge will route.

• Account changes are recorded

  Invitations, role changes, permission changes, membership changes, ownership transfers and billing movements are written to an append-only record a customer can read for their own organization. Advertising connection events are recorded the same way.

• No certification, and none inherited

  Selltics holds no security certification or attestation of any kind, and none is in progress. No audit firm has been engaged and no certification body has assessed the platform. Nor is any inherited: the environment that holds customer data runs on self-managed single-node infrastructure operated by Selltics, not in a hosting provider's region, so no provider physical-security control and no provider compliance certification stands behind it. Moving that environment to managed hosting is filed work and is the largest open item on the infrastructure roadmap.

• No third-party penetration test

  No third-party penetration test has ever been performed against Selltics, and none is scheduled. Selltics will not describe an internal review as though it were an external test. There is no bug bounty and no paid vulnerability reward programme. Vulnerability reports are accepted at support@selltics.net and are read by the operator, with no committed response time, triage window or payout.

• No independent review or separation of duties

  Selltics is operated by one person, so a change is written, reviewed and merged by the same individual. Nothing in the repositories records an enforced rule that changes must be reviewed before they reach a branch that deploys, and there is no approval step between a merge and the running product environment. Every review described on this page was performed by the operator on the operator's own platform, and no finding has been validated by anyone outside the company.

• No high availability, disaster recovery or tested restore

  Components run as single instances with no clustering and no automatic failover, and there is no secondary site. Selltics publishes no uptime guarantee, no recovery time objective and no recovery point objective, and nothing on this page should be read as one. The scheduled database dumps are compressed but not encrypted, and they sit in the same failure domain as the databases they protect, so they defend against accidental deletion, a bad migration or data corruption, not against loss of the underlying host. No restore drill has been performed. The backup rotation window is not a deletion clock: a copy can outlive it without anything reporting so, and any deletion commitment should be read against the live databases rather than the backup copies.

• No automated alerting, on-call rotation or security monitoring

  Nothing raises an automated alert to a human. No alert router is deployed, no alert rules are written, and there is no paging or on-call integration of any kind. Selltics is operated by one person and claims neither round-the-clock coverage nor a response-time commitment. No security information and event management system, intrusion detection system, file-integrity monitoring or behavioural anomaly detection is deployed, and no service publishes the request or authentication metrics such a system would consume. Problems surface through operator review of dashboards and logs, through the availability checks published on the status page, through the platform restarting failed workloads, or through a customer or partner report. The interval between something going wrong and Selltics becoming aware of it is therefore not bounded by any control Selltics can evidence.

• No encryption at rest for customer data, and no key rotation

  Selltics does not claim that the customer data it stores is encrypted at rest. No volume-level or database-level encryption is configured, and any protection provided by the underlying disks of the hosting environment is not something Selltics can evidence or commit to. Selltics operates no hardware security module and holds no escrow or split-custody copy of its encryption keys. The application's keys are not generated or used inside a managed key service: in the environment that holds customer data they are stored with the other deployment secrets in a cloud provider's parameter store, where the provider's own managed key encrypts them, as described among the encryption controls. The application holds one encryption key per purpose, today one for each kind of connected Amazon account's credentials, advertising and selling, and one for authenticator secrets, each delivered as a deployment secret, and there is no implemented procedure for rotating any of them while keeping existing data readable. An automated rotation capability and a written rotation and key-loss procedure are filed work. Selltics will not advertise encryption at rest until it is deployed, verifiable and stated with its scope.

• No enterprise identity integration, hardware-key or SMS factor

  There is no federated single sign-on with a customer's own identity provider, no automated provisioning or de-provisioning from a directory and no IP allow-listing. A customer signs in to a Selltics account with a password or a Google account. The only second factor is a code from an authenticator app, described among the access controls: there is no hardware security key or passkey factor and no code sent by SMS. There is no forced password expiry.

• No vulnerability scanning and no patch timeline

  No automated dependency scanning, container image scanning, code-analysis scanning or automated dependency update service runs on any change or on any schedule, and Selltics monitors no advisory feed. There is therefore no clock a remediation deadline could be measured against. Base images are built on upstream labels that move, so a base image is refreshed only as a side effect of rebuilding a service for an unrelated change, and the pinned third-party versions that do exist are on no review cycle. Any patch timeframe or base-image refresh cadence previously published is withdrawn. Introducing scanning and a documented cadence is filed work that has not started.

• Isolation inside the cluster, and who can act on it

  No network policy restricts which workload may connect to which other workload; the isolation that exists is at the edge, where nothing internal is routable from outside, and at the credential layer, where the message bus requires a per-service credential. Workloads hold no individual identity on the orchestration platform, so Selltics does not claim that platform role-based access control scopes each service to its own resources. The service databases are reached with a shared platform credential rather than a distinct least-privilege role per service, so a leaked credential is not confined to one service's data. Administrative consoles are internet-routable behind an identity-aware proxy whose policy is held with the vendor and not in version control. Administrative access to the underlying infrastructure is not recorded in an attributable audit trail, the consoles are entered with shared credentials rather than per-person accounts, and administrative standing is not yet a per-person record with a grant date, an expiry and a periodic review. Per-person identities, an access register and a privileged-access record are filed work.

• 23 October 2026ControlWhole advertiser accounts archived, never-activated profiles deleted after seven days
• 23 October 2026ControlDeployment secrets moved to a managed parameter store
• 19 October 2026ControlPublic status, trust and support pages moved to Cloudflare Workers

All updates

• ControlsThe control catalogue by domain, each with its status.
• AuditsThe self-audit programme and the record of completed audits.
• SubprocessorsWho processes customer data on our behalf, and where.
• ResourcesThe security documents, published or available on request.
• FAQThe security questions we are asked most often.
• UpdatesA dated record of what changed in the security posture.

Send a vulnerability report to support@selltics.net. The same address is the contact in /.well-known/security.txt. Reports are read by the operator, with no committed response time, triage window or payout.