Controls

In place

The repository backs the control today. Where it has limits, they are inside the statement rather than in a footnote.

In progress

Work that has started and is not finished. The statement says what is built and what is not.

Planned

Work that is filed and has not started. It is not in place today.

Not claimed

Selltics does not claim it. Absences are published in the register at the end of this page rather than left out of the catalogue.

What Selltics does not claim is listed in Not claimed, at the end of this page.

Not claimed in this domainNo certification, and none inheritedNo third-party penetration test

• Security claims are checked against the code

  In progress

  A statement is published here only when the source code, the deployment configuration or the deployment definition proves it today. A claim that could not be proved that way was lowered or removed rather than softened. Four first-party reviews have been completed since August 2026. One was measured against an external standard and produced a written report and a numbered set of sixty-eight remediation items; the other three were internal reviews of a single surface and produced neither. The review artefacts are internal working documents and are not yet held under version control with the platform's own configuration.

• Disproven public statements are withdrawn

  In progress

  The September 2026 review compared the security statements Selltics had written, both those already published and those drafted for an external application, against the repository. It found twelve the code does not support. Correcting or withdrawing every one of them is the first item of remediation, ahead of building anything new. That correction has not merged yet, so some older published pages still carry those statements. Where they and this page disagree, this page is the current one.

Not claimed in this domainNo enterprise identity integration, hardware-key or SMS factor

• Two sign-in methods, no others

  In place

  Customers sign up and sign in with an email address and password, or with a Google account. A session is issued only by those flows, by the refresh that extends a session they already issued, by following a valid single-use email-verification link, and, on an account with two-factor authentication turned on, by passing the second-factor check that follows the password or the Google sign-in; on such an account neither of those issues a session by itself unless the browser has been trusted to skip the second factor. Resetting a forgotten password issues no session: the user signs in again afterwards. A new account gets no session until its email address is confirmed: signing up with a password sends a single-use confirmation link instead of opening a session, and signing in with the right password before confirming is refused. A Google account counts as confirmed when Google reports the address as verified, and signing up or signing in with a valid invitation addressed to that email address counts as confirming it. Accounts created before the confirmation requirement was switched on count as confirmed, and an account still unconfirmed seven days after sign-up is deleted. The sign-in, sign-up, recovery and sign-out routes answer a request that carries no session, and so does a small fixed set of other endpoints, because the caller cannot have one: the consent callbacks Amazon redirects to after a seller authorises a connection, the payment provider's webhook, an invitation preview shown before the visitor has an account, and the service health check. None of those other endpoints issues a session, each is bound to a credential carried in the request itself, and each is rate-limited separately. Every other route requires a session.

• Passwords stored only as hashes

  In place

  A customer password is stored only as a salted one-way hash produced by argon2id, a password hashing function that is deliberately slow and memory-hard. A password set before October 2026 was stored as a bcrypt hash; it is checked as such and replaced by an argon2id hash at that account's next successful sign-in. Signing in recomputes the hash and compares it. No path reads a password back out of the credential store, and accounts created through Google hold no password at all. Whenever a password is set it must be twelve to one hundred and twenty-eight characters long after Unicode normalisation, with no composition rules and no forced expiry; one that contains the name part of the account's email address, the user's name or the word Selltics is refused, and so is one known to have appeared in a breach. That breach check sends only the first five characters of the password's one-way hash to a public breached-password service, never the password or the whole hash, and falls back to a bundled list of common passwords when the service cannot be reached. This is a statement about the credential store and nothing wider. Selltics does not claim that credential material is unreadable everywhere inside its own platform: some internal messages carry it and are retained by internal components for longer than the request that produced them. Bounding that retention, and removing credential material from the internal messages that do not need it, is filed work.

• Session tokens hashed, rotated and revocable

  In place

  Session tokens are delivered as HTTP-only cookies, so page scripts cannot read them. They are marked for HTTPS-only transmission whenever the request arrived over an encrypted connection, which is the case for every published address, they are scoped to the Selltics domain, and they are not sent on cross-site requests that could trigger an action. Since 11 October 2026 every sign-in opens a session that is a record on the server, and a session issued before then becomes one the first time it is refreshed. The long-lived token of a session is kept only as a one-way hash and is checked by recomputation, so a copy of the stored record cannot be replayed as a session. That token is replaced on every refresh, and presenting one that a refresh already replaced, outside a one-minute allowance for two tabs refreshing together, ends the session. The short-lived token that authorises each API call expires after fifteen minutes. A session ends after seven days without use, and in any case thirty days after sign-in. Signing out ends the session at once, and from then on the API refuses the short-lived tokens already issued to it; if the store that holds that refusal list is unavailable, those tokens are accepted until they expire. The platform can list an account's sessions, end any one of them, or end every session but the current one, and a password change ends every other session while a password reset ends all of them. The settings screen that offers the session list and the sign-out from every other session is not yet open to customers.

