Security — Luxury Resale Marketplace

Your data

Where your data lives, who can see it, and how it leaves when you ask. Photos and documents are kept apart on purpose.

The path of your data. Locks are drawn only where the documentation sets one.

Solid line: doneDashed line: planned

Where it lives

Planned

Your data is kept in the European Union, in Frankfurt, because the client and its buyers are in the EU.
Planned

This marketplace has its own installation. It is not shared with other companies.
Planned

The partners that handle your data (sign-in, payment, shipping, email) are chosen with EU data handling as one of the criteria. No list of partners is published yet.

Who can see it

Planned

Photos have their hidden location and camera details removed before anyone else can see them.
Planned

Identity checks, inspection evidence and certificates sit in a private store. They open only through links that stop working after a short time. Public product photos are served separately.
Planned

A hub inspector sees only the items at their own hub, their evidence, and the address for the next leg while it is needed. Never payment data.
Planned

Staff see only what their role needs, and every change they make is on record (part 5).
Planned

Messages between buyer and seller are checked for contact details on our side before they are delivered.
Done

Passwords are never stored or logged in readable form. Personal details stay out of the logs; an email appears there only as a scrambled fingerprint.
Planned

Card details are entered in the payment provider’s own payment form. Whether card numbers can never reach our servers is still to be confirmed.

Yours to take or delete

Planned

You can ask for a copy of your data and for it to be deleted. Each part of the product removes or anonymises its own part, and an administrator reviews the request.
Planned

You can close your own account, in the app too. It is refused while an order, case or payout is open, and an export is offered first.
Done

Deleting an account wipes the sign-in data, frees the email and ends every session at once. It asks for the password first.
Planned

You give or withdraw consent yourself, and cookies that are not essential run only after you consent.

On the way and at rest

Done

The browser is made to use a secure connection.
To be discussed

Encryption along the whole path is not stated yet, so this page does not say “encrypted on the way”.
To be discussed

Encryption of stored data is to be discussed until a decision states it.
To be discussed

What is kept after a deletion request (orders, payments and cases that must be kept), and for how long, is open.
To be discussed

Who in the operating team can reach production data, and when, is not documented yet.

Who gets in

Who can sign in, what each kind of person can reach, and how sign-in keeps strangers out.

Who reaches what, in the planned full set of roles. The first version of the server has two roles.

Accounts and roles

Planned

Five kinds of people have different reach: visitor, buyer, seller, hub inspector and administrator. The administrator is one role for now; that may change.
Done

No one becomes an administrator by registering. Public sign-up makes an ordinary account only.
Planned

Staff accounts are made by invitation from an administrator. The first administrator is set up once, at installation, and named by the client.
Planned

You see and change only your own orders, listings and profile. A request for someone else’s record is refused without saying whether it exists.
Done

Every action is checked, and anything not explicitly opened stays closed. A role taken away stops working on the very next action.

Passwords

Done

Passwords are stored scrambled, differently for each one, apart from the rest of the account.
Done

A new password is refused if it appears in known leaks. The check never sends the password anywhere, and if the check service is down, sign-up carries on.
Done

A wrong email and a wrong password get the same answer in the same time, so nobody can find out who has an account. Sign-up telling you an email is taken is a known, accepted exception.
Done

Changing your password or deleting your account asks for the current password. Changing it signs out every device.
Done

A forgotten password is reset through a link that works once and only for a short time. It signs out every device.
Done

Your email address is confirmed by a link.
Planned

Until it is confirmed you can browse, but not buy, sell, make offers or send messages.

Staff and the second step

Planned

Staff sign in with a second step, a code from an authenticator app, set up at first sign-in. Another administrator resets a lost one, with a reason on record.
Planned

The back office has its own address, is not linked from the public site, and can be limited to chosen networks (optional).
To be discussed

Buyers and sellers have no second step. It is for staff only.
To be discussed

Single sign-on, one company login for a whole team, is to be discussed. Everyone signs in with email and password.

Devices and letters that warn

Done

You can see where you are signed in and end one device without touching the others. If a stolen sign-in key is used again, that device’s session ends.
To be discussed

Signing out everywhere as its own action is to be discussed. Changing the password does it.
Done

The first version already writes the letters that warn you: repeated failed sign-ins on your account, a sign-in key reused, too many email requests, a password changed after a reset. They are sent for real once the email provider is connected.
Planned

Security, order, payment and case letters cannot be switched off.
To be discussed

The email templates show confirm your email, choose a new password and welcome. A “password changed” or “unusual sign-in” letter is not drawn yet.

Nothing is lost

What happens when something outside fails, why an item is never sold twice, and what is kept once it has been reported. Backups are still to be discussed.

When a partner fails halfway: your step waits, is retried, and is then handed to a person.

When something fails

Planned

If a partner (payment, sign-in, shipping, email) fails, your step is shown as waiting and tried again. When the tries run out, it goes to an administrator’s queue.
Planned

A change and the message about it are saved together, so a failed outside call does not lose the event.
Planned

In production the database has a standby copy at a second site in the same region, so one failing site does not stop it.

What is never lost or rewritten

Planned

An item cannot be sold twice. It is held for one buyer at a time, and an abandoned checkout lets it go.
Planned

Orders, payments and decisions are never deleted. A record that must change leaves its history.
Planned

The photos and details of a listing cannot be edited while it is being authenticated.
Planned

A rating cannot be edited after it is given.
Planned

A wrongly recorded inspection result can be corrected, and the correction is on record.
Planned

