Security and data handling.

Scope of this page

A2Z Supply Chain runs supply chain and marketplace operations inside systems our clients already own: their selling accounts, their warehouse portals, their supplier correspondence. That work needs standing access, so this page sets out what we are given access to, what we do with it, how it is protected, and what happens when an engagement ends.

This is separate from our privacy policy, which covers personal data collected from visitors to this website. This page covers client and selling-partner data. The controlling entity for both is Ecom Store LLC, 30 N Gould St, STE 28154, Sheridan, WY 82801, US.

What we are given access to

Access is always delegated by the client and always scoped to the work. In a typical engagement that means:

• A named user on the client's selling account, holding only the permissions the agreed scope requires. For our marketplace operations work that is inventory, inbound shipments, shipping settings, and case management.
• A named user on the client's warehouse or 3PL portal, for inbound scheduling, receiving confirmation, and invoice reconciliation.
• Sales, inventory, and purchase-order exports used to build forecasts and buy plans.
• Supplier correspondence, where we are asked to run purchase orders and production follow-up.

Retention and deletion

We do not retain personally identifiable information. Operational records that we do hold, SKU-level sales history, inventory positions, purchase orders, shipment plans, and invoice reconciliations, are kept only while they are needed to run the engagement.

When an engagement ends, our access is revoked by the client and by us, the operator accounts are closed, and the operational records we hold are deleted. A client can ask for deletion at any point during an engagement as well, and we confirm in writing once it is done. Requests go to sajjad@a2zsupplychain.com.

Access control

Access is granted per person and per account, never to a team and never to a shared login.

• Every operator has their own credentials. Account credentials are never shared between people, and we never ask a client to send us a password over email or chat.
• An operator is granted access only to the accounts they are assigned to. Being on the team does not grant access to every client.
• Permissions are set to what the work requires and no more. Where a platform offers granular roles, we take the narrowest set that lets the job be done.
• Access is reviewed when someone changes accounts and revoked the same day they leave the company or come off an engagement.
• Access events are logged, so who did what inside an account is answerable after the fact.

Credential management

Passwords for our own systems are subject to a minimum length of twelve characters, are rejected if they appear on a blocklist of common and previously breached passwords, are rejected if they are entirely numeric, and are rejected if they are close to the user's own account details such as their username, email, or name.

Passwords are never stored in plaintext and never stored in a form that can be reversed. They are hashed with PBKDF2 using a per-user salt, at a work factor we review against current guidance. Credentials belonging to a client's own systems are held in a password manager, never in documents, spreadsheets, or ticket threads.

Encryption

• All traffic to and from our systems is served over TLS. Connections are encrypted end to end, including between our edge and our origin, and origin certificates are validated rather than trusted blindly.
• Data is encrypted at rest in our production database and in backups.
• Exports and reports shared with clients go through the client's own systems or a link that expires, not as unprotected attachments to a public mailbox.

Network protection

Our production infrastructure runs on managed cloud hosting. A host-based firewall enforces default-deny on inbound traffic, with explicit allow rules for only the ports the service needs. Public web traffic is proxied through a provider that gives us denial-of-service mitigation, web application firewall filtering, and TLS termination in front of the origin. Administrative interfaces are not exposed to the open internet.

Monitoring and logging

We keep security and application logs so that unusual events, repeated failed authentication, access from an unexpected location, an action outside an operator's normal scope, can be identified and investigated. Logs are retained separately from the systems that produce them.

Incident response

We maintain a written incident response plan covering monitoring, detection, containment, assessment, notification, and recovery. It is the plan we follow for unauthorized access, credential compromise, and any suspected exposure of client data, and it is reviewed at least every six months. Our incident management point of contact is the founder, reachable at sajjad@a2zsupplychain.com.

• Detect and contain. The affected credentials and sessions are revoked and the affected system is isolated before anything else happens.
• Assess. We establish what was reachable, what was actually accessed, and which clients are affected, using the logs described above.
• Notify. Affected clients are told what happened, what data was involved, and what we are doing about it. Where a security incident involves Amazon Information, we report it to Amazon at security@amazon.com within 24 hours of detection, and continue to update as the investigation develops.
• Recover and review. Service is restored from known-good state, and the incident is written up with the change that prevents a repeat.

If you believe you have found a security issue affecting A2Z Supply Chain, email sajjad@a2zsupplychain.com with “Security” in the subject line. We acknowledge reports and will tell you what we did about it.

What we never do with your data

• We do not sell client data, and we do not share it with third parties for their own purposes.
• We do not share one client's data with another, individually or combined. Nothing you tell us becomes a benchmark someone else sees.
• We do not collect marketplace customer, product, or business information from sources outside the marketplace itself in order to enrich what we hold.
• We do not use client operational data to train models sold to anyone else. Forecasting runs on your history, for you.

Subcontractors

The work is done by our own employed operators. We do not subcontract account operations to third-party agencies or freelancers, and no outside party is given access to a client account. The only third parties involved are the infrastructure providers that host and protect our systems, which do not access client data in the course of that service.

Records and data subject requests

We keep a documented data handling policy and a record of the processing we carry out on a client's behalf, so that a client asked to answer a data subject request can get a straight answer from us rather than a search. Where a client needs to action a request to access, correct, or erase personal data, we assist within the timeframe the client is working to, and we confirm in writing what we did.

Where we hold delegated access to a marketplace account, we operate under that marketplace's data protection policy in addition to the controls on this page. Nothing here authorizes us to speak for a marketplace or to notify a regulator on its behalf; that remains theirs.

Organizational change

Where we hold delegated access under a platform's data protection policy, we notify that platform of relevant organizational changes, including changes of ownership, control, or the arrangements described on this page, within 30 days.

Questions

Anything on this page, including a request for the underlying policy documents before you sign, goes to sajjad@a2zsupplychain.com. If we change how any of this works, the date at the top of this page changes with it.