• Account lockout after failed sign-ins

  In place

  Ten consecutive failed password attempts on one account lock it for fifteen minutes, and the account holder is notified by email. That lock is kept in the account record itself, a wrong current password given while changing a password counts toward it, and while it holds even the right password is refused. In front of it, five failed sign-in attempts against one account within fifteen minutes lock that account for fifteen minutes, and a separate, higher threshold applies to a single source address. Those counters are keyed on a one-way hash of the email address, so the store that holds them never holds the address itself. A successful sign-in clears them. They live in a store outside the application: if that store is unavailable the attempt is permitted rather than refused, so that outer layer is not unconditional. The lock kept in the account record does not depend on it.

• Two-factor authentication, required before connecting Amazon data

  In place

  Selltics sign-in has a second factor: a time-based one-time code from an authenticator app, with no SMS, email-code or hardware-key alternative. It is required before an Amazon account can be connected to Selltics or authorised again: the API refuses to start either for a session that has not passed the second factor, whatever the interface shows. An account that already has access to a connected Amazon account through an organization it belongs to, and has no second factor turned on, is refused by the API on every route except a small set of account-security routes, among them those it needs to sign in, sign out and set one up, until it enrols; when the platform cannot tell whether an account has such access, the request is refused rather than let through. For an account with no access to a connected Amazon account, two-factor authentication is optional. When it is on, it is asked for after the password and after a Google sign-in alike, unless the browser has been trusted as described below, and a code that has already been accepted is refused if it is presented again. Ten consecutive wrong codes pause two-factor sign-in on the account for fifteen minutes. Turning it on issues ten single-use recovery codes, which are stored only as keyed hashes, and the authenticator secret is encrypted by the application before it is stored. A browser can be trusted to skip the code for thirty days; the period does not extend with use, only a hash of the browser's token is kept, and changing or resetting the password revokes every trusted browser. The account holder is emailed when two-factor authentication is turned on, turned off, moved to a new authenticator or reset by support, and when a recovery code is used or the codes are regenerated. An account holder who has lost both the authenticator and the recovery codes can have it reset only by support, after a manual identity check: the request has to come from the account's own email address, that address is told of it, and the reset is made only after twenty-four hours in which it can be objected to. The reset is recorded against the support request, ends every session of the account, and leaves an account with access to a connected Amazon account to enrol again before it can continue. The settings screen where an account holder turns two-factor authentication on or off is not yet open to customers.

• Permissions are data, not role names

  In place

  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 rather than a role name, so a customer can define a role with exactly the permissions they intend. Advertising data, advertising connections, profile management, automation, billing, membership, integrations and role administration each have their own key. Two deliberate exceptions are not capability checks: the organization owner, who bypasses them inside their own organization, and a small set of owner-only operations.

• Permission checks refuse, not warn

  In place

  In the environment that serves customers, a failed permission check refuses the request. The routes that link, list or remove an Amazon advertising connection refuse unconditionally, in every environment. A caller whose permissions cannot be resolved holds nothing, so a resolution failure denies rather than grants.

• Every request bound to one organization

  In place

  Each request acts in exactly one organization, and which one is decided server-side from the caller's memberships. A client may name the organization it wants to act in, but that selection is only ever validated, never trusted: a caller who names an organization they do not belong to is refused rather than redirected to another one, and a request that cannot be resolved to an organization is refused rather than sent on unscoped. Membership is proven once per request, by the service that owns memberships, and the resulting organization key is carried to whichever service answers the request. Those services filter every query by that key; they do not independently re-prove the membership behind it, because they hold no membership records to check it against. Organization administration is the exception: every write there is re-validated against the membership records inside the service that performs it.

• Access narrowed to named advertising profiles

  In place

  Within an organization, a member can be restricted to named advertising profiles rather than all of them. 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 rather than quietly narrowed to something else. The service that answers those reads applies the grant set itself rather than treating an empty one as no filter.

• Owner privilege stops at the organization

  In place

  The owner of an organization bypasses capability checks inside that organization and confers nothing anywhere else. Ownership cannot be handed over by editing a role, an organization cannot be left without an owner, and a member who is not the owner cannot grant a permission they do not themselves hold. Each of those four rules refuses rather than warns.

• Revoked access takes effect promptly

  In place

  Resolved permissions are cached briefly to keep the platform responsive. Every change to a membership, a role, an invitation or ownership invalidates that organization's cached permissions, so removing a member or reducing their role normally takes effect on their very next request. In the worst case, if the invalidation signal itself does not land, it takes effect when the cache entry lapses, which is under a minute.