A sale can be undone through a return or a refund, and the refund is never above what was charged.

To be discussed

To be discussed

Backups, and how far back they reach, are to be discussed: no policy is set yet.
To be discussed

Restoring from a backup, and how long it takes, are to be discussed.
To be discussed

Earlier versions of uploaded files are to be discussed.
To be discussed

An availability percentage, round-the-clock support and a second region are to be discussed.

Against attacks

Several layers stand between the internet and your data. A request must pass each one, and each layer is marked as it stands today.

One request passing through the layers, and what each one stops.

Solid line: doneDashed line: planned

Guessing and floods

Done

Repeated wrong passwords slow an account down, whoever is guessing and from wherever. The owner is told.
Done

A flood of requests from one place is cut off at once, with a stricter limit on the sign-in pages.
Planned

The limits hold across several servers, not only one.
Planned

A shield in front of the whole product filters known attack traffic and absorbs floods.

What is sent in

Done

Everything sent in is checked for shape and size. Unexpected fields are dropped, attempts to slip commands into the database are stopped, and oversized requests are refused.
Planned

Messages from partners are accepted only if proven to come from them, and each is handled once even if it is repeated.
Planned

Photos are processed again on the server.
To be discussed

Which file types and sizes are accepted, and whether files are scanned for harmful content, is still to be discussed.
Planned

Browsers on the website and the back office never hold your sign-in keys. The app keeps them in the phone’s protected storage.

Kept hard to break

Done

Standard protective settings in the browser, a strict list of sites allowed to talk to the product, and a content policy in production. The website and back office get their own content policy too, which is planned.
Done

Errors never show internals.
Done

Known weaknesses in the software the product is built on are checked on every change, and a serious one blocks the release.
Planned

That software is updated automatically. This is a backlog item.
To be discussed

Keeping servers, base images and the platform patched is still to be discussed.
Done

The system’s own keys and passwords are never in the code and must be long, and the system refuses to start without them.
Planned

In production those secrets live in a dedicated vault.

Watching

Done

Every security-relevant action is recorded as it happens, and suspicious ones are flagged for alerting.
Planned

Alerts on spikes of suspicious events. This is a backlog item that needs log collection first.
To be discussed

Who watches round the clock, and what happens when something is found, is to be discussed. No round-the-clock watch is assumed.

Every change on record

When something goes wrong, or is disputed, the record shows who did what, when and why. It is planned as a record that is written once.

One entry of the record, laid open. The fields are shown, with no real values.

What is recorded

Planned

Every change an administrator makes to a record, in any part of the product, is written down with who, when, why and which record.
Planned

Staff sign-ins, failed sign-ins and access changes are recorded.
Planned

Entries are written once and never changed afterwards. This is the rule; how it is enforced is not set yet.
Planned

An administrator can search the record by person, time, reason and record.
Planned

Changes to marketplace settings keep who made them, when, and the previous value.
Planned

Orders, payments, payouts, case decisions and listing moderation are recorded, so a dispute can be traced.
Planned

Every decision in a staff queue carries a reason, who took it, and who reassigned it.
Done

Customers’ sign-ins and security events are logged with a request reference, personal details hidden. These are logs, not the unchangeable record above.
Planned

A figure in a report can be traced as far as the orders and payments it is built from, with currencies kept apart. A click-through trace is not specified.

To be discussed

To be discussed

An outside auditor reading the record directly is to be discussed. There is no auditor role; an administrator reads it.
To be discussed

How long the record is kept is to be discussed.

In place, planned, to be discussed

The honest list: what is held, what is planned, and what is to be discussed, with whom to ask. No certification is claimed that was not obtained, and no figure is given that nobody has set.

What	Status	In plain words	Whom to ask
Protections already built and tested	Done	In the first version of the server: sign-in, passwords, the device list, the check against leaked passwords, the pause after wrong passwords, and checks on everything sent in. They are being carried onto the production database and will be checked again after the move.	—
Second step for staff	Planned	Decided, and still to be built.	—
Penetration test before launch	Planned	An outside tester tries to break in, with the web application security standard (OWASP ASVS, level 2) as the yardstick. Not run yet.	—
Who tests, how wide, and whether the report is shared	To be discussed	Who tests, how wide, how findings are fixed and whether the report is shared are open.	The client
The EU privacy law (GDPR)	Planned	The law applies and the design follows it: EU hosting, export and deletion, no personal data in logs.	—
A privacy-compliance sign-off	To be discussed	No statement that the product is certified or signed off as privacy-compliant. Delivered code is not a compliance sign-off, and who signs off is open.	The client
SOC 2	To be discussed	An independent audit report on how a company protects customer data. Not held, and nothing is planned in the documentation.	The client
ISO 27001	To be discussed	An international certificate for how an organisation manages information security. Not held, and nothing is planned in the documentation.	The client
Card-industry certification of the product	To be discussed	Not documented. Card payment is handled by the payment provider.	Open
Backups, restore, encryption	To be discussed	Backups and how long a restore takes, and encryption on the whole path and at rest, are not stated yet.	The delivery team
What is kept after deletion, and for how long	To be discussed	Open, and no period is published before it is set.	The client, with counsel
Who can reach production data	To be discussed	No access policy is documented yet.	The delivery team
Round-the-clock support, availability figure, second region	To be discussed	To be discussed.	Open
A security contact and a way to report a weakness	To be discussed	Neither is defined yet. The client is to name a contact and a procedure before launch, and this page will then show them.	The client