• Invitations are single-use and expiring

  In place

  An invitation to join an organization carries a randomly generated token. Only a one-way hash of it is stored, so a pending invitation cannot be recovered from the database. Each invitation expires after seven days, can be accepted only once, and can be revoked before that.

Not claimed in this domainNo encryption at rest for customer data, and no key rotation

• Public TLS terminated by the edge provider

  In place

  Public traffic is encrypted by an external content delivery and tunnel provider, which holds the certificates and terminates TLS for every published address. The provider therefore sees request and response content in readable form. The platform reaches that provider over an outbound, authenticated tunnel it opens itself. Selltics operates no public certificate authority and issues no public certificates of its own.

• Internal message bus encrypted and per-service

  In place

  In the environment that holds customer data, every service connects to the internal message bus over an encrypted, certificate-verified channel and must present its own credential to connect at all. The older unauthenticated channel and its anonymous superuser have been removed there, so a workload without a credential can neither read nor publish, and no service can publish under another service's name. Each service's permissions are granted individually rather than shared. One read-only operational console is the exception: its grant is deliberately bus-wide rather than a named subset, and narrowing it is filed work.

• Deployment secrets held in a managed parameter store

  In progress

  Deployment secrets are not committed to Selltics' source repositories in readable form. In the environment that holds customer data, the secrets of its services, data stores and operational tools are held in a cloud provider's parameter store, encrypted there under an encryption key the provider manages, and the cluster reads them from that store rather than from version control. Three credentials the cluster itself needs, to pull images from the registry, to give the deployment tool access to the configuration repository and to connect the edge tunnel, are not in the store: the operator places them in the cluster from local files, and they are not committed either. The credential the cluster reads with can read only that environment's values, and can decrypt them only through the parameter store. That credential is the one deployment secret still committed to version control, and only as a public-key encrypted object that nothing but the receiving cluster's own private key can open, bound to the single place it is meant to be used. Every read of the store is recorded in the provider's audit log, which keeps its records for one year before deleting them; that log is configured in the provider's console rather than in Selltics' version-controlled configuration, and its settings were checked on 23 October 2026. Local development values are read from a separate part of the same store and written only to files excluded from version control. The move is not complete: the build pipelines still take their own credentials from the build system's variable store, which also still holds the copies the parameter store was filled from, and removing those copies is filed work. This covers what is stored in the repository and in the parameter store. It is not a claim that secrets are encrypted inside the running cluster.

• HTTPS on every published address

  In progress

  Every published Selltics address is served over HTTPS, terminated by the external edge provider. Selltics does not present the redirect from plain HTTP as a control of its own: that enforcement is a setting in the edge provider's console, changeable there with no change to Selltics' version-controlled configuration, so Selltics cannot evidence it from its own records. The same is true of a strict transport policy for the browser-facing sites. Pinning HTTPS enforcement and a strict transport policy in Selltics' own configuration, and recording the edge settings with the date they were checked, is filed work.

• Encryption for connected-account credentials

  In progress

  Selltics is rolling out application-level encryption for the credentials that let it read a customer's advertising data on their behalf. The encryption component is built and deployed in the environment that holds customer data: authenticated encryption with a 256-bit key, a fresh random value for every record, and a key identifier stored with each record so that a change of key is detected rather than silent. The service refuses to start without a valid key. The rollout is not complete. As of today these credentials are not encrypted at rest and Selltics does not claim that they are. Until it completes they are protected by the access controls on the environment, and a customer can revoke Selltics' access at the advertising platform at any time.

Not claimed in this domainIsolation inside the cluster, and who can act on it

• One controlled entry path for public traffic

  In place

  Public traffic reaches the platform through a managed edge network, over a tunnel the cluster opens outbound to that edge rather than by an inbound route into the network. The set of hostnames that can be routed to the platform at all is a short list held in version control, and a workload that is not on it has no path from the internet.

• No datastore is reachable from the internet

  In place

  No database, cache or message broker is published to the internet. Each one is addressable only from inside the cluster, has no ingress rule and no externally routable address, and none of them appears on the list of hostnames the edge will route.

• Public information sites run off the product platform

  In place

  The public status page, this page and the public support page run on Cloudflare Workers, the edge provider's own serverless platform, and not on the infrastructure that holds the product's data stores. If the main platform is unavailable, the pages meant to tell you so, and the page you would write to about it, keep answering, because none of them depends on it. The separation is stated about the product's data stores rather than about customer data as such, because there is one exception and it is named rather than left to be inferred. A support submission the mail provider will not take is held in storage that belongs to the support page on Cloudflare until it is delivered, as a single record carrying the address the sender gave and the message they wrote, and it is deleted within thirty days whether it was delivered or not. If anything has been waiting seven days the form stops accepting submissions and says so, rather than keep taking messages on a channel that is demonstrably not delivering them. While a message is held it is not reached by the central log collection the product environment has. Selltics does not claim it is outside Cloudflare's own recovery history for that storage, which can keep a deleted record for a further period Selltics does not set.

  Selltics Status

• Administrative consoles behind an identity-aware proxy

  In progress

  The operational and administrative consoles, including those used to read logs, metrics and traces, are routable from the internet and are fronted by an identity-aware proxy at the edge: an unauthenticated request is answered with a redirect to the identity provider rather than by the origin. This is a rollout in progress and not a finished control, for two reasons. The proxy's policy is configured at the edge provider and is not held in Selltics' version control, so the current position is evidenced by a dated manual probe rather than by a tracked artefact. And no automated check verifies that the consoles are still gated. Taking these consoles off the public internet, or making their access policy reviewable, is filed work.

• CPU and memory limits on every workload

  In progress

  Every application service and every database declares explicit CPU and memory requests and limits, and so does the edge connector. A few shared platform components do not declare them yet. Selltics therefore does not claim that a single workload cannot exhaust a shared node: the guarantee the limits exist to provide is not complete until every component carries them.

• Container hardening on new workloads

  In progress

  Hardened container settings, meaning an unprivileged user, a read-only root filesystem, all Linux capabilities dropped, privilege escalation disabled, a default seccomp profile and no automatic mounting of platform API credentials, were applied in full only to two public-site workloads, and those no longer run as containers since the public sites moved to Cloudflare Workers, so no workload that remains carries the full set. The edge connector carries part of the set: an unprivileged user and privilege escalation disabled, but not the rest. They are not applied at all to the application services or the databases. This is a rollout in progress, not a platform-wide property.

• Key-authenticated operator access

  In progress

  Remote operator access to the platform is reached over an outbound tunnel rather than a published management port, and it is authenticated by public key. The authorised key list is a tracked file, so adding a key is a commit. It is not behind the identity-aware proxy that fronts the web consoles. Removing a key from the tracked list does not take effect until the workload is restarted, so the repository is the record of who should have access rather than a live enforcement point. Rebuilding this channel with per-person accounts is filed work.

• Rate limits on authentication endpoints

  In place

  Sign-in, registration and token refresh each carry their own request limit per source address, on top of a global limit that applies to the whole API. The limits are counted against the client address reported by the content delivery network in front of the platform, and no path reaches the origin except through it, so that address is set by the network rather than by the caller. The thresholds are configuration rather than code, so they can be tightened without a release. The counters live outside the application: if that store is unavailable the request is permitted rather than refused.

• Bot challenge ahead of the credential check

  In place

  Sign-up, sign-in, a password-reset request and a request to resend a verification link each put a Cloudflare Turnstile challenge in front of the request, and the challenge is switched on in the environment that serves customers. Verification fails closed: when the challenge provider cannot be asked, or answers something unreadable, the request is refused rather than let through, and so is every request to a deployment that has the challenge switched on without the key to check it. A token is accepted only when it was solved on the Selltics sign-in application for the same form it is presented to, so a token solved elsewhere or for another form does not pass. Switching the challenge off is a change to version-controlled configuration rather than a runtime default. It is a defence against automated abuse of these forms: Google sign-in and the second-factor check are bounded by rate limits rather than by the challenge.

• Browser security headers being standardised

  In progress

  Selltics is standardising the security headers its sites return to browsers. The application programming interface sets a standard set through its framework, and the public status page sets content-type, framing, referrer and permissions protections together with a content security policy. The sign-in application sets a content security policy that also forbids framing, a strict transport policy, and content-type, referrer and permissions protections. The other browser-facing applications do not yet set them. A single platform-wide header set applied at one place for every site is filed work.

Not claimed in this domainNo independent review or separation of dutiesNo vulnerability scanning and no patch timeline

• Build credentials kept out of published images

  In place

  Builds that need a credential to fetch private internal libraries receive it as a build-time secret rather than as a stored build setting, and the credential lines are removed again before the build step completes. The credential is therefore not carried inside the published build, where anyone able to pull it could read it. Of the sixteen repositories that build an image, eleven use this pattern and the other five declare no internal library dependency at all.

• Product environment reconciled from version control

  In progress

  Every workload of the product environment is described by files kept in version control, and a controller inside the cluster continuously compares what is running against those files, puts back anything that differs and removes objects a package no longer declares. An edit made by hand to a declared workload does not survive. Three limits are stated rather than implied: an object created by hand that no declaration covers is not tracked and therefore not removed; a small number of cluster credentials are created by an operator-run script rather than declared; and the public information sites run on Cloudflare Workers outside this controller, so a version deployed there by hand stays until the next merge replaces it. The file history is a complete record of every change to the declared product workloads, not of everything Selltics runs.

• Product builds traceable to their commit

  In progress

  Every product service and dashboard image is labelled with the identifier of the exact source revision it was built from, and the version each component should be running is itself a tracked file written by the pipeline when a build succeeds. A deployed product component can therefore be traced back to the source that produced it. This is not yet true of every component: two third-party platform components are deployed from a moving upstream label. The tracked file records what the environment is told to run; it is not by itself proof of what a given instance is running at a given moment.

• Rollback by reverting the change

  In progress

  Because the declared state of the product environment lives in files, withdrawing a deployed build means reverting the commit that selected it, and the controller then restores the previous build without manual intervention in the cluster. Each workload retains a bounded history of recent revisions. A revert does not undo everything a change did: database schema changes are applied forward by a job that runs ahead of the new build and are not reversed by reverting the declaration, and the public information sites are outside this controller: a revert there takes effect when the reverted change is merged and its pipeline deploys it.

• Automated checks before an image is built

  In progress

  In seven of the twenty code repositories an automated stage of type checks, linting, format checks or unit suites runs on every proposed change, is ordered before the image build and is not allowed to fail, so a change that fails it never produces a deployable build. In the shared contract package the test suite gates publication outright. The other thirteen repositories raise no pipeline at all on a proposed change, so the first automated step there happens after the change has been merged onto the branch the environment deploys from. This is not a platform-wide gate and Selltics does not claim one.

• Secret scanning in one repository

  In progress

  One repository runs two independent automated secret scans on every proposed change, with a rule set covering the credential formats this platform actually issues, and a hit fails the change rather than warning about it. No other repository has an equivalent check, so Selltics does not claim platform-wide automated detection of committed credentials.

• Dependency versions pinned in some builds

  In progress

  Several builds install from a committed, fully resolved dependency list, so the third-party code inside them is fixed and reviewable and the build refuses to proceed if that list no longer matches what the project declares. The service builds resolve dependency versions at build time within the ranges the project declares, so two builds of the same source revision are not guaranteed to contain identical third-party code. No minimum-version policy, advisory feed or approval step governs the third-party code inside a deployed build.

• Private registry, run-scoped image pushes

  In progress

  Builds and internal libraries are published to a registry that requires credentials to read, and the cluster holds a credential for pulling from it. The credential a pipeline uses to push a built image is issued to that single pipeline run and expires with it. That does not extend to every publishing path: the internal library packages are published with a stored credential rather than a run-scoped one, and the cluster's pull credential is created by an operator-run script from a stored credential. Scoping and rotating the stored credentials is filed work that has not shipped.

• Public information sites deployed by their pipelines

  In progress

  The public status page, this page and the public support page run on a separate estate from the product, and each is deployed there by its own build pipeline when a change is merged into its release branch, with no manual step in between. The pipeline is not the only path: a version can still be deployed by hand with the same account credential, and nothing reverts it until the next merge replaces it, so Selltics does not claim that what is published is provably the merged revision.

Not claimed in this domainNo automated alerting, on-call rotation or security monitoring

• Centralised log collection across all services

  In place

  Output from every running service is collected automatically by a platform-wide agent and searched from one place. Collection is not something a service opts into: any workload running in the environment that holds customer data has its output captured, including components that are not application services. Two limits are stated rather than implied. No retention period is published, because the log store does not yet sit on durable storage and there is no honest number to state until it does. And logs are not guaranteed free of customer content: some service logs can contain message content and responses returned by upstream advertising APIs. They are operational records held under operator-only access, not a customer-content-free store.

• Infrastructure metrics with durable history

  In place

  Resource and health metrics for the host and for every running workload are collected every thirty seconds and kept for fifteen days on storage that survives a restart. Standing dashboards show processor, memory, disk and network use, per-workload consumption against its limits, workload restarts, and workloads terminated for exceeding memory. No service publishes application-level metrics such as request rates, error rates or authentication-failure rates, so these dashboards describe infrastructure health and not request-level behaviour of the application.

• Distributed tracing across every backend service

  In place

  All ten backend services export distributed traces to a shared tracing backend, so one customer request can be followed across every service that handled it, and the API request log carries the trace identifier that links a log line back to its trace. Traces exist for live diagnosis: the tracing backend holds no durable storage, so they are not a retained record and Selltics does not present them as one.

• Append-only log of account and billing changes

  In place

  Changes to who can do what inside an organization are recorded in an append-only log: invitations created, revoked and accepted, role changes, permission changes, members removed or leaving, roles created, edited and deleted, ownership transfers, and attributable billing movements. Each entry records what happened, who did it, to whom or to what, and when, with the subject's name captured as it stood at the time, so a later rename cannot rewrite history. Customers read their own organization's log through the product, scoped to that organization, and entries are kept for one year and then removed by a nightly sweep. Billing amounts are hidden from a reader who does not hold the billing permission. Since October 2026 the same log also receives the security events of an account, under the account holder's own organization: sign-ups, sign-ins and failed sign-ins, sign-outs, lockouts, ended sessions, password changes and resets, and changes to two-factor authentication, with the IP address and browser they came from. Two limits are stated rather than implied. The record is written after the act it describes and can never block it, so an entry that cannot be stored is dropped rather than retried. The entries are ordinary database rows, with no hash chain, write-once storage or external replica. The log does not record reads of customer data, and of the actions taken by Selltics staff it records only a support reset of two-factor authentication.

• Append-only log of advertising connection events

  In place

  Every event in the life of a customer's advertising connection is recorded append-only and is readable by that customer: connected, re-authorised, disconnected, a credential refresh that failed, a data sync that failed, an integration linked or unlinked, a delivery that did not arrive. The record deliberately outlives the connection it describes, so a disconnection can still be explained afterwards. Entries are size-bounded, kept for ninety days and then removed by a nightly sweep.

• AI assistant runs recorded, then deleted

  In place

  Every run of the AI assistant is recorded: the rounds it took, the tokens it consumed, and the data the model was shown, including advertising figures. What the assistant did on a customer's behalf can therefore be reconstructed. That record is reachable only by the operator, through a read-only database role rather than the application's own credentials, and it is deleted thirty days after the conversation by a daily sweep. Selltics makes no claim that the record excludes customer data, because it does not.

• Credential redaction in the API request log

  In progress

  The service that terminates customer API traffic strips credential-bearing values out of its own request log before writing a line: authorization headers, session cookies, payment-provider webhook signatures, and the sign-in parameters carried by the advertising-platform authorization callback. Values are replaced with a marker rather than removed, so a reader can tell a credential was present without being able to read it, and one shared component applies the rule rather than each route. This is not an end-to-end property of the log pipeline. The layer in front of the application writes its own access record and is not covered by that rule, so a credential carried in a request URL can reach the log store unredacted even though the application's own line does not contain it.

• Written incident process, not a standalone plan

  In progress

  A written incident process exists: assess scope and severity, contain by revoking affected credentials and isolating affected workloads, notify affected customers and the advertising platform provider, remediate and recover, then write a post-mortem, preserving evidence throughout. Four things are not yet true, and Selltics says so rather than implying otherwise. It is not published as a standalone plan. It names no out-of-hours contact. Its stated review cadence is annual rather than every six months. And its first step assumes an alert that nothing currently produces, so the notification commitments run from the moment Selltics detects, which is not a bounded interval.

  support@selltics.net

• Categories of data the platform holds

  In place

  Selltics holds Amazon advertising performance figures, Amazon advertising catalogue and configuration history, account and organization records, billing and payment records, and records of conversations with the AI assistant. It also holds the authorisation credentials a seller grants when connecting an Amazon Advertising account, the link record for a connected messaging account, the connection activity log, account audit events, which include the originating IP address, and short-lived ingest bookkeeping including raw advertising records set aside as unprocessable. For sign-in it holds session and trusted-browser records with the IP address and browser they came from, the encrypted authenticator secret and the hashed recovery codes of an account with two-factor authentication turned on, the consent record of each sign-up with the Terms and Privacy Policy versions accepted, the security audit events of each account, and a delivery log of the account and security email sent, which keeps the recipient only masked and as a one-way hash. A continuously written copy of the raw advertising events is kept in a separate archive outside the databases. That archive also holds the stream records of the profiles of a connected advertiser account that the customer did not activate, kept while another profile of the account is activated; they are not loaded into the product or shown in it. Support correspondence is a further category, and it sits outside all of those stores: the address someone gives on the public support form and the message they write are held in the mailbox the submission is delivered to rather than in the platform, and the only other copy Selltics keeps is a submission the mail provider would not take, held in the support page's storage on Cloudflare Workers until it is delivered and deleted within thirty days in any case.

• No Amazon shopper personal data

  In place

  Selltics connects to Amazon Advertising, and to Amazon's Selling Partner API only in Amazon's test environment. The advertising records it receives are counts and amounts, meaning impressions, clicks, spend, attributed conversions, units and sales, attached to campaigns, ad groups, ads, keywords and product identifiers. The Selling Partner connection uses a test authorisation held by Selltics, never a seller's own, and Amazon answers it with fixed synthetic test orders rather than a real store's; there is no live Selling Partner connection, so no seller can connect a real store. From those test orders only order identifiers, dates, marketplace, fulfilment status, totals and, where Amazon supplies them, product lines are passed on; buyer, recipient, address, tax and payment fields are dropped before anything else in the platform sees them, and the connection keeps no copy of the orders. No real shopper names, addresses, contact details, order records or other buyer personal information is requested, received or stored.

• Minimal account and payment data

  In place

  An account record holds an email address, a first and last name, and timestamps. Sign-in holds either a password hash or an identifier issued by the federated sign-in provider the customer chose, and, for an account with two-factor authentication turned on, the encrypted authenticator secret and hashed recovery codes. Payments are taken by an external payment provider acting as merchant of record; Selltics stores that provider's references, the amounts and the status, and never receives card numbers or bank details. Personal data outside that minimum is disclosed rather than implied away: an audit event records the IP address the action came from; session and trusted-browser records, the consent record of a sign-up and the security audit events also hold the browser's user agent; and the payment provider's confirmation message is stored verbatim for up to ninety days, so whatever billing contact details that provider includes in it are held for that period.

• Payment callback bodies erased after 90 days

  In place

  The raw confirmation message the payment provider sends for each transaction is erased ninety days after it arrives, by a daily sweep. The payment record itself is kept afterwards as an accounting record, as tax and accounting law requires.

• Ingest bookkeeping expires automatically

  In place

  The internal bookkeeping that makes advertising data ingestion safe to repeat expires on its own. The duplicate-detection ledger is kept fifteen days, and records set aside as unprocessable are kept ninety days so a problem can be investigated and re-ingested. A daily sweep clears both.

• Disconnect withdraws the account and stops collection

  In place

  Disconnecting an Amazon Advertising account withdraws it from the product at once. Selltics asks Amazon to archive the subscriptions that deliver new advertising events, marks the connection revoked in Selltics, and signals the collector to tear the delivery down. The account, its advertising profiles and its recorded actions are removed from every view in the product, which also stops the charges tied to them; a profile that also has an Amazon Selling Partner marketplace stays, keeps only that source and keeps its charge. The teardown on Amazon's side is best-effort: where Amazon cannot be reached at that moment the disconnect still completes and the remaining teardown is finished by an operator. Disconnecting in Selltics does not revoke the authorisation at Amazon itself; a seller who wants the grant invalidated revokes it in their own Amazon account. Deleting a single profile stops its collection, while the other profiles of its advertiser account are still collected. When the last activated profile of an advertiser account goes, through a profile deletion or a disconnect, Selltics stops keeping that account's records at its next ingest run, and the archived records of the account's profiles that were never activated are deleted seven days later, unless a profile of the account is activated again before then. This is a withdrawal of the connection, not a deletion of the advertising history already collected for activated profiles: that history is kept indefinitely and is deleted only on a written request, within thirty days of it.

• Advertising history kept indefinitely, deleted on written request within 30 days

  In place

  Selltics keeps a seller's Amazon advertising history indefinitely and deletes it only on that seller's written request, within thirty days of the request. The performance history is compressed once it is older than thirty days and is never expired or thinned, and the catalogue and configuration history is append-only, so superseded versions are kept alongside the current one. The raw event archive is grouped per advertiser and marketplace, and nothing expires a seller's records in it. Its performance part is grouped per advertiser account and profile: while an advertiser account has at least one activated profile, it holds every profile of that account, and the records of activated profiles are kept the same way. The records of the account's profiles that were never activated are the one exception: they are deleted seven days after the account's last activated profile is deleted, and that deletion is cancelled when a profile of the account is activated again before the seven days end. For that seven-day deletion, a profile that was activated at any time counts as activated, except one activated and deleted again before the collector first saw it activated and whose activation notice was also lost; its records are treated as never activated. Apart from that exception, disconnecting an advertising account or deleting a profile does not delete any of that history. A written request is recorded by Selltics against the profile it concerns, including a profile deleted earlier, and the profile is withdrawn from the product. A deletion job, tracked step by step, then removes that profile's rows from every advertising table of the time-series store, compressed history included, together with its ingest bookkeeping, and recalculates the daily summaries those rows fed. Once delivery for the profile has stopped, the job deletes the profile's part of the raw archive, in both its per-advertiser grouping and its per-account grouping, and repeats that a day later to catch deliveries that arrived late; the archive keeps no earlier versions of an object, so a deleted object leaves no copy in it. When the request removes the last activated profile of an advertiser account, a second job also deletes the archived records of that account's profiles that were never activated, and keeps those of every profile of the account the organization ever activated; the other activated profiles of the account keep their data. Never-activated profiles have no rows in the time-series store, so that job touches only the archive. A rebuild of the time-series store from the archive skips every profile with a deletion job, and after a restore from a database dump the deletions made since that dump was taken can be run again. Each job keeps a record of what it deleted and when, and a job still open seven days after its request is logged as overdue on every check, unless both of its archive passes have run without an error and it is only waiting for a temporary delivery copy to expire; as the register of absences states, nothing routes such a line to a person automatically. Four things are outside the job. Archive records that carry no advertiser or marketplace, and records the archive failed to deliver, mix every seller and cannot be deleted per seller; they expire after twenty-one days instead, and an hourly check logs any new one as an error. Copies already in the scheduled database dumps are not edited; they leave as the dumps rotate, after twenty-eight days for the time-series store, a window the backup control describes as a target rather than a guarantee. Raw records archived before the per-advertiser grouping existed sit in an earlier layout that mixes every seller and receives nothing new; Selltics is deleting that layout in full rather than sorting it, and a per-seller deletion does not reach whatever of it remains. The advertising figures the AI assistant was shown are not part of the job either; its run records are deleted thirty days after the conversation in any case.

• Documented deletion procedure

  Planned

  Selltics accepts deletion requests in writing, by email. A request to delete a profile's advertising history starts the tracked deletion job described among these controls; when it removes the last activated profile of an advertiser account, it also covers the archived records of that account's profiles that were never activated. No request names an advertiser account on its own, and any other deletion request, such as one for a user account or an organization, is honoured by hand. Neither path is yet a written procedure: the intake of requests is not documented or measured, and no written confirmation naming what was removed is issued as part of it. The product offers no button that deletes an account or an organization, and no self-service export produces a complete copy of an account's data. A documented deletion procedure and a published retention and deletion policy are filed work. Neither exists today.

• No analytics or advertising trackers

  In place

  Neither the product interfaces nor the public websites load an analytics tool, a tag manager, a session-recording tool, an advertising pixel or a consent-management vendor. No third party is told which pages a customer visits or what they do inside the product. Anyone can confirm this by viewing the page source. The only third-party browser scripts anywhere are the payment checkout script, the bot-challenge widget and the documentation site's font request, each listed in the subprocessor register.

• Account and security email only; no marketing platform, CRM or support desk

  In place

  The platform sends account and security email through Cloudflare Email Service, which is named in the subprocessor register, and no other email to customers: confirmation of an email address, a notice that someone tried to register with an address that already has an account, a password-reset link or, for an account that signs in only with Google, a notice that it has no password to reset, a notice that a password was changed, a notice that sign-in was paused after repeated failed attempts, a notice that Google sign-in was linked, notices that two-factor authentication was turned on, turned off, moved to a new authenticator or reset by support, and notices that a recovery code was used or the recovery codes were regenerated. Each goes to the account's own address, and the verification and reset links in them are single-use and expire, a reset link after thirty minutes. Selltics uses no marketing email platform, no CRM and no support-desk product. The platform keeps a delivery log of those messages for thirty days: which message, when, and whether the provider accepted it, with the recipient only as a masked address and a one-way hash, never the message body. The public support page is a second path: its form hands what a visitor wrote to the mail provider over an authenticated, encrypted connection, addressed to Selltics' own published mailbox. The address the sender typed and the text they wrote therefore reach that provider, which is named in the subprocessor register. Nothing goes back to the sender automatically; any reply is written by the operator by hand, from that mailbox.

• No third-party monitoring or error tracking

  In place

  Application logs, metrics, traces and crash reports are collected by software Selltics runs itself. No monitoring service, error-tracking service, log-analytics service or performance-monitoring agent receives them, so no third party holds a copy of what the platform logs about a customer's activity.

Not claimed in this domainNo high availability, disaster recovery or tested restore

• Scheduled backups of every database

  In progress

  Every database is dumped on a schedule, nightly for the transactional stores and weekly for the larger time-series store, and each dump is written to storage that survives the workload being deleted or restarted. The retention side is not finished. Old copies are pruned only after that database has dumped successfully, and a dump interrupted part-way leaves a partial file the prune does not match, so the rotation window is a target the schedule usually meets rather than a bound Selltics is willing to guarantee. Making the prune unconditional is filed work.

• Independent availability checks

  In progress

  The entry points listed on the public status page are checked once a minute by a checker that runs on Cloudflare Workers, outside the product platform, so it keeps answering when the product platform does not. Each check records success, failure and response time, and ninety days of daily history are published alongside any incident or maintenance notice. Two limits are stated rather than implied: the checked set is a configured list and does not cover every customer-facing surface Selltics operates, and a component the checker cannot reach from the public internet is never reported healthy: it is either left off the list or shown as not monitored. A green status page means the listed components answered. The checks publish; they page nobody.

  Selltics Status

• 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.